Forum Replies Created
- Posts
We do have minimal ARM Mac support for the SP145 in the form of compiled APIs. If you were writing your own software you could take advantage of them to use the instrument on Mac. You can find those libraries in our SDK. Porting Spike is a much larger project, and no effort has been made on this port yet. It has been requested a few times over the years, there is some interest. I can’t provide any timelines or estimates on this project.
Hi Matteo,
I made some suggestions via email, were you able to test those yet? In both of my suggestions, the attenuator would not be part of the cal, but would be inserted afterwards and compensated using one of the techniques below.
The problem with having the attenuator in during the cal is that you will drive the signal into the noise and the unit will not be able to make a good cal.
Here is the main contents from that email.
Port extensions would likely work, there is both controls for setting a typical path loss curve and a fixed DC offset (for narrow spans or coarse measurements). In this scenario the attenuator would be inserted post calibration.
Deembedding would be a more accurate approach. Do the cal without the attenuator. Then insert and measure the full 2 port s-params of just the attenuator. Save the measurement as an S2p file, and use that file for deembedding.
In the final picture with the through measurement, the status bar indicates that only the factory calibration is loaded. That would tell me that your 2 port cal is not currently applied. Are you finishing all steps of the calibration, including saving the calibration file prior to making this measurement? Once your calibration is finished and applied, you should see your through measurement normalized.
Please contact us at support@signalhound.com with a detailed description of your issue and we can assist you.
An additional comment about DVB. DVB includes some additional PHY features such a pilot tones that our software is not equipped to deal with (in our digital demodulation mode). A straight 32-APSK signal would be fine to demodulate as long as the instantaneous bandwidth of our receiver is greater than the signal. The BB60 has an instantaneous bandwidth of 27MHz.
Hi Craig,
This is a known issue. Remote desktop doesn’t support OpenGL which is used by our application to render some of the plots. There is some workarounds, see this thread,
https://signalhound.com/support/forums/topic/opengl-and-microsoft-rdc-remote-for-bb60c/Thank you for the follow up feedback Victor.
I will see about making these changes, but can’t guarantee when they will be available.
Hi SBabic,
Apologies for not updating this thread sooner.
Over the summer we introduced an additional pricing tier for our phase noise offerings in response to customer feedback regarding our legacy phase noise measurements. This new tier is designed for customers performing single-device phase noise measurements, providing access to all of our latest phase noise measurement capabilities at a significantly lower cost than our cross-correlated phase noise measurements.
You can learn more about the new licensing tier and its features at the link below:
https://signalhound.com/news/upgrade-to-phase-noise-features-explained/
Hi John,
Most modern business laptops will run the BB60D without issues, laptops like,
– Lenovo Thinkpads
– Dell Inspirons/PrecisionsWe occassionally see issues on boutique (think gaming brand) laptops or weatherized laptops that use bulkheads and other things that can interfere with USB 3.0.
A laptop with a USB type-A 3.0 port is ideal, but you can easily convert to type C with a hub like the Anker 555.
Hello Pedro,
We are currently working on integration of a third party auto calibration module. The ETA for that support is TBD as the module is still unreleased. If you would like to be notified when we have added support for it, please email me at aj@signalhound.com.
For now, our software only supports mechanical SOLT cal kits.
Let me know if I can help with anything else.
October 9, 2025 at 3:44 pm in reply to: Spike sweep and real-time analysis modes display black screen above window size Thanks for the follow up and feedback!
I will pass this along to the team.
October 9, 2025 at 8:48 am in reply to: Spike sweep and real-time analysis modes display black screen above window size btlac,
We compile most of our Linux offerings on Ubuntu 18.04, and while we don’t list 24.04 I have many reports of success from customers. I will update our website to reflect this.
We have tested Spike on 4k monitors before. Do you see the issue when you put Spike on the main laptop display? If yes, does anything change if you disconnect the external monitor? Can you verify you don’t have any outstanding video drivers you can install for your machine? I haven’t seen your issue specifically, (black screen related to window size), but have seen customers report fully white/black windows, and usually updating video drivers resolves the issue.
Regarding the other issue, it should not be an issue, this is a longstanding output that seems benign, and resists our efforts to remove it.
We have a very limited number of command line arguments, help is not one of them. They are listed in the manual, but are generally unrelated to your issue.
You might need to increase the meter settings meas time. Try 1+ seconds. This will then be closer to the measurement you are seeing when you are dwelling at just one frequency with the meter enabled. When doing the auto scan, each frequency is only measured for the specified meas time.
Hello Mattia,
For the sweep measurement, only avg/max detectors are available. The QP measurements are relegated to single frequency measurements only. The workflow would ideally be, using a peak detector, finding all frequencies that exceed your limit, then testing those frequencies separately using the QP detector, one frequency at a time. In theory the reading from a peak detector will always be equal/greater than a QP detector. You’re saying you are seeing a larger value from the QP measurement than the peak detector. It might be the sweep isn’t dwelling long enough to characterise the signal. The dwell time can be modified on the sweep to help with this in the range table.
The API does not have a equivalent command for reference level offset (RLO). The logic for RLO is done entirely in Spike. Fortunately it is simply offsetting the reference level you set through the API. For example, a RLO of 20dB (implying something like a 20dB attenuator in line) would mean setting the reference level in the API 20dB lower.
Did you modify the network address of the SM200C and need to update the address specified in the sm_open_networked_device() function?
Sometimes we see the “ANY” address not work. You might consider changing the “ANY” 0.0.0.0 address parameter to your hardcoded NIC address.
I’m assuming Spike is not running at the same time?
Do you see any LED activity when the sm_open_networked_device() function is called?
I look forward to your response.
PK,
The API would be the recommended way to automate with the VSG25. The VSG25 software and device does not support SCPI. SCPI automation is only supported on the VSG60 software.
The VSG25 API exposes most of the functionality of the user interface. It can be found in our SDK, linked below. See the user manual for programming examples.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
Let us know if you have follow up questions.
No it does not.
We have now released ARMv8 API builds for the BB60, SP145, and SM200/435 devices. This is API only, no Spike. The README in the documentation mentions the platform and compiler used for each build. None of the builds will support Windows+ARM.
RSartell,
Porting Spike is definitely something we have talked about, but there isn’t a timeline for this right now. The work done on the APIs would benefit a Spike port.
From your previous post, it seems Windows on ARM is your target platform? As you’ve noticed, all my ARM compiles are for Linux or Mac. If we ported Spike, Linux would likely be the first target OS.
Andrew
After long delay, we are happy to announce the availability of ARM (AArch64) support for the BB60 API. The API was compiled on the Nvidia Jetson AGX Orin platform. It’s expected to work on many ARMv8 Linux based systems.
Library files and README can be found in the SDK.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/