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