- JasonS January 31, 2017 at 2:28 am
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!
Justin CrooksModeratorJustin Crooks January 31, 2017 at 9:05 am
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.JasonS January 31, 2017 at 12:20 pm
Is this still the case for higher end ARM processors? Thinking of the Nvidia TX1 SOC which is a high performance SOC.Andrew January 31, 2017 at 1:02 pm
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.
AndrewJasonS February 1, 2017 at 2:27 am
Same limitations for the BB60C? … actually, I don’t think you have any ARM implementation for it yet.
JasonAndrew February 1, 2017 at 9:44 am
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.
ronaldleesParticipantronaldlees July 3, 2017 at 9:04 am
Have you had any success with the XU4? I happen to have a couple of those lying around here.
– RonJasonS July 4, 2017 at 6:23 pm
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?
JasonAndrew July 5, 2017 at 9:43 am
We have not tried the latest FTDI ARM drivers, nor have we tried the XU4 platform.
RegardsJasonS July 5, 2017 at 4:18 pm
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!
LVXICHENParticipantLVXICHEN August 6, 2019 at 8:07 pm
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 PackageAndrew August 7, 2019 at 9:18 am
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.
LVXICHENParticipantLVXICHEN August 7, 2019 at 6:41 pm
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！Andrew August 8, 2019 at 8:05 am
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).
You must be logged in to reply to this topic.