Hi Jeroen, I place code that requires updates in:
void MainFrame::OnTimer(wxTimerEvent &evt) ...with various methods for maintaining state (like global pointers and member variables). Cheers, David On 2/6/20 6:35 am, Jeroen Vreeken wrote: > So the first part was easier then I thought. > > The m600 branch of https://github.com/JeroenVreeken/freedv-gui adds > support for both mode 6000 (transmit successfully tested) and the > ability to create a TAP device. > > Currently the TAP device will only receive packets. (from radio to TAP) > wxwidgets is new for me and I have not figured out how to hook the TAP > filedescriptor to its event loop (or whatever they call it). Anybody got > some pointers? > > Regards, > Jeroen > > On 05/31/2020 09:16 PM, Jeroen Vreeken wrote: >> On 05/30/2020 10:35 PM, David Rowe wrote: >>> Hi Jeroen. >>> >>> OK I think I see how that all sticks together (I'm climbing the learning >>> curve out from the physical layer!). Do you have a PR/link with some >>> code we we can run to try out your system? For example I don't know how >>> to set up TAP/TUN and need a demo/starting point. >> You could use https://github.com/JeroenVreeken/eth_ar >> But it is probably overkill right now. There is enough code in there to >> run an entire mixed mode repeater.... >> (And poorly documented :) >> >> All communication to other programs (e.g. handling linking via DML) are >> handled via the TAP device. >> Different data simply has a different ethernet type. >> e.g. if a packet is received with ethertype 7308 its contents will be >> regarded as codec2 mode 700C data (I simply added 7300 to the existing >> codec mode..). In eth_ar.h you can see various definitions for different >> voice and data types. >> Any voice frames will be handled seperatly in the code: either >> tranmitted using freedv_rawdata_tx or as analog baseband out. >> Frame types that are not recognized as voice will go to the data >> callbacks and freedv_data_tx is used >> E.g. any IP packet will go to the data callbacks. >> >> The TAP interface is actually relativly small (interface.c): >> - open /dev/net/tun >> - Use the right ioctls and you create a new 'ethernet' based TAP device >> - hook freedv data callbacks to sending/receiving on the device. >> >> Most code is actually involved in other stuff: >> - sound devices (opening, choosing whether to use left/right, etc) >> - rig interfaces (hamlib) >> - state machines: >> + tx_delay (wait with important data until transmitter is really >> transmitting) >> + tx_tail (don't switch of transmitter before all data is on the air) >> + choosing between data or (analog) voice? (voice has preference in >> most cases) >> - simplex or fullduplex >> - in case of fullduplex: repeat incomming voice? >> - morse beacon >> >> It is also what makes a simple demonstrator hard. >> I can make a really simple example, and it will work perfectly for my >> setup, but not for anyone else. >> >> I am looking at another way though: I am currently extending freedv-gui >> to allow the use of mode 6000. >> A thing I have been thinking of is to add support for opening a TAP >> device for data. >> The nice thing about freedv-gui is that it also already does most of the >> 'other stuff' I mentioned above.... >> It would mean that the user running the gui has to have privileges to >> create a network device, but one could get started with freedv and data >> quickly (while still being able to use it as a voice system) >> >>> To support the HF data use case, I'm adding support for longer frames >>> to the OFDM modem. This will eventually result is new FreeDV modes that >>> are oriented towards packets of data, rather than voice. We could also >>> do this for the VHF use case - in particular the addition of FEC over >>> FSK modems, or running OFDM on VHF links for bandwidth efficiency. >>> >> That would work out fine, these modes can skip most of the current >> framing/deframing code as a packet is already 'whole', but still use the >> data callback functions. Adding and checking a CRC is probably still a >> smart thing to do, FEC works almost like magic, but still not perfect.... >> So the freedv api already supports them! >> >> Regards, >> Jeroen >> >> >> >> _______________________________________________ >> 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
