The reset pin "floats" here, and a 1.79V is quite typical when connected to the Pi. Internally, in the MCU, the reset line is connected to 3.3V with a weak pullup but that doesn't show on the reset line itself since it's configured as input. If the PiMaster was resetting, you'd see the three LEDs blinking alternatively. I don't think this is an indication of an issue.
Are you experiencing this issue on the BalenaFin or a raspberry Pi or both?
Could you still post some logs covering the couple first minutes?
The hardware can certainly read CAN data up to 1 Mbps. We selected 125 kbps in order to cover longs distances. To read "classic" CAN data, you'd need to change the firmware (and also supporting software).
On scenario would be to reprogram a PiMaster into a generic CANbus device and then have a user-space utility like
nocand to then forward the data to MQTT, blynk, etc. All this is feasible, but it would take quite some work.
Well for now, I'm puzzled by this issue. I will try to get my hands on a BalenaFin to investigate things more precisely (Balena has offices in the same building where I sometimes work).
I've compiled a new version of nocand that tries to get around the issue by re-trying to connect 3 times with a pause between each try. It's the same link as before:
Let me know if at least that works.
Can you tell me if this version works then (without the
There should be a 3 second gap between the two blocks: the first block is a reset, and the LEDs on the PiMaster blink for 3 seconds. Then nocand waits for a specific signal to trigger the second block. My feeling is that nocand incorrectly sees the trigger signal immediately on the balenaFin.
Could you try to run
nocand with the following option:
nocand server --driver-reset=false
Let me know if this fixes the issue. If this is the case, I will later ask you to try a modified version of nocand that would make a more permanent fix.