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/
1 Like
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
http://batteryuniversity.com/learn/article/elevating_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.
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 Stream to 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 HardwareSerial).
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”
https://raw.githubusercontent.com/samuel-puschacher/TTP_Arduino_Boards/master/package_thethingsproducts_index.json
So @Charles can use the Constant in the Librarys for the HardwareSerial and @johan is happy with the stream
4 Likes
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
1 Like
The luminosity data from my node, since the code change, looks quite strange:
- If there is no direct sunlight the value is: 0
- if there is direct sunlight, the value can go up to: 1000
- in the night, when it should be 0, it is about: 8
I tested it with two nodes, same behaviour. Has anybody else noticed this?
@Charles could that have to to with the sleep mode, or gain setting?
plot of luminosity data from two days.
Do you light the led when reading luminosity ?