[Ovmsdev] AutoInit Inhibit

Tue Aug 28 15:55:15 HKT 2018

I seem to remember Greg and I discussing having an option to bring up the ext12v when obd2ecu started, or when car was on/off, etc. I think we decided it wouldn’t be hard to do, but perhaps better left to scripts?

We would still have to deal with the case of ext12v being used for something other than obd2ecu, so having it _also_ as auto init capable seems fine.

P.S. One other point on auto init is that I think the pcp base object can be used. Perhaps a power mode (like off, on, etc), or just a standard virtual AutoInit function. The only auto init module not currently using pcp is vehicle, but that would be trivial to fix.

Regards, Mark

> On 28 Aug 2018, at 2:51 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> In case an obd2ecu device has that race condition, wouldn't it be better to let the obd2ecu startup code control the ext12v power?
> 
> I.e. leave the general auto init config to user control, and add a "late ext12v enable" option to obd2ecu.
> 
> Regards,
> Michael
> 
> 
> Am 28.08.2018 um 08:45 schrieb Mark Webb-Johnson:
>> Greg, Michael,
>> 
>> I was trying to keep the ext12v close to obd2ecu for that reason. Don’t want to power it up too early, as we need obd2ecu up and running for the external hud to talk to.
>> 
>> No fixed ideas on the use of ext12v. The obvious use case is some sort of external display - and that could communicate over any one of a number of methods (but most likely bluetooth or can bus).
>> 
>> Regards, Mark.
>> 
>>> On 28 Aug 2018, at 2:37 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> 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:
>>>>>>> 
>>>>>>> External 12V
>>>>>>> Wifi
>>>>>>> Modem SIMCOM
>>>>>>> Vehicle
>>>>>>> OBD2ECU
>>>>>>> Server V2
>>>>>>> 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:
>>>>>>> 
>>>>>>> Wifi
>>>>>>> Bluetooth
>>>>>>> Server V2
>>>>>>> Server V3
>>>>>>> Modem SIMCOM
>>>>>>> External 12V
>>>>>>> Vehicle
>>>>>>> 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 <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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 <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180828/89ccb341/attachment.htm>