Forums

Hi,

Though I'm not familiar with Bluetooth FW, the cc254x and cc253x

sharing the same peripherals and power modes (Radio is the major difference).

Read the OSAL_API.pdf, in Z-stack calling osal_pwrmgr_powerconserve() otside

of OSAL is not a wise thing to do.

Evgeny Lunev

current measured on KeyFob.. 1.6 - 1.7 mA before and after

While measuring this current the keyfob is connected to debugger?

In debug mode cc254x and cc253x SoC's emulates deep sleep power modes (PM2 and PM3),

but consumes much more power. 

Hi,

>>While measuring this current the keyfob is connected to debugger?

Sure not, with debugger the usual current is about 17-18 mA.

So, qeustion remains - how to shift to PM3 mode from application stack?...

Evgeny

Read this!

http://www.ti.com/lit/an/swra347/swra347.pdf

:)

And then we can talk again.

Thank you, we've already stambled upon it)

but there is another question, related to it

how to detect disconnect event (due to explicit request or timeout). I saw several related events like

GAPROLE_INIT = 0,
GAPROLE_STARTED,
  GAPROLE_ADVERTISING,
  GAPROLE_WAITING,
  GAPROLE_WAITING_AFTER_TIMEOUT,
  GAPROLE_CONNECTED,
  GAPROLE_ERROR

but there is no disconnect event as such or something like that.

What is best suitable event for disconnect ?

Or disconnect handling functions should be triggered in some other way?

Regatrds,

Evgeny.

Any suggestions on how to catch disconnect event?

Any help highly appreciated.

Regards,

Evgeny

From observation running the BLE v1.2,

if disconnection was caused by link supervision timeout, you will be notified of the new GAP state GAPROLE_WAITING_AFTER_TIMEOUT;

otherwise will be notified of GAPROLE_WAITING.

Thank you,

just checked - it works)

BR

Evgeny

Not mine but the one who gave you the answer! Whatever. Bye!