RAYNET in my area use EasyPAL to transmit images and other data. A limitation with this so far is that EasyPAL is only available for Windows. Thankfully this looks to change. PA0MBO has a DRM transceiver for Linux, TRXAMADRM. I thought I’d see if it would run on a Raspberry Pi.
Building
I downloaded Version 3.1 and removed the Windows version and the pre-compiled binaries for X86. I then checked the code into Git so that I can keep track of any changes. I installed the following packages on the Pi:
- libasound-dev
- libfftw-dev
- libusb-dev
- expect
- libtk-img
I then ran
./configure make
The build took quite a while, and left me with ARM binaries for the Raspberry Pi.
There are a few scripts present. The one that seems to work is startdrmtrx.sh. This produced the separate receive and transmit applications and a waterfall window.
Setting up sound
I have a Signalink USB connected via a powered USB hub. I don’t know how much current the Signalink draws. The Raspberry Pi has limited USB output current.
The sound device is selected by card number. Using alsamixer I was able to find that my Signalink USB adapter was card 1. I connected directly into the Signalink’s “Speaker” input from the headphone output of my netbook running EasyPAL and played waterfall texts until my callsign appeared clearly in the waterfall display.
It is not easy to set the input level. The transmit data is louder than the waterfall text data, so waterfall text is not a good way of setting levels. When the level is correct for receiving data, you should be able to see the four pilot signals as solid lines in the waterfall with the data as a nicely contained grey texture around it. If anything the screen shot shows an input that is too loud, but not so loud that the reception fails. I installed Audacity and used its input level meter and a short test recording to check that the input level was correct.
First Run
The picture in the image was provided with the software. Despite the promising results shown, I was not able to receive a whole image without asking EasyPAL to make multiple transmission attempts. TRXAMADRM does support the EasyPAL BSR mechanism to request retries. I didn’t have the sound output wired up to test this.
The problem seems to be CPU load, Some of that may come from the DRMTST back-end program which performs the decode, some from the TCL front end which uses Expect to parse the status information that it outputs at quite a high rate, some from the filesystem and IO writing the file. My Raspberry Pi also performs some network infrastructure duties, but load from these is low. The high load causes processing to pause, which causes input audio to be lost and decoding to fail.
Running the DRMTST backend on its own
The data is received by the program drmtst. This is controlled by an ini file, which is generated by the TCL front end. It also needs some other files from its working directory, so is run in the “linux” directory. The drmtst program produces the waterfall display and outputs a lot of information to the console. The console on the Raspberry Pi had difficulty coping with the load, so I redirected the program output to the /dev/null special device.
[sounddevices] devin=1
drmtst > /dev/null
The CPU load was reduced to about 50%. It was lower when the program was successfully receiving data. I was able to transmit in modes A and B and have the files received correctly. They appear in the picsrx folder, and are shown automatically in the Raspberry Pi’s file manager.
I also tested EasyPAL’s RS2 error correcting mode. The file was received with an rs2 extension and a separate utility provided with the application was used to decode it. The RS2 feature is designed to allow the image to be reconstructed from partial data. I don’t know how well this would work with an “incomplete” file in RXAMADRM.
RXAMADRM is useful as an EasyPAL receiver in this configuration.
Further Work
I have not tested transmit yet, or tested the system over a real radio link.
It would be useful to remove the waterfall display and the copious console output from the drmtst program. The output could be replaced with a much smaller status display showing that drmtst is receiving. The smaller drmtst could then be used as part of an automated process befitting of the Raspberry Pi.
I’m not much of a Linux user yet but I sure would like to see EasyPAL run on a PI.. I can just many applications for this combination. I look forward to seeing the progress.
It’s not something I’ve progressed with, or at the moment have much time to progress with.
It’s doable on the stock PI without overclocking. I think the device could be left to receive and hope it would transmit too. I expect the code could be made more efficient but found it hard to work through. It looked as if there was the HamDRM decoder designed to work with a specific input, and preprocessing to convert the actual input to work with it. Why not directly decode the input? There may be a clue at http://www.qslnet.de/member/hb9tlk/drm_h.html when it mentions “Carrier spacing: 1 / FFT_SIZE” remembering that a given size FFT gives the same number of frequency domain samples. Reducing the size of the transform means that the input has to be just right, but transforms are expensive.
Hi all,
Just starting to test on my PI.
./configure : no problemo
./make : takes long, but no errors
Running: was missing “Convert”, found out to be included in package “imagemagick”, did apt-get install and now TX-part seems to be working.
However the RX-part is NOT, beats me why… i get the errors:
Error in startup script: expect: spawn id exp8 not open
while executing
“expect {
“psd ” {
expect “\n” {
set plotdata $expect_out(buffer)
set plotdata2 [string trim $plotdata]
}
# if psd display is on
if { $disp == 3} { …”
(“while” body line 2)
invoked from within
“while { $stop == 0 } {
expect {
“psd ” {
expect “\n” {
set plotdata $expect_out(buffer)
set plotdata2 [string trim $plotdata]
}
# if psd display is…”
(file “./rxamadrm.tcl” line 731)
Still missing something here ????
Based on http://expect.sourceforge.net/FAQ.html#q65 it looks like the drmtst program is failing. Can you run drmtst directly and see if it gives any error messages? What are you using for receive sound device?
Hello Richard,
Thanks for your help.
I am using a 3D-sound USB-headset stick (c-media) therefore need a 2Amp HUB in front to deliver this extra .4 A power.
Usually works fine when using VLC-player, for instance; only have to set soundcard to “sysdefault” .
Yes, DRMTST fails, but message makes no sense to me:
Channels count (2) not available for record: Invalid argument
Setting of hwparams failed: Invalid argument
Where can I set the sounddevice to “sysdefault”, so it can detect ?
73 de PE1DFQ
I’ll have to log back into mine and look at the sound settings. I don’t remember doing anything to ALSA config, but I may have already had it set up for other experiments.
I don’t have any custom ALSA configuration, but I do have that modified rxamadrm.ini as shown above
[sounddevices]
devin=1
In fact my /etc/asound.conf file has been renamed to move it aside.
I ran alsamixer to find the sound card numbers and to ensure that volume controls were correct.
Hi,
Its strange, the Alsamixer tells me everything is fine.
When the USB-audio is not installed, 0= BC2835 and
when its installed after boot: 0=C-Media USB headset and 1=BC2835, so far OK.
But it does not see the MIC-part, so this could be the problem.
As I told before TXAMADRM is working fine, I can only transmit MODE= E / 2.2 KHz BW and 4QAM without problem, having more than 18 dB SNR (short range test at 21.4 MHz).
When I go to 16QAM the signal drops away regular, too high CPU load, therefore Clock-recovery (PLL) cannot stay locked (No FAC/MSC ).
Pity I cannot test the RXAMADRM part.
B.t.w QSSTV 7.1 is also working well with the sound device (TX and RX) , however too much load for a Raspberry PI !!
73
From what I remember of the code in TRXAMADRM it looks like it could be made more efficient, but it would take me a fair amount of time with my head stuck in my old DSP text books to do it. It looks like software designed to work with a 12kHz IF signal has been adapted to work with the narrow 2.5kHz amateur signal by shifting the amateur signal up to the expected intermediate frequency before decoding.
Perhaps if the decoding logic could be made to work at the lower frequencies, directly on the input signal. Also if it is using multiple decoders in an OFDM configuration, would it be possible to adjust the decoder frequencies to work with what’s there rather than try to manipulate the input signal to match what they expect? Or maybe I’ve forgotten too much about DSP!