Hi all,

I reworked tux_pong.c. In the current form all values were multiplied by 10 then up to 10 values where stored and the average was calculated.
As the original value was an integer, the result is most likely also an integer (and the fraction part is not really accurate anyway in such cases), I've moved everything to integer.

Not sure exactly how the algorithm is supposed to work though. I did not manage to create an in-room situation with the quality < 100 (and actually did not bother to put tux in the garden or the toolshed or attic or so).

I would appreciate if someone could briefly explain the algorithm (either here or as comment in the code).

FM

The ping/pong stuff is something I created nearly two years ago in an ultimate attempt to convince the guy that wrote the RF that one out of 2 packets were lost. I still finally had to fix the issue myself and found that quite convenient as a "test case" of the firmware code so I kept it.

The principle is that you send a "ping 200" (200 is a parameter) and tuxcore will send back 200 pongs with an index as first paramater (200 down to 0). Tuxaudio (the second MCU) will check all of them and I add it's own index as the second parameter. Then the USB MCU will do the same and use the 3rd parameter for it's index. Finally the daemon will count them and check how many were lost. I used 200 and stopped as soon as the index was under 100 otherwise if you send 100 and wait for 0 but the frame "0" is lost, you have to add a timeout. Then if you receive 80 pongs, looking at the 3 different indexes, you can tell where the frames were actually lost (in the I2C between tuxcore and tuxaudio, or in the SPI between tuxaudio and tuxrf, ot in the RF link, or finally in the USB communication.) I don't know exactly how it's implemented now in the daemon but the pong mechanism didn't change.