Yes, you're right, the manual needs more work - but it is an 'Interim' manual. The Trackgen system was initially implemented with just the AD9850 and AD9851 in mind. The interface was kept as simple as possible as I was more interested in getting a result to work with, than I was with a robust comms protocol. Apart from an initial connection problem, the comms link seems to be reliable.
is the interface expected to echo/not echo the commands sent to it?
No, the firmware echoes neither individual characters or complete commands. There is no acknowledgement of a received command.
what does the interface do if it gets back '\r\n' (in whatever order) rather than just '\n' (as per the manual) for return strings?
The analyser sends a string to the firmware followed by the default Windows NewLIne character which is LF - ASCII 10
The analyser reads a string from the firmware up to the default NewLIne character. I then use string.Trim() to trim any non-text chars from the end of the string. That will take care of receiving '\r\n' or '\n\r'.
The firmware sends a string to the analyser followed by '\r\n'
The firmware reads a string from the analyser up to the '\n' character - '\n' is discarded by the Arduino comms library.
for the majority of commands (i.e. commands other than those with an explicit return string - GETPINS etc.) is a command acknowledgement expected/required and if so what?
In other words, what error checking/correction protocol is there to make sure a command has been correctly received and acted upon?
No - There is no acknowledgement of a received command. There is no error checking or any form of ACK/NAK-type handshaking.
when a string is returned (e.g. from GETPINS) is the string case sensitive?
Not sure what you mean here. GETPINS returns a string from the firmware, case sensitivty should not be an issue here. Am I missing something ? All command strings sent from the analyser to the firmware are case-insensitive. You can use upper or lower case, or a mixture of both if you wish.
for the return string from GETPPMTRIM, is there a prefix before the number?
No - The command just returns the PPM value set as an ASCII string.
for GETDDSTYPE, the manual shows numbers for 2 DDS devices; are there other numbers defined?
And if not, is there a central registry to have numbers allocated/reserved?
No, there are no other numbers defined. As mention, the initial design was to just support the AD9850 and AD9851. I'm also going to be adding support for the AD9910. It's possible in the future that support for other generators will be included. I think in such a case that I'd probably use the chip's name instead of an ID number. You may have read in another thread on the subject that the analyser does not allow frequencies higher than the DDS maximum output to be sent to the Trackgen module. I've already changed the analyser code to allow for higher frequency devices such as the AD9910. I'd suggest you use '3' for the time being and I'll do likewise in my code, but at some time in the future you might have to change your code to use ID strings instead of numbers.
Is it safe to assume that no other command, other than those defined, will be sent to the TrackGen (equivalent) code?
If not then is there an 'unknown command' style return string?
No - there are no undocumented commands. The Trackgen firmware will ignore an unknown command.
I hope I've covered your queries, if you need any further information, let me know.
The whole Trackgen system is very fluid at the moment. The feedback received seems to indicate that the system may be more popular that I thought it would be. Currently there is no feedback from the firmware to the analyser to let the analyser know what the current DDS frequency is during a sweep. This, and other options need to be thought about. Once the debugging is finished (almost done now) I'll turn my attention to the whole Trackgen system.