This PR includes several changes that fix bugs and enhance capabilities, mostly relevant to FEC ProtocolMode. The Memory ARQ improvements should also improve performance in ARQ ProtocolMode when data frames are repeated due to a received DataNAK.
Issue #34 appears to have been caused by a mistaken comment in ProcesReceivedData() in TCPHostInterface.c. This comment incorrectly described the expected format of data passed to ardop via the TCP data port. A host program following the information provided in that comment would have produced the problem described in Issued #34. That comment is corrected.
Earlier versions of ardopc and ardopcf contained code intended to permit sequential received data frames of the same type to be correctly decoded and their contents passed to a host program when in FEC mode. However, that functionality was broken. Code in SoundInput.c related to Memory ARQ was designed for ARQ mode, in which sequential received data frames of the same type can be assumed to be repetitions of the same frame such that they can be discarded if that frame has already been successfully decoded. This problem was identified in Issue #33. This PR mostly fixes that issue by evaluating possibly repeated FEC data frames and only discarding them if the contents perfectly match the last data frame received. This works well when received frames are able to be reliably decoded.
Unfortunately, when FEC frames, especially multi-carrier frames, cannot be fully decoded the first time they are received, there remains a possibility that different frames will be mistakenly interpreted as copies of the same frame. This can inhibit decoding and in rare circumstances result in invalid received FEC data containing fragments from two or more data frames being mistakenly interpreted as valid data. Efforts to mitigate this problem are made, but the limitations of the Ardop protocol do not allow this possibility to be completely eliminated without disabling all Memory ARQ functionality. Host programs using FEC data should consider implementing higher level message validation protocols to detect and respond to such errors.
It is believed that the problems fixed by this PR could have caused the symptoms described in Issue #35. That Issue describes repetitions of earlier data being passed to the host in place of newly received data. This may have been a case of data from two frames being mistakenly combined. As described above, the likelihood of this occurring has been reduced, but in rare cases it might still occur.
Earlier versions of ardopc and ardopcf implemented Memory ARQ capabilities. This is intended to use data collected from repeated transmissions of the same data frame to allow it to be correctly decoded when no single copy could be decoded by itself. However, this capability was only partially implemented, and there were bugs in some of that implementation which prevented it from working as well as intended. Those bugs are fixed, and Memory ARQ is now applied to all carriers in all data frame types. This significantly improves the success rate when receiving repeated copies of the same data frame under poor conditions. Such repeated frames occur whenever FECREPEATS is set greater than zero in FEC mode and whenever an ARQ data frame is repeated upon receiving a DataNAK.
A minor change was made to the behavior of the host interface in FEC mode. If "FECSEND TRUE", which is used to initiate transmission of FEC data, fails to send any data, then a FAULT message is passed to the host. Previously, the host was not notified that a failure had occurred.
This PR includes several changes that fix bugs and enhance capabilities, mostly relevant to FEC ProtocolMode. The Memory ARQ improvements should also improve performance in ARQ ProtocolMode when data frames are repeated due to a received DataNAK.
Issue #34 appears to have been caused by a mistaken comment in ProcesReceivedData() in TCPHostInterface.c. This comment incorrectly described the expected format of data passed to ardop via the TCP data port. A host program following the information provided in that comment would have produced the problem described in Issued #34. That comment is corrected.
Earlier versions of ardopc and ardopcf contained code intended to permit sequential received data frames of the same type to be correctly decoded and their contents passed to a host program when in FEC mode. However, that functionality was broken. Code in SoundInput.c related to Memory ARQ was designed for ARQ mode, in which sequential received data frames of the same type can be assumed to be repetitions of the same frame such that they can be discarded if that frame has already been successfully decoded. This problem was identified in Issue #33. This PR mostly fixes that issue by evaluating possibly repeated FEC data frames and only discarding them if the contents perfectly match the last data frame received. This works well when received frames are able to be reliably decoded.
Unfortunately, when FEC frames, especially multi-carrier frames, cannot be fully decoded the first time they are received, there remains a possibility that different frames will be mistakenly interpreted as copies of the same frame. This can inhibit decoding and in rare circumstances result in invalid received FEC data containing fragments from two or more data frames being mistakenly interpreted as valid data. Efforts to mitigate this problem are made, but the limitations of the Ardop protocol do not allow this possibility to be completely eliminated without disabling all Memory ARQ functionality. Host programs using FEC data should consider implementing higher level message validation protocols to detect and respond to such errors.
It is believed that the problems fixed by this PR could have caused the symptoms described in Issue #35. That Issue describes repetitions of earlier data being passed to the host in place of newly received data. This may have been a case of data from two frames being mistakenly combined. As described above, the likelihood of this occurring has been reduced, but in rare cases it might still occur.
Earlier versions of ardopc and ardopcf implemented Memory ARQ capabilities. This is intended to use data collected from repeated transmissions of the same data frame to allow it to be correctly decoded when no single copy could be decoded by itself. However, this capability was only partially implemented, and there were bugs in some of that implementation which prevented it from working as well as intended. Those bugs are fixed, and Memory ARQ is now applied to all carriers in all data frame types. This significantly improves the success rate when receiving repeated copies of the same data frame under poor conditions. Such repeated frames occur whenever FECREPEATS is set greater than zero in FEC mode and whenever an ARQ data frame is repeated upon receiving a DataNAK.
A minor change was made to the behavior of the host interface in FEC mode. If "FECSEND TRUE", which is used to initiate transmission of FEC data, fails to send any data, then a FAULT message is passed to the host. Previously, the host was not notified that a failure had occurred.