Forum Replies Created
- Posts
Hi Jake,
It was nice meeting you today.
Justin will need to comment on the USB cable/power concerns/questions directly. He will be back in the shop on Friday.
We do have an option/upgrade for the BB60C that removes the need for the y-cable and adds an external power supply.
Are you running in a VM on your Mac? We don’t recommend running our products on Apple hardware or in VM’s. If possible, are you able to switch to a native Windows PC for running our device? It could help us rule out a few concerns if you are running stable on a native Windows PC.
Feel free to follow up with us directly. andrew and justin at signalhound dot com.
Regards,
AndrewHi Quadsat,
I would recommend using a small form factor Windows PC like the Intel NUC line or other brick-like models. There are also several Atom based SBC computers that would run the SA44B. Also consider the Intel compute stick.
While we do provide an x64 Linux and an ARMv7-A API build on the downloads page, they are not supported and less than ideal for the SA-series of products as we have difficulty maintaining the USB throughput on Linux operating systems, and thus difficulty in providing reliable measurements.
Let me know if you have follow up questions.
Regards,
Andrew February 28, 2018 at 9:00 am in reply to: On the BB60C, Does the FPGA Perform the FFTs, or Is It the Computer? Hi Gary,
Good question. In the BB60C, all of the signal processing happens on the PC side. This is also the case for the SA44B. Our recently released SM200A is the first receiver to move some of this processing to the FPGA, specifically when the instantaneous bandwidth is greater than what we can push through USB 3.0. The SM200A also has an image imbalance filter on the FPGA.
Let me know if you have additional questions.
Regards,
AndrewHi Chris,
The issue specifically is the how the Spike software renders the plots. The issue isn’t with the hardware(SA44B) itself, which means you would not have the same issue if you were to utilize the hardware through LabVIEW. Our LabVIEW project functions as a wrapper for our C API that we provide for all of our receivers. There are examples for configuring the device for sweeping.
If you have questions while getting set up in the LabVIEW project contact roger@signalhound.com
Regards,
AndrewHello Chris,
I can’t say for certain that the driver will fix these issues you are seeing. I have been able to find a few forums that talk about similar incompatibilities, but nothing conclusive. (With regards to this series of cards and the functionality of OpenGL we use (Vertex Buffer Objects)) The older age of the GPU does worry me since we utilize functionality that was standardized around that time that the hardware itself would have to support.
This is generally why we recommend the newer Intel i3/i5/i7 CPUs since they have integrated graphics we have tested against. Unfortunately I don’t have access to a system like yours to test.
If you are unwilling/unable to update the driver or the driver does not fix the issue, contact me directly at aj@signalhound.com. We do have a 30-day money back guarantee. I wouldn’t want you to be stuck with a unit you cannot use.
I look forward to your response.
Regards,
AndrewHi Chris,
This is a common issue related to graphics card incompatibilities. There are a couple reasons you might see this. The Spike software for certain rendering modes requires the GPU to support OpenGL 2.0 or greater. You will see this issue with either an older GPU that does not support it or sometimes with a newer GPU that might have outdated drivers or drivers that have issues providing this functionality(rare).
Can you let me know what type of PC you are using? Preferrable make/model/CPU model and the GPU model(which you can usually find in the device manager under the display adapters).
I look forward to your response.
Regards,
AndrewHi Volker,
Thanks for the images, I was able to reproduce what you are seeing.
It took me a minute to determine why this is happening and have determined the cause.
In the latest release, we have changed how we plot the limit line. The algorithm we use to test the limit is still the same but instead of plotting what we test against (the interpolated points) we plot the limit line as requested. Since your limit line includes a Spike between two output bins it gives the visual appearance of failing the limit line but in fact the testing is being done on adjacent interpolated bins. If you were to load this limit line into 3.1.11 you will notice the limit line being displayed will not actually come up to -60dBm as we plot only what is being tested against. In fact I included a screen shot of 3.1.11 with the same -60dBm peak being loaded into the limit line and you can see it gets rendered at ~-68dBm because that is the interpolated value that is being tested against. You can also see my input signal below -60dBm.
On review of this, I think we will need to go back to plotting the values tested against rather than the requested limit line.
In conclusion, my current understanding is that we have changed how we are plotting limit lines in the new version but the pass/fail message will match what you would see in the older version 3.1.11.
It might be more beneficial to create a box like limit line that has at least a width of 1 bin (RBW), and then sharply drops off, I think this will create the result you are looking for with more consistency. Currently with a very narrow spike, the high point can easily fall between two bins at which we can’t test at.
If you want to load an older version of the software you can find the link here.
signalhound.com/sigdownloads/Spike/Spike(x64)_3111.zipI will work on restoring the old way of plotting the limit line for the next release.
Let me know if you have follow up questions.
Regards,
AndrewHello Bharath,
We have an FSK demodulation option, but not specifically MSK.
Regards,
AndrewHi Volker,
So I played around with the single tone file you linked, and got it to work as I think you intended, as a test for whether a CW is present. I attached some images, where I zoomed in on the CW and I increased the Div to 15 to see more y-axis.
I did also change the point at 250M to -60 instead of +24 so it’s easier to play with a signal generator at my desk.
I attached three pictures, one where I increased the RBW and you can see it passing. Then two more where I shifted the CW freq and lowered the RBW and it fails both.
The limit line was configured as a min limit line.
Can you provide any more information or maybe a picture showing the scenario you see. If you are able to zoom in on the span as well, it could help me determine why you are unable to reproduce my results.
I will need to look into the roundings, I agree that it is an issue. I will try to get a fix for this for next release. I’ve been editing the files in a text editor for now and it seems to be working.
Edit: I think I see the issue you are experiencing with the line always passing sometimes. One of the issues here is that the spike that you are putting in the limit line is very narrow, and there are only a finite number of points in the sweep, so it is possible that the entirety of the spike and adjacent points fits between two of the sweep points. Basically the lowest RBW you can get away with is what you should use as it will increase the number of points in the sweep giving you more resolution to test again the limit line with.
I look forward to your response.
Regards
Hi Volker,
I’m sorry for the inconvenience. The functionality has changed slightly. The old method had you specify both the min and max amplitude for each frequency (on each line in the file). Now you will want to create two files, a minimum and maximum line and load them into two different limit lines.
The file format has only changed slightly, instead of specifying two amplitudes for a min and max, the single amplitude will be interpreted as a min or max depending on your selection in the limit line menu.
Freq(MHz)1, dBm1
Freq(MHz)2, dBm2
…
Freq(MHz)N, dBmNI attached both files you would load to recreate your old setup and a picture of them working on my screen.
Regards,
AndrewHello Luigi,
Sorry for the difficulty you have experienced.
I can clarify some things. The Spike software does not install/uninstall any drivers for the SA or TG, only the CDM installer/uninstaller. If the Spike software detects and run the SA44, then the driver is installed properly, since the SA shares the same driver with the TG. You cannot connect the TG through the Connect menu in Spike. Spike will only interact with the TG through the Utilities->TG control panel menu or by activating scalar network analysis.
I would try using the Utilities->TG menu to try to control the TG. Additionally, ensure the “Load VCP” checkbox is unchecked for any devices that appear for both the TG and SA in the device manager.
I look forward to your results.
Regards,
AndrewHello Mallaug,
Since Spike also uses the API to retrieve the firmware string and is working for you, it would lead me to believe the issue is probably in the C# interop.
Hopefully someone here has enough C# experience to answer your question. You might also try searching online with search terms like “PInvoke char pointer parameter” or similar. It seems to bring up a lot of relevant results.
Regards,
AndrewDavid,
The bbConfigureProcUnits() refers to the video processing units, “Video Units” in the Spike software. For channel power you will want to set this value to power as you were. The detector should be set to average, and the scale in the bbConfigureAcquisition() function should be set to BB_LOG_SCALE. You have the scale set to BB_LIN_SCALE, which is what changes the output units from dBm to mV.
Regards
Hello David,
I think the biggest issue I see is that since you specified a linear scale output from the API, the sweep is in the units of mV. In the Spike software we specify a log scale output and then convert each sweep bin to mW (power units) before summing them up, and then convert the final result back to dBm. If you want to stay with the linear scale (mV) output from the API, just square each sweep bin before summing.
I will attach a file I have sent others from the Spike software. It has some additional details that are irrelevant here, such as only summing up the power in a range specified by the user, but you will notice the same logic for summing the bins as mW and then dividing by the window bandwidth.
If you aren’t already, you can test the output of your code to the values Spike provides. Assuming similar channel widths, it should match very closely.
Regards,
AndrewHello Carlos,
Thank you for emailing us as well. We will continue to work through your issues via email.
Regards,
AndrewHello JY,
You will need to calibration file for each SA44B you own. If you know the serial numbers for the devices I can help you get links to the calibration files.
Newer SA44B devices store the calibration file on the device itself. If you try running Spike with the other devices, it might automatically find the cal file from either the device or our server.
Regards,
AndrewHi Travis,
KB0NE is correct. There are no discussions for introducing other receivers into the Spike software.
Regards,
AndrewHello JY,
These instructions are for the Spike application.
Download the calibration file for your unit here
https://signalhound.com/custdata/P2054/D20540419.binPlace this file into this directory path.
C:\ProgramData\SignalHound\cal_filesProgramData is a hidden folder so you must “Show Hidden Files/Folders” in the Windows file browser menu. If the SignalHound/cal_files folder does not exist, then go ahead and create it. Once there, rerun Spike.
I believe for the 2.14 application simply place the .bin file in the same directory as the executable in the application directory.
Let me know if you run into any issues.
Regards,
AndrewHello setu_mohta,
There is currently no plans to offer a signal generator with these features.
Regards,
AndrewHello setu_mohta,
We do not have a CSV signal library other than the small number of examples we ship the unit with (~5 examples which indicate more of how to create the CSV files over providing various waveforms)
Regards,
Andrew