New transmission control for RFM69's

[lhw455]

I saw this (http://lowpowerlab.com/blog/2015/11/11/rfm69_atc-automatic-transmission-control/) which I thought was interesting, especially when using Arduino's on batteries.

Will this need to be integrated into the existing sketches or can we try and integrate it ourselves?

[papa]

Good eyes, lhw455. This sounds interesting especially for battery powered nodes, one of which I am in the process of building. In the original Uber Home Automation the battery powered nodes were put to sleep to save power, but I believe that created reliability problems. This could be a reliable way to save & extend battery power.

When I get a chance, I'll look at the low power example sketches & see how hard to add this feature to our sketches.

But I'm really hoping Computourist examines this & decides how to respond to the availability of this feature.

May not be so useful for wall powered nodes, except to quiet the signals radiating from one's location.

[computourist]

Hi papa, lhw455,

I had a look at the description of this feature. It is really interesting and seems easy to implement in the design we are using.
Especially the impact in the gateway is minimal, so I made a note to include it whenever an upgrade of the gateway code is needed.
We could even implement the same principle on the gateway (Gateway measuring RSSI and telling the node to back down)

Up to now there is no reliable code available on this forum for battery-operated devices. There were some attempts, but they were all dropped due to unreliable radio links.
I have seen some nice ideas on Jeelabs.org that could be an inspiration.. (jeelabs.org/2012/09/15/one-million-packets/)

To have a node operate on batteries it must:
- go to sleep mode and only wake up on regular intervals to transmit, then go to sleep again.
- only use the push-model for data acquisition (the device is not available when in sleep mode)
- The gateway needs some store-forward mechanism if control of these type of nodes is needed

Implementing the ATC-feature really is only interesting when reliable code for a sleep-mode node is available.

I guess the approach is obvious:
- first develop code for a sleep-mode end node
- then maybe adapt the gateway to handle these kind of devices
- try to extend battery life by increasing the transmit interval or lowering the signal power or both.

Who takes the first step ?

[papa]

Thanks, Computourist, for taking a look at this so soon & mapping a strategy for considering it.

I'm not super confident in my coding skills, esp. about things like sleep modes & interrupts.

However, I do fairly well in studying things that work, learning from them, tweaking & adapting from there.

When I get a chance, I'll look at the Jeelabs & ATC stuff & see what I learn.

However, I hope anyone else will feel motivated to jump in here. Maybe we can tag team this.

A battery-sipping option would be a nice addition to the project.

I just finished a bare bones 3.3 volt Arduino DHT end node on a double sided circuit board that is using 4 AA alkaline batteries in series for power. To save some power, no USB so one programs the ATMega328 chip separately. No end node push button & no reset button. It does have an LED to toggle, but plugged into a female header so I can remove it. It runs the basic Computourist DHT End Node sketch with push button code commented out. Now I'm letting this battery powered node run with fairly new batteries to see how long it will go.

What I built took the MCP1701 3.3 volt regulator from the Uber Home Automation battery power node & then continued with what I'd learned about building bare bones 5 volt Arduinos. I hope to document what I've done so far & improving battery use would be even better.

[kmac]

There is another issue with sleeping nodes that must be considered.
Some devices require a warm-up period before they are accurate.
For instance I think a 2 second warm-up is suggested for the DHT22 before it gives an accurate reading.

[papa]

Yes, kmac, one might have to allow for things like warm up period & maybe also consider where it is appropriate to put battery powered nodes that sometimes sleep. Off the top of my head, one would put them where wall power is not available (outside, away from one's home) or very inconvenient AND avoid functions needing ongoing control (like a heating / cooling system).

[papa]

    About devices' (like DHT sensors') need for a warm up period:

Adafruit's info on DHT11 sensors & DHT22 sensors : "The only real downside of this sensor is you can only get new data from it once every 2 seconds, so when using our library, sensor readings can be up to 2 seconds old."

I read the above as NOT requiring a "warm up" period for DHT sensors. Rather that there must be at least 2 seconds wait between getting FRESH data from the sensor. It would seem from this, one would not need to wake up a sleeping Arduino & wait 2 seconds before getting DHT data. Or am I missing something?

[kmac]

According to the datasheet on Adafruit, it looks like the startup time is 1 second, then 2 seconds between new data.
From datasheet:
1) Powerand Pins
Power's voltage should be 3.3-6 VDC. When power is supplied to sensor,don't send any instruction to the sensor within one second to pass unstable status.

[papa]

Thanks for nailing that down, kmac

[papa]

I just started a new thread, Battery-sipping DHT Node (a la Computourist) to collect our conversations about battery nodes & perhaps add some progress.  Thanks for your contributions.

[greginkansas]

It works fine. most of my nodes are so close, at first I was not sure but they are just at the min power. Just add the code from the samples

[papa]

Thanks, greginkansas, for trying it [ATC, I assume] & reporting back here. lewishollow has also been using it in his adaptation of the computourist end node. See his thread Re-imagined RFM node code - All-in-one, low power, OO design