File transfer messaging

Status
Not open for further replies.

linuxgeek

Well-known member
I've managed to send a file over serial from the t3 to the PC using Processing & java rxtx.

But, I'd like to ensure the data transfer is accurate. I need to ensure that the data has been received, that it's not corrupted, and some info about the file.

I've outlined below what I thought would work. Does anyone know if this has already been done? I don't want to use a big library though to just transmit a file.

arduino - periodically checks for command on serial
pc - sends command to receive file
arduino - closes file. Sends file info below:


<filename>test.edf</filename>
<filesize>-1</filesize>
<segmentBytes>512</segmentBytes>
<checksum>true</checksum>
<checksumBytes>4</checksumBytes>


arduino - listens for successful transmission
pc - sends command of success or retransmission
arduino - begins sending file, or retransmission of file info
pc - receives segmentBytes + checksum
Send success command, or command to re-send if doesn't match
arduino - waits for success command or re-send command

To end transmission
Last segment will have a -1 for checksum.
PC will then send a command to receive how many bytes in last chunk & checksum.

It will be a little awkward to send checksum on file info at beginning.
file info will need to fit in 1024bytes with an additional 4 byte checksum

I'm thinking this would be good for xbee too. I imagine I'm re-inventing the wheel here, but I also don't want to put a tractor tire on my RC car. :)
Is there anything that I'm missing or does this make sense as is?
 
I found some stuff. It seems I did not think about ordering of packets.

checksum doesn't necessarily check if the packets are out of order. So, I should send the packet number along with the checksum.
Then, I can send as fast as I can, and the commands sent back from the pc will be requesting the specific packet number to re-send.
It does start to get a little more complex that way, but I could start with including the packet#, but still do the simple send-and-wait method initially.
 
At this point, you essentially re-implemented TCP/IP. Be sure to deal with the fact that host int sizes might be different on the host and client.
 
I did find this project:
http://playground.arduino.cc/Code/SerialIP
It takes up around 9kB of flash space and enough RAM that you can easily run out of memory (which normally results in the Arduino rebooting unexpectedly.)

But, I think it's gonna be better to do something that is less all-encompassing. Also, trying to figure out how to do tcp/ip over serial on the pc (or whatever else) side might be problematic.
 
I did find this project:
http://playground.arduino.cc/Code/SerialIP


But, I think it's gonna be better to do something that is less all-encompassing. Also, trying to figure out how to do tcp/ip over serial on the pc (or whatever else) side might be problematic.

By TCP/IP I meant that you were essentially replicating TCP/IP with the IP layer transmitting packets, and the TCP layer handling sequencing and packet corruption checking. I agree, that you probably want to strip things down to save memory.
 
Right.

I am wondering how does one handle the commands that are sent back & forth. Does it need it be in a whole packet by itself, so you can use a checksum to verify that it was received? I guess that's what an ACK is for.

I'm considering a quick-and-dirty solution that would behave very horribly if there was significant data loss or corruption, but would be fast otherwise. At least I think it would be.
Is it feasible to have the t3 transfer the packets (with indexes) as fast as it can until it's done. When the receiver has detected that it's done transferring, the pc or whatever would request the packets that were not valid.
The t3 would then re-send those again. Sound reasonable? I'm thinking it would be easier cause less constantly sending commands back and forth.

The xmodem seems interesting, but I think it's gonna still be better to roll my own.
 
Status
Not open for further replies.
Back
Top