Forum Replies Created
- Posts
I’m hoping for later this week or early next week on the Spike release. Thank you for your patience.
Regards
Hi Mike,
You are correct about the tuning speed and step size.
You can find the DANL specs here,
https://signalhound.com/download/sm200a-data-sheet/
The RBW will add 10*log10(RBW) dB to the noise floor.
But, sometimes a picture can be instructive.I attached an image of the device configured for the 1THz sweep speed. You can see the device sweeping a 20GHz span in 17.257ms with a 30kHz RBW and a reference level of -20dBm which will configure the receiver for maximum sensitivity. If you increase the reference level the noise floor will come up in 5dB steps.
Let us know if you have additional questions.
Regards,
AndrewHello Bindinir,
Thank you for sharing this picture. I was able to reproduce this issue without the DC block, (which isn’t required). It looks like a bug with our software at this very specific setup. If you change your stop frequency to 90MHz or 110MHz I noticed it no longer occurs and sweeps normally. I will explore this more. In the meantime are you able to change the stop frequency to one of these other values and continue use? If you encounter other issues you can let me know here or email me directly at aj at signalhound dot com. I can try to fix these before the next release.
Regards,
AndrewHello vanderbasaran,
If you are interested in the option 10, contact justin at signalhound dot com. He can give you pricing information and set you up with an RMA to get the option applied to your unit. If you haven’t purchased your unit yet, you can order through sales at signalhound dot com, and be sure to mention you want the option 10.
Regards,
AndrewI would expect this functionality within the next 6 months.
Regards,
AndrewHello Vanderbasaran,
At this point and time there is no way to utilize the FPGA resources for your own development. We have discussed this as a possibility but have no plans to implement this for now.
Regards,
AndrewHi 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,
Andrew