The OBD2ECU task assumes that "all" HUDs and such devices operate at
500k. Are you aware of any that don't (can't) operate at that
speed? I was hoping I wouldn't have to support multiple speeds,
especially autosensing them.
BTW, I have not seen any problems connecting an OBDII Dongle to the
OVMS and letting it do its default scan through the various rates in
order to connect. It just takes longer than it would if (as I
usually do) tell it what rate and frame size to use. The various
frames and speeds tried before figuring out the right one don't seem
to bother it.
I am also now seeing this.
Trying out the OBD2ECU HUD cables, I was having
problems getting it to work. Those HUDs try to transmit at
different baud rates, to probe for what is correct, and that is
causing errors at our end. Once we get those errors, seemingly
we can’t recover. A ‘can can3 start active 500000’ fixes the
issue and the HUD connects.
It looks something like this:
OVMS# can can3 status
CAN: can3
Mode: Active
Speed: 500000
Interrupts:
1
Rx pkt:
0
Rx err:
105
Rx ovrflw:
0
Tx pkt:
0
Tx delays:
0
Tx err:
0
Tx ovrflw:
0
Err flags: 0x8000
Or this:
OVMS# can can3 status
CAN: can3
Mode: Active
Speed: 250000
Interrupts:
146
Rx pkt:
0
Rx err:
128
Rx ovrflw:
0
Tx pkt:
0
Tx delays:
0
Tx err:
0
Tx ovrflw:
0
Err flags: 0x800b
E (713021) canlog:
Error can3 intr=1 rxpkt=0 txpkt=0 errflags=0x8000
rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0
E (713021) canlog:
Error can3 intr=2 rxpkt=0 txpkt=0 errflags=0x8000
rxerr=2 txerr=0 rxovr=0 txovr=0 txdelay=0
E (713021) canlog:
Error can3 intr=3 rxpkt=0 txpkt=0 errflags=0x8000
rxerr=4 txerr=0 rxovr=0 txovr=0 txdelay=0
...
OVMS# can can3 status
CAN: can3
Mode: Active
Speed: 250000
Interrupts: 3757
Rx pkt: 1
Rx err: 128
Rx ovrflw: 0
Tx pkt: 1
Tx delays: 0
Tx err: 0
Tx ovrflw: 0
Err flags: 0x800b
...
OVMS# can can3 status
CAN: can3
Mode: Active
Speed: 250000
Interrupts: 3775
Rx pkt: 10
Rx err: 128
Rx ovrflw: 0
Tx pkt: 10
Tx delays: 0
Tx err: 0
Tx ovrflw: 0
Err flags: 0x800b
And then the can bus dead (until ‘can start …’ to
reset it).
Good news is that with those HUDs, it is very easy
to recreate the fault condition. I’ll see what I can do to find
out what is going on. My guess is we are not clearing the
MCP2515 error condition correctly. I will try to find out what
is going on...
Regards, Mark.
On 14/05/18 20:36, Stein Arne Sordal wrote:
I also tried to raise
the stack size to 6144.
It seems like it got worse…Can buses (RX) stops
working more often. TX is fine.
I don't see an improvement either. I wrote the new
firmware with updated sdkconfig at about 3pm yesterday
and it rebooted and lost the state of charge metric at
8:45pm, the car woke up at midnight and started
charging, providing data for the SOC metric, during the
charge there were a couple of gaps in the telemetry,
charging finished at 3:10am and the OVMS rebooted at
3:45. The OVMS then stopped sending telemetry completely
at 7:20 am when the car was switched back on. I had a
chance to plug a laptop in and the module was
unresponsive on the serial port.
I'm not sending the monotonic metric so it's only
possible to see the first reboot after the car is
switched off (when it forgets the SOC).
I've built a version of the firmware with most things
turned off (and found vehicle depends on webserver and
webserver depends on OTA) I'll see how that goes
tonight.
Otherwise I'll get the datalogger out and/or try the
sdcard logger again.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev