Splitting the 'backend' and 'frontend' is a good idea. This means one lump of code can be used in a headless situation on something like a RPi, and a 'client' can connect in if you want to see statistics, or perhaps control a few parameters. Hopefully somewhat less duplication of code.
I have done this in the past by piping the JSON stats output from fsk/horus_demod via UDP into another process, it worked pretty well, but that was only one-way. Good enough for my applications though. Also, in terms of CPU usage, my Horus GUI (PyQt5 + C library for the demod) is actually using less CPU on my desktop than FreeDV doing the same demodulation, which I found a bit surprising! Haven't tried it on a RPi, but I would generally operate 'headless' in those situations. 73 Mark VK5QI On Sat, Jul 11, 2020 at 6:36 AM David Rowe <[email protected]> wrote: > Thanks Mark, yes I have been pondering those approaches. Another option > is a small C++ GUI (if such as thing is possible) - to make it all one > application. There is some attraction to using C on small platforms > rather than C and Python. > > Also considering splitting the GUI and FSK Rx across a network using > sockets. A typical use case will be connecting to the Pi from a more > powerful host machine to debug the radio IP link, then leaving the Pi to > run headless. > > In this case rtl_fsk could send debug info to a UDP or TCP port, and we > could use a JSON or similar approach to move the data over the socket as > you mentioned below. That would keep it quite "light" on the > embedded/rtl_fsk side of the system. > > - David > > On 10/7/20 5:56 pm, Mark Jessop wrote: > > We kind of solved this problem in the Wenet project: > > https://github.com/drowe67/codec2/blob/master/octave/fskdemodgui.py > > > > It needs the FSK stats output in JSON format, like what fsk_demod and > > horus_demod produce. > > # Call using: > > # <producer>| ./fsk_demod --cu8 -s --stats=100 2 $SDR_RATE $BAUD_RATE - > > - 2> >(python fskdemodgui.py --wide) | <consumer> > > > > It'll show frequency estimators, FFT output, Eb/N0 estimates, all live. > > > > I'm doing similar in a much cleaner manner within a new project > > here: > https://github.com/projecthorus/horus-gui/blob/master/doc/horusgui_screenshot.png > > However i'm doing the audio FFTs myself, as I wanted a bit more > > customization in the update rates and resolution. I am overlaying the > > frequency estimator data, which provides a really nice feedback on what > > the modem is doing. > > > > 73 > > Mark VK5QI > > > > On Fri, Jul 10, 2020 at 12:04 PM David Rowe <[email protected] > > <mailto:[email protected]>> wrote: > > > > I've now developed an integrated Rx/fsk demod application, so on the > Rx > > side you can do something like: > > > > rtl_fsk -g 1 -f 144490000 - | fsk_put_test_bits - > > > > However I feel I'm flying blind without some sort of GUI to monitor > the > > received signal. Something similar to previous Python scripts > > should do. > > > > Jereon - now that I'm linking with libcodec2 it's not far off being > able > > to use your VHF packet system with TAP as well at Tomas' TUN design. > > > > It's also not far off being a FreeDV receiver, we could pipe the > decoded > > audio to the Pis sound card. A transceiver could be implemented too, > > using rpitx. > > > > Cheers, > > David > > > > On 9/7/20 7:03 pm, Tomas Härdin wrote: > > > Hi > > > > > > Cool, I'll have to take a closer look at this. > > > > > > What I suspect may get tricky is the higher-level protocol stuff. > It's > > > possible to just use straight-up Ethernet and frequency > > multiplexing to > > > avoid some of the problems that WiFi solves. At lower baudrates > some > > > thought has to be put into header compression I think. > > > > > > I'm busy with uni things at the moment, hopefully more time should > > free > > > up for this in the coming month or so. > > > > > > /Tomas > > > > > > tor 2020-07-09 klockan 18:40 +0930 skrev David Rowe: > > >> Further to this I have created a new repo, added instructions, and > > >> started integrating the various command line applications > together: > > >> > > >> https://github.com/drowe67/pirip > > >> > > >> Next step is to link rtl_sdr and the fsk demodulator into one > > >> application. > > >> > > >> - David > > >> > > >> On 22/6/20 7:39 am, David Rowe wrote: > > >>> Some good progress on support for VHF/UHF data using Codec 2 > > >>> modems: > > >>> > > >>> http://www.rowetel.com/?p=7207 > > >>> > > >>> - David > > >>> > > >> > > >> _______________________________________________ > > >> Freetel-codec2 mailing list > > >> [email protected] > > <mailto:[email protected]> > > >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > > > > > > > > _______________________________________________ > > > Freetel-codec2 mailing list > > > [email protected] > > <mailto:[email protected]> > > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > > > > > _______________________________________________ > > Freetel-codec2 mailing list > > [email protected] > > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > > > > _______________________________________________ > > Freetel-codec2 mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
