CC3135MOD: C3135 actual DTIM

Can you provide air sniffer log? (wireshark)

what is your WLAN Power Management Policy (SL_WLAN_POLICY_PM)?

Hi Kobi,

The sniffer log is available at: https://drive.google.com/file/d/1qgMdl0eK5Z3N_iezPspLyYGJh2igtu4u/view

It contains our device's (MAC: b0:b1:13:42:7c:3a) reboot sequence.

The SL_WLAN_POLICY_PM set upon link up is SL_WLAN_LONG_SLEEP_INTERVAL_POLICY, DTIM set to 300.

Best.

 What is the MaxSleepTimeMs selected?

assuming it is 300 or more, you should see 300 msec (or more if above value is set for 600msec) of sleep.

Note that the device starts with a learning phase (to learn about jitters in beacon transmissions and create as wakeup window as short as possible) when he wakes up for every beacon and then it starts sleeping according to the settings. If there are large jitters in beacons intervals (such that transmission falls out of the wakeup window) and the device starts losing beacons it may get back to the learning phase (same can happen if there are other interferences on the channel).

Maybe you captured the behavior during the learning phase.

If the configuration is correct and the behavior is consistent, please send us the NWP and MAC log for further analysis.

You can find the procedure in our NWP programmers guide, see. SWRU455 chapter 20. You just need to replace the PIN_62 that is for NWP with PIN_60 that is for MAC firmware. Let me know if you can make it work. 

Hi Kobi,

MaxSleepTimeMs selected is 300ms. I'm monitoring actual value via current consumption spikes.

Please find logs into the zip:
drive.google.com/.../view

The zip contains NVP log, MAC log and current measurements CSV file, captured 10 minutes.
All of them were taken simultaneously (capture started one after another with a diff of a second or so).

At the capture start, device was in normal operating mode and around 20 seconds later I rebooted it.


Best.

at least the NWP logs are not readable. If possible try to get a new one.

I'll try to check the MAC log later today.

The MAC log is also not right.

Please try again and make sure you follow the capturing instructions correctly.

Hi Kobi,

The new files set is available at:

https://drive.google.com/file/d/1n-vZwIHBXwSg0WWj3D_OIhrWdZr0g5FI

The same scenario was used: 10 minutes capture time, data was taken simultaneously, starting with normal operating mode and reboot at ~20 secs after start.

Best.

something is still wrong with these.

I guess you have measured the power in different times during the connection. The SimpleLink utilize an adaptive beacon tracking mechanism in order to use the minimal RX window in each beacon/DTIM/LSI interval. This starts with learning phase where the device wakes up for every beacon (to measure average jitter), only after ~20 beacons it will start sleeping longer. 

In case of a continuous beacon loss (in case of large jitter in beacon transmission or due to other interference on the channel) the SL device will go back to the learning phase.

Hi Kobi,

We're constantly measuring consumption during whole 10-minutes sessions. Measurements are available to you in provided output.csv file.
I'd like to underline again, that I have two Wifi APs available for testing, this issue appears on one only (Anatel's Unifi 6 Lite).

The key issue which I cannot explain to myself can be summarized in the following:
- the device is in WiFi associated mode, DTIM set to 300,
- even several minutes after the communication is established, the consumption spikes appear at DTIM 100 pace.

Please check the captured data in:
drive.google.com/.../1VBIVN5nSxKm203sMbmJHcqmnnVVfrGgn

This zip contains two sets, data captured for 10 minutes, DTIM 300. Approx. 20 seconds after the capture start a reboot was performed in both cases. The diff in subfolders is the following:
1) "associated" folder scenario:
- normal operating mode, capture start,
- after 20 seconds a device reboot is performed,
- upon boot, the device is connected to WiFi AP (this time it took 2 attempts - not an issue, ignore this),
- afterwards, a short status packet is sent,
- the device remains in WiFi associated mode for remaining time (~9 minutes),
- if you check consumption during this associated time, it permanently remains very high. For example, after 8 minutes the consumption looks like this:
drive.google.com/.../1paiA-4z0NcYsuzxLCbKhtPWA7HYrZyVO


2) "with_comm" folder scenario:
- similar to the above, but this session contains also a dozen of transmissions.

The "with_comm" folder is for reference only. Please focus on data in "associated" folder - this is something what bothers us and we'd like to get your explanation for.

Be aware that this is a high priority issue for us, therefore feel free to ask for any details in order to get closer to a conclusion.


Best.

Ok, those logs are good!

We can see that the device sometimes sleeps for ~300msec (DTIM), however it seems that we are receiving data frequently.

Every time the device gets data, the logic goes back to wake up every beacon (under the assumptions that there will be more transactions following). We then see that after couple of beacon interval, it gets back to 300 msec interval but then another packet is received...

Looking at your sniffer log, i see that the AP keeps sending IPV4mcast_fb packets. I don't know the reason (may be related to the mesh support) and this seems to be the reason for the wakeups.

You may try to use RX filters (see chapter 11 in https://www.ti.com/lit/swru455) to try to ignore these and see if it helps. 

Hi Kobi,

Thanks for the investigation.

I added RX filtering, the initial rule applied is based on destination IP address filtering. I've started to measure impact on consumption and will probably compare results also with few additional rules combinations.

Best.

ok. please update with your findings.

Hi, Kobi,

Yes, destination IP address filtering decreases the consumption by up to almost 1 mA in worst case.

I'm investigating now also filtering based on the WiFi module's MAC address (and BSSID is the next candidate), to see how low can we go.

Not sure if you cover also this filtering area, but I bumped into an issue with filtering based on MAC criteria, I've opened another thread with the question: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1135877/cc3135mod-programmable-rx-filters

Best.

Probably an ARP/Other broadcast issue that is needed the setup time. Can you delay the RX filter setting until the socket is up and running?

If you will provide air sniffer log it can help identify the exact issue and maybe add and filter to solve this.

Anyway, I'll let the owner respond to the other thread.