Hi,
I’m evaluating the DA16600 used to send about 300 bytes of data from a host micro every second via a TCP or UDP socket. My host micro wakes the DA16600 from DPM sleep3, sends the data, and instructs it to sleep again via AT commands, and I observe that the DA16600 stays awake for about 300ms; is this roughly the minimum wake time I can expect?
Hi Ksw,
Please try the APIs in the screenshot, it is not fixed connection window but with retry counts. in chapter 3.4 UM-WI-030 DA16200 DA16600 DPM User Manual (renesas.com)
BR,
JH_Renesas
Thanks, but I'm insufficiently knowledgaeble about the API to be able to use these configuration functions, and the documentation doesn't provide enough detail to help me understand them.
If I were able to use these functions, from your experience, can you give me some indication of how quickly the device could return to sleep after a transmission?
As it shows in the picture, the first wake up reconnection slot is 3times/1s. so your reconnection 300ms is the fastest time slot.
Thanks, but I can't see how you arrive at 300ms from the diagram; I'm using AT commands between my host micro and the DA16600 (following the guidance in section 5.6.9.1.2 ‘Data Transfer with DPM’ of UM-WI-03 DA16200/DA16600 Host Interface and AT Command Rev.3.4) and, as I understand it, the connection to the AP is maintained, whereas the Figure 6 diagram relates to reconnection timing.
I can't find any timing information for my use scenario when the host wakes the DA16600, sends data, then tells it it sleep with 'AT+SETDPMSLTEXT' - I'd like to confirm whether what I'm observing (about 300ms) is the fastest that can be realistically achieved?
There is no limitation with the reconnect time, as you can see in the picture, if you reconnect in 300ms means the reconnection succeed in the first reconnection slot without retry. it is the fastest reconnection between your devices in your testing environment.
The diagram you referred to (Figure 6) is under section '3.4 DPM Connection Retry State' which starts: "If the device loses connection to AP in the DPM mode,..." wheras I'm operating the device according to section 3.5.2 and my understanding is that my device remains 'connected' to the AP - maybe I've misunderstood the use of the term 'connected'?
To my mind Figure 2 is the more applicable timing diagram for my test scenario, where the devices is receiving AP beacons in DPM 'LPM' mode (hence maintaining 'connection') and is then woken by my host into DPM 'FFM' mode by a GPIO event for my host data to be transmitted to the AP? If that's correct, I just want to know roughly how short the FFM period can be in this case; I'm observing about 300ms after my host sends the 'AT+SETDPMSLTEXT' before it enters the LPM state. If there is some way to reduce this duration it would obviously improve the average current consumption for my application, but if not then so be it.