USB Protocol Queries

[ozonejunkieau]

This project looks great, I'm really keen to try it out. I want to put together a Python interface that enables a few more features than ASCOM directly supports, and have a few comments/questions about the HID protocol:

• Great to see embedding the commit ID in the protocol, that makes things so much easier in the future in my experience!
• Are you contemplating adding in a release version query to the command set too? Can sometimes be good to be able to display to a user a x.y release version in addition to commit message, just for understanding feature parity for example.
• It's not documented but I assume the GUID is a unique id for any individual given board? From looking at the code it looks like part of this is returned as the USB serial number?
• Can you please clarify that the VID and PID values are decimal, in most documentation they are reported in hexadecimal? They would also generally be two bytes in length, is the upper byte zero?
• For the command bits, is the toggle used as a toggle bit or a set bit? Ie. for bit 7 - if this value is 1, does this toggle whatever the current state of the Home Towards Max bit is currently set to? Is there a reason that toggling configuration is preferred instead of just using a set bit? It seems like bit 6 and 7 could easily be a single bit of "home direction"? I'm just trying to understand for implementing client side.
• Thanks for including all the driver status flags in the responses, always nice to have the maximum amount of info available for tuning motors.

Looking forward to having a play with one of these.

[AlistairSymonds]

A lot of the weird toggle/write enable command bits are a hold over from how I originally did the USB data - I figured I could send everything all the time at once and never have to worry about any selective reading/writing and the host would have all the data all the time.

Alas this became more and more of a pain in terms of keeping stuff in sync when wanting to modify one field and not others. Eg setting the current position to zero manually would then result in a move to the existing set position. So lots of the toggle/set command bits are a hold over from that.

Here's an older version of what I started with: https://github.com/AlistairSymonds/SympleAstroFocus/blob/1319b463652e7280eeb5c11386e1a01c3b04bba9/docs/usb_protocol.md

The GUID is a 96bit stm32 specific id each chip has - similar to the other info in those top addresses I just figured it's best to have more info rather than less :)

For maintaining an actual version I was planning have basically a git commit -> release version LUT, but haven't implemented that yet so there may be issues with the plan.

The current ascom driver I think is pretty readable in terms of an MVP baseline.

https://github.com/AlistairSymonds/SympleAstroFocus/blob/main/ASCOM/ASCOM/Driver.cs

(and thanks for the pointer about hex vs decimal, they're decimal in this case - bites in the ass all the time at work too, the vid and pid were chosen arbitrarily, since I don't think I'll be stumping up the 5k for USB certification anytime soon these seem like as good as any other free ids?)

[AlistairSymonds]

And regarding INDI/linux I've started putting something together under: https://github.com/AlistairSymonds/SympleAstroFocus/tree/main/driver

It's obviously very barebones and needs to be run as sudo or have your udev rules updates on linux, but it will make a little short program that will connect over USB on both linux and windows. I'm going to get this figured out as a cross platform core then have the INDI driver and rewrite the ASCOM driver to use it to handle the USB connection etc.

Commands to build it for now, you'll need to copy the generated .so or .dlls to the same folder as the executable manually for now.

cd driver
mkdir build
cd build
cmake ..
cmake --build .