Nope. We ended up pitching it.

I tried on both my Windows box and my Linux box, and there was no “List devices” button within the “SM200C Network Configuration” window.

Attached is all that shows up.

Attachments:

You must be logged in to view attached files.

Some good suggestions there, and some things that I had tried (after my original post).

I have a second SM200C and I swapped SFPs and power supplies, so I’ve ruled out those issues. I also used that second SH at my desk and had no issues with it on my current network card and fiber cables, so I don’t think that that is a problem.

When I start a connection with Spike, I see it blink red once, and then about 10 seconds later blink red once again (otherwise it is always green).

I tried to use the USB connection but get “Configuration failed, device not found”. I am on a Linux machine though, and I know that sometimes your stuff prefers Windows.

I appreciate it Andrew, but as expected, it was my fault. I won’t bore you with the details, but the way that the software was written (which was before my time), the vector of pointers to our sub-class of radios wasn’t getting freed properly. So even though the app was closing, none of our destructors were getting called, and it was keeping certain things running that we were only doing with the SH when in IQ streaming mode. Once I caught that and re-worked it, all seems good again.

So thank you for your help.

Thank you for the info Andrew, those are definitely the sort of tips I was looking for. It does smell like the process isn’t getting closed properly, but I don’t see any leftover processes tied to this app running (I am in Ubuntu), and the light is a solid green on the unit when I exit.

That is interesting that two different processes can interface at the same time. I assumed that if I could get a handle, it meant that no one else was currently using that device. I’ll have to keep that in mind while debugging.

I am not getting any errors while I am getting my data, so I think that the SH at least thinks that it is operating as it should.

I just keep coming back to the fact that it works until I switch modes; always when going from iq stream to freq sweep, so it must be the way I am cleaning up when done with IQ stream (though I am not sure why a hard reboot of the unit would fix that).

I’ve tried playing with the smPreset option, but I have never gotten it to work without having to do a power cycle on the unit. I always get smDeviceNotFoundErr (-2) after the blocking is done (which is about 15s).

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.

[jmatusiak]

(deleted)

• This reply was modified 2 years, 5 months ago by jmatusiak.
• This reply was modified 2 years, 5 months ago by jmatusiak.

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?

smSetSweepSpeed(this_device, smSweepSpeedAuto);
smSetSweepStartStop(this_device, this_startFrequency, this_stopFrequency);
smSetSweepCoupling(this_device, this_rbw, this_rbw, this_period);
smSetSweepDetector(this_device, smDetectorAverage, smVideoPower);
smSetSweepScale(this_device, smScaleLog);
smSetSweepWindow(this_device, smWindowNutall);
smSetSweepSpurReject(this_device, smFalse);
smSetAttenuator(this_device, -1/*auto*/);
smSetPreselector(this_device, smFalse);
smSetReference(this_device, smReferenceUseExternal);
shStatus = smConfigure(this_device, smModeSweeping);

Thanks again

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).

Thanks

[Author]

Posts