Author Topic: Ultra low power listening mode for battery nodes  (Read 185153 times)

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #45 on: July 21, 2015, 08:04:19 AM »
For the node in the pit, you can run some 50ohm typical coax to an antenna above grade and that should make that node very "loud".
Yeah, you can use the u.fl connector that Felix provided the footprint for  ;)

Seriously, this is a very nice feature of the Mega.  Hint to add to feature list for R5.
Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #46 on: July 21, 2015, 08:15:43 AM »
Tom, the cheapest and easiest way to get an antenna away from Moteino is till just bare coax soldered to ANT and GND. The UFL is for modularity, but those connectors add to the cost quite a bit and hence they are not populated, but people can add one if they want to. For the rest of Moteinos the space is pretty tight, i have to worry about other things on there, and not sure how many people would take advantage of it. Even without the dedicated footprint coax is a good compromise and with a little care, a UFL can still be connected between the AND and GND pads on the bottom. Scraping some GND pour provides extra solder surface. It's not ideal I know but it's possible.
It's a tough call where to make the divide between the features of the different Moteino variants. It's like options on cars right?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #47 on: July 21, 2015, 09:35:36 AM »
 
Quote
I forget your wakeup protocol.  Does the gateway send to a specific node?  Presumably all nodes wake up but only the one that was addressed responds while the others go back to sleep?

By the way, while you're redesigning your bootloader, see if there is a way to do it (in low power mode) without external flash  ;D

Tom

I support both a broadcast mode and addressing specific nodes. You'll recall that I can't rely on address filtering by the rfm69 since due to a bug that leads to longer receive windows than specified in listen mode. So yes, all nodes wake up and the ones that aren't targeted go back to sleep immediately.

I plan to use broadcasts to trigger measurements to minimize erroneous wake ups.

The bootloader will always work without external flash since that's the reason it exists. In fact this whole project is really just fodder for my first PCB project and since I'm trying to build something that's both useful and a bit scalable I've decided for a battery optimized Moteino that can be optionally used as standalone thermometer. So the space for the external flash will optionally host the si7021.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #48 on: July 21, 2015, 10:04:01 AM »
Felix,

Rg synchronization: currently I initiate the boot process at a baud rate that works. Then both sides switch to the highest baud rate. When they don't receive anything both sides downgrade to the next slower profile after a certain timeout. The client downgraded to the next lower profile if packet loss rate is too high.

All this means lots of traffic from client to server when they are not yet in synch - clearly a no go for coin cells. I'll need to rework this - will probably have client communicate to server at safe baud rate and have it select the baud rate the server should respond at. Server to client speed is what matters and with that approach I can sequence the process into a long chain of request, response, sleep cycles.

I'll send the profiles later. I know I can have an external antenna for the pit - but I like having at least one challenging node ;)

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #49 on: July 21, 2015, 11:42:47 AM »
Here are my profiles. The 55kbaud one is yours. the 300kbaud one I don't use because already with 200kbaud flashing is the bottleneck for the bootloader.

Code: [Select]
const uint8_t profiles[][5] = {


#if 0
// CFG0: 28kb  1750 ms

  { RF_BITRATEMSB_300000, RF_BITRATELSB_300000,
RF_FDEVMSB_100000, RF_FDEVLSB_100000,
RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 },
// sleep server 1800
// timeout client 10

#endif
 
// CFG1: 28kb 2200 ms 
  { RF_BITRATEMSB_200000, RF_BITRATELSB_200000,
RF_FDEVMSB_100000, RF_FDEVLSB_100000,
RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 },
// sleep server 2400
// timeout client 10

// CFG2: 28kb 7100 ms
  {
  RF_BITRATEMSB_55555, RF_BITRATELSB_55555,
  RF_FDEVMSB_50000, RF_FDEVLSB_50000,
  RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2 },
// sleep server 8500
// timeout client 30

// CFG3: 28kb 18500 ms
  {
  RF_BITRATEMSB_19200, RF_BITRATELSB_19200,
  RF_FDEVMSB_50000, RF_FDEVLSB_50000,
  RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2 } // (BitRate < 2 * RxBw)
// sleep server 23000
// timeout client 50

};

ulli

  • Jr. Member
  • **
  • Posts: 87
Re: Ultra low power listening mode for battery nodes
« Reply #50 on: July 21, 2015, 02:52:07 PM »
I already have developed a function which let me deactivate the functionality I do not use on ultra low power moteinos.
It also includes the WDT. I use the RFM69 DIO0 on a INT0 pin of the Atmega to wake everything up.

Code: [Select]
/*******************************************************************************
*
* Argument  Description
* =========  ===========
*
* 2. adc ADC module disable control:
* (a) ADC_OFF - Turn off ADC module
* (b) ADC_ON - Leave ADC module in its default state
*
* 3. timer2 Timer 2 module disable control:
* (a) TIMER2_OFF - Turn off Timer 2 module
* (b) TIMER2_ON - Leave Timer 2 module in its default state
*
* 4. timer1 Timer 1 module disable control:
* (a) TIMER1_OFF - Turn off Timer 1 module
* (b) TIMER1_ON - Leave Timer 1 module in its default state
*
* 5. timer0 Timer 0 module disable control:
* (a) TIMER0_OFF - Turn off Timer 0 module
* (b) TIMER0_ON - Leave Timer 0 module in its default state
*
* 6. spi SPI module disable control:
* (a) SPI_OFF - Turn off SPI module
* (b) SPI_ON - Leave SPI module in its default state
*
* 7. usart0 USART0 module disable control:
* (a) USART0_OFF - Turn off USART0  module
* (b) USART0_ON - Leave USART0 module in its default state
*
* 8. twi TWI module disable control:
* (a) TWI_OFF - Turn off TWI module
* (b) TWI_ON - Leave TWI module in its default state
*
*******************************************************************************/
void TurnOffFunktions(bod_t bod, adc_t adc, ain_t ain, timer2_t timer2, timer1_t timer1, timer0_t timer0, spi_t spi, usart0_t usart0, twi_t twi, wdt_t wdt) {
// Temporary clock source variable
unsigned char clockSource = 0;

if(bod == BOD_OFF) {
// turn off brown-out enable in software
MCUCR = bit (BODS) | bit (BODSE);  // turn on brown-out enable select
MCUCR = bit (BODS);        // this must be done within 4 clock cycles of above
}

if (timer2 == TIMER2_OFF) {
if (TCCR2B & CS22) clockSource |= (1 << CS22);
if (TCCR2B & CS21) clockSource |= (1 << CS21);
if (TCCR2B & CS20) clockSource |= (1 << CS20);

// Remove the clock source to shutdown Timer2
TCCR2B &= ~(1 << CS22);
TCCR2B &= ~(1 << CS21);
TCCR2B &= ~(1 << CS20);

power_timer2_disable();
} else if(timer2 == TIMER2_ON) {
if (clockSource & CS22) TCCR2B |= (1 << CS22);
if (clockSource & CS21) TCCR2B |= (1 << CS21);
if (clockSource & CS20) TCCR2B |= (1 << CS20);

power_timer2_enable();
}

if (ain == AIN_OFF) {
DIDR1 |= (1 << AIN1D) | (1 << AIN0D);
} else if(ain == AIN_ON) {
DIDR1 &= ~((1 << AIN1D) | (1 << AIN0D));
}

switch(adc) {
case ADC_OFF:
ADCSRA &= ~(1 << ADEN);
DIDR0 |= (1 << ADC5D) | (1 << ADC4D) | (1 << ADC3D) | (1 << ADC2D) | (1 << ADC1D) | (1 << ADC0D);
power_adc_disable();
break;
case ADC_ON:
power_adc_enable();
DIDR0 &= ~((1 << ADC5D) | (1 << ADC4D) | (1 << ADC3D) | (1 << ADC2D) | (1 << ADC1D) | (1 << ADC0D));
ADCSRA |= (1 << ADEN);
break;
case ADC0_OFF:
DIDR0 |= (1 << ADC0D);
if((DIDR0 & 0x3F) == 0x3F) {
ADCSRA &= ~(1 << ADEN);
power_adc_disable();
}
break;
case ADC0_ON:
power_adc_enable();
DIDR0 &= ~(1 << ADC0D); //Just Turn ADC0 on
ADCSRA |= (1 << ADEN);
break;
case ADC2_OFF:
DIDR0 |= (1 << ADC2D);
if((DIDR0 & 0x3F) == 0x3F) {
ADCSRA &= ~(1 << ADEN);
power_adc_disable();
}
break;
case ADC2_ON:
power_adc_enable();
DIDR0 &= ~(1 << ADC2D); //Just Turn ADC0 on
ADCSRA |= (1 << ADEN);
break;
default: break;
}

if (timer1 == TIMER1_OFF) {
power_timer1_disable();
} else if(timer1 == TIMER1_ON) {
power_timer1_enable();
}

if (timer0 == TIMER0_OFF) {
power_timer0_disable();
} else if(timer0 == TIMER0_ON) {
power_timer0_enable();
}

if (spi == SPI_OFF) {
SPCR &= ~(1<<SPE);
power_spi_disable();
} else if(spi == SPI_ON) {
power_spi_enable();
SPCR |= (1<<SPE);
}

if (usart0 == USART0_OFF) {
UCSR0B &= ~((1<<RXEN0) | (1<<TXEN0));
power_usart0_disable();
} else if(usart0 == USART0_ON) {
power_usart0_enable();
UCSR0B |= (1<<RXEN0) | (1<<TXEN0);
}

if (twi == TWI_OFF) {
TWCR &= ~(1<<TWEN);
power_twi_disable();
} else if(twi == TWI_ON) {
power_twi_enable();
TWCR |= (1<<TWEN);
}

if (wdt == WDT_OFF) {
wdt_reset();
wdt_disable();
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = 0x00;
/* } else {
wdt_enable();
WDTCSR |= (1 << WDIE);
*/
}

}

@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?
« Last Edit: July 21, 2015, 02:57:16 PM by ulli »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #51 on: July 21, 2015, 03:16:18 PM »
Quote
@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?

Well as soon as a Moteino wakes up it goes right back to sleep for 3s to ensure that the burst is over and then it reports back to the server. It certainly doesn't sit in receive @ 16 mA for 3s.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #52 on: July 21, 2015, 04:52:27 PM »
Quote
@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?

Well as soon as a Moteino wakes up it goes right back to sleep for 3s to ensure that the burst is over and then it reports back to the server. It certainly doesn't sit in receive @ 16 mA for 3s.
Now that's interesting.  Ulli, it was a good question and with your answer Joe, it seems as if you must go back to sleep but no longer in Listen Mode but this time with WDT wakeup a few seconds later?  And how do multiple nodes avoid collision when they finally reply to the gateway?

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #53 on: July 21, 2015, 05:11:35 PM »
I actually do stay in listen mode - that's not a problem since the listen window won't be hit until the WDT hits. I do have to use the WDT for that delay obviously. From an energy budget point of view that's not relevant since its 4uA with a duty cycle of say 3s : 180s.

Collisions are unlikely to happen since the burst lasts 3s. At 200kbaud a packet takes say 2ms. Remember there are no acks. Even with a large number of nodes the probability that their randomly distributed 2ms windows overlap during a 3s interval is exceedingly small. If it does happen it won't happen next time.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #54 on: July 21, 2015, 05:27:06 PM »
I should add that I'm planning to use an extra Moteino for the burst collection. It'll be the bathroom fan controller which is AC powered and therefore powered to take on that role. I don't want the whole network to be down during the burst collection. So the gateway will continue to do its thing. The bathroom fan Moteino will send the burst and collect answers on a separate frequency. When all answers are in it will relay them to the gateway.

But that's icing on the cake. If you just want to deploy a bunch of thermometers the given scheme will work without this luxury. If however you want to be able to open your garage while the thermometers are being polled having an extra Moteino is the way to go :)

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #55 on: July 21, 2015, 06:57:48 PM »
I actually do stay in listen mode - that's not a problem since the listen window won't be hit until the WDT hits.
Why is that?  ISTM that if a burst of packets produce a hit, then subsequent packets within the same burst may produce a hit also since the listen window is slightly narrower than the burst width (as I understand it).
Quote
I do have to use the WDT for that delay obviously. From an energy budget point of view that's not relevant since its 4uA with a duty cycle of say 3s : 180s.
Understood, just confirming.
Quote
Collisions are unlikely to happen...
Boy, if I only had a nickle...  ;)

Tom
BTW, I think the bathroom fan is an excellent place to hide your burst collector.  Very secure - who would think of looking there?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #56 on: July 22, 2015, 02:42:58 AM »
Quote
Why is that?  ISTM that if a burst of packets produce a hit, then subsequent packets within the same burst may produce a hit also since the listen window is slightly narrower than the burst width (as I understand it).

Yes, true. In the current prototype you could get hit twice. In my "production system" I  have a much shorter second sleep period since I collect results at the gateway which can collect while the bathroom fan bursts ;). But for the new system the burst collector receives at the higher baud rate so the sleep period is necessary and things will be a tiny bit better by switching listen mode off before sleeping.

Quote
Boy, if I only had a nickle...  ;)

Let's get systematic: the size of the send window is 2 : 3000, call it 3 : 3000 or 1 : 1000 for easy calculation. The probability that there is no overlap with n senders should be 1000! / (1000-n)! / 1000^n. With 10 senders that's 0.955.

That's ok but worse than I thought. Some busy spinning might be in order to wait until the air is clean. Or I'll wait a bit longer than the burst window. With a 6 second send window you'd have 0.985 for the probability of no overlap. Will have to experiment a bit with that.


joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #57 on: July 22, 2015, 02:53:14 AM »
Ah just thought of the solution to the collision problem: I'll have a counter in each burst packet. That way a client knows when in the burst it woke up and can time it's response. I'll just cut the response window into n slices and have each node respond during one of them.

No collisions, no busy spinning, faster response after burst end - everybody happy :)


TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #58 on: July 22, 2015, 08:14:27 AM »
Ah just thought of the solution to the collision problem: I'll have a counter in each burst packet. That way a client knows when in the burst it woke up and can time it's response. I'll just cut the response window into n slices and have each node respond during one of them.

No collisions, no busy spinning, faster response after burst end - everybody happy :)
Well, I was pulling your chain in the previous post, because, as you say, this is not mission critical stuff and you'll get the data on the next cycle.  Having said that, yes, I do like this particular solution.  Good job!

Now given that you've adjusted the response window according to when in the burst the recv occurs, you can also resolve the multiple recv per burst issue by shutting off listen until the response is sent.

Tom
« Last Edit: July 22, 2015, 08:18:47 AM by TomWS »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #59 on: July 22, 2015, 08:20:51 AM »
No collisions, no busy spinning, faster response after burst end - everybody happy :)
I forgot to mention in my previous post, it's always good to keep your bathroom fan happy!  DAMHIKT!

Tom