and the software, you use different ports or the same port and change the value ?
seems to be a hot use case in hotels/bars/restaurants ect … with a small investment (no wiring ect) the manager can see on his phone how angry or satisfied the clients are
I have not decided yet. I do consider collection of data by the device over time both agregated and over periods. I could use ports to discriminate between information type.
So the question is: how much intelligenct with respect to teh application shall be inside the node?
new 2 x 5 W little speakers arrived - hoping to improve RPI assistant sound compared to the 2 x 3 W I use now.
I’m experimenting also with these little cheap Chinese amplifiers:
I’ve planned to build the Google Senior assistant system in 2 big, but low enclosures, one housing the RPI 3A / amplifier/ battery /wireless charger receiver / speakers and in the other one (the craddle) the wireless charger transmitter.
Its an Christmas present I’m working on for my old mother, she can’t use a keyboard/computer because she has shaky hands.
That’s why I set it up so that she don’t have to connect the assistant to charge but just put it on the wireless charger, it clicks in the right position because of a magnet.
There is a led indicator when fully charged.
Also its a mobile device , she can take it to another room / bed and in the future she can control things with voice commands. (recognizing the word ‘help’ and then calling someone when she falls for example)
Only problem sofar… still no Dutch language available
How to drastically improve battery life of an EEVBlog uCurrent Gold
Most of the uCurrent’s battery power is consumed by its LED (‘BATT OK’). So battery life is mainly determined by the LED’s current (not well-designed for a device focused on low-current and itself powered by a tiny battery).
The LED is on when the device is powered on and battery voltage is 2.65V or higher. The warm-yellow LED has a 270 Ohm series resistor and draws around 3 mA current.
Replacing the LED with a bright version and a much higher valued series resistor will drastically decrease current consumption and therefore improve the battery life.
After replacing the LED on my uCurrent Gold (rev5) with a bright green one and replacing the 270 Ohm series resistor with 20k Ohm, the LED draws only 42 uA current (@3.0V) which is only 1.4% of (71 times smaller than) the original 3 mA!
According to the uCurrent Gold’s specifications battery life should be at least 50 hours when using a standard CR2032 cell (220 mAh) with 2.65V cutoff voltage.
Below discharge curve shows that the maximum capacity that can be consumed with 3 mA discharge current and 2.65V cutoff voltage is around 80 mAh.
To light the LED with 3 mA for 50 hours requires 150 mAh capacity which is much more than the 80 mAh that the curve shows. Even if the values in the curve are taken with a grain of salt, the specified 50 hours battery life is probably still too optimistic. And that is only based on the LED current, not taking into account the current consumption of the uCurrent itself, which - based on the uCurrent Gold’s specifications - will probably be very small when compared to the current consumed by the LED.
Therefore minimizing the LED’s current will have a major positive effect on the battery live time.
Notes: It is difficult to find CR2032 discharge curves for currents in the mA range, many available CR2032 discharge curves only cover discharge currents of 100 nA and lower. Many manufacturers base their specified CR2032 capacity on a 2V cutoff voltage, so with the uCurrent’s 2.65V cutoff voltage an important part of the specified capacity will not be used. Also the constant discharge (LED) current is relatively high for a CR2032 battery which further reduces the battery’s usable capacity.
. .
On the left: original yellow LED with 270 Ohm resistor and on the right: LED replaced with bright green LED with 20k Ohm resistor (smaller LED because I had no larger).
Been off trialing & negotiating potential new GW sites for BE&C & Warrington communities ready to take some of the new GW’s as well as contributing elsewhere. As well as prepping for an LPWAN/Sigfox/LoRa/LoRaWAN update pitch to a UK industry conf later in the month…
Workbench not idle though!
Took delivery of a handful of these:-
To wireless enable the RAK pilots and some new builds…forgetting of course that as Pilots are Pi3 based WiFi built in so no dongle needed! Still wont go to waste as have Pi 2 builds like this:-
So let me introduce you to Cedric:-
And his cousin Ozzie!:-
Who looks like one fierce Owl by Night!
He is RPi0W based using an early build of one of @charles bds
… unfortunately that thing still use 8mA in deep sleep
There is an ‘always-on’ LED, maybe I can win a bit there…
Edit…
De-soldering the LED brings me to 7mA, not a big win.
Powering the board directly with 3.3v gives a bigger win, I am now at 1.2mA.
I am not keen to remove the LDO, as I won’t be able upload software anymore
Remains the LiPo battery charger, but I am not sure it comes into play here.
I tested one with the U8g2 library with the full framebuffer graphics test example (using the ST7565_64128N() constructor, not UCX1701X() which didn’t work).
IIRC I measured around 260 uA while active and 14 nA in powersave mode (not using the 16 mA backlight). In powersave mode the display content is not visible.
The idea is to have a battery powered device to display some data.
MQTT wouldn’t work as it would be too power hungry.
I store all my TTN data in an InfluxDB database, and I expose a simple REST API to retrieve data.
So the ESP32 wakes up now and then (let’s say every hour), collect data, print them on ePaper and go back to sleep. If fresh data is needed, a button can trigger immediate collection.
ePaper is nice for this application as it doesn’t need power to maintain display