Hi Victor,

Thank you for your updates and patience. I looked into this a bit further, and I hope I have come up with a solution. Start with a fresh download of the firmware updater folder and install this driver from FTDI. Link below

https://signalhound.com/sigdownloads/Spike/CDM%20v2.12.00%20WHQL%20Certified.exe

The ftd2xx.dll/bb_api.dll you dropped in are likely 64-bit versions. The FTDI driver install will be necessary for using the TG44/TG124 and will install the 32 and 64-bit versions. I think this is the missing piece. The firmware updater is a 32-bit application and installing the FTDI drivers hopefully will install the last missing DLL.

Let me know if this works.

Regards,
A.J.

[Andrew]

Hi Victor,

Yes, version 3.0.7 means that you can now pair the BB60C with a TG44/TG124 and make scalar network measurements. Yes, you will need to update your existing BB60C to firmware version 5.

I just added two links to the BB60C downloads page under the firmware updater download. To run the firmware updater, you will need to download/install two Microsoft libraries. I apologize for the inconvenience.

Regards,
A.J.

• This reply was modified 8 years, 5 months ago by Andrew.

Hi Mervin,

Thanks for updating us on your situation. I am glad a newer release seems to have resolved your issues.

Regards,
A.J.

Hello Mervin,

Can you please email support@signalhound.com to begin the support process.
Please send information regarding your setup such as the current configuration of the software, such as frequency range, and the tracking generator control values you are setting when seeing this issue. Also please describe what you mean by “remove the SA/TG” and what kind of error messages you are seeing on screen. Also please share your PC information with us, most importantly, the Operating system, whether you are 32/64 bit and the CPU model number. Any other information you can think of that is unique to your setup or measurement process is helpful so we can try to duplicate the issue or determine its source.

Regards

Julian,
I might be the best person to answer this. Yes, a good noise source will work, but it will suffer from:
1) Dynamic range. Since your energy is spread through the entire spectrum, the energy at each frequency bin is quite a bit lower. You might only get 40 dB of dynamic range, instead of 90 ish.
2) Nonlinearities. If you are trying to test the frequency response of a device, and “zero out” the response at some maximum amplitude for best signal-to-noise ratio, you may have significant intermodulation products affecting your readings. When you insert your DUT and filter some of them out, your flatness may be less than ideal.
3) Lack of automated software support. With the TG44AA / TG124A, you get software specifically written to do the task, saving you time and potential errors.

Hello Julian,

Currently we have not implemented quasi-peak detectors in the BB60. Expanding our EMC functionality is something we are planning on doing the second half of this year. We have a number of features requested by users and that we want to implement ourselves that fall within the realm of EMC precompliance.

I am not familiar with any 3rd party software that uses our unit for EMC pre-compliance.

The real-time functionality of the BB60 is great for EMI testing.

Regards,
A.J.

Hey Dan,

Here is the direct link to the archived ARM build.
https://signalhound.com/sigdownloads/SA44B/arm_sa44B_api.zip
Compiled on a beagleboard with GCC, Cortex A8 processor.

Regards,
A.J.

Hello Feng,

Video triggering is not a function of the API. If you need video triggering you will need to check the amplitude of the I/Q samples against your trigger level as you acquire them.

Let me know if you have any other questions.

Regards,
A.J.

Hello Richard,

Thank you for bringing this to our attention. The Spike software does not have extensive text scaling capabilities for high DPI screens like the Microsoft Surface. Other users have had varying success with the Windows text/icon scaling. Have you tried this yet? Other than the Windows text/icon scaling, the only other alternative we can suggest is to reduce the screen resolution. I apologize for the inconvenience. It is something we are planning on looking into in the future.

Regards,
A.J.

Hello Dan,

Unfortunately all of our programming interfaces are proprietary, so we cannot share the sources. At this point the Linux and ARM libraries are provided as is. We have focused our efforts on our Windows libraries releasing a large update/overhaul about 1 month ago. At some point in the future we might re-visit Linux and bring over the major changes we made on the Windows side, but we have no definite plans as of yet. I apologize for the inconvenience.

Regards,
A.J.

Hello Feng,

You did not state whether you are using the API or using our supplied software. If you are using our software then you can setup video triggers in zero-span mode using the control panel. If you are using the API and retrieving IQ data from the device directly then video triggering is just a function of checking each IQ sample for you trigger level.

If this does not answer your question, please try to restate your questions.

Regards,
A.J.

Hello Mark,

I can explain what you are seeing, and clarify the difference in behavior between the old software and new software.

As you know, a frequency bin in a sweep rarely lines up nicely on an even number like 10MHz. When you enter a marker frequency like 10MHz the closest frequency bin has to be used, and it might correlate to a frequency like 9.999037MHz. The old software simply printed the frequency you entered even though it was using the frequency bin at 9.999037MHz while the new software will simply show you the frequency of the bin used.

Ultimately both versions of the software use the same frequency bin to report the amplitude but the old software shows you the frequency you entered and the new software shows you the actual frequency of the marker.

Let me know if you have further questions.
Regards,
A.J.

Jared,

In hindsight that would have been a better idea.

Regards,
A.J.

Hello Marholt,

That is correct, CPU speed affects sweep speed up to a point. That point is when the time to acquire data from the device is greater than the time to process it. For most sweeps, the processing can happen in parallel with the data acquisition. There are many factors at play here (single vs. multithreaded processors, RBW, VBW) and so it is impossible to give you a single number that would meet your needs. The sweep times you see on the 3.3/2.7 GHz processors are almost certainly the fastest those sweeps can perform.

Regards,
A.J.

Hello Filippo,

We do have an example. If you go into the bb_series folder we have a fully fleshed out API in the csharp folder for our BB60 API. The BB60 API is very similar to the SA44/124 API so it will be mostly cut and paste.

The mechanism by which this is performed is commonly referred to by many names, most notably as PInvoke, Interop, or marshalling. These are the mechanism by which a C# program can call a C function in a DLL on Windows. Searching the internet for these terms will return many examples of doing this.

Regards,
A.J.

Hello Jason,

The preset files are located at
C:\Users\YourUserName\AppData\Roaming\SignalHound\
AppData is a hidden folder by default on Windows systems
They are named “Preset[0-8].ini” and they correspond to Presets [1-9] in the software.
You can place them on a different computer in the same directory and they should work. Each preset is only compatible with one type of device, e.g. a preset saved with an SA124 cannot be loaded for an SA44.

Regards,
A.J.

Hello Feng,

Video and External(BB60 only) triggering is available in Zero-Span mode. You can configure the triggers on the control panel after entering Zero-Span mode. In the API no triggering is performed directly, but the location of external triggers are returned when the API is configured correctly. You can see the API manual to learn more about setting up external triggers. https://signalhound.com/sigdownloads/BB60C/BB60-API-Manual.pdf

Regards,
A.J.

Hey Jared,

Thanks for the feedback. The trace export format is mentioned very briefly in the user manual on page 9.

The format for the columns is
Freq in Mhz, Min Amplitude, Max Amplitude.

I hope this clarifies why you are seeing what appears to be multiple traces.

Regards,
A.J.

Hello Feng,

The software is open source, so the .bbr format is exposed if you want to try to extract information from the file.
The two files of significance would be
https://github.com/SignalHound/BBApp/blob/master/BBApp/src/model/playback_toolbar.h
https://github.com/SignalHound/BBApp/blob/master/BBApp/src/model/playback_toolbar.cpp

The format is a bit simplistic, which does make it simple to parse.
It starts with a header, defined in playback_toolbar.h.
Then there are ‘header::sweep_count’ traces which are laid sequentially out as

– (Header 1 time only)
– 64 bit integer, (standard ms from epoch time, when the sweep was captured)
– header::trace_len 32-bit floats representing the “min” trace
– header::trace_len 32-bit floats representing the “max” trace
– (Repeat last 3 lines until eof)

Everything is saved as binary, so fread will work great.
Let us know if you have any other questions.

Hello Bongo,

Thank you for confirming this. Spike requires a minimum of OpenGL 2.0 to run. I apologize for the inconvenience.

Regards,
A.J.

[Author]

Posts