Hacker News new | past | comments | ask | show | jobs | submit login

This sounds like a really fun thing to play with and could be useful for extending covered range where bandwidth requirements are low.

Where I usually struggle is making it all small and robust enough. Does anyone know of any products which integrate power supply (mains or battery) and the esp8266 into a small, cheap enclosed product. The best candidate I have found so far would be the Sonoff products.




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.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: