John Melton G0ORX/N6LYT

Saturday, August 27, 2016

pihpsdr hardware development

From my early prototype:

To the first Apache Labs PCB (mounted on some wooden stands):

To the production unit:

Saturday, June 11, 2016


Having received an early LimeSDR courtesy of Lime Micro, thanks to Andrew Back and Ebrahim Bushehri, I wanted to see if I could get it working with some of the code I had been developing specifically for the Raspberry Pi 3 with a 7 inch touch screen and HPSDR compatible radios.

The first job was to put the LimeSDR into a small case to protect it.

The second job was to install gqrx on my Intel i5 system and test the board out and to investigate the use of SoapySDR as the method of communication with the device.

I downloaded the source code for SoapySDR and for LimeSuite and built them.  This would be a good learning curve as I would have to do that on the Raspberry Pi.  As it happens this was a fairly simple operation.

The code for the application was already designed and written to run with multiple protocols to communicate with the radio.  The protocol used with HPSDR radios has a new protocol in development and I had implemented both the existing protocol and  the new protocol.  Adding an additional protocol based on SoapySDR was fairly easy.

The existing code discovers what devices are on the network that it can communicate with.  I added a similar module to list the USB devices found with SoapySDR.

In the above screen grab the discovery has found 3 HPSDR devices on the network and the LimeSDR on USB.

The Configure button lets the user select the sample rate and some screen configuration options.  The Raspberry Pi can have encoders and push buttons in which case the controls are not needed at the bottom of the display. The Start button starts the application running with the selected radio.

This screen grab shows the LimeSDR tuned to 126.825 MHz in the air band and running at 384K samples.  I live close to Gatwick Airport so there are plenty of signals the test a radio with.

Note that the signal strength meter has not been calibrated yet with this radio.

The only LimeSDR specific option coded is to select the antenna connection on the LimeSDR.

Next steps are to get the code running on the Raspberry Pi and to add transmit capability to the LimeSDR code and see if I can make a contact on 2Mtrs and 70cm with the ultimate goal of making a satellite contact.

Note that the Raspberry Pi does not have USB 3.0 but should work with restricted sample rates.  We have run it at up to 384K with the HPSDR devices.

The code is written in C using GTK+ for the UI.  The DSP engine is WDSP, written by Warren Pratt NR0V, that I have ported from Windows to Linux.

Thursday, May 05, 2016

Odyssey SDR transceiver

A problem had been found trying to use my Android software with the Odyssey transceiver developed by David Fainitski so he offered to loan me one to help find the bug.

The problem was that the start command being sent to the HPSDR device should be 64 bytes long and there was a typo in my code so the buffer was 84 bytes.  The HPSDR devices were obviously not checking the packet length so were processing the start message.  David's code was more strict so was discarding the message and as a result would not send any I/Q or mic data to the client.

I was able to run some tests using an Odyssey SDR transceiver using both the Android application and my new piHPSDR code.  The piHPSDR code was correct so did work with no problems with Odyssey.

The discovery process detects Odyssey as a Hermes device.

When started it ran perfectly as can be seen from the screen dump below.

I have to complement David on the Odyssey.  It is a very small package and is well built.

Thursday, April 07, 2016

Raspberry Pi Update

Good progress is being made with the Raspberry Pi.  I now have a Raspberry Pi 3 as well as the 2 and also the official Raspberry Pi 7 inch touch screen.

This is a screen dump of the latest UI. The code now supports 4 rotary encoders and 8 switches.

The latest version of WDSP has now been ported over to Linux and some of the new features have been implemented in the UI including the panadapter detector and averaging functions.

I have had good signal reports on the air and several mentions of good audio, which is mostly thanks to the wdsp code.

Running at 96000 I am seeing the following when running "top -H -p ".  The -H option shows all the threads separately, so you can see there are 9 threads running which get shared around the 4 processors.

Still more work to do, but progress is going well.

Saturday, January 02, 2016

Pi 2 CPU Utilization

This is the system monitor from the Raspberry Pi 2 running my HPSDR software.  It looks like the threads are being distributed among the 4 cores.

This screen shot was taken while running at 48000 sample per second, using an Orion v1 board (as is currently in the ANAN-200D) with  Alex filters. Currently there is no PA attached. The Orion is running the new Ethernet protocol.

The Raspberry Pi 2 is being over clocked at 1GHz and has a 5 inch LCD touch screen attached with a resolution of 800x480 and a 600 ppt optical encoder for tuning.  It is all enclosed in a small aluminium enclosure. I have also included a DC-DC converter to supply the 5 volts for the Raspberry Pi 2 from the 13.8v supply.

Monday, December 21, 2015

Raspberry Pi 2

The latest Raspberry Pi 2 Model B now boasts:
  • Broadcom BCM2836 ARMv7 Quad Core Processor powered Single Board Computer running at 900MHz
  • 1GB RAM so you can now run bigger and more powerful applications
As an experiment I have put one together with a 5 inch HDMI LCD Touch screen with a resolution of 800x480 along with a rotary encoder (800 P/R) for the tuning control.

The RPi is running Raspian Linux and is capable of running up to 96000 samples per second with no problems when the RPi is over clocked to 1GHz.

The software I am running is based on the code for ghpsdr but is implementing the new Ethernet protocol and has a different UI interface built, but still using GTK+.

The latest source code for wdsp has been ported, although currently not all the newer features are implemented.

A short video is available on YouTube.

The source code is not yet available, but will be soon along with instructions on how to install the software and drivers required for the screen and rotary encoder.

Wednesday, June 17, 2015

NVIDIA Shield CPU Usage

This image shows the CPU utilization on the NVIDIA Shield running the Android openHPSDR application.  The version running has WDSP and FFTW3 built for 64 bit Arm.  Looks like it has plenty to spare.

Click image for full size