Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Battery would probably be a no-go here.

You can't put repeater into sleep mode[#], and in active AP+STA mode ESP8266 takes 70mA @3.3v, which is 3-4 times lower than best purpose-made wifi repeaters, but will still drain 3000mA*h battery in couple of days.

[#] ...unless whole sensor network has scheduled "data upload" internals, something like 1-minute window twice a day. But even that is going to be very tricky due to notoriously poor precision of ESP's real-time clock - see for example https://github.com/micropython/micropython/issues/2724



Schedule it more often than once per day and when it triggers, resync the clock with your neighbours? If you wake up and nobody else seems to be awake, go into degraded mode where you continually listen for the next scheduled interval.


> when it triggers, resync the clock with your neighbours?

Indeed. Periodic clock resync is a must here. Better from external NTP though, as neighbours have their clock badly drifting as well.

> If you wake up and nobody else seems to be awake, go into degraded mode where you continually listen for the next scheduled interval.

That'll defeat the purpose completely. Here's why:

- "Listen" consumes full 70mA;

- "wake up and no neighbours awake" will happen very, very often. Let's take simplest example of two nodes with drifting clock. When they both wake up (each by local clock), inevitably one will wake up first. That node will discover there's no neighbours awake. I a mesh, statistically this will happen to 1/N nodes each wake-up, where N is average number of neighbours. If we tighten requirement from "anybody awake" to "enough nodes awake to reach uplink" (so to make use of external NTP) probability of "not enough neighbours awake" even will come close to 100% on each wakeup.

Slightly better approach would be - when each node wakes up, it stays awake for long enough to cover worst-case all neighbour's clock drift. Average clock drift seem to be +/-2%. Let's say +/-5% would be worst case. That means, all nodes have to be awake 10% of the time just to re-sync clock so that next wake-up will be not worse off than current one.

And staying awake 10% of the time means average power draw of 70mA * 10% = 7mA, which is pretty darn high (3 weeks on a 3000mA*h Lithium cell. Even less if there is payload data transmitted on this mesh.)


External high accuracy RTCs with builtin alarms like the ds3231 can be had for cheap


I don't really see the need for external NTP. The mesh needs to coordinate internally, it doesn't need to agree with the world.

Staying awake 10% of the time seems like a decent improvement on staying awake all the time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: