[Ovmsdev] AutoInit Inhibit

Tue Aug 28 14:37:08 HKT 2018

As enabling the external 12V has near zero crash potential it doesn't hurt doing that in step 1.

That also allows to power e.g. a mobile wifi router from that line (just an idea, haven't tried that).

Regards,
Michael

Am 28.08.2018 um 08:25 schrieb Greg D.:
> Hi Mark,
>
> One thing to consider is that you've got a small race condition with the external device powering up before the code that services it is ready.  Most devices
> retry, and the OBD2ECU code starts quickly, but some devices will drop into alternative modes if that initial handshake fails.  Typically not fatal (using
> extended mode instead of standard, for example), but it's a race none the less.
>
> What sort of devices were you thinking of for driving with the external 12v power?  Any plans for a service other than OBD2ECU to drive the external CAN bus
> in support of it?  OBD2ECU is certainly not the only option.
>
> Greg
>
>
> Mark Webb-Johnson wrote:
>> The order I suggested was loosely based on trying to maintain connectivity (even if a module is causing a crash). I’ve put the least used modules (or those
>> not related to connectivity) at the bottom of the list, and the most critical modules (but hopefully most reliable) at the top.
>>
>> Currently, Server V3 should be at the bottom, but I am hoping it will improve in reliability. Perhaps it should be after SIMCOM for the moment.
>>
>> The idea behind putting external 12v reasonable high (before vehicle) was (a) it is highly unlikely to cause us any issues, and (b) external displays may
>> provide status and other indications useful to identify problems. It could probably swap with ‘vehicle’, without much impact.
>>
>> Regards, Mark.
>>
>>> On 28 Aug 2018, at 1:45 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>
>>> Hi Mark,
>>>
>>> The new proposal sounds like a good idea (in spite of putting OBD2ECU at the bottom {sniff} ).  If we someday get the ability to configure the module from
>>> the Modem, would it be a good idea to move SIMCOM up in the priority chain, to allow for remote repair if either of the servers is causing the trouble?  The
>>> V2 server has been pretty stable for a long time, but I wonder about V3.
>>>
>>> Curious why you put External 12v above OBD2ECU.  I'd move 12v to the bottom, so you don't turn on the external device until the server is running.  What
>>> else is dependent on the external 12v supply?
>>>
>>> Greg
>>>
>>>
>>> Mark Webb-Johnson wrote:
>>>> Last week’s 3.1.009 issue with Tesla Roadsters was interesting. Looking at the car I saw with the problem, it was booting, crashing when the vehicle module
>>>> received a certain CAN bus message (triggering the issue), and rebooting. It would do this 5 times, until it his the AUTO_INIT_INHIBIT_CRASHCOUNT count,
>>>> and then AutoInit inhibit would kick in, and it would end up sitting idle with nothing loaded (and no network connection). The approach worked very well,
>>>> and prevented an endless reboot loop.
>>>>
>>>> However, we ended up with a car unable to connect to the network, and requiring a console cable and laptop to recover. I’ve been thinking about bluetooth
>>>> (which is intended to provide a smartphone connection irrespective of wifi configuration), how that might work with a completely unconfigured module (for
>>>> initial configuration), and I can suggest a workaround to try to improve this…
>>>>
>>>> At the moment, the order of autoinit is:
>>>>
>>>>  1. External 12V
>>>>  2. Wifi
>>>>  3. Modem SIMCOM
>>>>  4. Vehicle
>>>>  5. OBD2ECU
>>>>  6. Server V2
>>>>  7. Server V3
>>>>
>>>>
>>>> None of those run if the early crash count > AUTO_INIT_INHIBIT_CRASHCOUNT (coded as a constant 5).
>>>>
>>>> My suggestion is to change this as follows:
>>>>
>>>>  1. Wifi
>>>>  2. Bluetooth
>>>>  3. Server V2
>>>>  4. Server V3
>>>>  5. Modem SIMCOM
>>>>  6. External 12V
>>>>  7. Vehicle
>>>>  8. ODB2ECU
>>>>
>>>>
>>>> But also to change that logic that:
>>>>
>>>>   * #8 will start if early crash count > AUTO_INIT_INHIBIT_CRASHCOUNT
>>>>   * #7 will start if early crash count > AUTO_INIT_INHIBIT_CRASHCOUNT+1
>>>>   * #6 will start if early crash count > AUTO_INIT_INHIBIT_CRASHCOUNT+2
>>>>   * etc.
>>>>
>>>>
>>>> This will mean that once we hit the AUTO_INIT_INHIBIT_CRASHCOUNT limit, we turn off the least required module (OBD2ECU), then continue to see if that
>>>> solves the problem. If not (ie; we crash and reboot), then we try turning off the Vehicle module and OBD2ECU, then continue to see if that solves the
>>>> problem. etc.
>>>>
>>>> In the example case of the Tesla Roadster vehicle module causing the issue, this revised approach would leave us up and running with Wifi and a Server
>>>> Connection (but no vehicle data). Checking the module would identify the problem quite quickly (and remotely). Starting the vehicle module manually would
>>>> presumably result in a crash and we would pretty quickly get an idea of the cause (especially if we added a command to show the status of AutoInit, what
>>>> was started, and what wasn’t because it is causing a crash). I think we could even issue an Alert notification in the case where autoinit recovered after
>>>> inhibiting certain modules (but not all).
>>>>
>>>> The disadvantage is that we would crash more (up to 13 times, vs 5) in the case the system is badly messed up.
>>>>
>>>> What do people think? Does this make sense?
>>>>
>>>> Regards, Mark.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180828/7e3f02f3/attachment-0001.html>