jmatusiak February 7, 2022 at 9:27 am
- This topic was modified 1 year, 7 months ago by jmatusiak.
I was wondering if there are any timing examples for working with the SM200C. We use a lot of Ettus USRP radios and for timing purposes feed (matching length) 10MHz and 1PPS to them, and then we can set the unit’s time “on the next PPS edge.”
We would like to start sprinkling in a couple of SM200C into our lab (we already have two) and are trying to decide the best way to get as close as we can to a similar setup.
I know that the SM200C doesn’t operate in the same manner, but I couldn’t find any examples for how to take advantage of the timing that is in the firmware. We would be interested in doing this for both IQ, as well as FFT spectrum scanning.
AndrewModeratorAndrew February 7, 2022 at 9:51 am
If you can run a GPS antenna to the unit, you can get the API to performing timing for you. Enabling the smSetGPSTimebaseUpdate() allows the internal GPS to discipline the timebase of the unit. While the device is open, you can query the state of the lock with the smGetGPSState() function, you can wait for ‘disciplined’. Once disciplined the timestamps you received from the smGetIQ() function are referenced to the GPS. Technically you can get timestamps without the disciplining, but you will see timestamp drift between PPS’s.
If you want to do this manually with an external 10MHz and PPS, tell the instrument to use an ext 10MHz timebase with the smSetReference() function and connect the PPS to the trigger input port (and the 10MHz reference to the 10MHz ref input). Then when streaming I/Q, the PPS events will show up in the trigger output buffer. Its then easy to timestamp samples based on their location relative to the PPS trigger position in the stream. With this method though, you will have to acquire and parse the NMEA data from the GPS to know the absolute time of the PPS event. The advantage of doing this externally is being able to use higher accuracy GPS receivers than our internal one, and running multiple units off of one external GPS which will have better precision for certain tasks.
We have an example for the first method discussed above, but not for the second. We only have a generic ext trigger example which you can view to see how the triggers come in. Hopefully the explanation is enough to piece the rest together. If you have follow up questions as you work through this, please let me know.
Spectrums via the API sweep configuration are timestamped when using the internal GPS, but due to how we process the sweeps, it will be hard to get precise timing on an event in the sweep. It should really only be used as a coarse monotonically increasing timer. The I/Q sweep list functionality in the API allows you to sweep the I/Q acquisition with the same speed as our fast sweeps. Timestamping with the I/Q sweep lists only works with the internal GPS (rather than providing an ext 10M/PPS), but this approach would give you precise timestamped ‘steps’ of I/Q samples. The downside, is that you would have to FFT and construct the sweep if you wanted the classic sweep plot as well.
You can email me directly at firstname.lastname@example.org if needed.
jmatusiakParticipantjmatusiak February 9, 2022 at 11:26 am
Thank you for the information Andrew, that was very thorough and helpful.
There is a chance that we could get GPS to the SHs, but we know for sure that we can route the 10MHz/1PPS (since I already physically have them routed). We are currently using Ettus Octoclocks for our timing distribution, and it is able to keep disciplined time based off of it’s GPS receiver. I may be misunderstanding things, but I think that if I know what the time is at the next PPS edge from the Octoclock (which is feeding the 10MHz/1PPS to the SH), I can internally associate that time with the trigger position the SH reports in the stream. Does that sound correct? Since you think that the GPS on the SM200C’s accuracy could be improved on, is there any value to going the GPS antenna route based on the other options I have available (mentioned above)?
I will email you directly to get a copy of your example app, thank you for the offer.
Andrew February 9, 2022 at 11:43 am
- This reply was modified 1 year, 7 months ago by Andrew.
Yes, it sounds like your understanding is correct. If you know the time of a specific PPS, and you know what I/Q sample it occurs on (information that our API provides), you can extrapolate timing to any sample. The PPS will appear in the I/Q stream each second, so you can continually correct for any drift/error.
The main advantage of using the internal ublox-m8 is convenience. In a multi receiver setup such as yours, what approach you take will likely depend on your timing requirements and/or hardware limitations (i.e. can you run 10M/PPS to every receiver).
The ext trigger example I mentioned can be found in the SDK, in the sm_series/windows/examples/c++ folder. It only shows you how to call the functions, it does not simulate timestamping. Programming specific questions are best directed to me via email, or if you need a more elaborate example.
You must be logged in to reply to this topic.