@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
Thanks for the answers. For sure it is possible to buy an ATmega and even a full-featured debugger would be acceptable compared to the effort of porting. But still, I am very biased towards the PIC without logical or economical arguments.
I did not yet work with the mysensors libraries and only browsed quickly through the github repo. Maybe someone can give me a few hints to estimate the effort deeper than just claiming it as "much workload"?
What I see so far is:
make the C++ code compile (translate to C with clang/llvm and compile with the XC8 compiler)
create a new HAL (in hal/architecture) which seems not too much effort for making it initially working
Questions:
Do I see it right, that there is a linux-port available? -> I would expect much more effort to port from AVR to linux than to port it to a different MCU
What about the licensing? It looks like the code is GPLv2, but in the CLA it seem that contributors need to give away their rights on the contributions and that mysensors can even redistribute the code under another license - which seems completely against the principles of the GPL. Can someone explain that in more detail?
@NeverDie said:
Can it be programmed through the Arduino IDE?
I had briefly looked into it back in 2011 and was able to get an Arduino sketch for blinking a LED to work. I had to upload it using the external dfu program since at the time the Arduino IDE did not allow specifying an external programmer device. I'm not familiar with what may currently be possible with the Arduino IDE since that time however.
Plain C using gcc and uploading using dfu-programmer works fine though.
Does anybody have a link to a fixed version of this board? It's exactly what I am looking for form-wise, but I'd be nice if VCC was wired to 3.3v out of the box. Thanks!!
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.
Hi @GertSanders,
Do you happen to still have the Eagle project files from version 3 you created and shared on OSH Park? I'd like to add a set of pads for the mini smd version of the NRF24L01. If not, I'll just use the version 2 files from openhardware.io and try my best to recreate the changes you made between them.
Kind regards,
AH
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.
