Wip_write assigned to a timer


I have a timer which perodically sends data to an UDP server every 5 seconds:

adl_tmrSubscribe(TRUE, 50, ADL_TMR_TYPE_100MS, (adl_tmrHandler_t) SENDTimer);

and the function attached to this timer is:

adl_tmrHandler_t SENDTimer(u8 tmr_id)

				udp_Socket_Chanel = wip_UDPCreateOpts(evh_udp, NULL, WIP_COPT_PORT, wm_atoi((ascii*) getItems(P_SERVER_PORT)), WIP_COPT_PEER_STRADDR, getItems(P_SERVER_IP), WIP_COPT_PEER_PORT,  wm_atoi((ascii*) getItems(P_SERVER_PORT)),  WIP_COPT_END);



So this function checks if the UDP socket is not opened, opens it. Then runs the function “sunucuyagonder” which sends data to our server using wip_write:

wip_write(udp_Socket_Chanel, (void*) rsp, (u32) wm_strlen(rsp) + 1);

So, the only place in the code that uses this socket and sends data via wip_write is the function sunucuyagonder(). And it is called by the function SendTimer() which is called every 5 seconds, according to the timer.

Then, why do I see data that are sent to the server in less than 5 second interval, or sometimes less than a second?

Here is a list of data received to our server:

I don’t see this issue very often but, it is still an issue. Do you have any suggestions or any place to check for this issue?

The server logs show you when the data was received by the server- not when it was sent!

Your log also shows some delays significantly larger than 5s.

IP networks are subject to delays - especially over GPRS links.

You need to check the traces at the sending end to see if its timing is correct…

Thank you for your answer,

Delays higher than 5 seconds are not an issue since the data is sent according to events [messages are saved to a flash queue and then sent from there by reading every five seconds] . But below that duration is the issue.

So, let’s say we have sent 5 messages with 5 seconds delay, when the server receives those 5 messages, shouldn’t there be at least 5 second delay between their received time on the server?

Is it possible on UDP to cache 5 of them and process them at once on a tomcat server?

Since devices are on mobile vehicles it’s not practical to monitor these devices 24/7 on their side. So, what I am really asking is either this (sending multiple messages at the same time on this configuration) is possible or not. Or is this a GPRS or server side issue?


Think about it: if one message suffers a 4s delay, and the next message has only 0.5s delay, then they will arrive 1.5s apart - won’t they?!

This is why, as the old saying goes, you wait ages for a bus - and then 3 arrive all at once!

This makes it very likely that your messages have highly variable delays!

You certainly shouldn’t be relying upon arrival time at the server as an accurate indication of the time at which the reported event occurred!

You could (maybe, even, should) build such monitoring into the application.

Maybe I can add the sent time which can be read from the RTC to the end of messages for a while since they are disregarded on the parser in our server.

Ps. I have added sent timestamps to messages, but something interesting came up:

adl_rtcTime_t currentSentTime;

returns 25 if the time is 00. Is this normal?

By the way, I will check results if it is about the delay issue or not. Current messages are as followed: