• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 626 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541: coin cell battery-powered reed switch event counter

Oleg Semyonov
Intellectual 360 points
Part Number: CC2541
Other Parts Discussed in Thread: CC2640R2F, CC2540

Hi all,

I start learning BLE technology. As a starting point I want to code the coin cell battery-powered reed switch event counter. The goals are: long cell battery life, internal counter, an ability to send counter data to a central device on demand or periodically. And I have few newbie questions:

  1. I can implement it as advertiser/observer. It's easy but not optimal. If I implement a service and use master/slave connection, I can use connection events with few seconds intervals and save power. As far as I understand, I should implement advertising by request (button) for few seconds, then connect to it, and stop advertising. But what if a master device was unavailable for, say, 10 minutes or an hour? The slave drops connection and now there are neither connection events, nor advertisements. So master will not be able to connect again automatically, I should press a button to start advertisements again. What is a usual practice to make connection self reestablishing and still not wasting power on advertisements if master lost for few minutes or an hour?
  2. And another question: when in low power state, CC2541 consumes near 1uA. What is a usual practice to wakeup on reed switch event? I can enable internal pullup/down, or use an external resistor. But to have comparable power consumption it should be around 100-300M. Is it ok, or maybe some other methods exist? The same is actually applied to BLE keyboards and remotes. How to keep current low and still be able to wakeup on dry contact event?

  • 0
    TI__Guru** 101460 points

    Hi,

    I will assign an expert to comment.

    Best regards,

  • 0
    TI__Guru 56590 points

    Hello Oleg,

    If you are planning a new product I would recommend you to use CC2640R2F or CC26x2 instead of CC2541. CC2541 is a solid product, but the collateral for CC26xx simplelink family is even more mature and outperform the CC2541. 

    http://dev.ti.com/tirex/explore/node?node=ADoEZBrWKWqhpyfpKc8WDw__krol.2c__LATEST

    1. You will have to waste some energy on advertisments as it is the only way to form a connection. But you can either use a button to wake up the device and enable limited discoverable mode advertisements and configure a duration it will advertise before it disable and go back to sleep. In this case you can even enter the lowest power mode (PM3). If you do not have a button or wake up input signal available you must either periodically enable/disable advertisements or set a very high advertisment interval. This can increase the duration it takes for the Master device to be able to initiate a connection in a noise environment. 

    2. Please refer to the RESET circuitry on our reference designs. Or button design on keyfob (CC2540/CC2541). There will not be leakage current on configured input pin that is pulled to a logic level. 

  • 0 in reply to Eirik V
    Intellectual 360 points

    Currently BLE is a hobby for me, so I use cheap Chinese CC2541-based modules which I have at a hand.

    1. If I use long adv intervals, do I have anything else to concern apart from having longer reconnect times from initiator device (assuming that it is a rare case to reconnect, so I am ok to wait even few minutes and have few weeks/months more battery life).

    2. I see that buttons on the keyfob are just switches to the ground. This assumes that to read them I have to enable pullup resistors which are 20KOhm. So when the switch is short to the ground, I have a leakage through that resistor. Unless the switch is a short-pressed button, it may stay in any position for a long time, this will waste energy. So the question is: do I have any other solution to be able to read the switch in both states without high leakage, or the only way to keep consumption low is to use very high external resistor to pull up?

    Thank you for your answers.

  • 0 in reply to Oleg Semyonov
    Intellectual 360 points

    And another question: the module I have misses an external 32768Hz crystal. I had to define XOSC32K_INSTALLED=FALSE.

    Can it be a reason to have regular connection drops? If no, what else can be a reason? I am playing with SimpleBLEPeripheral example. It works but drops connection (tried with Android 7.0 and iOS 12).

    EDIT: yes, it is documented for the chip that external 32768Hz crystal must be used for BLE stack in PM modes. After I disabled PM, I have stable connection. So if I want to use BLE master/slave connection, I MUST have an external 32768 crystal, and RCOSC calibration does not help with that?

  • 0 in reply to Oleg Semyonov
    TI__Guru 56590 points

    Hello Oleg

    1. No.

    2. You can find a single-pole double-throw (SPDT) reed switch and connect it to 2 IOs. Then disable the pull and input on the active IO.

    3. Yes. You must disable power saving when there is no 32 kHz crystal present. The  XOSC32K_INSTALLED=FALSE may already do this for you. If you want to enable power saving you will need an external 32 kHz XTAL to meet the timing requirements in the BLE Core spec.

  • 0 in reply to Eirik V
    Intellectual 360 points

    Thanks, I've got it for 1 and 3.

    As for the 2nd, I use a factory sealed resource (water) counter, so I have no control on the switch inside. Still, can you explain a bit more about SPDT switch? If I use 2 GPIOs for it, how to detect the "input on the active IO" without pull? If both are floating inputs without pulls, what should I expect to read from currently not connected IO line? Wouldn't they generate a noise?

  • 0 in reply to Oleg Semyonov
    TI__Guru 56590 points

    You always need pull on the active input. But when your application is awake you can configure the IOs as you please. You can disable/enable and configure Pull dynamically however you like. I have not made something like this before, but the idea was that you only enable input with pull for the output (NO) that is left open. That way you can disable the input and pull on the other output (NC) that is closed. There would be no leakage, but you would have to implement some sort of debounce and logic to make sure you don miss necessary switch events. You might get some more feedback on circuit hobby forums or the like.

  • 0 in reply to Eirik V
    Intellectual 360 points

    Thanks, I'll look into this.