according to the last commit we are now searching for data chunks from the end of the existing data. If a data chunk exists twice or more in our already received data, only the last one will be replaced
if we are loosing a burst ACK because of fading signals or bad conditions or just because - combined with a changing speed level - theres now a good chance we are not loosing the entire data frame because of a corrupted CRC, anymore. We are now searching in already received data, if our new (smaller) data chunk already exists. If so, we are stripping the entire data to this position and adding our new data chunk. If not, it seems we received new data the regulary way. However, this could cause problems if we have a too small data entropie. We might also check if we have an increased NACK counter or if a data chunk exists, twice or more - in a further step
...and a lot of different changes. Also deactivated single mode transmission. This needs to be optimised another day...Time is the missing ressource...
changed protocol so IRS is now the speed-level master / send ptt state via network / introduced no rig mode / disable scatter and waterfall in gui and tnc/ increased network chunk size / ...
..and some other changes to the gui so its compatible again with the latest socket commands. The rx buffer has now a unique id, and new structure. Also all messages and files will be saved to the same buffer. All commands which will be sent to the tnc or dameon are now written in lowercase
I decided removing this from the code and keeping everything simple for N=1 frames per burst. N>1 frames per burst need a completely rethinking of buffer management.
it seems we need to wait a little bit for our modulation data. There are some moments where audio output is stuck a little bit. Maybe python is sometimes faster than the buffer allocation or its a threading problem
