Hello,
I have found an strange issue on zstack communication. I am using zstack varsion 2.5.1a for cc2530 chip and one of the examples called SampleApp. I found out that sometimes the delay after function AF_DataRequest (message is seen with packet sniffer) can be as long as 300 - 500 ms, when it is normally about 20-50 m. I am doing a test where large amount of data packets is sent through network and these kind of delays are not wanted. Same issue occurs zstack earlier version 2.5.0. The delay is in Coordinator's transmit. End Device seems to transmit OK.
It looks like the situation occurs when radio signal gets weak, for example there is some obstacle between antennas or suchlike. When system goes to "slow-mode" it will continue slow even if signal level gets back to good. SystemReset corrects the situation back to normal.
Has anyone had this kind of problems, and is there any solutions of this?
Thanks to all,
Risto
Would you plese describe more step-by-step detail on how to duplicate your observation? When you say "delay after function AF_DataRequest" what delay are you talking about and how are you measuring this delay? For example, are you toggling a GPIO after calling AF_DataRequest, and then what to measure a delay?
Hi, Mr Dirty Harry.
I mean with the "delay" the time after AF_DataRequest call to the time when radio message is shown on the air. I have measured it with PacketSniffer and doing some instrumentations with GPIOs. I have connected these GPIO pulses to scope and measured the time values.
The duration of AF_DataRequest - function is allways the same (about 3 ms). Packet start sending duration is also the same. ED response time is the same (ACK messages comes at the same time). The only thing that increases is the delay between packets. With PacketSniffer it can be seen that time between last received message and next transmission is increased. With GPIO instrumentation I can observe that time is spent somewhere after AF_DataRequest.
I could add some GPIO instrumentation after the AF_DataRequest to the point where the actual packet is leaving from the zstack, to examine where the time is spent. But I do not know the exact operation of zstack's OSAL layer or transmit sequence neither.
Br,
Hello - I still don't understand how you measure on the scope the time from the AF_DataRequest on the sender to the time packet is detected over the air by the sniffer - is there also a gpio on the sniffer device that gets toggled, and how does the sniffer determine when to toggle the gpio, etc.? You realize that the ZC cannot even send the message over the air until the ZED makes a poll for data, thus the time from the AF_DataRequest to the time packet is detected over the air can vary wildly. So I would need a more concrete, step-by-step process by which I could duplicate this observation on devices using the Z-Stack sample application.
Hi.
I can not synchronize the measurement with sniffer and Z-stack code. They are totally separate. So, I am not able to measure the exact point where the message goes OTA. Sorry, for the confusion. I can only examine these information separately. Now when I have been figured out this issue more carefully, I cannot be sure where the delay is. It can be after AF_DataRequest or it can be before AF_INCOMING_MSG_CMD. Take a look at enclosed document.
Yes, I am aware that there is some vary of timing and it's absolutely normal. But the main issue is why the situation changes so dramatically?
Step-by-step transmission cycle:
- CO sends the data request to the ED (Address 0x0000 -> 0x7EAE), 29 Bytes
- ED sends the ACK
- ED sends the data packet to CO (Address 0x7AEA -> 0x000), full packet 120 Bytes
- CO sends the ACK
This simple cycle is running continuously. Note, that new data request is sent to OTA normally about 20 ms after CO's ACK (it can be seen with Packet Sniffer). When the situation changes the new data request is sent about 400 ms after CO's ACK. The change can be triggered by limiting the radio signal. Note, that the situation is not happening every time, you may try several times until the problem occurs.
Packet Sniffer snapshots are enclosed to PDF - file (three cycles for each situation). Also there is timing diagram where sniffer times are printed in red (for ease to compare). There are two gray boxes on both end of "Radio Message Handling" slot. The duration of those boxes is not known (marked with ? ms). Whole slot "Radio Message Handling" means that data is controlled by CO's low level Z-Stack and End Device.
Hope this clarifies the situation.
Thanks,
I suspect that what your sniffer trace is showing is the situation when the packet sniffer suffers from radio interference and misses packets over the air.
The reason of thedelay is that the end device will sleep and poll.
So the transmission cycle actually is:
-The MCU sends the data to CO by AF_DATA_REQUEST
-CO would not send the data immediately,it only keeps the data in it's buffer and wating the polling from ED
- ED wake up and send polling message to CO
and below is what you had know:
-----------------------------------------------------------------------------------------------------------------------------------
Because the end device will take a sleep of 1S(default),so what you had got is that the message will be delay 0~1000ms to send over air and after you had execute the AF_DATA_REQUES command.
But if the ED send a message to the CO,because the CO never fall to sleep,the message will be send over air immediately.
The situation is real and sniffer is collecting the data correctly. This is seen by the scope measurements. We also measure the elapsed time after 20 kB datafile transfer. System's transfer rate is about 15 kbit/s in fast mode and about 2 kbit/s in slow mode.
Hi,
Good idea, but I am using the following options on ED:
-DRFD_RCVC_ALWAYS_ON=TRUE
/* The number of milliseconds to wait between data request polls to the coordinator. */-DPOLL_RATE=0
/* This is used after receiving a data indication to poll immediately * for queued messages...in milliseconds. */-DQUEUED_POLL_RATE=0/* This is used after receiving a data confirmation to poll immediately * for response messages...in milliseconds */-DRESPONSE_POLL_RATE=0/* This is used as an alternate response poll rate only for rejoin request. * This rate is determined by the response time of the parent that the device * is trying to join. */-DREJOIN_POLL_RATE=0
I assume that with these options the ED will never go to sleep and no polling is done. I cannot use polling because it slows down the transfer rate too much.
Anyway, thanks for the idea, but the real problem is somewhere else...
New clue: the function ZDOInitDevice() in coordinator stops the slow mode and fast mode starts to run on the fly. End Device remains as it is.
It looks like slow communication problem is only with End Device. If I use Router instead the slow mode is not staying permanently. With router the communication does slows down for couple of rounds (when the radio signal level goes down), but it remains back after a while. With ED the slow mode stays forever.
This is very easy to demonstrate. I use two MiniKit evaluation devices loaded with XStack 2.5.1a SampleApp software. Software is modified a little, so the CO sends a packet to RT (or ED). RT/ED answers full length packet back and after CO receives this it will start the cycle again. MiniKit's M430 processor is modified to stay in reset, so the only CC2530's software is running. Couple of IO lines is going through MiniKit's debug connector and behavior is examined with oscilloscope.
Slow mode is started by putting the ED to Static Shield Bag. This makes radio signal weaker. ED stays in slow mode but RT does not. ED should not be in sleep because of the -DRFD_RCVC_ALWAYS_ON=TRUE flag. ED can sometimes even start on slow mode and stays in it.
This observation helps me a lot. I can now use RT instead ED. Still this is a bit weird effect with ZStack - software packet.
I can duplicate the problem and have reported it to management.
But this problem cannot occur with the normal build of the ZED, it can only be duplicated when building with -DRFD_RCVC_ALWAYS_ON=TRUE
So your workaround to this problem is to not use ZED built with that flag - if you need receiver always on, use a ZigBee Router instead.
By the way, what is the real life use of such a weird ZED build - with receiver always on you burn almost as much energy as a full router but have so much less functionality?
Thanks for the answer.
Actually there is no need to build the project for ZED. The only reason I am doing this is that I have too small cc2530 FLASH at the moment. I got the hardware with bigger FLASH size recently, so I can start using router with all devices right now.
Hope this helps someone who has experienced same kind of problems.
Problem is now solved, thanks.