Understanding SA44B Limitations – Windows/Linux/ARM

Hi Guys

I thought I would finally ask this question. I’ve got the SA44B which I am using with a number of computers. For instance windows x64, windows x32, raspberry pi, linux i86 and my latest instalment is trying to get the SA44B APIs to work on an odriod xu4.

So I’ve managed to interface to the SA44B via the APIs for each operating system, but would like to understand the limitations (or where the limitations are) when working with the ARM devices.

There is definitely a drop in performance when switching from an i86 to an ARM environment. Where is the issue? Is it some memory management thing? Is it something to do with dropped samples?

I’m just trying to understand what ARM device I could use that would give similar performance to the i86 devices or is it a case of the APIs needing to be updated?

Any recommendations in helping me understand the ‘issues’ with the ARM environment?

An example of the discrepancies between the 2 architectures would be if I was looking at a DBV-T spectrum (in spike) on an i86 pc, it would be a nice flat amplitude response. Whereas, with the same settings, the ARM response would show significant peaks and troughs in the amplitude. Averaging fixes this but I’m after the better performance!

Many thanks

Regards
Jason

Jason,
The biggest issue is that the ARM architectures we have tested cannot stream I/Q data at the full data rate, so there are RBW / VBW limitations. Additionally, FFTs take much longer, so on the ARM architecture we do the minimum number to satisfy the settings.
For better performance, something like an Intel Atom processor gives you the full SA44B performance at lower power consumption.

Thanks Justin.

Is this still the case for higher end ARM processors? Thinking of the Nvidia TX1 SOC which is a high performance SOC.

Hi Jason,

The problem we have isn’t specifically with ARM, but with the FTDI USB libraries on *nix systems. The restrictions exist even with x86 Linux systems. The FTDI libraries for our chip (both the ones provided by FTDI and the open source version) are unable to meet the throughput required for our device to operate optimally (for reasons unknown).

Additionally we know that using a Linux low-latency kernel on x64 will not have any restrictions. The same cannot be said for ARM.

So, the options as we have seen,
Windows: x86/x64 – full capability.
*nix: Standard kernel – x64 – limited functionality.
*nix: low-latency/real-time kernel – x64 – full capability.
*nix: ARM – (all systems we have tested) – limited functionality.

Let me know if you have additional questions.
Regards,
Andrew

Thanks Andrew

That helps.

Same limitations for the BB60C? … actually, I don’t think you have any ARM implementation for it yet.

Regards
Jason

Hi Jason,

We currently don’t have an ARM build for the BB60C. It is unlikely we will any time soon, because we would have to find replacements for the signal processing libraries we use, which target x86/x64 specifically. The processing requirements are simply too high to re-implement the functionality in naive C code and have it run on ARM.

Although, we do have a BB60 Linux build for x64 and it does not require any modifications to the kernel to run. A standard Ubuntu (or similar) install will work fine. We used the libusb library for USB 3.0 with no issues.

It should be stated that our Windows APIs are the only APIs that receive full support. We do fix issues in our other APIs but it may take awhile compared to the Windows versions.

Regards,
Andrew

Hello Jason:

Have you had any success with the XU4? I happen to have a couple of those lying around here.

– Ron

Hey Ron

Not yet … had to resort back to Windows.

Cannot replicate the accuracy of the windows version vs ARM/linux. There’s something amiss in the way the FTDI driver caches data.

At the moment, this is on hold …

However, FTDI have just released some new drivers … will test when I get a chance.

Andre, have you guys tested the new FTDI drivers for linux/ARM devices yet?

Regards
Jason

We have not tried the latest FTDI ARM drivers, nor have we tried the XU4 platform.

Regards

Did a quick and dirty test on linux 64 bit intel processor running low latency kernel with the new FTDI drivers.

Getting same results as with previous drivers. If you’re not after absolute accuracy then its fine, if you’re looking for the 1.5dB stated amplitude accuracy then the linux/ARM API is not going to meet this for channel power type measurements anyway. Or anything that is close to the noise floor.

Would like to work with Signal Hound to get it working on the other platforms as well as it does on windows.

Let me know how I can help … it would benefit a large range of industries to use non-windows PCs!

Regards
Jason

Hello，I want to connect with SA44b on the ARM Cortex-A8 hardware platform, and get the transmitting power and frequency of wireless devices through API interface function，Can I use it this way? Are the packages of”arm_sa44B_api.zip” provided on your website fully tested and ready to use?
The File of “arm_sa44B_api.zip”is Under “Signal_hound_sdk_07_15_19-SDK” Software Development Suite Compression Package

Hello,

As you’ve noticed, the SA44B ARM packages in the SDK are located in the “obsolete” folder. This is because we have obsoleted/deprecated these versions of our APIs and no longer support them. We recommend Windows only due to the limitations which you can read about in this thread.

Regards,
Andrew

Andrew，Thank you for your reply。Due to the limitation of using environment, we can only use ARM hardware platform，Does SA44B support this use? Why don’t you support API on ARM now? Is it due to fewer users or to technical reasons? What will happen if we connect SA44B on ARM Corex-A8?
We look forward to your reply！

We no longer support ARM architectures or Linux systems for the SA44/SA124 due to technical limitations that you can read about in this thread.

If you attempt to use either ARM architectures or a Linux OS, the device will not operate properly. (data loss, becoming unsynchronized, etc).

Regards,
Andrew

[Author]

Posts