TrackGen interaction details

Information and discussions on Spectrum Analysis
Post Reply
AussieSusan
Posts: 30
Joined: Wed Aug 16, 2017 6:50 am

TrackGen interaction details

Post by AussieSusan » Mon Apr 29, 2019 3:21 am

I am using an STM32L4 device to control my AD9910 which means I'm writing my own version of the TrackGen code. The manual provides me with the command set and the 115200 8N1 specs for the communication but it does leave silent a couple of points:

- is the interface expected to echo/not echo the commands sent to it?
I would assume no echo but it is worth the question. Also if an echo is expected, is it on a character-by-character basis (I would assume so)?
- 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?
- 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?
- when a string is returned (e.g. from GETPINS) is the string case sensitive?
- for the return string from GETPPMTRIM, is there a prefix before the number?
- 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?
- 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?

Thanks

Susan

Reason: No reason

SteveAndrew
Posts: 213
Joined: Thu Nov 16, 2017 11:06 pm
Location: Gold Coast, QLD, Australia

Re: TrackGen interaction details

Post by SteveAndrew » Tue Apr 30, 2019 10:10 am

Hi Susan

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.

Steve

Reason: No reason

AussieSusan
Posts: 30
Joined: Wed Aug 16, 2017 6:50 am

Re: TrackGen interaction details

Post by AussieSusan » Wed May 01, 2019 2:41 am

Thanks for the comprehensive response Steve.
Susan

Reason: No reason

SteveAndrew
Posts: 213
Joined: Thu Nov 16, 2017 11:06 pm
Location: Gold Coast, QLD, Australia

Re: TrackGen interaction details

Post by SteveAndrew » Wed May 01, 2019 7:09 am

Hi Susan

You're welcome. I'll be interested to see what you make of the AD9910. It's on my list, but not right now - to much of a distraction until I get the beta version ready.

I was just looking through some code and spotted an error in the information I gave you. The response from the firmware to the analyser in response to a "GETPPMTRIM" command is "PPMTRIM=123" for example, and not as I stated, a numeric string without any prefix. :oops:

Steve

Reason: No reason

Post Reply