…starts now!
Why did I not report back for so long?
Because I’ve worked a lot! But what had to be done?
We have still found one or the other small problem with the hardware and I have started with the final firmware for the blueReader. There was also one or the other problem with the software and many small surprises:
Most of the headaches had always been the energy consumption, so we measured, tweaked and tried out to find out where the whole energy went, although we still use one of the most energy-efficient chips available on the market (The nRF52 is of course much better, but was not yet available at the start of the project).
The answer was not so easy, we first decomposed the hardware step by step (or equipped boards only partially) to determine the real consumption of individual components.
This brought only a small improvement: A redundant diode could be deleted from the placement plan and brought us minimal more energy when loading the blueReader, but nothing that is of real significance.
So I have continued with the software. Where can energy be wasted? A few minor things are noticeable, as on page 41 of the reference documentation of the NFC chip, a footnote to a table describing a function that simply is missing in the documentation of the protocol and helps saving a lot of energy. These and many other minor changes brought me to a stable runtime of two days with one load.
That was still not in the range of what I wanted or regarded as something acceptable. After this, an odyssey lasting over a week started with me versus the internals of the BLE chip …
After a short time, it was clear that a mistake in the management of the connection between BLE and NFC chip caused a far too much energy need for nothing, and even more because it was sometimes the reason because of which the NFC chip was not sleeping. Result: over 3 days running time are possible. However, during those tests there were always errors in the timers, which are code blocks which are executed after a certain time or at certain intervals. This took me eventually to the finish line …
After devouring incredible amounts of documentation on the subject of the timer, I was able to re-structure the code and went expectantly into the initial measurements:
For all those who only see a colorful picture: This is a measuring device, actually a quite expensive one, but this one is self built by us 🙂 For all others: A measurement with a 10Ohm shunt, resolution 20ms / 0.1V, large plateau is read out of the Libre-Sensor, small plateau transfer of the data to the mobile phone, tail is standby with active BLE connection …
The energy requirement is now negligible! Negligible? Yes! The system should now run over 25 days with just one load: D But I will not wait until it is empty before I deliver the first devices … But I will write a post of course as soon as I have the first reliable data!
If the calculation should coincide with the reality, it is enough to charge the blueReader during the warmup time of a new sensor to get enough energy for the next 14 days, but as I said, first wait for data!
Oh so, the data also refer to some changed parameters.. so far, all solutions have read the sensor at top every 5 minutes, but the sensor itself stores a new value every minute! So I have reduced the interval to one minute for these tests and calculations 🙂
What’s up next?
- A few small changes are still necessary in the firmware to be able to deliver the first devices.
- These changes I intend to have completed by Monday.
- Here are now waiting almost 20 devices to get their release firmware (all transparent, with and without magnets) which are then to be sent directly to you all 🙂
So let’s see if this weekend brings even more joyful surprises!
Like this:
Like Loading...
same color as the wireless charger.
