CC3135MOD: Consumption increases after some days

Hi,

This may be an IOP issue with the AP.

what vendor and model are you using?

an air sniffer would be good here but also an NWP log and MAC firmware log.

Please try to capture an NWP log (see details in chapter 20 of the programmer's guide (https://www.ti.com/lit/swru455).

A MAC log is also required. The procedure is the same as for NWP but the pin is 60 and not 62.

since it is cc3135 and not cc3225 you do not need to mud anything on SW and you have these like mixed out already.

shlomi

Hi Shlomi,

Thanks for the quick response.

Please find attached zip containing debug output of MAC and NWP. We're still working to capture the air sniffer logs.

Attached are also results of current consumption measurements. All logs were taken at the same time. Initially, the WiFi module was connected to a server, then I started to change mode back to power-off, and back to fully operating mode. You can see consumption steps of these events in mentioned current measurements.

Do not hesitate to let me know if you need any further details (next to air sniffing data).

Thanks and best wishes.

CC3135_Consumption.zip

Hi Shlomi,

Thanks for your answer.

I'm not sure these broadcasts are the (main) reason for increased consumption.
What makes me skeptic is that we have a setup of 20 equal devices, physically located close one to another (on the same desk). They have equal WiFi configuration (same SSID, DTIM, etc.). However, observed increased consumption occurs randomly, just on few of them per day.

The consumption level drops back to normal immediately after a device is de-associated and associated to AP. When this "recovery" is done on the first device, this doesn't have impact on remaining ones, of course. The de-association & association needs to be performed on each.
Afterwards, these devices have normal consumption again for several days... and in the mean time increases occur on few others. Randomly.

If broadcasts were the reason, I'd expect that all devices would behave very similarly.


The logs I sent in the previous message were captured on another hardware with exposed debug outputs (furthermore, located in another room, connected to another AP). What we did was to move this "debug device" next to mentioned 20 ones and applied the same settings to it.
You can expect new complete set on logs from this device in the upcoming days.


Best regards

Thanks for the update.

I agree that broadcasts are not the only contributors since other devices should also experience similar behavior.

Moreover, re-association where broadcasts are still transmitted should have cause high power consumption immediately.

Let me know when you have more logs.

Shlomi

Hi Shlomi,

I set some automatic scripting and have captured a suspicious event. It lasts just 3 seconds (see consumption graph below), but this data might be useful anyway.

The logs available in zip https://drive.google.com/file/d/1jis5fFpm2F-ekR-m2Highk8eNvnvKkK8 were collected 30 minutes, the event occurs after 7 minutes.

The output.csv file contains current consumption data, this event appears in it after 421 seconds (timestamp 421094.56). Logging is started from a script, launching log-grabbing item one after another, consequenly, there might be slight time offset between related items in the files (< 1 sec, I believe).

Any feedback is appreciated.

I'll continue to collect logs for critical events...

Kind regards

Hi,

Logs are a little corrupted so hard to see. Also, the MAC log seems short.

Can you elaborate what is the MAC address of the station and of the AP?

Shlomi

Hi Shlomi,

Thank you again for the quick response.

The device's MAC is 34:03:de:11:bb:d6, and AP's MAC 01:00:5e:00:00:fb.

It could be that reading UART data approach I'm taking is not suitable for this baudrate. I'm going to investigate this.

Kind regards

Hi,

MAC 01:00:5e:00:00:fb is just a multicast, not the AP MAC.

Your AP according to the DUT is Ubiquiti with MAC ba:fb:e4:84:82:21.

I do not see something strange in the air sniffer after 420 seconds but the problem is that the gLogger also shows me the TSF of the AP it is connected to and the TSF is way off the one that appears in the sniffer for Ubiquiti. It must be identical.

Can you double check?

Shlomi

Hi Shlomi,

I changed the UARTs data reading (using PuTTY now) and have caught the same 3-seconds increased current consumption case, attached below.

Logs zip: https://drive.google.com/file/d/1rIk13RhCC81UKpnKDZjwA3pt15TrYvzq

This event occurs 682 seconds after the start.

The hardware setup remains the same.

Hopefully, logs content is now consistent and more useful ?

Kind regards.

Hi,

This one is completely corrupted but I could recover the previous one that occured ~420 seconds from the beginning.

The log marked as MAC was actually NWP and vice versa.

Anyway, I could not observe any strange behavior on MAC or NWP.

Both seem to go to ELP/sleep and wakeup only to receive the beacon and multicasts.

Also, the value of 10mA seems also strange since if I remember correctly, NWP/MAC would normally consume ~20mA when active.

Are you probing the current from CC3135 only or does it also include your MCU?

Shlomi