In order to properly test it, I should probably start with all new batteries. I did capacity testing on some of the older batteries and then retested their capacity again to see if the numbers matched. They didn't. So, given the small sample size, I'd be weary that there might be too much noise in the sample to draw conclusions if I start with batteries that are already impaired.
What became clear though is that batteries which just sit in a drawer can degrade quite a lot, and that it's not from overuse or re-charging. That's just what happens to NiMH batteries as they age. I guess it shouldn't be surprising, because that's what we expect from alkaline batteries also. But maybe some of the impairment was due to allowing their charge to fall while being stored? That seems to hold true for SLA batteries. Not sure about NiMH batteries.
So, unfortunately, I just don't have the data to say what the effects of trickle charging might be. If it turned out to actually extend the useful life of rechargeable batteries, then that would be an interesting outcome. Maybe someone reading this will feel inspired to conduct such a test and post the results.
@alphaHotel said in Version 3.0 atmega328p test platform:
@NeverDie Awesome. thanks.
I uploaded the files for version 3.0, including the KiCad 6.0 project archive as a .zip file contained within the .rar file. As it has already served its purpose for me, I didn't meddle with the spacing on the batteries, but I did go out of my way to avoid possible short-circuits between the battery holder and traces on the PCB.
Well, I was able to artificially raise the CTS line, which is active low, and halt the transmissions, so I don't think the problem is with the UARTE on the nRF52x. Rather, I think the problem may be with how virtual com ports are handled on PC's, and maybe they aren't configured to properly use RTS and CTS for flow control. At any rate, I was able to crank the UARTE transmission speed all the way up to 941176 baud, and at that speed it takes only a very small artificial delay (around 300usec) after each transmitted string to avoid problems, so I'm just going to do that and move on rather than chase down how to get perfect RTS/CTS working on a PC's virtual com port. So, for that reason, this PCB project will still have value when its finished by keeping the "wiring" all within a single PCB rather than strewn about externally with a rat's nest of actual wires.