# Computing stuff tied to the physical world

## Should we send, or not?

We have three ways to try avoiding getting into trouble, i.e. running into “limbo state” where the MPS is powered up, but not well enough to send out packets.

### Vcc estimation

Unfortunately, the LPC81x series does not have a real ADC, only an analog comparator, a 0.9V band-gap reference, and a 31-tap voltage “ladder”. But as it turns out, with the help of some trickery and math this is just enough to estimate the supply voltage with!

The idea is a bit convoluted, but fairly simple: we compare the known 0.9V reference with each of the taps, while the ladder is connected to Vcc. That means each tap will have 1/31’rd of the Vcc voltage, and at some point the level will exceed that 0.9V level.

When Vcc is low, each tap/step will be a small voltage, so the match will occur at a higher tap. Conversely, when Vcc is at the maximum allowed 3.6V, each tap will be 3.6V/31 ≈ 0.12V, and the match will happen at a lower tap. This is available as example on GitHub:

``````1.6V => estimate: 1641 mV
1.7V => estimate: 1743 mV
1.8V => estimate: 1860 mV
1.9V => estimate: 1992 mV
2.0V => estimate: 2146 mV
2.1V => estimate: 2146 mV
2.2V => estimate: 2325 mV
2.3V => estimate: 2325 mV
2.4V => estimate: 2536 mV
2.5V => estimate: 2536 mV
2.6V => estimate: 2790 mV
2.7V => estimate: 2790 mV
2.8V => estimate: 3100 mV
2.9V => estimate: 3100 mV
3.0V => estimate: 3100 mV
3.1V => estimate: 3487 mV
3.2V => estimate: 3487 mV
3.3V => estimate: 3487 mV
3.4V => estimate: 3487 mV
3.5V => estimate: 3985 mV
3.6V => estimate: 3985 mV
``````

At the low end, the estimates are fairly accurate, but at the high end they are very coarse.

With this code, we could enhance the MPS logic to only start sending out wireless packets when the supply voltage is known to be, say, 3.1V or more. But we may not have to…

### Avoiding voltage drop

In fact, we can do better than that by making the supply voltage drop less. There are two simple ways to accomplish this:

1. send smaller packets, i.e. shorter “ON” times for the power-hungry transmitter
2. increase the two reservoir capacitors, to collect more energy for us

Step 1) is easy to do by not encrypting packets. This may seem odd, but the 128-bit AES engine in the RFM69 will round up all payloads to a multiple of 16 bytes (128 bits) after encryption. The receiver then decrypts and returns the payload length as sent.

For our purposes, we’ll use a 6-byte payload: a 4-byte unique code, derived from the LPC8xx’s built-in hardware ID, and 2 bytes as placeholder for additional information.

Step 2) is even easier: by simply using larger capacitors, it will take a little more time for them to charge up, but they will hold their voltage level much better when the transmitter starts eating up the energy (with its 15..25 mA power consumption, however brief).

### Staying out of trouble

Both of the above improvements add value, in that we’ll be able to send only when we think it’s feasible (high enough Vcc) and even with lower Vcc’s since the supply won’t collapse as quickly (larger capacitors) – but we can still get into trouble, depending on AC variations!

So the third trick is really the most important one: re-using the Q1/Q2 circuit to properly shut off the entire MPS when Vres drops below an acceptable level of 1.6..1.8V or so.

As it now stands, the circuit described so far doesn’t shut off nicely due to diode D3, which prevents turn-off. With slightly re-dimensioned resistors and leaving the diode out, we can however get a well-defined turn-off behaviour into the MPS:

The base of the transistor will go higher as Vres rises, up to the point where it starts conducting. Then, the 220 kΩ positive feedback resistor will cause it to “snap on”. But when Vres drops, it will at some point stop, and now the feedback will cause it to snap off:

Where: CH1/yellow = Vres, CH2/blue = Vradio, CH3/purple = Vdd (i.e. the µC supply).

At about 2.5V, the circuit snaps on, but when power is lost (the 500W AC load was turned off), the circuit snaps completely off once Vres drops to ≈ 1.6V. Note that Vres no longer drops, since both the µC and the radio have been disconnected. The remaining energy will come in handy on the next cycle. How about that, eh? We can store some energy for later!

Note how Vradio drops according to its own rules, due to the RFM69’s internal circuitry.

We now have predictable behaviour, and best of all: we have a guaranteed reservoir on startup, because a full drop from 2.5V to 1.6V is now always supported. As long as we can stay above that lower bound, the µC + radio can go to sleep and loop, else Q1/Q2 will shut them off and force a complete power-up cycle as soon as more energy is available.

This modification – plus shorter packets and larger reservoir capacitors – makes the circuit foolproof: whenever it starts up, we’ll be able to send out at least one wireless packet!

[Back to article index]