Author Topic: ListenMode settings to support ULP  (Read 7123 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: ListenMode settings to support ULP
« Reply #15 on: September 16, 2015, 04:48:57 PM »
That's why I think there's a chance that your non-burst method might not trigger the bug.

That's what I'm hoping.  If it does trigger it, then it sounds like I can dial-in a bigger gap between Tx's until it doesn't.  Adding gap is easy.  Getting smaller and smaller gaps, as you have already managed to do, is more challenging.


Strangely, it turns out the default for the RFM69 library is to have address filtering turned off.  Not sure why that would be.  If I turn it on, Listen-Mode continues to work just fine with address filtering on, regardless of whether packets are sent to the receiver node's address or not.   If I send a long string of packets (the 1.2ms cycle I described above), but to a different address, the receiving node continues with business as usual in Listen-Mode while  address filtering is turned on.  It did not go into a sustained Rx mode.  i.e. it did not encounter the bug.  So, just FYI, in case anyone is curious.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: ListenMode settings to support ULP
« Reply #16 on: September 20, 2015, 01:58:00 AM »
Additionally, I think that it is not necessary to hand tune the delay, if you use the following function to check the transmission/FIFO status during your burst?
Code: [Select]
while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFOLEVEL) != 0x00); // Wait till Threshold is not exceeded / Does not work in Sleep_Mode!

Ulli, it works! Well actually not exactly your version, but this:

Code: [Select]
while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFONOTEMPTY) != 0x00);


You officially receive Joe's Listen Mode Medal  :). I can now send 5577 packets using 200kbaud during my 2900s burst period or 0.5ms per packet. I previously had the manual delay at 2ms. Once every 120seconds I poll my nodes for updates using listen mode. On average I will miss about half an packet delay - so I get a saving of 1ms / 120s * 16mA = 133 nA. Not huge but nonetheless.

I think the real benefit is that one can now send arbitrarily long packets without had massaging the code.

Thank you.

Joe
« Last Edit: September 20, 2015, 02:00:26 AM by joelucid »

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #17 on: September 20, 2015, 09:40:34 AM »
Did you set the RF_FIFOTHRESH_VALUE? My setup is as the following:
Code: [Select]
{ REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE }
RF_FIFOTHRESH_VALUE=0x0F

I do not understand how your code should work?
Code: [Select]
while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFONOTEMPTY) != 0x00);

Therefore your while loop waits till the FIFO is empty. That must not happen in unlimited package mode.
You have to fill the FIFO during transmission and prevent it to be  empty or full.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: ListenMode settings to support ULP
« Reply #18 on: September 20, 2015, 11:16:06 AM »
No, I don't use unlimited length packets. I use a non-interrupted burst of very short packets. So for me FIFO empty is exactly the right condition. If you use a huge packet how can your listening client pick up the beginning of one?

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #19 on: September 20, 2015, 01:46:26 PM »
The client detects the preamble and sync words, like your client does.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: ListenMode settings to support ULP
« Reply #20 on: September 20, 2015, 01:49:32 PM »
Are the two ways of doing it functionally equivalent?

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #21 on: September 20, 2015, 01:52:58 PM »
Basically it sends the same message. I just want this unlimited package length method because I can be sure that there is no gap between the two message frames.
I had some issues with separated messages that the client detects the end of a burst within the canSend function to early and therefore I missed the client ACK several times.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #22 on: September 20, 2015, 03:08:10 PM »
Joe, would you post your send function? I would like to compare our to ways...

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: ListenMode settings to support ULP
« Reply #23 on: September 20, 2015, 04:13:30 PM »
Quote
Joe, would you post your send function? I would like to compare our to ways...

Absolutely. Here you go...

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: ListenMode settings to support ULP
« Reply #24 on: September 20, 2015, 04:19:03 PM »
Quote
I had some issues with separated messages that the client detects the end of a burst within the canSend function to early and therefore I missed the client ACK several times.

With coin cells canSend and even acks are death. When my clients receive a burst they powerDown until it's over and then send their update to the server. For me the need for a continuous burst is driven by the requirement for clients to always receive a packet during a burst no matter how short the RX period. You don't want the RX period to happen during a gap between two TX periods.

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: ListenMode settings to support ULP
« Reply #25 on: September 20, 2015, 11:03:39 PM »
You officially receive Joe's Listen Mode Medal  :).
I second Joe's nomination!  One of my Tiny TH Motes was a very poor 'listener' for some reason, randomly failing to respond to a wakeup burst about 30-40% of the time.  However, I made the change Joe mentioned above and it hasn't failed since (about 12 1/2 hours now).  I'll be updating my library in the next couple of days.

Thanks!

Tom
UPDATE: 2 misses out of 163, not good enough, but still a significant improvement from 1 out of 3!  I still have to dig into why this particular mote is weak.
UPDATE 9/23/15: Turns out there were NO errors after making this change.  See post https://lowpowerlab.com/forum/index.php/topic,1307.msg8979.html#msg8979
« Last Edit: September 23, 2015, 08:49:39 AM by TomWS »

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #26 on: September 21, 2015, 01:11:05 PM »
Hi ListenGuy`s, :)

I did some additional tests (also with Joes code) and spend some more time thinking about bursts....

Now I come back with a question which were not be answered by the datasheet :(
What is the trigger of the RFM module to send a new package and therefore the module adds the preamble, syncwords and does the calculations for the CRC and does datawhitening?
  * when I set the mode to RF69_MODE_TX coming from a other mode?
  * when the FIFO is empty and new data will be written to the empty FIFO?
  * when the SPI CS pin changes? (select, unselect)

I additionally found an issue in correlation with setting a small as possible REG_RSSITHRESH value to reduce phantom wake ups in ListenMode.
(I think that was the problem why my client did just run 2 month on 2xAA batteries)
I reduced the threshold till -80 and still get a good detection but the canSend function stops working well.
With low rssi thresholds the module can not longer detect when a burst is over.
--> Workaround: I do set the RSSIThreshold to his maximum when ever the CanSend function is running.

I would be thankful for further hints or your feedback.

PS.: With Joe`s code and the workaround it looks like I can transmit nearly 100% of packages to the client which is in ListenMode and get a ACK in <10ms after a burst.
« Last Edit: September 21, 2015, 01:13:05 PM by ulli »

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: ListenMode settings to support ULP
« Reply #27 on: September 21, 2015, 02:04:30 PM »
Keep it up, ulli and you might have your medal taken away from you  :-\

Why on earth would you want to try to get an ACK to a burst transmission?  That is so fraught with problems I can't even imagine them all!   If your sender needs an 'acknowledge' (notice the lower case) then each of the receivers can send ANY kind of Packet it wants AFTER the dust has settled on the burst and the network has quiesced.  What's wrong with this approach?

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: ListenMode settings to support ULP
« Reply #28 on: September 21, 2015, 04:58:15 PM »
Hi Ulli,

From the data sheet:

Quote
The transmission of packet data is initiated by the Packet Handler only if the module is in Tx mode and the transmission condition defined by TxStartCondition is fulfilled. If transmission condition is not fulfilled then the packet handler transmits a preamble sequence until the condition is met. This happens only if the preamble length /= 0, otherwise it transmits a zero or one until the condition is met to transmit the packet data.

I think we have the txstartcondition fifonotempty set. So if you fill the FIFO and the switch to TX transmission will get initiated. Also if you keep the radio in TX transmission will continue as soon as you start writing to the FIFO again. In between preamble will be sent.

Rg Rssithresh: I use Felix settings during normal operation. When I receive using my listener class I reprogram the radio to use a less sensitive threshold. After using listen more I reinitislize the radio, reestablishing Felix settings.

Like Tom said I wouldn't recommend acks. Just have the nodes send back a packet after the burst is done.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: ListenMode settings to support ULP
« Reply #29 on: September 22, 2015, 03:34:41 PM »
Hi joe,
Thanks for your hints!

Quote
The transmission of packet data is initiated by the Packet Handler only if the module is in Tx mode and the transmission condition defined by TxStartCondition is fulfilled. If transmission condition is not fulfilled then the packet handler transmits a preamble sequence until the condition is met. This happens only if the preamble length /= 0, otherwise it transmits a zero or one until the condition is met to transmit the packet data.

I think we have the txstartcondition fifonotempty set. So if you fill the FIFO and the switch to TX transmission will get initiated. Also if you keep the radio in TX transmission will continue as soon as you start writing to the FIFO again. In between preamble will be sent.
Ok, therefore in the case of keeping the radio in TX transmission the separation of two packets will be defined by a Fifo empty condition.
As soon as I write to the empty Fifo the radio is starting to send the preamble, syncwords, the new Fifo filled payload an calculates on the fly the CRC?
Is that correct?
Based on that facts your proposal "while ((readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_FIFONOTEMPTY) != 0x00); " make sense!

Quote

Rg Rssithresh: I use Felix settings during normal operation. When I receive using my listener class I reprogram the radio to use a less sensitive threshold. After using listen more I reinitislize the radio, reestablishing Felix settings.
All right you are doing something similar!

Quote
Like Tom said I wouldn't recommend acks. Just have the nodes send back a packet after the burst is done.
Of course, I know that waiting in RX till a burst is over is waisting energy!
I will include a byte in the payload to give the client the information for the sleeping period when the burst is over later on...(something similar like you did in your code )