Forum Replies Created
- Posts
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.
Hi Jacks,
Unfortunately, I cannot reproduce the problem with the provided information. Would you be willing to email us at support@signalhound.com with more information about your issue? Please provide screen shots of the Spike software and descriptions of your setup and any signals you are generating/measuring. Hopefully we will be able to quickly troubleshoot and resolve your issue.
We look forward to your response.
Andrew
Good question,
Over the years, we have learned that using a single USB 3.0 type A port will generally be OK. PCs seem to supply adequate power to our device over a single cable. Places where you can see issues is with ultraportable devices like the Surface Pro line. If you only have a single USB type A cable and it does not supply adequate power, then we recommend a USB 3.0 hub that has external power.
If you only have a USB type-C port, you will need to use an external hub that performs power negotiation/use external power. A hub such as the Anker hub linked below has been reported to work with our devices. Using a direct type-C to type-A adapter usually will not work, we believe due to power issues.
https://www.amazon.com/Anker-PowerExpand-Adapter-Delivery-Ethernet/dp/B087QZVQJX
Andrew
1) When using the I/Q recorder the scale factor is not recoverable, so you will have to use the data as full scale if saving as 16-bit ints. If using the API you can store the scaling factor separately and use it to convert to dBm if needed. The reference level being used as the scale factor does not apply with the I/Q recording utility.
2) Check out the docs for more information on scaling, we use this approach for both our BB and SM line of receivers. I/Q values have a similar scale as a voltage, but need additional conversion if you want to use them as a voltage.
https://signalhound.com/sigdownloads/SDK/online_docs/bb_api/index.html#IQDataTypesAndrew
1) My guess is that 0 duration just means the event lasted for a single sweep, and 0 bandwidth means that only a single point in the sweep exceeded your threshold. Does that line up with what you are seeing?
2) Using the recorder in Spike means that you would only have to write code that parses those files and looks for events. Using the API gives you more flexibility to write files in a format that’s better for you, and also you can automate more of the recording process vs manually saving the files in Spike. It’s the same underlying data/samples in both approaches.
Our data rate is 160MB/s. Using the API you can choose whether to receive 16 or 32-bit complex values. The 16-bit are shorts, and 32-bit are floats.
Retrieving I/Q data via the API is by default continuous. If you set the purge flag to false, the I/Q data will be continuous. The API stores about 1/2 second worth of I/Q data internally, so you must not let this internal buffer “wrap/overflow/etc”, otherwise you will have a gap in samples. You must continually poll the API for the duration of time/samples you need. You can detect gaps by monitoring the sample loss parameter and the status flag returned from the bbGetIQ function. You can request arbitrarily large buffers sizes from the API if desired. If you plan on streaming for long periods of time, I suggest requesting buffer sizes around ~1/60th of a second. This is still a small enough buffer to quickly allocate and does not call into the API (which has a small amount of overhead) too many times per second.
Andrew
Hi BDick,
The limit line amplitudes you listed are in positive dBm. I suspect you meant for them to be negative? (-50, …) Right now the limit line is being drawn off the top of the screen.
Andrew