@NeverDie You have a point. The TPL is also simpler.
But bless the developer. Yes, I was trying to hype his product. I forgot to mention that doing this current test was really easy because this thing just worked... right out of the box (really, out of the anti-static bag.) Rarely have things work so quickly for me. Even the TPL required fumbling.
So if sleeping is the objective and timing isn't really important, then the TPL it is. But if configuration settings, Bluetooth, ADC, I2C, SPI and timing are relevant, then the Trigboard is the way to go.
I'm finding that some of the basic UART example programs in Segger Embedded System's IDE no longer even compile for the nRF52-DK without encountering obscure errors that, judging from some youtube videos, didn't exist a year ago. Did Segger fail to maintain their example code during covid? I couldn't get to the bottom of it, so I'm punting on SES and will be switching to gcc, which I hope won't have the same issues. Fingers crossed.
Looks as though I'll be sticking with SES a bit longer, because it does contain at least one example shell for the nRF52805, and as long as I can hollow out and fill that shell with bare metal code, then (so far) it all seems to compile and upload and the code works on the nRF52805. At the moment I've confirmed that the bare metal UART code I put together from just the datasheet alone (which has far more ambiguity in it than I remember it having) is now properly working inside the nRF52805, which was (is?) probably the hardest thing to get going, but now that it's in place (for debugging purposes) I feel more comfortable moving ahead like this. One thing I do like about SES is that compared to GCC the compile and upload cycle happens very, very quickly. That alone may not by itself be a deciding factor in what to toolchain to choose, but it is a nice luxury that I truly enjoy.
Next up: getting some bare metal proprietary radio code to work on the nRF52805. Ignoring the PCB antenna, the rest of the module looks as though it is smaller than the size of a dime! I don't yet fully grasp the details of how Nordic crippled it, so I hope I won't be tripping across any nasty gotcha's. Apparently one of the benefits of the crippling it is that it is more power efficient (as, for instance, it has less memory to retain while sleeping). Compared to its siblings, it has "only" 24KB of RAM and 192K of flash, but that is nonetheless hugely more than what the atmega328p has, so from that perspective it should have more than enough for doing most Arduino-type things. It's biggest cramping limitation seems to be its very small number of GPIO pins (technically 10 pins, but really more like 9 pins since one of the ten pins serves as a RESET pin).
@hlehoux said in long-term usage of nRF24L01+ with PA: no reliable transmission:
Maybe try E01-ML01DP5 Long Range SPI nRF24L01P 2.4Ghz 100mW SMA Antenna IoT Wireless Transceiver
Or, based on your description, use a load switch, like a MOS tube, to completely turn-off power to your transceiver when not in use, and then turn it back on just prior to use. It shouldn't be necessary, but sounds as though it would work for your hardware if nobody has any further answers for you. Good luck!
Some updates in almost one year.
I moved all the gateways and controller part in a most suitable location
I've created a dual current sensor for the fuse box and the inverter. Each Current sensors can withstand 90A max, so I used both channels in parallel. The sensors are defined for both Channel 1, 2 and Sum(Ch1+Ch2) to handle this case easily
Recently I made an updated version of my Photovoltaic monitor since the 20A that the old one could withstand are not enough now, so the new version is capable of 50A max. Still waiting the Hall sensors though...
Finally, I cleaned up a bit the deployment under the bench
but I am not done yet