mgiannikouris
commented
9 years ago Thanks for logging this ticket. I haven't seen any power cycles during my testing yet, but after thinking about it for a few minutes I have a theory.
CAN transmits are on the main loop (not interrupt driven like CAN receive). The Telit state machine is cooperative during initialization, but the HTTP transactions themselves do not yield until they complete. Since you're running OBD firmware, the only "loggable" traffic are the OBD responses on 0x7E8 - 0x7EF. If the HTTP transaction takes longer than the CAN sleep time for whatever reason (say, bad or dropped network connection), then the device would not see any CAN traffic and would sleep. The device would then immediately wake up again because the CAN bus is still active.
Same behaviour OpenXC displays when installed on an active CAN bus that doesn't contain any of the filtered messages compiled into the firmware.
I think the CAN timeout time is something like 5 seconds, and it's very possible that we're going to have network hangs like that from time to time. So it seems reasonable that we need to address.
Probably the best way is to make HTTP transactions cooperative. That way all processes that need to be called in a timely manner will be satisfied.
emarsman
On initial testing, the modem was able to connect. However, after a couple minutes it appeared to power cycle. The LED was flashing blue and red and then back to solid green while waiting to go blue for the modem connection. It did this about 5 times on a 40 minute drive. Zac also reported a couple power cycles on his first try. I was not able to capture any logs yet using python though.