Possibility of acknowledgement and retransmission? about icsc HOT 2 OPEN

Hi Matt,
nice to see that someone else has the same idea.
I undertook some efforts to enhance the lib. But it is not easy though.
My approach is to let the lib as it is and to add some useful functions into the code.

1. Everey command function calls an ack function that immediately returns the data to its source with a predefined ack command (i.e. 'A', but can be anything).
2. The ACK function on the source machine then checks if the received data is the same like the data which was stored from the last sending. If yes, the memory is released, if not or the timeout is reached and no answer is received the sending is repeated for x times.

Issues? Yes!
There are two main issues in this concept I was not able to overcome so far.

1. Storing of the data already sent to compare it later on or to re-send it is not trivial. It costs a lot of memory and sometimes I get confused with char and char* and so on.
2. Timing is depending on the baudrate. I.e. a message to and fro on 115200 b/s is about 4 ms, with 9600 b/s it takes 40 ms. So 40 ms would be definitely the timeout for a network on 115200 b/s. I did not calculate a formula for this yet.

If you like (or anyone else) I would appreciate to join and share the code I made so far. Since it is not running flawless at the moment I wouldn't post it for public yet.

By kduino

from icsc.

Hello kduino,
Thread is a little old, but if you're anything like me, this stuff bubbles on for years ;)

If I've read it correctly, for issue 1 you could have the contents of the 'acknowledgement' reply be the checksum of the original message rather than the whole original message. This could save on the space required, and you'd be fair certain the messages have been transmitted and received correctly.

For the second issues I guess you could do a compile time calculation based on the defined baud rate and maximum message size. A better option would be to calculate based on the sizeof() of the message send divided by the baud rate... But if you adopt the solution for 1, then the reply message will always be the same size, so then its just a function of the baud rate which could be set a compile time.

I've only just started looking at this library, you should just post it up with the caveat that it doesn't work and help is welcome.

Cheers,

alex

from icsc.