Forum Replies Created
- Posts
Val,
If you have the waveform as a baseband I/Q file, or the ability to create a LoRa waveform with a tool like MATLAB, and the sample rate of the file doesn’t exceed 50MS/s, then yes you can use the VSG60 to transmit this waveform using the ARB output mode. Our software does not have native LoRa waveform creation capability, you would have to provide your own waveform.
Kaiser,
This is good information, thanks for the thorough reply.
What are typical sweep settings you are using? (span/rbw/etc). If I try to reproduce I want to get as close as possible to your setup. Thankfully we are about to release a high speed GPIO controlled switch, so it shouldn’t be too hard to simulate this!
Kaiser,
Fun setup. There’s a lot going on here, so maybe I can start with some high level ideas and questions.
– How are you switching between your sources? Are you using the smSetSweepGPIO function?
– If yes to the question above, have you done any monitoring of those GPIO pins? Any way to verify they are cycling through all your states and not missing one periodically? Whether it’s hardware/software, that would be extremely helpful to know.
– Am I to understand that the “sweep offset” sticks around for many cycles? So if you are cycling through all 20 slots, are all 20 slots now off by 1 for some duration until it corrects itself? Or is it just slot 10 that shows up in slot 9 for several seconds until slot 9 reverts?
– Does using just 1 receiver make the problem go away? Even with 16 queued sweeps?
– Is it always a specific slot, e.g. 9/10? Or random?
– Does the “sweep offset” happen on both receivers? Or just one?
– Let’s say you’re switching through slots 8,9,10,11. Does it now look like 8,10,10,11 for 15 seconds and then go back to 8,9,10,11?I’m trying to collect enough information that I could try to setup something here to reproduce, and narrow down the scope. I’m not aware of any outstanding issues with this functionality, but this is likely a more complex setup than most customers, and more complex than we’ve simulated here.
I look forward to your response.
Hi Val,
1) You want to make sure your IF bandwidth is wider than your signal of interest but not wide enough to include adjacent signals/channels. For FSK, this will mean knowing something about the frequency deviation and padding it. As for filter, yes, you want to know what the transmitter is using and match that.
2) We do not have any LoRa specific measurements. You might be able to use zero-span mode to estimate chip rates. My understanding is that its some sort of chirp like signal. That can be viewed with an FM v Time plot in zero-span, using markers to estimate chip rates?
Andrew
See my response in your other thread.
Andrew
Hello BSchwartzer,
We no longer support the RPi builds for the SA devices. The RPi builds had several issues and we were not able to get the SA devices to run stable either on ARM or x86 Linux architectures. For the forseeable future, the SA’s are supported under Windows only.
Additionally, None of our devices are supported under ARM architectures. The BB, SP, and SM lines are supported in x86/64 Linux OS’s. We target Ubuntu primarily with some support for CentOS and Redhat.
We are evaluating the NVidia Jetson platform for specific device APIs (it will not include the SA44/124). We will have more information on that in the future.
If you have follow up questions, let me know.
Hi lsullivan,
Unfortunately phase synchronization is not possible with any of our single channel receivers. That being said, Signal Hound is currently developing a multi-channel phase coherent receiver to address these needs. You can learn more about it at the link below.
If you have follow up questions, you may contact me directly at aj@signalhound.com.
Andrew
You are correct. The sweep recordings cannot currently be controlled via SCPI. This has been requested before and is something we hope to add to our software in a future release.
Until we can add this to the software, there might be another solution. You could use the API and store the data in the SHR file format. Located in the SDK, you can find an example SHR file parser project. From this project, you can learn about the file format and use the API to retrieve sweeps to store in your own SHR files.
Thanks for the update. Glad you got it working.
MCarr,
The API does not have any of the modulation capabilities. When using the API you have to provide your own waveform. You have a couple options,
– The VSG60 UI can be programmed using SCPI commands. in the SDK, look under the SCPI folder and you will find a manual and examples for configuring the software via SCPI commands. Labview has support for sending SCPI commands. In this scenario, the VSG60 software would be running, and then you would run a SCPI “script” in Labview (or any other programming language) that would configure the software.
– Generate your own I/Q waveform. If you don’t know how to generate a QAM waveform, you could use offerings from Labview such as,
https://www.ni.com/en/support/downloads/software-products/download.labview-modulation-toolkit.html#484334
or MATLABs communication toolbox. If you generate the waveform outside labview, then you would want to save it as a file, and in Labview, load the file and feed it to the API.Thanks for the requests RVanDyke. I’ll see if there is something we can do here.
The API certainly should be able to interface several devices. We interface up to 8 devices in our manufacturing line using the API. What you will find is that most PCs will limit the number of actively streaming VSG60’s to 2, primarily limited by USB throughput and CPU cycles. Some PCs do struggle to transmit on 2 simultaneously. If you are also using one of our spectrum analyzers, you might consider moving the analyzer to another PC for making measurements.
If you are on Linux, please be sure to read the section on Linux in the VSG60 manual,
https://signalhound.com/sigdownloads/SDK/online_docs/vsg60_api/index.html#autotoc_md9Opening a second device should be as simple as calling vsgOpenDevice a second time with a new handle variable. This will result in you having two handles, one for each device. The handle values should be 0 and 1 after the vsgOpenDevice function returns.
If you are on Windows, you can verify that you see 2 devices connected in the device manager. If you don’t, then you need to resolve this first. The LED should also be solid green on both units when connected and idle.
We have not tested multiple devices in our Python environment, but it should be the same. If possible, you can test multiple devices in C++. The Python wrapper simply wraps the C interface. You can see the function assignment in the vsg_api.py file.
Tom,
We will be responding to these questions from our support email, thanks.
November 9, 2023 at 2:23 pm in reply to: Can auto gain/attenuation/pre-amp settings change during Spike recording? If the signal level changed by a non-trivial amount, I would consider that a bug and we could investigate further. It’s hard to tell from your picture since a lot of the signals are broad band. If you were ever able to inject a simple known signal like a CW for a test run, that would certainly make it easy to determine.
November 9, 2023 at 12:59 pm in reply to: Can auto gain/attenuation/pre-amp settings change during Spike recording? The gain/atten settings getting changed is very possible and likely the cause. Based on your other responses, it’s safe to assume this unit is exposed to the elements? (at least temperature variation) The Spike software will auto reconfigure the device when it experiences a 2C shift in internal temperature. That shift might necessitate different temperature corrections as well as a different gain/atten to maintain optimal measurements. If either the gain or atten changed due to that automatic update, it would result in ~5dB shift in the noise floor. The signal power of an input signal should not change (other than correcting any small amount of error that might have been present with the old temperature correction).
At room temp, I would not expect this auto reconfigure to occur once the unit has stabilized in temperature.
I know you are on an older version of Spike, but newer versions do allow you to disable the auto recal in the preferences menu. If you do this, you subject yourself to measurement errors if the devices drifts too far in temperature. You can also force the gain/atten, which would still perform the recalibration, but might not update the gain/atten to eek out more dynamic range when it could, or may not provide enough room for a full scale input. Both of these would be minor repercussions.
Very interesting Andrew, thanks for sharing. Do you know what old version of Spike you are running on this installation? Alternatively, do you know roughly what version you start having the stability issues with? It would be interesting to review the change log and code to see what changes might have affected this.
We have a number of customers in the pro audio community. You might also try forums specific to those groups, like https://forums.prosoundweb.com/index.php
There is mention of our product on those forums, you might get more responses there.Good luck!
The way that max hold works in Spike, is that each time a new sweep is performed, each bin in the sweep is max held with that same bin in the max held sweep.
Your algorithm might look like this,
1) Configure device
2) Capture first sweep and set as max hold sweep
3) Capture next sweep into variable “temp”. For each bin in the max hold sweep, set that bin to the max of either temp or max hold.// Pseudo-code for #3 for(int i = 0; i < sweepSize; i++) { maxHoldSweep[i] = (maxHoldSweep[i] > temp[i]) ? maxHoldSweep[i] : temp[i]; }4) Repeat #3 until desired number of sweeps or time elapsed, or after ping has been sent.
5) To determine the peak value in the sweep, simply iterate over the max hold sweep and look for the max value.// Pseudocode for #5 int maxIndex = 0; for(int i = 1; i < sweepSize; i++) { if(maxHoldSweep[i] > maxHoldSweep[maxIndex]) { maxIndex = i; } } double maxValue = maxHoldSweep[maxIndex];Hope this helps
The RHEL8 version was updated.
Thanks
Tamantea,
1) Unfortunately the SA124 is not supported on Ubuntu. Spike itself will work on Ubuntu, but only with our other models. Neither the SA44 or SA124 models work under Linux, only Windows 10/11.
2) You can certainly try using a standard cable. In most instances it will be fine. But not all USB ports will be able to supply adequate power to the SA124 over a single USB port. If you experience issues, you will need to revert to the y-cable.
Let us know if you have additional questions.