M17 Project Forum

Full Version: Last stream/packet BER publishing
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi, 
   I've been thinking a bit about the M17 protocol and I think it would be also very good for a transmitter to publish the BER of the last received stream/packet as part of the protocol. 

This  information could be send preceding the next transmission or after some timeout if the channel goes idle.

This would only be a RF-LINK thing between direct tranmistters/receivers and would not extend to internet linking as it only makes sense at the RF level. 


This also gives the previous transmitter that has just gone quiet enough time to turn around and be ready to receive an indication of theBER for its last transmission . 

On the turn around of a link (i.e. a repeater)  this would allow all clients to gets an indication of the BER or some other performance metric of the last stream/packet received by the repeater

It would allow users to have a very good indication their link reliability and in the case of a repeater, show which segment of the link is performing  poorly..   the uplink to the repeater or the downlink to the receiver(s). 


With a few tweaks to the protocol we could add support for a high rate codec2 voice and low rate codec2 voice... with the low rate using a lower codec2 rate and adding much more redundancy to the bitstream.

This keeps the fundamental bit rate of the link consistent, but for the low rate adds much more energy per bit for a more reliable copy with a lower codec2 rate. 

I see this beneficial as it gives you a high performance or a high reliability option.    As with digital systems, when you approach a certain error rate the performance falls off a cliff.  

This high/low rate would be used generally with the high rate/high performance in normal conditions, however it gives users the option to switch to the low codec2 rate/ high reliability link to finish the QSO gracefully when things get marginal. 


I expect it would also be desirable to have a high rate/ low rate encoding for packets as well.   In the case of APRS or other unidirectional transmissions, the low rate/ reliable option may be used as there is no acknowledgements.  Better spend a few more bits to get a reliable transmission, especially for low power trackers and alike. 


However for protocols link TCP/IP where there is inherent ack/nak in the protocol or in a well dimensioned fixed (non mobile)link, the extra performance of a high rate can be utilized reliably. 


Whilst something like this does not  have to be entirely specified now, adding a bit for highrate/lowrate convolutional encoding may facilitate the extension of the protocol to support this. 


Please note that this is only in relation to the extra redundancy in the convolutional encoders... the physical layer remains identical so that the bit modems can do their thing and it is all handled in the datalink layer. 


This is not a well formed proposal, however I would like to get ideas from others as to why this would be a good idea or reasons as to why it is not. 


Thought?   



 Best Regards, 
David  VK3DCU
D-Star already has (at least within the MMDVM) something similar to this. D-Star has an already defined acknowledgement transmission which was extended to include this extra information. The same could easily be done for M17, how this BER (and maybe RSSI at the repeater) is interpreted within the transceiver is another matter. If we could fit the BER and RSSI into one META field (14 bytes) then the M17 transmission needed could be very short indeed, essentially a header frame and an end of stream frame.