Matthew Cook vk5zm at bistre.net
Tue Dec 19 09:39:27 AEDT 2017

It will be interesting to see how this code goes on different platforms.

I've been looking at the Odroids C2 (quad A53 @1.5GHz), C1+ (quad A5 at 1.5GHz)
& XU4 (quad A15 at 2.1GHz + quad A7 at 1.4GHz) there is no doubt the XU4 has some
serious grunt.

However the ASUS Tinkerboards I've got at home have a RK3288 which is a
quad A17 running at 1.8GHz also featuring a Neon Co-pro! So on paper this
should give the C1+ and C2 Odroids a bloody nose in a MIPS fight or at
least a run for their money.

What I really like about the Tinkerboards is they have an inbuilt sound
card (192kHz)/24bit) for both record (microphone) and playback (stereo out)
for the same money as an Odroid.   So that would just leave me needing to
build a suitable PTT circuit with h/w timeout.

It will be interesting to see just how hard I can push one of these
Tinkerboards, for ~A$85 delivered to VK they seem good value.

The plot thickens.



On 19 December 2017 at 06:42, Glen English VK1XX <
glenlist at pacificmedia.com.au> wrote:

> 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
> xmas.
> 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 CNR).
> 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
>> VK5ZM
>> 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-raspbe
>> rry-pi-zero.html
>>         <https://core-electronics.com.au/pimoroni-phat-dac-for-raspb
>> erry-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
> _______________________________________________
> OZAPRS mailing list
> OZAPRS at aprs.net.au
> http://lists.aprs.net.au/mailman/listinfo/ozaprs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aprs.net.au/pipermail/ozaprs/attachments/20171219/d26fc9d8/attachment-0001.html>

More information about the OZAPRS mailing list