Forum Replies Created
OK, the update to 7.7.1 on my “bad” SM200C seems to have fixed the issue. Thanks for the feedback.
It doesn’t recover even after that first acquisition.
Here is an additional piece of information I just discovered, my two two SM200C are actually acting differently. The one that I referenced above was running firmware v3.3.1. The other one I have (which I just discovered isn’t showing the uncal issue) is running v5.5.3. Maybe that has something to do with it…
I am going to try to update the firmware on them both, but first I need to get a hold of a windows machine since it doesn’t look like you have a linux firmware updater tool.
OK, makes sense on the sweeptime. Thank you.
Maybe it is an issue with my custom RX software, but when I get the uncal data error, I get pretty much garbage samples, so I can’t use it. My problem is that by the time a user has hit go to start receiving samples, the SH has been setup and they think that everything is good, yet I don’t know that I will have a problem until I try to do the very first receive. I am thinking that I might have to figure out some bounds that I don’t let a user work outside of so they don’t get into this state.
I see the confusion. I am working in Linux, it doesn’t look like you offer both 32-bit AND 64-bit. I think you only offer a 64-bit version, right?
libsm_api.so.2.1.17: ELF 64-bit LSB shared object
OK, I think I see my issue. When I initialized my device, I was setting the vbw to be what the rbw was. I then changed the rbw and kicked things off. The vbw wasn’t getting updated, so when I set the SweepCoupling to use the new rbw (200kHz now), but had the old vbw (100kHz), it caused the allocation error.
Dumb question, How do I know if I am using the 32b API or not? I haven’t seen this distinction anywhere.
OK, I will go with Nuttall for now until someone on our end complains to me about it. Is the Nuttall window the one that caps out with a minimum of 30kHz for RBW (it wasn’t clear to me in the API document)?
Thank you for the quick response. We were only going to give the user options for start/stop frequency, rbw, and period. Based on that, I think the best thing to do is to follow your recommendation and leave the speed as “auto” and let the user’s parameters drive the speed.
Do you have a recommendation for a safe window type since I am not going to give the user the ability to set it? I see you use flat-top in your example sweep app, but Nuttall in your thz sweep (btw, you spelled Nuttal with only a single ‘t’ in the API). I am leaning towards Nuttal, but I figured I would double check.
This seem like a reasonable set of API calls?
smSetSweepStartStop(this_device, this_startFrequency, this_stopFrequency);
smSetSweepCoupling(this_device, this_rbw, this_rbw, this_period);
smSetSweepDetector(this_device, smDetectorAverage, smVideoPower);
shStatus = smConfigure(this_device, smModeSweeping);
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 and Justin, thank you for the quick responses. The software guys working on this piece of code realized they had numerous issues that needed to be addressed, so they are fixing those before we bug you further. If that doesn’t seem to help, I will certainly email you with the details. Thanks folks!
Thank you for the sanity check. Tossing a 50ohm load on the antenna port shows a spectrum like one would expect (the lower band is much quieter and is just some noise like the rest of the spectrum).
I do want to investigate the pre-selector option you mention though, as I can still see an increased noise floor from DC to ~640MHz (maybe ~5dB).