EHS6T - transfer rate over GPRS issues | Thales IoT Developer Community
April 10, 2015 - 1:23pm, 3272 views
I'm aiming to use the EHS6T terminal in an application that would transfer large chunks of data and speed is a factor. I'm using at commands directly, sending them over serial link.
I've followed the tutorials and successfully managed to establish a data connection over TCP/IP, but the data transfer seems to be having issues.
I tried the transparent **** and noticed that if I send a small packet of data, it always arrives to the other end with a 4-5 second delay. If I send another packet just after, it seems to be forcing the first packet to arrive faster, but the second is still placed on 4-5 second delay. If I send huge chunks of data, the transfer seems to be stable and going up to desired speeds (about 11.5 kB/s, as serial of 115200 allows) - everything is sent in proper except for the very last packet which, again, seems to arrive 4-5 seconds later. It doesn't seem it's a flow control issue - more like a that there's some packetization timeout employed by the terminal, but I cannot seem to find anything about it in documentations. It doesn't seem that the parameter "timer" used in at^siss, address has any impact on it. Does anyone have an idea what I may be missing?
I also tried sending the data via at commands, without transparent ****, but it's going a lot slower (around 4.5 kB/s) using the same environment. There seems to be about 150-200 msec delay between the moment in which the 1460 data chunk is sent and receiving OK notification in a single at^sisw call. Is this the actual time of sending, meaning that the terminal first accepts the data, buffers it, then starts sending it and returns OK only after the data's been sent to the network? By comparison, the time between OK and ^SISW that indicates that the terminal is ready to accept the next at^sisw call seems 10 ***** smaller. Is it the limitation of the terminal or I'm missing something?
I don't believe it's a network transfer speed issue as I'm able to have over 10 kB/s while streaming, but maybe it's still related to the how the operator sends notifications back to the terminal.
I dumbed down the configuration to be as plain as possible to avoid setting any parameter that would interefere. Here's my listing: