Hello,
While running a test overnight, I saw that DA16200 was woken up with NOBCN but did not go into abnormal DPM. This means that it didn't actually disconnect from the network. Is that expected? We're on SDK 3.2.4.0 and running Getting Started AT commands.
// Normal GPIO wakeup21:58:21.560 +ATPROV=STATUS 021:58:21.709 [1;33m>>> Start DPM Power-Down !!! 21:59:21.683 [0mPS TIME 2898�21:59:21.683 Wakeup source is 0x90 21:59:21.683 Configure GPIOA11 for wake-up21:59:21.683 >>> Start DA16X Supplicant ...21:59:21.830 >>> TIM STATUS: 0x0000001021:59:21.830 >>> TIM : FAST21:59:21.830 Enabling multi-pin coexistence21:59:21.830 Coexistence Setting: rf_meas_btcoex(1, 0, 0)21:59:21.830 21:59:21.830 +ATPROV=STATUS 021:59:21.978 [1;33m>>> Start DPM Power-Down !!! 22:00:04.263 [0mPS TIME 2898�
// Normal GPIO wakeup
21:58:21.560 +ATPROV=STATUS 0
21:58:21.709 [1;33m>>> Start DPM Power-Down !!!
21:59:21.683 [0mPS TIME 2898�
21:59:21.683 Wakeup source is 0x90
21:59:21.683 Configure GPIOA11 for wake-up
21:59:21.683 >>> Start DA16X Supplicant ...
21:59:21.830 >>> TIM STATUS: 0x00000010
21:59:21.830 >>> TIM : FAST
21:59:21.830 Enabling multi-pin coexistence
21:59:21.830 Coexistence Setting: rf_meas_btcoex(1, 0, 0)
21:59:21.830
21:59:21.830 +ATPROV=STATUS 0
21:59:21.978 [1;33m>>> Start DPM Power-Down !!!
22:00:04.263 [0mPS TIME 2898�
// NOBCN wakeup22:00:04.419 Wakeup source is 0x92 22:00:04.419 Configure GPIOA11 for wake-up22:00:04.419 >>> Start DA16X Supplicant ...22:00:04.419 >>> TIM STATUS: 0x0000000822:00:04.419 >>> TIM : No BCN22:00:04.419 Enabling multi-pin coexistence22:00:04.419 Coexistence Setting: rf_meas_btcoex(1, 0, 0)22:00:04.419 22:00:04.419 +ATPROV=STATUS 0// No disconnect and DA16200 does not go into sleep mode22:31:19.648 L2 Packet process completed, Set DPM Sleep !!! 22:31:19.804 L2 Packet process completed, Set DPM Sleep !!! 23:30:12.010 L2 Packet process completed, Set DPM Sleep !!! 23:30:12.170 L2 Packet process completed, Set DPM Sleep !!! 00:29:00.012 L2 Packet process completed, Set DPM Sleep !!! 01:27:49.002 L2 Packet process completed, Set DPM Sleep !!! 01:27:49.147 L2 Packet process completed, Set DPM Sleep !!! 02:26:45.193 L2 Packet process completed, Set DPM Sleep !!! 02:26:45.337 L2 Packet process completed, Set DPM Sleep !!!
// NOBCN wakeup
22:00:04.419 Wakeup source is 0x92
22:00:04.419 Configure GPIOA11 for wake-up
22:00:04.419 >>> Start DA16X Supplicant ...
22:00:04.419 >>> TIM STATUS: 0x00000008
22:00:04.419 >>> TIM : No BCN
22:00:04.419 Enabling multi-pin coexistence
22:00:04.419 Coexistence Setting: rf_meas_btcoex(1, 0, 0)
22:00:04.419
22:00:04.419 +ATPROV=STATUS 0
// No disconnect and DA16200 does not go into sleep mode
22:31:19.648 L2 Packet process completed, Set DPM Sleep !!!
22:31:19.804 L2 Packet process completed, Set DPM Sleep !!!
23:30:12.010 L2 Packet process completed, Set DPM Sleep !!!
23:30:12.170 L2 Packet process completed, Set DPM Sleep !!!
00:29:00.012 L2 Packet process completed, Set DPM Sleep !!!
01:27:49.002 L2 Packet process completed, Set DPM Sleep !!!
01:27:49.147 L2 Packet process completed, Set DPM Sleep !!!
02:26:45.193 L2 Packet process completed, Set DPM Sleep !!!
02:26:45.337 L2 Packet process completed, Set DPM Sleep !!!
Thanks,
Konstantin
Hello Konstantin,
From the logs you provided, it appears that the DA16200 woke up due to a NOBCN event and then entered normal sleep mode after packet processing was completed. This behavior is expected…
Hi Konstantin,Thank you for posting your question online.Let me check on this and I will get back to you.Kind Regards,OV_Renesas
From the logs you provided, it appears that the DA16200 woke up due to a NOBCN event and then entered normal sleep mode after packet processing was completed. This behavior is expected since a NOBCN event indicates that the device has lost synchronization with the access point, but it doesn't necessarily mean that the device should disconnect from the network.
When the device wakes up due to a NOBCN event, it will attempt to resynchronize with the access point by scanning for beacons. If the device successfully synchronizes with the access point, it will continue to operate normally. However, if the device is unable to synchronize with the access point after a certain period of time, it may choose to disconnect from the network and enter abnormal sleep mode.
In summary, the behavior you observed is expected, and the device should continue to operate normally as long as it can successfully resynchronize with the access point after a NOBCN event. If you have any further concerns, please feel free to ask.
Thanks. That makes sense.
In that case I think you should update your documentation. I believe DPM manual shows that disconnect happens on NOBCN and DEAUTH.