Forum Replies Created
- Posts
You could adapt from 2.4 to 3.5/2.92 which would give you the option to connect 2.92, 3.5, and SMA and go > 20GHz when needed. Since that adapter will be expensive, you could buy a cheaper connector saver, like SMA-SMA or 3.5-SMA if you plan on doing a lot of SMA mating cycles.
2.4 to N exists and isn’t horribly expensive,
Here’s some ideas,
Andy,
The 3D waterfall was removed in 2017. We decided to add more features to the 2D waterfall instead of supporting both moving forward.
Regards
Andy,
Gary was referring to the waterfall view in zero-span mode. Once in zero-span mode use the “Add Measurement” button in the upper left of the application to add a water fall plot. It shows you a very dense spectrogram plot over the duration of the time domain capture, usually overlapping FFTs by 90% or more depending on settings.
In sweep mode, it’s just a matter of clicking the “spectrogram” checkbox in the upper left as well. Same general functionality, less overlap between lines in the plot as compared to zero-span.
Speaking of which, maybe we should be a bit more consistent in our naming.
All of our waterfall/spectrogram views are “flat” 2D plots, if that is what you were referring to.
Let me know if you have more questions.
Yes you can. In general only one application can have a SCPI connection to Spike at a time. Any application that can communicate SCPI commands via the VISA SOCKET protocol can communicate with Spike.
We use IO libraries internally for testing, using the interactive IO panel. We have heard of customers using the SCPI capabilities in MATLAB and LabVIEW with Spike.
Eric,
Thank you for the report.
We have not done any testing with LTE-M signals, or any of the LPWA variants. Given this, I do not believe we can adequately support these measurements. I have added these comments to our development logs. In the future we might be able to introduce this capability.
Out of curiosity, what sort of equipment are you testing?
I have not done this myself, but it appears possible with some limitations. See the linked article below.
A typical GPS antenna has ~30dB of gain, but even this is not enough to get a spectrum plot capable of characterizing the signal. The author in the article uses 60dB of gain through active antenna and additional LNA and just manages to get the signal above the noise floor. Being that you want to measure inside your vehicle, there will be additional attenuations from the chassis.
On the spectrum analyzer side, you will want to make sure the receiver is configured for maximum sensitivity and a low RBW. You also need to make sure no signals exceed +20dBm into the front end of the receiver with that much gain. An RF limiter or filter might be necessary.
https://www.eetimes.com/testing-gps-receivers-with-real-world-data/
I hope this helps.
The bandwidth on the SA44 is too narrow to demodulate BLE. BLE1M requires ~1MHz of bandwidth, and the SA44 has at most 250kHz of instantaneous bandwidth.
Our BB60 would be the most affordable spectrum analyzer that is capable of making these measurements.
Let me know if you have follow up questions.
Andrew
Thanks for the feedback Gary, glad you’re liking it! I think it’s our RF engineers favorite view as well.
Akumar,
Do you want to run all 3 on one PC? If yes, are you doing sweeps or I/Q streaming?
If just sweeps, I think a standard desktop PC with an Intel i7 processor would work fine assuming it has enough USB type A ports.
If you need to perform streaming I/Q then you will need to either use more than 1 PC, or add PCIE to USB adapter cards. The reason is that when I/Q streaming, most USB 3.0 host controllers can support at most 2 BB60 I/Q streams. Most PCs only have 1 host controller who’s bandwidth is shared between all ports. Adding a USB 3.0 to PCIE adapter card will add more host controllers with their own 5Gb/s link. You would distribute the BB60’s accordingly. Additionally the PC would need to have adequate performance to be able to maintain 3 I/Q streams, which a quad core i7 or higher would likely be capable.
Let me know if you have follow up questions.
AndrewHi SRobert,
This sounds like a bug in Spike. We can definitely look into this, and if we can reproduce/find it, we can get a fix into the next release. Can you reach out to us via email at support@signalhound.com? Just say that you are from this thread. That way we can contact you easily if we have follow up questions? I believe we will have time to look into this next week.
I appreciate your patience.
AndrewI will have another engineer comment on the performance improvements of the BB60D, but regarding the ExtIO changes, you can email any findings to aj@signalhound.com. We haven’t used SodiraSDR here, but whatever you find will probably be applicable to more people and we can try to update our offerings with your modifications.
Thank you Phil.
Gaston,
I responded to your email before I saw this post.
Hi Jing,
Yes, you have to reconfigure the receiver between I/Q captures, and yes, with the BB60, there will always be a gap when switching frequencies. I would expect the gap to be in the 10’s of milliseconds.
Unfortunately there is not a way to improve this with the BB60. Our SM200/435 has an I/Q sweep list feature, which allows for preconfigured I/Q frequency/capture_len pairs to allow for very fast switching times, (120us switch times). I can provide more information on that if desired.
Andrew
No worries Ed. This is not on our immediate road map and we have no plans to add it right now. I have added it to our customer request log but I cannot make any guarantees about when we would be able to look into this.
We recently added the average power readout (on the zero-span AMvTime plot) as a query-able value via SCPI. See the ZS:Fetch command. If you can get this value to work for you, that might be sufficient. Otherwise see my prior suggestions.
Hi MMohseni,
If you download the SDK (link below) and look in the examples folder for the BB60C, you will see a folder for C# that includes a wrapper API and an example of how to use it. This example can be easily modified and extended to suit your purposes.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
Andrew
Hi Ed,
Unfortunately we have not added SCPI commands for the zero-span channel power measurements since your last messages.
You can see a full list of SCPI commands we support in the SCPI manual found in our SDK.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/There are no commands other than the ones in that document.
Andrew
Unfortunately, we are not familiar with the LoRa specification and do not have any resources to help you with your task.
Sorry, it looks like I didn’t update the SCPI manual to reflect the change.
Try “FETCH:ZS? 10” for the average power.
Let me know if you run into issues or have follow up questions.
For future reference, when making channel power measurements, both ‘average’ detector must be selected, as well as ‘power’ video units. If either of these settings are not used, you will not get consistent channel power measurements.