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
