Ultra low power listening mode for battery nodes

[joelucid]

Hey Craig,

as you can tell if you've spent some time on this thread I've spent a lot of energy on listen mode. And for me the end result is that listen mode is so broken on the SX1231H that it can't be used as is.

I haven't come to this conclusion lightly. I've developed workarounds for most of the first order bugs. But with listen mode the chip just becomes increasingly less functional as you apply the workarounds. I've also contacted Semtech and talked to a representative. But the more detailed my questions became the less inclined he became to find answers  .

The issues are subtle - everything will seem fine but after a week your first node drops off. Or everything runs fine for months but when you have a loud noise signal your radios will wake up and never go to sleep again, draining the battery. It just depends on how many levels of workarounds you already have implemented.

So here's my current assessment: the only reliable way to make use of listen mode is to set RSSI thresh to 0 so it never triggers and just use the PllLock irqs as wakeup timer. That only gives you a cheap and imprecise clock, but you can implement your own listen mode on top. I have listen mode as timer running on maybe 20 nodes around the clock. It never fails.

Here's what I've come up with as listen mode replacement. It has the added benefit of using only standard radio features - none of the hacks I had used earlier (e.g the uninterrupted stream of wake-up packets):

- Client uses listen mode as wakeup timer to wake up every n ms and switches the radio to RX using a given RSSI thresh. Wait for 2 bits and see if the RSSI irq triggers.
- Server switches the radio to TX when trying to wakeup a client. Staying in TX for > n ms sends a stream of preamble which the client detects via RSSI.
- Server then puts radio into standby and waits a couple of ms. Finally sends real payload.
- Client probes for the server to stop sending preamble by detecting RSSI every m ms.
- When preamble no longer sent client switches to RX and receives packet.

This works well.

You'll have to actively manage RSSI thresh for this to work. Just keep slowly lowering the thresh until you get ghost RSSI detects and then quickly dial up.

Regardless of the listen mode configuration I see a significant drops in range. I am using the low power version and I see around 120m when purely in RX mode, however when going into Listen I struggle to get above 70m.

The radio needs to see the full packet with enough preamble. I don't know what your wake-up packets look like - but you'll need to take that into account. I initially used an uninterrupted stream of packets, ensuring that if RX starts mid packet RSSI would be detected and the next packet received. Another approach would be one packet with a really long preamble - however keeping the receiver longer in RX. I think the approach above combines the best of both methods.

Joe

[joelucid]

Attached is my "manual listen mode" implementation. It uses my radio lib but might still be useful as example of how to do it.

Joe

[craigburden]

Hi Joe,

Thank you so much for the speedy reply, but to be honest it isn't the news I was hoping for this morning!

So I guess this leaves me with two options (Well... three but I don't like the third).

Option 1:

The one major advantage our devices have is that they are waking up every second (Using the micro's internal WDT) to sample temperature and so I could write some code to check and manage the state of the radio. So basically I could use listen mode as I have it setup now with a RSSI threshold of 255. I could even turn RSSI off if that is an option. This would of course mean the radio would wake up for the full duration of the timeout2 every time but at least that means the issue of needing to see the preamble for a good RSSI reading may not be an issue? Of course this makes it a whole lot more power intensive than if the RSSI was working as it should. The fact that we wake up regularly I could check the radio state and potentially correct for it having gotten stuck in RX for example? This only works because I am not reliant on the radio for wake ups. I know that my packet takes 4.2ms to send including the 3 byte preamble, so I could set my timeout 2 such that I am on for around 10ms meaning I can pick up over 2 packets (I could reduce this if it doesn't seem to affect range).

Option 2:

Instead of using listen mode, I create the same listen mode setup as I described in option 1 however manually. I could put the radio in RX mode every second wake up for example and leave the radio on for 10ms. Again this is not ideal for power and requires a lot more of the micro's resources to manage.

Option 3:

Find a new micro like the SI4463 or the CMT2300AW. In terms of the time frame I have to get all of this done in, I really don't like this option as I would need to design new circuitry etc.



With regard to the transmission sequence you have recommended, I can move to something similar with a very large preamble as a wakeup type message. But I am not entirely sure that this would be sacrificing the backward compatibility that we would really like to keep. The previous system used the MRF49XA which is what the RFM12B is cloned off. I would need to ensure that those devices are able to handle the long preamble given that they expect 3 byes currently and we are not able to reprogram them. Do you recommend increasing the normal preamble length for each packet or just to send a large preamble for wakeup purposes.
As you may have deduced so far, the current system doesn't use a specific wakeup message. Rather it just starts streaming repeated data once a fire is detected.

I am going to range test the listen mode code I have now, and aim for using option one. Do you have any advice?

[joelucid]

So basically I could use listen mode as I have it setup now with a RSSI threshold of 255. I could even turn RSSI off if that is an option. This would of course mean the radio would wake up for the full duration of the timeout2 every time but at least that means the issue of needing to see the preamble for a good RSSI reading may not be an issue?

I've not tried listen mode with address match - that might well work better. But with RSSI as I said I could never quite get it to work right.

The fact that we wake up regularly I could check the radio state and potentially correct for it having gotten stuck in RX for example?

Yeah - well that's what I tried. I used the RSSI detect irq to wake the MCU and the supervised the RX process of the radio, switching it out of listen mode if it got stuck. But listen mode sometimes doesn't like that and will leave the chip in a state where it will immediately cancel RX once the RSSI thresh hits during listen mode. I had a workaround for that, too. But that led to listen mode not longer even triggering a PLLLock irq.

Instead of using listen mode, I create the same listen mode setup as I described in option 1 however manually.

Yeah, better chances I think. You can do RSSI detect as I suggested in the example.

Find a new micro like the SI4463 or the CMT2300AW.

I actually like the SX1231H, listen mode issues notwithstanding. I have a gateway supporting adaptive bitrates and frequency hopping, with pretty amazing range. You don't need to give up on the chip.

The previous system used the MRF49XA which is what the RFM12B is cloned off. I would need to ensure that those devices are able to handle the long preamble given that they expect 3 byes currently and we are not able to reprogram them. Do you recommend increasing the normal preamble length for each packet or just to send a large preamble for wakeup purposes.

I only use the large preamble as wakeup signal only. No need to increase it for normal packets. The receiver doesn't really care how much preamble it gets as long as its enough to allow the bit synchronizer to synch the bitrates. That however is important so you need to ensure that whatever mode you design the receiver always sees the full 3 bytes.

Joe

[craigburden]

So I hacked together a quick version this mode where I put the transceiver in RX mode when I wake up for a period of time (6ms currently, as that is about 1.5x a packet length) and then process the packet if there is one. This is giving me the full range at long last with a almost workable current draw. I have some trickery to get it a bit lower.

I am very interested in implementing the RSSI check you have used however I am again unsure as to how to determine the threshold value. Is there no formula or something that defines the sensitivity? Is the only way to scale it by hand and in order to find the correct value? My concern is that the RF environment in the office is obviously very different to where our devices are used so is that a sensible method? I guess regardless of the environment there will be a point at which all of them will trigger falsely.

My hope is to make the power even if the device were to wake up everytime still a workable value, which is currently where I stand, and then make it such that if it didn't wake up falsely the current is greatly reduced.

Thank you so much for the help! It is wonderful finally having someone who has played with listen mode to talk to!

[WhiteHare]

The issues are subtle - everything will seem fine but after a week your first node drops off. Or everything runs fine for months but when you have a loud noise signal your radios will wake up and never go to sleep again, draining the battery. It just depends on how many levels of workarounds you already have implemented.

Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

As usual, you have great information to share.  Thanks!

[craigburden]

Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

As usual, you have great information to share.  Thanks!

Yes I have ruled that out, we use one or two AA alkaline cells in parallel so current draw isn't a issue. Plus our boost converter is capable of 300mA at 3.3v. I have tried it on a bench supply too, it didn't seem to make a difference. But good thought!

And thank you, I really enjoy having this forum. Previously we use transceivers that were rather obscure and I would spend ages troubleshooting these problems alone which really slows the progress! I will write up a what I learnt post some time to hopefully help others

[WhiteHare]

Actually, I was directing that particular question at Joe (I guess I should have been more clear about that), but I'm glad that you answered it for your situation also.  The more datapoints the better!

[joelucid]

I am very interested in implementing the RSSI check you have used however I am again unsure as to how to determine the threshold value. Is there no formula or something that defines the sensitivity? Is the only way to scale it by hand and in order to find the correct value? My concern is that the RF environment in the office is obviously very different to where our devices are used so is that a sensible method? I guess regardless of the environment there will be a point at which all of them will trigger falsely.

Yeah you have to tune it dynamically. A predefined value can only be used if you have such a strong signal that you can set your thresh a massive distance from the sensitivity and have room for e.g. noise issues.

Something like this: whenever you get a ghost activation increase the threshold by one and wait a second. Whenever you haven't had a ghost activation in 10 minutes decrease the threshold by one. The waiting period prevents racking up the threshold too high for an intermittent noise source. And waiting 10 minutes to decrease means that you'll only get one ghost activation every 10 minutes in equilibrium.

But yeah it's a challenging problem. In my gateway I have a similar problem where I need to detect whether a signal exists at a given bitrate to enable multiple clients to send at differing bitrates. There I use address match instead of RSSI because the gateway  is mains powered and I didn't want to manage RSSI for 50 channels x 5 bitrates.

Joe

[joelucid]

Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

I have had these issues with coin cells and also with 9V battery powered moteinos. I have one moteino with removed regulator running from 2x aaa lithium which has never had the issue.

[ChemE]

I have had these issues with coin cells and also with 9V battery powered moteinos. I have one moteino with removed regulator running from 2x aaa lithium which has never had the issue.

That makes me think the LDO is the cause...

[WhiteHare]

That makes me think the LDO is the cause...

Well, something is causing it, but who knows what. 

Actually, Joe's "manual" way of doing it shouldn't require a whole lot more current (percentage wise at least), and it has the benefit of making the code more portable to different radios that may not have a built-in listen mode. 

[TomWS]

That makes me think the LDO is the cause...

Doesn't follow.  The coin cell units didn't have LDO VR either.  However, both the coin cell and 9V unit with VR would have a higher ESR and the 2xAAA lithium would have a higher voltage (3.4-3.6 typ).

Tom

[WhiteHare]

Say, Tom, you have been using listen mode quite a bit and for quite a long time now, if I'm not mistaken.  Have you too encountered the kind of issues with it that Joe has described?

[joelucid]

Actually, Joe's "manual" way of doing it shouldn't require a whole lot more current (percentage wise at least), and it has the benefit of making the code more portable to different radios that may not have a built-in listen mode.

Also my more recent motes all have a clock xtal for frequency hopping. And a "listen mode" implementation that's synchronized and lets the gw reach its clients exactly when they're listening is much more powerful and can be implemented in compliance with the regulations. That's where I see this going in my stack - so I don't have much of a need to further mess around with native listen mode.

Doesn't follow.  The coin cell units didn't have LDO VR either.  However, both the coin cell and 9V unit with VR would have a higher ESR and the 2xAAA lithium would have a higher voltage (3.4-3.6 typ).

Correct. And actually due to the limited transient response LDO's often produce quite a bit of a voltage spike down when a pulse load hits. So it's not impossible there's a connection here. Perversely a directly connected lithium aaa often provides a much more stable power supply than a regulator. I had to remove the LDO from a recent project since it would create such a pronounced drop on sudden load that the BOD got triggered (this with a LDO with lots of reserves current wise and fairly big bulk cap).

Joe