- hquezada November 19, 2020 at 1:05 pm
I am currently using the example API code for “simple sweep” for a Linux machine. The code works just fine with relatively large spans and rbws, however my project requires very low span and rbws values.
The problem I want to address is how to reduce the sweep time.
Specifically, the values I am passing into the code is as follows. The values were chosen from the same settings that were used in Spike to capture the data needed:
center frequency: 5GHz
span: 1000 Hz
sweep time: 0.001 s
Here are the observations I have made:
1. When running the code with the specifications mentioned above, the code takes about 250 seconds to execute (however a few months ago I remember it taking around 10 seconds). Sometimes it takes about 10 seconds if the Preset function is added at before initialization, but after about 10-20 consecutive runs, the execution freezes. I have found that the function that is primarily responsible for taking this long is “bbFetchTrace_32f”.
2. The only error I get returned from any of the functions used is for “bbFetchTrace_32f” which is “Sweep uncalibrated. Data invalid or incomplete” which I traced back to the manual and saw it was “due to either USB data loss during device acquisition or being unable to keep up with the necessary processing to create the sweep”. However, even with this error, I am still getting all of the amplitudes from “max” array.Andrew November 19, 2020 at 1:27 pm
You did not mention which RBW shape/window function you are using. I would recommend the Nutall window for this measurement. It will speed up the measurement by about 2x which will help with stability.
Based on the sweep time and warning you are receiving, it sounds like the PC is unable to keep up with the measurement. The measurement as configured will require high sustained USB throughput and high CPU usage to perform, more so than sweeps with larger RBWs, which is why you are seeing issues at this RBW and maybe not others.
The 250s sweep time tells me the API is likely falling behind and getting in an undesirable state. I have configured this sweep in Spike and get consistent ~6 second sweep times. Are you able to reproduce this in Spike?
What is the make/model/CPU of the PC you are using?
Attachments:You must be logged in to view attached files.hquezada November 20, 2020 at 3:05 pm
Attachments:You must be logged in to view attached files.Andrew November 23, 2020 at 8:28 am
Consider increasing RBW or using the Nuttall window (rbwShape parameter on bbConfigureSweepCoupling) if the device is unstable at low RBWs like 1Hz. It looks like your PC is unable to keep up with the processing required for the 1Hz RBW on the BB60C. Unfortunately RBWs that low on the RBW require significantly more processing than other measurements.
Regardshquezada November 30, 2020 at 3:09 pm
I apologize for the last post. I didn’t mean to post that incomplete.
I did try using a Nuttall window as you suggested and it did not make a difference unfortunately.
The PC I am using is Dell OptiPlex 9020.
Processor Core: i5
CPU Freq: 3.30GHZx4
Available Memory: 257GB
I am able to reproduce it on Spike. The thing I don’t understand is that how on Spike, the settings I require are working fine without any lagging, but not with the API? I am consistently getting ~6sec sweeps on Spike as well.
I have noticed that immediately after replugging it, it is working correctly (6 sec sweeps) for about 1-3 times, and then that is when it is getting stuck.
Also, I know in the API the user is responsible for passing in the sweep time. The manual says it is recommended to use between 10ms-100ms, however would it be better to for my application to use 6 seconds?
What CPU specs would be required to have a rbw of 1Hz?Andrew December 1, 2020 at 8:38 am
Try setting the sweep time in the API to 1ms instead of 6 seconds. With 1ms the sweep time parameter will be effectively ignored and it will use the minimum sweep time needed to achieve the 1Hz RBW which will be 2-4 seconds depending on window function. If you set the sweep time to 1ms, this will mirror the settings used in Spike more accurately which it sounds like is working for you. Spike also uses the API, so if you are able to find settings that work in Spike you simply need to mirror them in the API to get similar results.
You must be logged in to reply to this topic.