[OZAPRS] HF APRS -2
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.
73
Matthew
VK5ZM
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