The WORKBENCH part 1

testnode running 1 week … AA battery dropped from 1.56 to 1.52 with an update every 5 minutes



this node should work with a battery voltage down to 1 v

1 Like

You are using Alkaline batteries I assume? 0.04V drop in a week at updates every 5 minutes isn’t that bad for a fresh battery because that tends to drops fast at the beginning, but it isn’t very good either.


At what SF is the node sending? are you using ADR with OTAA?.
As you are running it near your gateway SF7 should suffice, if it is running at SF12 then energy consumption for the sending part will be roughly 32 times higher (if I did the math correctly). Ah think the SF is SF7 looking at a previous post in The WORKBENCH part 1 - #55 by BoRRoZ. Did you measure the standby consumption already?

But I’m not telling you anything new I guess :blush:
Maybe this thingy deserves its own review/discussion topic?

Yes its running on a fresh AA duracell battery

OTAA and I haven’t seen any ADR activity (I can reach 2 or 3 GW on SF7)
basically Its a 328P+ BME280 with a RN2483, and this one is responsible for waking up the 328p.

sleep = 50 uA and Tx = 20 mA @ SF7BW125 and test payload = CayenneLPP 28 bytes

planning is / was to let it run until it dies… but we have had a little problem, started this afternoon with Cayenne updates, luckely Cayenne (and TTN) support is very active and looking into it @ this moment.
problem fixed :slight_smile:



hardware done… now some code, first the dual colour led blinking sequences

  • connecting
  • can’t find network
  • connected / standby
  • power on
  • heartbeat


no smoke ? :sunglasses:

1 Like




detecting AC current is very easy, as an ‘AC testload’ I use a PC powersupply :sunglasses:

so now how do I make a bi colour led blinking a pattern without disturbing lmic…

You run your LED code in a separate function on the other ESP32 processor core as explained by Andreas Spiess - Video link posted on the BIG ESP32 thread

tnx… one little problem, I use a 32U4 :wink:

I have allready looked here … blink without delay
guess I’ll have to try that with lmic running

Eh, my bad. sorry! I thought I had seen an ESP32 inside the enclosure on this thread. In any case I am curious to see how you get on as I have 4 of these due any day from eBay.

’ you want this smartphone, I can’t buy a battery for it any more ’


sure… now I have a dedicated TTN mapper :stuck_out_tongue_winking_eye:


going into week 3 with a single AA battery

* inside is the old hw version of the RN2483 (with firmware 1.03) so curious to see what happends when it starts freezing… we’re close to that point at night.

So as I am not a programmer I may be offering an other humble apology here but a question;
Can you #include <Ticker.h> and call a function to decide which LED on your led flash interval and then
bool ledState = !ledState;
digitalWrite(green, ledState);

What for the beginner like myself will be a problem with LMiC? Is it very sensitive to being blocked?

Thx, G

tnx for the idea :sunglasses:

its just me who wants a fancy not neccessary blinking multicolour led interface …
if I just use red / green high/low there is no problem :rofl:

* and then only start blinking red when it’s impossible to join the network


problems… sometimes the attached AC load (coffee machine) generates an mcu reset
should I filter the AC before the AC-DC converter or does a node only work reliable on a battery ?
should I ‘shield’ sensitve parts … question questions :slight_smile:

  • I first must implement a softserial debug port, because now everytime this happends the connection between pc and module is broken because of the 32U4 ‘uart’

could be caffeine overload? :wink:

1 Like

Maybe disabling brown-out detection (or lowering the bod fuse levels) might help?
Or is it already disabed? This has its risks of course.

brownout levels are not involved here … the MCU gets constant power, there is some ‘dirt’ on the AC line when switching the load on/off and that breaks the uart connection with the pc and don’t come back.

From the photo, it looks like you have a LiPo socket, so I would definitely try it out. I would always try to have either a few hundred microFarads or a LiPo to handle peak current draw caused by WiFi or GSM and it might work well in this case…

Hey borroz. Dit you implement the varistor for peak current handling in your design? The exampe in the link with the fuses has one in the design. Could well be that the coffee maker gives a peak on the ac line.



1 Like

first major hardware update … :sunglasses:


the humidity from the bme280 sensor seems stuck @100%

1 Like

I had a similar problem with bme280 where the reported pressure did permanently stick at about 30% less than the actual value. It somehow got defective.