Forum Replies Created
- Posts
Hello Filippo,
Some other things you could check,
– Are they both running the same OS?
– Does one have active anti-virus?
– Are both using the high performance power plan configuration in the power options control panel menu?
– I’m assuming you have verified that the sweep configuration hasn’t changed? (same RBW/VBW/spur reject/etc)
– Is one i7 a laptop and the other a desktop? Laptops usually have slower clocks and might account for some of the difference.
– Is one application running in debug mode vs release mode?An additional 200ms is a long time for the same sweep. The major things that contribute to sweep time is the device sweep speed limitations, USB transfer time, and processing time. Both USB and processing time should be small compared to the sweep speed limitations of the SA.
You could also compare your sweep time to the sweep time in Spike with the same configuration. If Spike sweeps substantially faster, it might be a configuration issue or something related to the C# FFI.
Regards,
AndrewHello Serpi,
Can you please email support@signalhound.com with this question. In your email, can you please provide information about your measurement test setup and any images of the incorrect readings. Please be as thorough as possible. We look forward to your email.
Regards,
AndrewHello Cristian,
You can use the video units and detector to accomplish a number of detector types. Our min/max is the same as plotting peak+ and peak- on the screen at the same time. When average detector is selected, the video units determine whether power averaging, voltage averaging, log power averaging or no averaging (sample) occurs. The only quasi peak detector we have in our software is in the EMC precompliance mode which is not compatible with the SA44B. It is a single frequency QP detector. Due to the FFT based approach in our analyzers, you may not see a difference between some detector settings (because the RBW/VBW specifies only a single FFT to occur). Lower RBW/VBWs will change this.
Regards,
AndrewHello Miran,
Justin is off this week, when he returns on Monday he will have some suggestions for you regarding a power switch.
Regards,
AndrewHi Ermy,
We do not have a frequency offset setting for the TG in our software. I apologize for the inconvenience.
Regards,
AndrewHello Jacks,
Thank you for contacting me via email.
The firmware update will not resolve this problem. I will be emailing you shortly for technical support.
Hello Jacks,
Do you have any issues with the BB60C with FW version 7? FW version 8 addresses an issue where the device doesn’t properly power cycle when a valid USB 3.0 connection is not detected. This ended up helping some customers on embedded/small form factor and certain other motherboards. In general we don’t recommend updating unless the FW version specifically fixes a problem you are experiencing.
If you still want the link to the version 8 updater, please contact me at aj@signalhound.com.
Regards,
AndrewThank you for the feature request Miran!
Regards,
AndrewHello Artur,
In older versions of our software we had a smith chart but it could only plot a single frequency (single point) on the chart. We are unable to sweep a frequency range (and hence we don’t refer to the devices as a VNA). Due to this limitation we have removed the smith chart from our current Spike software. The legacy software that supports this measurement is available on the download page for the SA devices.
Regards,
AndrewWe don’t provide any BER testing capabilities. One could use our APIs to manually perform BER testing. EVM measurements are sometimes used as an alternative/approximation to BER testing. We don’t have resources for doing this.
Regards,
AndrewI am not familiar with software that can be used to generate these waveforms.
Regards
That is correct Dhivagar.
We no longer support ARM architectures or Linux systems for the SA44/SA124 due to technical limitations that you can read about in this thread.
If you attempt to use either ARM architectures or a Linux OS, the device will not operate properly. (data loss, becoming unsynchronized, etc).
Regards,
AndrewHello,
As you’ve noticed, the SA44B ARM packages in the SDK are located in the “obsolete” folder. This is because we have obsoleted/deprecated these versions of our APIs and no longer support them. We recommend Windows only due to the limitations which you can read about in this thread.
Regards,
AndrewHello Sachin,
You can see the Spike user manual at the link below. I apologize for the inconvenience.
https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf
Regards,
AndrewOur APIs are not open source. Additionally, the FTDI library is only used in the BB60 API for the tracking generation compatibility. The BB60C itself uses libusb for USB 3.0 communication. The BB60C has a complex and proprietary protocol that we do not publish.
Regards,
AndrewUnfortunately no progress on this.
Regards,
AndrewHello asvol,
Unfortunately, the BB60C is not compatible with ARM architectures and cannot be easily ported. For the time being, our devices remain x86/x64 compatible only.
Regards,
AndrewGary,
It looks like cmake isn’t able to find the necessary files it needs for our OOT modules.
What have you tried so far? Have you searched this issue and tried any of the troubleshooting steps found online?
Here are some hits that look relevant.
https://github.com/daniestevez/gr-satellites/issues/15
and
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00174.html
and
https://github.com/daniestevez/gr-satellites/issues/37Regards,
Andrew