Here you go:
Could you share you’re sourcecode ? Look great !
If you had a printer…
tnx I ordered one to test … like that it’s very compact
Cool but suboptimal. Did some tests with different DIY Radiation shields. And now i use Davis 7714. Expensive but serious. Another compilation for this theme: https://www.allmeteo.com/radiation-shield-comparisons/
For batteries life should also considered the self-discharge which is different based on chemistry of the battery (and construction), state of charge, temperature, …
Here can be found an article with some data about self discharge
Role of temperature and state of charge for a Li.ion battery
So same place, same device installed in winter or in summer, will have different lifespan.
The tables inclusion of ‘Nickel-based’ is presumably based on old style NiCd and NiMh batteries.
I have been using the low self discharge NiMh for many years now, they have roughly the same self discharge as Lithuium cells.
Yes, Ni-MH “eneloop” batteries are not like “standard” Ni-MH, Sanyo (than sold to Panasonic) introduced many innovations decreasing self discharge, increasing performances over temperature range and increasing charge/discharge cycles.
One should look at batteries datasheets to have a better idea on what performances one could expect.
I am not an expert, just searched a little bit some years ago to llok for good batteries for low power applications (rechargeable and not rechargeable ones) to be used in outdoor applications and that didn’t cost too much.
Good non rechargeable batteries, with a not too high cost, are Saft LS / LSH lithium-thionyl chloride batteries, for example LS 14500, LS 14250 and LS 17500.
Couldn’t agree more. We use Energizer Ultimate Lithiums in the ZigBee loggers that we ship and they just run and run.
And if you ever need to carry batteries as spares, these Enegizers are light and have a claimed shelf life of 20+ years.
Do you know if anyone has already changed the sketch, so that if there is a join error the unit goes to sleep then try again a bit later ?
I have got one unit which has got this error and it stayed stuck on the ON state with the blue LED for 3 days, which caused a 1V voltage drop. I had to reboot the unit to get it back online so I can’t really deploy the TTnode in the field as is.
don’t know… that’s a question for @Charles
Does anyone know, when the latest pull request from @Charles will be approved?
I think it won’t happen, just look at the PR comments.
We’re facing on a “technical no way”, let me explain, for low power I needed to do changes on arduino-device-lib. Talking to RN2xx3 LoRa module with TheThingsNode or TheThingsUno is done with a hardware serial (UART) but the way it was coded if for a generic stream (not serial) without
begin() methods needed.
My LowPower fix need to call this and I changed
HardwareSerial for that. But it looks like arduino-device-lib can also be used with software serial (altsoftserial library) which has a different type (not
But at compile time library is unable to know what user will use (hardware serial or software) so the only solution I got is to define a constant to let the library which code to compile. I admit it’s not my favorite but I don’t have another solution, and looks like TTN team neither.
This solution (using stream instead of hardwareserial) makes sense to have majority devices compatible (which are not TTN one) without changing a line of code in the library. But on the other hand it impact the LowPower mode for TTN devices (which I repeat all use Hardware Serial).
So from my point of view TTN lib should match TTN devices and make them working as expected (ie no impact on battery life), and I think it’s what TTN backers and devices buyers want (let’s say an assumption of 90% of users?)
The other vision (not mine) is to make (again let’s say 10% and I’m sure I’m quite large?) others users happy and be able to use soft serial on other devices (not TTN one) without changing any line of code in the library, we impact severely battery life of 90% remaining users that bought TTN device and expecting as announced a battery life for one year.
As a reminder TheThingsNode battery life was between 2/3 weeks with a send every 5 minutes and now with fix it’s just ten time longer.
So if any code guru has a better solution let me know of course.
What about creating Boards for The Arduino Board Manager
And with precompiler check if it’s compiled for a TTN device
If it’s a TTN device use HardwareSerial otherwise use Stream … with precompiler
What do you think about that idea?
Absolutely, that’s what I suggested earlier (instead of selecting Sparkfun Board) in the PR, I’ve done by the past for custom boards and it’s not so complicated, just time consuming that I do not have
I could fork the sparkfun Board and change the name?
Not enough, you need to have a repo, then a link to this repo to be able download boards definitions, that are compressed files with some MD5 calculation of the archive and some json description file.
Then TTN need to change documentation to this new procedure (add new boards and select them) and after that merge the modified PR
We created now a device Library, which defines the constants “THINGS_NODE” and “THINGS_UNO”
So @Charles can use the Constant in the Librarys for the HardwareSerial and @johan is happy with the stream
The Board Manager URL has changed by wishes from @johan
The new link is: https://raw.githubusercontent.com/samuel-puschacher/arduino-boards/master/package_thethingsproducts_index.json