Forum Replies Created
- Posts
Andrew, thanks for the quick and thorough reply.
I’m going to keep investigating this some more myself to try and understand what’s going on and verify the rest of the system. It just *feels* like a Queued sweep bug since any time I go above 1 (basically queueing at all) it starts to happen. But feelings aren’t fact, so we’ll do what we can to finish narrowing down the issue.
– How are you switching between your sources? Are you using the smSetSweepGPIO function?
— No. We have the SM200’s set to produce a waveform (go low when scanning, transition high when near the end of the sweep) and that transition to high then tells the FPGA to move to the next position.
– If yes to the question above, have you done any monitoring of those GPIO pins?
— We monitor counters in the FPGA for that rising edge, and they always seem to line up…but then again, when you’re doing something at multiple kHz, and there’s only ever an off-by-one bug it would be a needle in a haystack.
We don’t think that we are missing triggers because otherwise it wouldn’t go back! We know if we have a bad trigger line because then what was in slot 10 goes to 9 and then to 8 and then to 7, and so on. But this corrects itself! Which is just odd.
– Any way to verify they are cycling through all your states and not missing one periodically? Whether it’s hardware/software, that would be extremely helpful to know.
— Yea, that is one of our concerns. I don’t know why it would go away when we set the queue to one, unless we were for example missing a trigger and then catching up somehow? But I don’t know how the FPGA would do that since we’re just looking for an edge transition on a pin. One of the avenues we are investigating on our end. But again, it only happens when we queue sweeps…one thought would be that the waveform / time the GPIO is high before the next sweep happens is longer when we’re not queuing, so we “catch” it more regularly…but then again, why would it correct itself!?! It would process moving bins in that instance, I would think.
– Am I to understand that the “sweep offset” sticks around for many cycles? So if you are cycling through all 20 slots, are all 20 slots now off by 1 for some duration until it corrects itself? Or is it just slot 10 that shows up in slot 9 for several seconds until slot 9 reverts?
— Yes, we really have a couple hundred “slots” that we cycle through. And we kind of see the whole thing shift one left, and hold there for a bit and then shift one right, back to the original and desired location. Then it’ll go back and forth doing that. Really odd, honestly.
– Does using just 1 receiver make the problem go away? Even with 16 queued sweeps?
— Our hardware and software architecture is very very intertwined with having two SM200’s working in concert with each other. I think we might be able to hack some places in the code to reduce it down to one signal hound, but only for a little bit before buffers and other things start overflowing and getting too far out of sync elsewhere. Otherwise it’d be a huge effort to get it down to just one.
– Is it always a specific slot, e.g. 9/10? Or random?
— It appears to be all the slots kind of shifting by one. Almost like we started getting scans out of order for a bit or something. It seems more like the problem would be elsewhere. But it is 100% solved when we queue only 1 scan, and is apparent when we go for more than one scan. I honestly haven’t been able to come up with a theory as to why / how the queued/non-queued is at play here. But as far as we can tell, it is.
– Does the “sweep offset” happen on both receivers? Or just one?
— It does happen to both. We are looking into that more this rest of this week. We had an issue preventing us from looking at both and seeing if they do it at the same time, or if it’s a random correlation between the two.
– Let’s say you’re switching through slots 8,9,10,11. Does it now look like 8,10,10,11 for 15 seconds and then go back to 8,9,10,11?
It looks like 1,2,3,4,5,6,7,8,9 goes to 2,3,4,5,6,7,8,? for a while and then back to 1->9 in order. We’re investigating whether the ? is just old data in there, or if it’s 1 from the previous slot. It’s actually fairly hard for us to put energy *only* in one slot with our current setup, but figuring this out I think might provide a lot of insight, and that’s what we are attempting today.
It’s a tough nut to crack, because the entire system is orchestrating this at multiple kHz, and there’s a lot at play here, and we’ve tried a ton of things across all the other components, both hardware and software at play here, and it wasn’t until we only queued 1 sweep up did anything fix it.
With queued sweeps, is there maybe some extra allocation / deallocation (and thus garbage collection or other process) going on under the covers in the driver that’s maybe going on here?
Thanks Justin. I had tried all of those things before posting with no joy. I tried the 12.0 version, the .28 and the .26 version of their drivers, uninstalling, re-installing, etc with no success. Using the CDM uninstaller and more.
It’s a RS-422 chip for the VN-310, and I wonder if there’s something special there or not.
I *swear* that I had all 3 working together about 4-5 weeks ago, and I’m not sure what broke it — a Windows update, or something else, or if I just fooling myself about all 3 working at once. We don’t even need to pull up Spike, just plugging a single SM200B into power, is an immediate stoppage on the VN-310….like right as Windows enumerates the drivers, it goes bye-bye. I’ll be watching data stream in the terminal, and then it will stop and just send NULL and BREAK repeatedly. Unplug the SM200B and instantaneously data starts flowing again.
We bought some converters so that we can try and shove it in a resident serial port on the computer and see if it works that way.
For my own reference/googling/spec sheet hunting, what does the SM200B use for it’s USB chip — is there some serial<->USB conversion or something else going on on the front end?
Thanks!
Looping pins 3 and 11 together did bump the output signal to 3.3V.
It was crazy — I have a system that’s supposed to trigger at 1.4V, and I could see the ~1.6V SH level going into it, and it just wasn’t triggering. If I slowed it down, it would sometimes trigger. Very odd. I hooked up a function generator and exactly matched the SH output signal, and it triggered perfectly!
So, something about the pull down and series resistor or amount of current available to source coupled with my digital IO card was causing more voltage loss inside the card. The bump to 3.3V in solved it all.
So, have you tried a free-field measurement yet (aka not in the chamber)?
Antenna test is intricate. It’s hard to truly say what is or is not the problem here because there can be dozens of things that cause something like this, or it could really just be that.
Just looking at it, given the frequencies you’re talking about, if an engineer came to me asking about this and what to do next. I’d suggest a free-field measurement. In general, my comments would be that you’re testing at a low frequency (250MHz) has a ~4′ wavelength. In order for the fields to enter into the antenna, you’re going to want other things (walls, absorber, etc) at least that far away from it unless you’ve specifically verified the test setup, that you have absorber behind the antenna to prevent reflections, but far enough away to not artificially couple and affect the antenna. There are a lot of things much closer than that at the frequencies your talking about. Also, the chamber could also end up acting more like a resonant cavity than a chamber depending upon size and exact geometry. Again, maybe not a problem, but could be. Also, have you ran S11 on the antennas post install? Are they being detuned, or a reflection coefficient issue created during install? And so on.
The bottom line is that from the pictures, given the issue that you’re seeing, you could spend days/weeks/months tinkering with the test setup and never hit a definitive conclusion on the issue, as there are potentially many, and they could interact in complex ways. So, I’d tell my engineer to check S11 an as-installed items, and check it in various chamber configurations. S11 open-air vs chamber should be the same; if substantially different, something is up.
Then separate out the test chamber from the measurement, and then add pieces back in. Go find some open space somewhere, and just run a real quick simple test. Collect that data, and then start introducing your test setup piece by piece, verifying that you’re good every step as you do so. You’ve already half did that with the test from a certified house, but it’s just hard to truly say you’re replicating or there’s an antenna problem, etc when all we really have with these exact items is a somewhat problematic test chamber setup.
April 26, 2019 at 8:50 pm in reply to: BB60C, EMC measurements:How to lower the noise floor of my setup ?
Yea, I understand where you’re at regarding the noise floor. The thing is that you’re just continually bouncing waves in the chamber, which will build up (you’re in a microwave oven) and increase the noise floor.
Think of the difference in background noise in a small library or church that’s all tile, granite and glass. You can hear everyone doing everything, and there’s a small “din” as all the sound bounces around with nowhere to go. You’re noise floor is higher. Take that same building with the same people, hang some tapestries, put that carpet down and it will be tens of dB quieter and without that “din”. You don’t need to upgrade the whole chamber, but some basic foam like I said can help a lot.
For the LNA, you don’t need anything fancy. I don’t know your frequency range and necessary specs, but we typically would use something like this, maybe even two of them depending upon line loss and the gain budget:
Put it as close to the receiving antenna as you can (right on the connector if possible), so it drives the signal down the cable and into the BB60. This should increase your SNR.
If you’re already near max input power level, the LNA could cause some issues there. You may want to toss a filter in in front of the LNA to knock down whatever else is causing the issue. But some red warning light in my head is going off because what’s being described isn’t totally matching with what I’ve seen in the field. The BB60C should have more than enough dynamic range for nearly any test. If you’re driving it near IF overload, but you’re still having sensitivity problems as evidenced by the attenuator test, then it feels like something else is going on. Have you checked for other interfering signals, zooming way out on the Spec An? Maybe your chamber isn’t as tight as you thought, or there’s some injection leakage. Is your test equipment *outside* the chamber, and just the antennas inside? Is the chamber appropriately sized for your lower frequencies (too small and it will act more like a waveguide)? Or maybe the chamber is just bouncing the signals around too much and you’re getting to much of that echo bouncing around nailing you. Have you tried it outside the chamber with the power tuned down some?
A box of anechoic foam (4 pieces) isn’t too expensive, and clever placing of it can help a lot. We don’t always use a chamber (in fact we often don’t), like I said slap a couple of pieces on plywood and make something that looks like an open box laid sideways that the antenna fits in and you’ll knock out the vast majority of interference. Add in a height differential or a piece of foam at the halfway point on the ground, and you’re pretty good to go.
So, try the LNA, that will definitely give you more sensitivity for better measurements. But my guess is that there is another gremlin or two out there that you’ll need to slay to get good results. It probably will be something you would never have thought of. Keep at it, RF test is hard!
edit: You also could always have a bad device; but that’s one of the gremlins to slay that I was talking about. Get some of the other stuff figured out, and see where it leads you.
Bypassing open air and just connecting Tx (or an appropriate surrogate) to Rx with an appropriately large attenuator (start with lots for safety, then dial it back) should give you the best signal characteristics and can help determine if you have a bad device or not. Could also be a bad Tx that’s putting out broadband noise also… Then you can also add in components walking the chain to see where things change. And antenna / atmosphere is a component in your link budget, so eventually you add that back in also 🙂
Thanks Andrew. I’ll play with it once we order the SM200’s since it’s not currently a pressing issue for us. Just exploring potential risks.
Our processing is also in other threads, and we’re seeing pretty low utilization compared to what we expected so we might be ok. I can write a simple program to check that it’s working or not, but it’s always useful to make sure that you’ve set the right permissions on the actual final executable process 🙂
I updated our current script to use #1 above, set the process to -10 nice and was able to execute it without having to sudo. htop showed it at -10 nice level, and it did seem to get first priority over CPU resources. Used -20 (realtime, aka all the CPU) and it did consume all of the CPU. So it should be easy to test once I get to that point.
But reading more about it, niceness probably isn’t going to work.
The easiest way would be to allow your application to run as root by editing the sudoers file to allow it without password. But then you’re giving all root capabilities to the .exe, which if altered could result in complete pwnage of the system.
Next easiest woul be to allow access to a command, like set_rlimit
or chrt or setcap() via the sudoers file. That should be simple and safe, but I’m not in a place to test it right now. Linux just has so many darn ways to skin a cat, it can be hard to figure out which one is the best.My guess would be a sensitivity drop. The noise figure of the BB60C is pretty high, and unless you have a LNA before it, you can lose a good amount of SNR that way.
We had a user using the BB60C for test, and saw the 20dB issue. Since they weren’t setting the noise figure of the test using an LNA, the noise floor of the BB60C was determining sensitivity, and it was fairly bad. Then when they changed the Ref level setting, which controls the attenuator, they kicked in 20dB of attenuation up front, it naturally increased the noise floor by 20dB, and they came to me with this exact problem that you’re posing here.
We tossed in a cheapo LNA in front before the BB60C, and it all worked out nominally regardless of BB60C setup.
A good check for monitoring ANY signal is to take your end measurement device, and kick in 10dB or more of attenuation. With spectrum analyzers you can do that by either manually setting the attenuation, or adjust the ref level to make it change the attenuator. Other devices, you put a 10dB pad in front. If the SNR measured changes at all, then you have a bad setup and need to stick more amplification in somewhere to compensate for test losses.
edit: btw, it’s not an anechoic chamber without foam. It’s a faraday cage. It’s the anechoic foam that makes it an anechoic chamber. An anechoic chamber without absorber on the walls (aka a Faraday cage) is typically worse than just doing it in the open unless you’re time-gating to ensure you’re not getting any reflections. I don’t doubt that small changes in the geometry of anything in the chamber can result in 20dB swings due to standing wave interference patterns. You’re building a mode stirring chamber without stirring the modes or the fancy math to back out performance parameters. I understand that you’re trying to shield yourself from external interfering signals, but you need some absorber in there otherwise you’re just in a big echo chamber.
You’re in essentially the worst environment for testing anything that’s not a pulsed, low duty cycle waveform. Get some absorber, mount it to some plywood and build a half-box around your antenna. It’s cheap, easy, and will dramatically improve test repeatability.
