Forums › SA Series Discussions › USB-SA44B and beagleboard
- This topic has 17 replies, 6 voices, and was last updated 9 years, 2 months ago by tyutfmz.
- AuthorPosts
marholtParticipant- This topic was modified 9 years, 6 months ago by marholt.
I want to measure channel power with USB-SA44B and beagleboard.
I’m using angstrom linux. Channel frequency is 474MHz, span 12MHz, Bandwith 8MHz.
When I compared the speed of measurement between linux and Windows, in windows is 10 times faster (~450 msec) . In linux measurement takes about 4 seconds.
Settings are the same. Code for linux included. What am I doing wrong?Attachments:
You must be logged in to view attached files.
AndrewModeratorHello marholt,
The speed of measurements is going to be correlated with the speed of the processor. We also experienced long sweep times and measurements when using the Beagleboard.
Regards,
A.J.
marholtParticipantWe need a portable small solution for measurement, that is why we tried beaglebone, but the sweep time is to big and now I’m searching for antoher soluion.
Did you try Raspbery pi instead of beaglebone? The new raspberry will also support windows.
http://makezine.com/2015/02/02/microsoft-windows-support-raspberry-pi-2/Do you have another solution that can replace beaglebone and speed up sweep times?
AndrewModeratorHello Marholt,
Thank you for the follow up. We have not tried other small portable solutions such as the Raspberry Pi or other alternatives. Might I suggest an x86 alternative such as a tablet or netbook with an Atom processor or Celeron processor? There might be x86 single board computers that work, I believe Intel has released a few in the last couple of years below $100. We just released a major update to our SA44 API which is compatible with x64 and x86 processors. This is the route you might have to take if you are looking to avoid longer sweep times.
If you have any further questions, let me know.
Regards,
A.J.
BruceModeratorHi Marholt,
We have successfully used the Dell Venue 8 Pro tablet with the Spike 32-bit version 3.0.2 and saw minimal slowdown in the sweeps. The user interface is small however so you would probably want to use a stylus pen for navigating.
marholtParticipantThank you for the info.
We are searching for new board that will have x86 or x64 processor.I’m trying now to compile the 32-bit linux version api (https://signalhound.com/sigdownloads/SA44B/linux_shapi_x86.zip)
but compiler is showing an error that the library libSHLAPI.a is incompatible with x86.
“i386:x86-64 architecture of input file `libSHLAPI.a(myFFT.o)’ is incompatible with i386 output”
AndrewModerator- This reply was modified 9 years, 6 months ago by Andrew.
Thank you for the heads up on the Linux API. I can look into it. Are you looking to stay on Linux or use Windows to take advantage of the new API updates?
Our Linux APIs (non-ARMs) required low-latency kernels and do not include any updates made over the last couple of years.
Regards,
A.J.
marholtParticipantWe are trying to stay on linux.
marholtParticipantWhat is the status with windows libraries updates?
I’m developing an aplication, that will measure channel power and some other sensor measurement (like temperature, GPS position…) and save does measurement to a file for later analasys.
AndrewModeratorHello Marholt,
The Windows libraries have received a major update over the last couple of weeks. You can get the libraries by downloading the Spike software package here. signalhound.flywheelsites.com/spike You can find the library file and API manual in the api folder in the application directory after installation. The API does not provide channel power measurements directly but returns sweeps on which you can perform your channel power measurements.
Regards,
A.J.
dbretonParticipant- This reply was modified 9 years, 6 months ago by dbreton.
Hi A.J. et al,
I am also trying to get the Signal Hound to work with embedded linux, specifically the TS-7670. I’ll simply be logging the output to files, no GUIs involved.
I am having a similar problem with the libSHLAPI.a file, though my machine/compiler complains:
g++ CUSBSA.cpp -o USBSA.o g++ main.cpp CUSBSA.o libSHLAPI.a /usr/local/lib/libftd2xx.a -o test_shapi -lpthread -ldl -lrt libSHLAPI.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status
Is there any way I could get the source files that go into the .a library? I’d like to try to compile them on my machine to see if there is some weird architecture thing that is keeping this from working. Failing that (e.g. those libraries are proprietary or something) can I send you information about my processor and toolchain for cross-compiling?
Thanks in advance,
DAN
AndrewModeratorHello 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.
Justin CrooksModeratorIt looks like you’re using the 454 MHz ARM Freescale i.MX286? Unfortunately, we have no experience with this part. If our 32-bit x86 library and our ARM library both fail to compile, we most likely don’t support the architecture. We tried to satisfy the Linux embedded market with our Beagleboard ARM-based API, which works on a subset of ARM processors. I realize this is not an ideal platform for all customers. Most of our users connect the Signal Hound to a laptop or PC, so we have not had a high demand for embedded support, especially once users see how much slower it performs on a low power embedded platform.
dbretonParticipantGentlemen,
Thanks for your replies. I have tried the 64 and 32 bit x86 libraries, I am not sure that I have tried the ARM version associated with the Beagleboard.
I had no illusions about the sweep speed; that is not particularly important for my application. However, the ability to handle -40C (option 1), low power consumption and useful frequency range of the SA44 made it ideal for my project.
I’ll try to get a hold of the ARM library and give that a go, though I don’t see it listed on the SA44 download page anywhere…
Thanks,
DAN
AndrewModeratorHey 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.
dbretonParticipantHi A.J. and Justin,
Sorry I did not answer your question re: processor. Yes, I am trying to get this to work with the 454 MHz ARM Freescale i.MX286. I’d be willing to switch though if you have an industrially-rated, low power device that you can recommend. I’ve looked at the Blue Steel (can’t seem to buy one though…) and the various ‘bones at Special Computing. Do you think the industrially-rated Mentorel machines might work? https://specialcomp.com/beagleboard/bone.htm
Thanks for the link to the ARM build. I have downloaded and unpacked it and now am trying to compile a simple test code. The code and my attempt to compile it are attached. Basically, it looks like some kind of issue with the FTDI driver. I am using the latest driver version from the FTDI website, and did not have any issues with it on the 32-bit build.
Thanks for your time,
DANAttachments:
You must be logged in to view attached files.
Justin CrooksModeratorDan,
You will probably want to use the most powerful Beagleboard you can get your hands on. The ARM processor has to be powerful enough to perform thousands of FFTs per sweep, and keep up with 2 megabytes per second of data from the device, where very little latency is tolerated.
tyutfmzParticipantHi Dan
I got the same problems,Can you leave your email?We can discuss it togeter.
thinks
tyut- AuthorPosts
You must be logged in to reply to this topic.