Glen English VK1XX glenlist at pacificmedia.com.au
Tue Dec 19 07:12:33 AEDT 2017

Good discussion

yeah a small drop on PCB would be simple. I THINK that later Cx ODROIDS 
are header-compatible with the R-PI headers.

after madly writing debugging python modules all day yesterday, and 
remembering how to write ODBC expressions heading out to do some mobile 
survey work and will get back on the case at xmas.

SNR requirements are very low, so sound card quality is pretty 
unimportant except that the sample rate clock should be better than a 
free running LC...

I will do a full writeup while familying with emily's family up north at 

The demodulator requirements are proportional to the recv bandwidth 
search window, the frequency step search, the sync threshold, and the 
LDPC FEC "gain control".

The whole spectrum is step frequency searched with a matched 
filter-correlator for my sync word which provides the next stage time 
and frequency offset data. When a sync detection is triggered, the time 
and frequency offset of this "candidate" is pushed into a FIFO and  is 
passed to stage 2, and that stage goes about extracting the samples from 
a deep buffer  and attempting decoding. Stage 1 sync works on about 1 
second of audio data, stage 2 works on about 10 seconds worth.

Using an STM32F7 there would be enough memory to implement the 
demodulator with reduce peformance but stil very useable (say +3, +4 dB 

Pi Zeros probably on par with a STM32F7, the old ARM11 architecture is 
pretty slow.

Cache misses is what hurts the implementation. Care is taken not to 
abuse the cache, but the system operates by searching all over a large 
buffer so memory misses are part of the game.

The existing implementation is 46.875 bps (48000/1024) however the bit 
rate can be change by simply changing a $define DIVIDER to anything you 
like. I was thinking 48000/512 was a good starting point.

This permits multiple use of a channel. a sideband channel can fit alot 
of 50Hz or 100 Hz wide signals, and the demod is designed to deal with 
it. I would say the end performance is something like PSK31 but with 
reduced SNR requirements. You can push it right down to 0dB SNR but the 
demodulator ends up spending a bunch of time in stage 2 attempting to 
demod candidates that are really noise ... CPU requirements increase.

On 18/12/2017 10:04 PM, Matthew Cook wrote:
> That interface card is hideously expensive for what it is;
> Other options;
>   * The wolfson sound card is less than a third that price including
>     shipping from E14, however a syba USB sound card is less than $5
>     from eBay.
>   * PTT is just a transistor of an I/O pin, preferably with a h/w
>     monostable timer to prevent locking the transmitter on; I still
>     don't trust Pi's with 100Wpep of HF present, box or no box.
> Personally I'll be trying a Tinkerboard first since it has onboard 
> microphone and audio, more grunt that a Pi-3, wifi, BT, I/O and serial 
> ports. In my case I can read the GPS from within the HF transceiver, 
> which is already shared three times in the back of the car already.
> However will still experiment with STM32 option since this would make 
> a very nicely integrated option in the new year.
> 73
> Matthew
> On 18 December 2017 at 20:57, Mark Jessop <lenniethelemming at gmail.com 
> <mailto:lenniethelemming at gmail.com>> wrote:
>     David Giddy has reminded me off-list of the existence of the
>     UDRC-II: http://nwdigitalradio.com/product/udrc/
>     <http://nwdigitalradio.com/product/udrc/>
>     This is pretty much what I was looking for, with the exception of
>     the onboard GPS. A little bit pricier than I was hoping for, but
>     time vs money and all that...
>     Would require a bit of coding to make whatever modem Glen writes
>     key to the relevant GPIO pins, but hey - open source, and I'm more
>     than happy to write and test code :-)
>     73
>     Mark VK5QI
>     On Mon, Dec 18, 2017 at 7:35 PM, Mark Jessop
>     <lenniethelemming at gmail.com <mailto:lenniethelemming at gmail.com>>
>     wrote:
>         Given the cost of boards like the Raspberry Pi Zero, and other
>         similar boards, I don't see it being targeted at ARM-NEON
>         being that big of a deal.
>         I guess a good product to complement the modem would be a
>         'shield' (or hat, or cape, or whatever the kids call them
>         nowadays), for a raspberry pi or similar, that includes:
>         - An Audio codec chip (probably via I2S? Example DAC board
>         here, but no ADC:
>         https://core-electronics.com.au/pimoroni-phat-dac-for-raspberry-pi-zero.html
>         <https://core-electronics.com.au/pimoroni-phat-dac-for-raspberry-pi-zero.html>)
>         - PTT interface (relay? FET?)
>         - Maybe even a GPS unit? (Something like a uBlox MAX-8 would
>         go nicely)
>         Of course you can do a lot of this with a USB sound card and
>         some external circuitry, but I like the idea of a
>         self-contained unit that you could mount in a small box.
>         I might look into parts for such a board over the holidays, if
>         I'm not too busy chasing balloons at Mt Gambier...
>         73
>         Mark VK5QI
>         On Mon, Dec 18, 2017 at 1:22 PM, Glen English VK1XX
>         <glenlist at pacificmedia.com.au
>         <mailto:glenlist at pacificmedia.com.au>> wrote:
>             Matthew Cook asked me about the hardware and STM32 :
>             STM32F7 MIGHT run the decoder, for narrow bandwidth search
>             windows and slightly higher SNR requirements (+1 dB say) .
>             The search algorithm is intensive and the LDPC decoder is
>             hard work, also. But there is a nice vernier control on
>             the "how hard it tries" to control CPU usage.
>             STM32-anything will definitely run the encoder (lots of
>             LUTs in FLASH)
>             (it already is implemented on STM32L151 back in 2014)
>             talk soon when I am not so flat out
>             cheers
>             _______________________________________________
>             OZAPRS mailing list
>             OZAPRS at aprs.net.au <mailto:OZAPRS at aprs.net.au>
>             http://lists.aprs.net.au/mailman/listinfo/ozaprs
>             <http://lists.aprs.net.au/mailman/listinfo/ozaprs>
>     _______________________________________________
>     OZAPRS mailing list
>     OZAPRS at aprs.net.au <mailto:OZAPRS at aprs.net.au>
>     http://lists.aprs.net.au/mailman/listinfo/ozaprs
>     <http://lists.aprs.net.au/mailman/listinfo/ozaprs>
> _______________________________________________
> OZAPRS mailing list
> OZAPRS at aprs.net.au
> http://lists.aprs.net.au/mailman/listinfo/ozaprs

More information about the OZAPRS mailing list