Hi ghuxtable,

Yes, changes in the reference level affect sensitivity, which change gain and attenuation of the instrument. A lower reference level implies you will be making measurements on smaller signals, in which we increase the sensitivity.

In standard sweep mode, linear scale frequency is the only scale possible. There is no way to plot on a logarithmic scale outside of the precompliance mode. I apologize for the inconvenience.

Regards

[Andrew]

ghuxtable,

You can convert to dBm from dBuV by simply subtracting 107dB.

Try decreasing your reference level. The devices maximum sensitivity is ~50dBm or 57dBuV. Your noise floor will drop ~30dB from its current position. This will get you very close to the pictures in the other software you provided. Decrease ref level to 60dBuV or 55dBuV. Any lower than -50dBm and you won’t see any improvement in the noise floor.

Your path loss table values appear correct. Our software will linearly interpolate between your points. If you need more resolution you can also add more points later.

Regards

• This reply was modified 5 years, 3 months ago by Andrew.

[Andrew]

Thanks for the follow up information Volker.

Did you see the Spike manual section on Noise Figure? We have the equations we use for the measurement. We will be writing a white paper for this soon.

I agree that measuring the noise source once is the best first step for automation.

NF of the BB60C will vary slightly per device, but is roughly the DANL of the instrument + 174. You can find the DANL specs in the product manual.

• This reply was modified 5 years, 3 months ago by Andrew.

Hello ghuxtable,

The precompliance measurements mode in Spike would allow you to setup a measurement like the one in the picture you provided, with one limitation, in that we only perform QP measurements at a single frequency. Ideally you would sweep with a peak detector, and check troublesome frequencies with the single frequency QP detector we provide. The single frequency QP detector is only available in precompliance mode.

The SA44 and SA124 are excluded from the precompliance measurements due to their lack of hardware image rejection. Using the SA124 for precompliance measurements will introduce false positive spurious image responses for every real signal input. Without a good understanding of the SA124 architecture it will be difficult to interpret the results.

At this point we do not have plans to enable precompliance measurements for the SA124. The BB60C is the most affordable analyzer we sell with precompliance mode enabled.

You can use the path loss table functionality to enter the antenna factor table. This will be applied for both sweep and precompliance measurement mode. Units would then be in dBuV/m. In precompliance mode, dBuV units are default, in sweep mode, you can select dBuV from the reference level control.

Let me know if you have follow up questions.

Regards

Miran,

Do you have any documentation for the mask you are trying to create? Any standard documents we can review? As it stands, given your current settings, reducing the minimum frequency of the offset to 0Hz instead of 1kHz would have no effect on the measurement. It would never fail in this region. If we extend this lower frequency, I would like to do it in a way that meets your requirements.

Regards

Hi Miran,

Thank you for the suggestion. I have implemented this and it will be in the next release of Spike.

Regards,
Andrew

Hi Volker,

Thanks for the feedback.

We have disabled the measurement for the SA44/124 devices due to their lack of hardware image rejection. The wideband noise source aliases in at all points in the measurement affecting the results. We have not determined if we will address this.

We intend to revisit this measurement in the future. Reusing the noise source measurements (step 1/2) is something we plan on adding. We agree that it would be beneficial to not need to perform this step for each measurement.

We have also considered how we would perform more automation with the noise source. The trigger idea is good.

We can review the noisy values you are seeing. With some more testing we might be able to reproduce and deal with these. Can you provide any configuration information for the measurements on which you saw this issue? I will include this in my notes.

Can you clarify your last question?

Thanks again for the feedback. This will be very useful for future development. We are happy this measurement has been useful for you. Hopefully we can make it better in future revisions.

Regards,
Andrew

Hello Miran,

It appears that the 1kHz minimum is an artificial limitation in the software. We could look into removing this limitation in a future release of the software.

The best you could do right now create an offset between 1kHz to 100kHz.

Additionally, given your current settings, if you create an offset that is higher than the measured channel power, it would never fail. Is this close in offset for visual indication only?

Also, the channel power bandwidth used when “Auto” is selected is based on your current offsets. If you created an offset that comes all the way in to 1kHz or below (given a software update), you will want to manually set the channel power bandwidth.

With your current RBW of 300Hz, being able to specify a start frequency of < 1kHz would only test a few additional points. Are you testing against a standard mask? I look forward to your response. Regards

[Andrew]

Hi Kaiser,

Would you please email the request to sales@signalhound.com. They can determine if this procedure is possible and provide a quote. Please provide your unit serial number when you message the sales department.

Thanks

• This reply was modified 5 years, 4 months ago by Andrew.
• This reply was modified 5 years, 4 months ago by Andrew.

mneuman,

Unfortunately the device does not have an idle mode. Once plugged in it will draw ~6W regardless of whether is it making a measurement or not. The only way to reduce power consumption is to unplug the unit. The 50C idle temps will not hurt the unit, but I understand it may be undesirable for other reasons. If you want it to be unpowered while not in use, consider a powered hub you could also keep on your desktop. Some hubs have buttons that allow you to turn off that port.

https://www.amazon.com/LYFNLOVE-Splitter-Charging-Individual-Switches/dp/B072LW1RGG/ref=sr_1_3?crid=3E5LE2M94PPYL&dchild=1&keywords=lyfnlove+usb+hub+3.0&qid=1607355253&sprefix=lyfn%2Caps%2C225&sr=8-3

Regards,
Andrew

Thanks for the update Gary.

There are limitations on how quickly people can reply to a thread to try and help cut back on spam. If it becomes a problem for our customers we can relax those limits.

Thank you Gary, I was able to immediately reproduce the issue. This is not intended behavior. I can get a fix for this. Until the next release, you can press the “Clear” button on the trace controls when trace 2 is selected to clear the max hold trace. Since we just released Spike I’m not sure when the next release will be.

Thanks again for the feedback!

Regards

[Andrew]

Gary,

That is the intended behavior (for sweep mode). I was not able to reproduce the behavior you are seeing (max hold NOT clearing when changing frequencies). I’m testing this in sweep mode on Windows 10. Can you please provide more information about your setup? Maybe a picture of the software before you make a change and I can try to reproduce it?

• This reply was modified 5 years, 4 months ago by Andrew.

Gary,

Try re-downloading it now. We re-included this file in the installation directory. It is not present for some OS’s outside the recommended Ubuntu 18.04, so we have to ship it with our application. It should work for you now.

Thanks

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.

Regards

[Andrew]

Thanks Volker,

I was able to track it down. It looks like another display related issue affecting just the limit lines. As before, the limits lines are still being tested the same as they have been for awhile.

I was able to fix this display issue, and can get it in the next release.

I apologize for the inconvenience. I will likely get a release out in the next 1-2 weeks.

Regards,

[See image for your line with fix implemented. Peaks align on the graticule lines and don’t shift left at higher RBWs. Although increasing RBW too much is not recommended with your narrow limit line spikes.]

• This reply was modified 5 years, 4 months ago by Andrew.
• This reply was modified 5 years, 4 months ago by Andrew.
• This reply was modified 5 years, 4 months ago by Andrew.
• This reply was modified 5 years, 4 months ago by Andrew.

Attachments:

You must be logged in to view attached files.

hquezada,

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.

Regards

hquezada,

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?

Regards

Attachments:

You must be logged in to view attached files.

Peter,

The entire sweep is stored in the recording file. The example you are running simply finds and prints off the peak amplitude point in each sweep. You will need to modify the program if you want to do something different with the data.

Regards,
Andrew

[Andrew]

mcline,

The biggest source of error is going to be from the RBW. With a 10kHz RBW, the frequency readout on a marker in Spike is going to be +/- several kHz, which is what you see. Lowering the RBW will improve the frequency accuracy of the marker.

Another source of error is going to be from the frequency difference between the two devices. If they do not share a reference, they may be some fraction of a ppm offset from each other. At 700M center frequency, this could be on the order of a 100Hz.

You could use a high resolution frequency measurement in the software such as the frequency difference meter utility. This will give you a much higher resolution than the marker approach.

For a given RBW, the points in the sweep might only be spaced RBW/4 Hz apart. For a 10khz RBW, that might mean 2.5kHz resolution on the points. Similar limitations apply to the E4407 as well, but the frequency of the point the peak fell on might have simply been closer to the true peak of the VSG60. There are certain configurations with the BB60C on which this might happen as well.

I hope this helps. Let me know if you have additional questions.

Regards,
Andrew

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

[Author]

Posts