I want to get started with The Things Network and this board seems like the best budget option however, I’m not sure whether I should go for the CubeCell Dev-Board or CubeCell Dev-Board Plus, the Plus seems to feature the higher powered SX1262 chip so should offer better range?
What version is easiest to get set up and connected to the network?
HTCC-AB02 in addition has a display and more IO ports than HTCC-AB01 and is therefore more versatile.
Read the topic start. All current CubeCell boards have an embedded SX1262.
Should not make any difference.
Oh cool, I don’t know where I got the idea that the HTCC-AB01 was using the SX1261 it might have been an old aliexpress listing.
What is the recommended capacity for solar panel and battery to pair with the HTCC-AB01 and BME680?
I understand the battery should be a 3.7V SH1.25-2 LiPo and the solar panel must be 5.5V-7V, but I’m not sure about the exact capacity and wattage.
Probably need some more info.
How often are you taking a measurment and are you going to sleep between readings/sending data?
I don’t directly have answer for capacity but ‘SH’ connector is incorrect. See this post for more info:
Also take care to put a diode between the solar panel and the board:
I really don’t know maybe every 5 minutes and I would like a 1 day battery buffer?
What diode do I need or how do I calculate what diode I need?
Cheers
No, not at all. Towards/during winter/darker months the solar panel will ‘hardly’ generate energy at all (compared to its max capacity). A one day buffer is therefore insufficient and very subjective.
Without using any sensors I was able to send some 75000+ uplink messages (with 3 bytes payload) over a period of months from one single charge of a 1200 mAh Lipo battery with a HTCC-AB01 board (without solar panel). So that is quite some days of operation / quite some buffer.
You will have to check the datasheet for your sensor for its power consumption characteristics and incorporate how you will use it to calculate your power requirements.
And then select a battery capacity and a correspondingly dimensioned solar panel capacity that fit those requirements.
You can use any popular Schottky diode that can handle the maximum current of the solar panel (actually the max input current that the board uses for battery charging).
Solar + battery is not just simple to dimension. Proper dimensioning will have to be properly calculated taking multiple aspects into account, including the expected number of sun hours (which is something different than the numbers of day/sunlight).
It all depends on your requirements.
Ok so if I get a 1200 mAh 3.7V battery that would be 4.44 Wh and I would want to recharge that at least every 3 days so if I get a 1W solar panel and I say on average it generates 3W/day that should be sufficient?
Would I pair a 1W 5V panel with a SS14 diode as that seems to be the smallest Shottky diode available?
No things are not that simple and solar is not linear.
What about hardly getting much sunlight in a period of e.g. 2 weeks. Your battery will hardly be charged during that period.
Also be aware that you should not calculate with power in Watts here but calculate with current instead. For example, the voltage of the panel will be higher than the voltage of the battery, but it is the charge current that is essential here. You will lose an essential part of max panel capacity due to conversion losses (and there is almost sure/definitely no MPPT optimization built into the CubeCell board).
I suggest to learn a bit more about solar energy to get a better understanding of what to expect from solar panel energy and what not.
What is the maximum current of that solar panel?
(P (in Watt) = U (in Volt) x I (in Ampere)
What is the maximum (‘forward’) current of that diode?
(Lookup its datasheet)
Is max current of that diode larger than max current of that solar panel?
YES, so SS14 but also SS13 and SS12 will do (as many others).
Aside, IIRC it’s usually best to overdimension a Schottky diode as little as possible to minimize reverse leakage current. So a ‘smaller’ version (e.g. SS12) would even be better here.
You will have to do your own homework and not try to let others do your homework.
Yeah, I’m going to have to read up.
I have calculated that my daily power draw will be ~0.5Wh and with a 1200mAh battery that should last ~week. I have found that with a 750mA solar panel on my worst day I should generate enough power to fully charge the battery. I believe this should provide sufficient power security.
So if I understand correctly I need a ~750mA diode however the smallest I can find are 1A so if I use one of those should that be fine?
Only thing I’m still confused about is the reverse voltage of a diode to I need to get one which matches my solar panel or battery?
You will have to take care of Forward Current and Reverse Voltage in the specification.
Forward voltage will be small (ideally we would want 0V) but reverse voltage is the voltage that should be safely blocked so this should at least be the ‘open output voltage’ of the solar panel (which is bit higher than is its nominal output voltage).
For a 5V-7V panel something like a SS12 or similar with reverse voltage of 20V should therefore be sufficient.
Unless an engineering miracle occurs, you’re likely to get an OKish result but unlikely to get the results you were expecting.
This is why we have to try things out. Getting in to too much detail until you have some experience (like about 4 or 5 deployments) is somewhat academic.
Ideally, you get an INA3221 so you can log voltage & current from the solar panel, the voltage & current (in & out) for the battery, and the voltage & current to the device. Bear in mind that the device will peak for short intervals so you need to capture that info more frequently.
This will give you lots of data to do some modelling and provide a setup that allows you to swap different components around.
Free tip for today: Point the solar panel with a tilt towards the east, so it gets more direct sunlight in the morning when the battery will have had some use overnight. If you get the right combination, you can have the battery full by early afternoon on a sunny day so it’s ready for the night.
For those who find this interesting, below an overview of the battery status during 3 days of a Cubecell setup with the standard LoRa sketch from the manufacturer. Measurements are taken every 15 minutes, via TTN to an InfluxDB and Grafana. I use a cheap LiPo battery (labeled 1400 mAh) and a cheap 90x60mm solar panel. As you can see the battery, with an average cloudy sky in the Netherlands, remains full and on voltage.
Thanks for sharing. At first glance this may give the impression that the configuration will run solely on the solar panel the whole year but reality is a bit more complex:
The above measurements of (only) battery voltage over a limited number of 3 consecutive days (from a total of 365) are not representative for the amount of energy (battery charge) that was produced by the solar panel. Neither is ‘an average cloudy sky’ representative for the amount of received solar energy.
I previously posted here about having sent 72000+ uplinks with a HTCC-AB01 board on a single 1200 mAh Lipo battery charge (without solar panel). After 72000 uplinks the battery voltage was still 3.69V.
Let’s assume that I started with a full battery voltage of 4.2V and that the battery voltage (on average) decreased linearly with every uplink message. That means a decrease in battery voltage of (4.2 - 3.69) / 72000 = 0,00000708333 V per uplink message.
You sent about 4 * 24 * 3 = 288 uplink messages in those 3 days. With an oversimplification of reality, compared to above calculations from my test, that would cause a decrease in battery voltage of about 0.00256 V over those three days (for sending 3-byte uplink messages without sensor measurements). Your battery capacity is even larger so voltage should even decrease less. You are measuring/reporting with two decimals accuracy and therefore won’t notice such small decrease.
I only did send uplink messages during my test without performing any sensor measurements so your configuration will probably draw a bit more current while not asleep.
This probably explains why you see the variations in battery voltage (over a 0.02 V range) during those 3 days. The decreases caused by consumption of the board and sensor and the increases caused by charging from the solar panel.
Not really. Your graph shows an average 0.01V decrease in battery voltage over the 3 days in September which indicates that the battery did not get fully recharged by the solar panel. When extrapolated the decrease is 1.22V for a full year. September is not one of the least solar productive months. Expect much less charging during the autumn and winter months. Consumption will not change so the battery will drain more during those months (and battery voltage will drop accordingly).
Example of distribution of monthly in-plane radiation for fixed angle for some Dutch city.
If you want to use battery voltage as indictor to see if the battery and solar panel are sufficiently dimensioned, this will require measuring battery voltage over a much longer period that should include some of the least solar productive months.
Hi Bleujedi,
Please don’t blame me for posting this message here. I meant to be nice but I’ll never do it again. How could I be so stupid so please accept my humble apologies.
Humble greetings, Hans.
Hi @TIS,
There is no blaming and no pun intended.
Nice and welcome that you share your experience and measurements!
Your conclusion “battery remains full on voltage” is incorrect however.
0.01V decrease in 3 days may seem unimportant (or go unnoticed) but in the context of battery powered LoRaWAN devices it surely is relevant.
My response was to temper unrealistic expectations from battery and solar panel combinations (and explain a bit why), while you probably only wanted to share your results.
There are people with different levels of experience here on the forum so it happens that people with more experience on a subject step in to help by providing additional information, but can sometimes also be critical about less correct/incorrect statements because these may result in unrealistic expectations for other users. No pun intended.
BR