[OZAPRS] HF APRS -2

Matthew Cook vk5zm at bistre.net
Tue Dec 19 10:54:13 AEDT 2017


Yes of course, there are separate i2s ports on the 40 way connector you can
implement your own sound card or the USB if you would like to use a low
cost syba dongle.

However if you were to cook/smoke the internal sound card then the same
would have occurred to an external one.

Killing a sound card means that you didn't put the current back from where
you got it from (first law of RF design), which usually results from not
paying attention to grounds or RF sneak paths under fault conditions.  The
cheat is to use galvanic isolation between the modem and radio input, which
isn't always necessary YMMV.

73

Matthew
VK5ZM

On 19 December 2017 at 09:57, Carlos Peco-Berrocal <carlos.peco at gmail.com>
wrote:

> Can you still use external sound cards with the Tinkerboard ?
> What if you cook the internal one ?
>
> cheers
> Carlos
>
>
>
> On Tuesday, December 19, 2017, Matthew Cook <vk5zm at bistre.net> wrote:
> > Cool.. well that means I've got a suitable test bed ready and waiting.
> > The receiver I've got lined up has a full rockwell collins 3kHz IF
> filter (not 2k7 or 2k4 like most japanese radios) so that should work
> nicely.
> > Time to start working out how to get the levels and drive right,
> something for me to do over xmas.
> > 73
> > Matthew
> > VK5ZM
> > On 19 December 2017 at 09:24, Glen English VK1XX <
> glenlist at pacificmedia.com.au> wrote:
> >>
> >> The original would run about 3kHz search window at full 'gain' on a C1
> (quad A5).
> >>
> >> The XU4 would smoke it at 10kHz BW. The out of order reordering CPU
> really smokes. but it also smokes the power supply.
> >>
> >> The C2 would run a 10kHz search window IRRC.
> >>
> >> I have some TV boxes with RK3288s and they also are excelllent
> processor.
> >>
> >> good on the internal sound card.
> >>
> >> code currently only uses the 2010 grade NEON, not the new v8 NEON
> AArch-64 etc on the A53 etc .
> >>
> >>
> >> g
> >> On 19/12/2017 9:39 AM, Matthew Cook wrote:
> >>>
> >>> 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 <mailto: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>
> >>>         <mailto: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/>
> >>>             <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>
> >>>         <mailto: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>
> >>>
> >>>         <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>
> >>>                 <mailto: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>
> >>>         <mailto: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>
> >>>                     <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>
> >>>         <mailto: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>
> >>>             <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 <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
> >
> >
>
> _______________________________________________
> 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/d65858f8/attachment-0001.html>


More information about the OZAPRS mailing list