Possibility of acknowledgement and retransmission?

[mattbsyd]

Hi, I love this library, I was searching for something along these lines for a while and was very excited to find this as nothing else was quite right. This works great as it stands and I love the functionality, especially the way that the commands are registered to a function for easy handling, great job there! But, as with most things I have a question/suggestion/request...

I am running this over RS485 (MAX485 chips) with the collision handling enabled and so far testing is a success in the sense that collisions are detected and packets that collide do get re-sent, but there's no guarantee that the target "id" actually received the packet, so, I was wondering how possible it would be to enhance it to allow confirmation that the target has received the packet and re-transmit if not received, similar to a TCP stack. Even better would be the ability to have some sort of return value, sort of like a remote function call but I am probably dreaming here. This of course means that you'd have to be certain that each station has a unique ID or you will end up in a mess, but that's a small price to pay.

I was going to start writing my own sort of a message queue but I'm not that great at this sort of programming so it'd be a dogs breakfast, and thus I thought I might ask the question as someone might have already done this in a way that could be slotted into this library, or someone may just have a brilliant idea.

Thanks!

[kduino]

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

[alphalove]

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