I’ve got a TCP created and the modem is due to send GPS information to a server by creating a TCP connection.
Running a 6.63c on a 4.23 Open AT Os, when i run wip_write, even if the data is not received by the server, the return value will always be the same as the length of the text to be sent
When i drive from a GPRS area --> Non GPRS, i’ve made a module that deals with unsolicited CREG responses that will trigger the modem to store data in the flash if the GPRS does not exist, send data if it exists.
It sometimes takes time for the GPRS --> Non GPRS to kick in, and the data might still be stuck in mid air, so i need to have a return value on how much data has been sent so that i can perform appropriate action on it.
Anyone’s got a clue what’s going on with wip_write or any other way of dealing with this?
We check the write buffer. It is a good way to know that GPRS actually works. But the only correct way to know that your data is sent is to send acknowlege messages from the peer.
To check the write buffer you should use ‘get options’ command. Read the wip guide for it.
I don’t think checking the write buffer works in this scenario. That’s the think i wanted to actually verify. When i use the wip_write function and on a GPRS coverage, the buffer is actually cleared out. But there’s no way of knowing whether it has been received by the peer.
The acknowledgement is a low level implementation of TCP. I’ve always assumed that actually wip_write handles the acknowledgement returned by the peer because that should be the correct way to actually get the byteswritten in theory.
But the issue is, wip_write is not returning the values correctly or the intended value. I’ve checked the options in wip_getOpts but none of them are relevant in my opinion that could affect wip_write.
That’s why I wanted to ask the opinion of some of you guys here, that has actually use the wip_write function and might have been tanked by the return value which I am experiencing. I’m sending GPS information every 30 seconds and there are intermediate periods where I lose GPS information easily from 30-8 minutes because the modem still detects there is a GPRS before it changes the state to Non-GPRS
Anyone had the same problem? Or possible resolution
Once again: the only correct way to be sure your data is received by the peer is to implement some kind of acknowlegment. The implementation in TCP/IP is not enough - it works only for point to point connection without proxies on its way.
Also how do you know that write buffer is actually cleared out? Did you check it?
BTW in our implementation of GPS logger we do not mind successful delivery of GPS packets - they are not so important. We just ‘send and forget’ them and store in flash. Every 30 minutes we send synchronization command from the server with the date of the last received packet. If we find that the difference in time is bigger than some threshold we know that GPRS does not work, reinitialize GPRS, look in flash for point with date from synchronization packet and retransmit the part of the buffer with date newer than this date.
Well for one, i thought wip_write will be decent enough to work on such circumstances. After all, this are basic communication protocol that normal developers will encounter. More so important on a device that is communication based. So i’d thought the wip_write should handle the acknowledgement.
I’m in the process of writing some codes to take in the acknowledgement, but i’m still looking and see if i could have missed any options that could have saved my current situation. The wavecom modem is currently connected to a GPIO and is triggered quite often. Due to the sensitive nature of the task, there must not be any GPS data that could not have been sent.
You better read about TCP/IP basics. Or you can miss some important details. For example you cannot rely on packets integrity… And if your data is so important, did you think about buffering, because GSM is not a very stable channel.
I’ve done the explicit acknowledgement, but the timing is essential.
Anyway, just a note to those that might use the wip_write return value
This i got from Wavecom HQ after being raised to Level 2 support. In flaky GPRS area, the WIP_CEV_READ is triggered sometimes 20 secs after a packet has been sent, and the timing is just skewed out massively. And not to mention the amount of duplicates that might occur. Explicitly implementing Selective Repeat ARQ or Stop-and-Wait ARQ on this wireless CPU has caused me nothing but frustration.
Just hoping someone has a better understanding of this:
When sending a packet using a wip_write call on a flaky GPRS connection, how is it stored in the pipeline/buffer?
Sometimes when the function is used, the data might not be received from the server side because the GPRS is not stable. However, the data automatically is re-sent once the modem detects the GPRS. Was wondering if anyone knows where this data might be stored in the modem, and how to access/delete/edit it?
I’m not sure the buffer can be accessed for direct management, but we are using wip_getOpts to check if the buffer is empty. And I found that there are Buffer Management functions in WIP API which is probably what you need.