5 ms·
It is possible to react at any time because of an external hardware event, such as a button press or a hardware sensor that triggers. Depending on the sensor or
by adunk 9y ago
It is possible to react at any time because of an external hardware event, such as a button press or a hardware sensor that triggers. Depending on the sensor or external hardware, those events can be very cheap in terms of power consumption. For example, a button switch can be completely passive and consume power only when it triggers. Once it triggers, the microprocessor wakes up and can decide to handle the event, potentially by using the radio to send a message. Sending the message will consume much more power than just turning on the microprocessor, so depending on the application logic the microprocessor can simply choose to ignore the event and go back to sleep.
"Waking up" in the context of the article should be taken as "waking up an turning on the radio to check if anything happens that I should be aware of". This involves power-consuming activities, such as turning on and using the radio, and cannot be completely passive. That's why it pays off to not do this too often.
- sbierwagen 9y agoSure, the local node can wake up at any time, but if it has to transmit over the mesh network, then it has to wait for the remote node to wake up. How does the mesh network handle deep sleep, anyway? Do they synchronize clocks so they all wake up at the same time, or does a node just transmit continuously until someone reasons?
- adunk 9y agoThe mesh nodes have to run either in always-on mode (which makes perfect sense if they are powered by, say, a wall socket, which they often are) or in a sampled listening mode. Sampled listening shaves some 98% off from the radio duty cycle compared to always-on mode, but still is not enough for the mesh nodes to run on coin cell batteries. Give them a larger pack of batteries and they'll run for months though. To send data to a node in sampled listening mode, the sender sends a string of smaller wake-up packets that indicate when the sender intends to send the real data packet. When the receiver picks up the wake-up packet, it knows when it should wake up again to receive the data packet, so it can safely go back to sleep again for a while. And if the sender knows that the receiver is in always-on mode, because it is powered by a wall-socket, the sender can skip sending those wake-up packets, saving a bit of power. This requires clocks to be synchronized, but only loosely - millisecond synchronization is enough. The trick is to strike the right balance between communication responsiveness and power consumption.
- sbierwagen 9y agoThe BOM indicates that the clock oscillator is just a vanilla quartz crystal. http://www.ti.com/lit/df/swrr135b/swrr135b.pdf http://www.ti.com/lit/df/swrr135b/swrr135b.pdf Does the firmware do any clever temperature compensation using the onboard thermometer, or are you just sending lots of clock skew correction packets as the mesh warms up and cools down diurnally?
- adunk 9y agoFor this level of time synchronization it is enough to send a few extra bytes with synchronization information in each packet. If you'd be down at microsecond-level synchronization, you probably need to do temperature compensation - particularly in outdoor deployments where there can be a 40 C / 100 F difference between two nodes on a sunny winter day.
- trelliscoded 9y agoYeah it's just a regular XO. There's some calibration data they stick in a special flash area at the factory that the radio firmware uses to handle temperature compensation for the chip's internal digital oscillator. I also believe you can run it in a XO-less mode with some caveats.