The WORKBENCH part 1

next version maybe… this is a battery endurance test

:grin:

Something like this would be nice (but in small form factor like on small weather stations).
Maybe a nice project for a 3D printing enthusiast.

lex_ph2lb also found a nice solution

but you can 3D print it yourself

but in my experience with 3d printed display bezels … it will look very bad after a year

bezelyellow

this bezel was made by ITEAD, I bought it together with a small nextion display.
and look what happend to the material … it was bright white when it arrived here.

2 Likes

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

fields

firstweek

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.

image

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:

RSdesign

2 Likes

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

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

x522

x523
no smoke ? :sunglasses:

1 Like

helloACworld

offonoffx526

x525

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 ’

x527

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

2weeks

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

x532

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…