<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Some notes/comments (pasted from previous discussions, and new):<div class=""><br class=""></div><div class="">Here is a rough description of the PCP power states:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Every peripheral class in the OVMS v3 system (both physical and virtual) should be derived from pcp (Power Controlled Peripheral). That base class implements the concept of a power state, as well as standardised commands to change state (and for sub-classed peripherals to implement those states).</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><blockquote class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class=""><font face="Andale Mono" class="">class obd2ecu : public pcp</font></div><div class=""><font face="Andale Mono" class=""> {</font></div><div class=""><font face="Andale Mono" class=""> public:</font></div><div class=""><font face="Andale Mono" class=""> obd2ecu(const char* name, canbus* can);</font></div><div class=""><font face="Andale Mono" class=""> ~obd2ecu();</font></div><div class=""><font face="Andale Mono" class=""><br class=""></font></div><div class=""><font face="Andale Mono" class=""> public:</font></div><div class=""><font face="Andale Mono" class=""> virtual void SetPowerMode(PowerMode powermode);</font></div></div></blockquote><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">At the moment, we don’t use this much. Some peripherals implement it, some don’t, and some only partially. Have a look at ::SetPowerMode() in the peripheral code itself.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">In general:</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><blockquote class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">Undefined<span class="Apple-tab-span" style="white-space: pre;"> </span>Power mode is undefined</div><div class="">On<span class="Apple-tab-span" style="white-space: pre;"> </span>Fully powered on</div><div class="">Sleep<span class="Apple-tab-span" style="white-space: pre;"> </span>Reduced power mode (but all functions expected to be fully operational)</div><div class="">DeepSleep<span class="Apple-tab-span" style="white-space: pre;"> </span>Minimal power deep sleep mode (may turn off some functions to save power)</div><div class="">Off<span class="Apple-tab-span" style="white-space: pre;"> </span>Fully powered off</div></blockquote><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><div class=""><br class=""></div><div class="">This will become important later when we implement the sleep and deep sleep modes in OVMS firmware (primarily to save those little 12V batteries).</div></div></div></blockquote><div class=""><div><br class=""></div></div><div>We had a discussion a while ago about powering down peripherals (primarily on vehicles with little 12V batteries):</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">We’ve just put in the base support in PCP (Power Controller Peripheral), and implemented it in most places. I think all the peripherals (as well as the ESP32 chip itself) implements those power control features (where possible), but there may be gaps in support.</span><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">For a place to start - a review of everything derived from PCP and ensure that they support the SetPowerMode function to do something reasonable.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">That is the base support. Then, we need something on top to intelligently control power. That would call SetPowerMode() on the peripherals themselves. This would be best implemented in class pcpapp (MyPcpApp). It would monitor the state of the system (and perhaps the 12V battery), and perform tasks as directed by configuration.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Power consumption wise, the modem is the biggest culprit. That has a low power mode (supported in the SIMCOM driver we wrote), but will tear down the data connection. So that means we lose App control. In low power mode it can be woken up from an incoming USSD / SMS message (which is cool for hologram users as incoming SMS is free) - for those users, if the modem is in low power mode, when the App connects the server could talk to Hologram to wake up the modem (that is the way most other telemetry systems work).</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">When I thought of this originally, I thought of having different power control profiles. Each profile would be a set of configuration options defining what power control steps to take. Then the user picks a profile to use (including a custom one). The simplest profile would monitor the 12v battery and power everything down (including ESP32) if the 12v was below a critical level. But nothing like that is implemented at the moment.</div></div></div></blockquote><div class=""><div><br class=""></div><div>In short, the framework is in place but there is no centralised power control at the moment. Should we implement it, the suggestion is to implement a MyPcpApp that monitors system events and powers up/down or sleeps depending on a configured power profile.</div><div><br class=""></div><div>To answer your specific questions:</div><div><br class=""></div><div><blockquote type="cite" class="">I assume when the vehicle is "off" the ovms module wakes up periodically to check location, upload current status. And when the vehicle is "on" it stays booted. And this driven by some metrics?</blockquote><br class=""></div><div>Not currently. Each vehicle control module is responsible for this, and in particular the OBDII polling framework has support for different polling states that the vehicle class can switch between (usually depending on vehicle state - off, on, charging, etc).</div><div><br class=""></div><div><blockquote type="cite" class="">Are there other metrics I need to manage for miminal support?</blockquote><br class=""></div><div>I suggest you have a look at vehicle_obdii as a starting point. At a minimum, you should look to implement vehicle on/off, SOC/fuel level, mode (charging, driving, etc). From there, things like temperatures, speed, gear, etc, are useful.</div><div><br class=""></div><div><blockquote type="cite" class=""> Speaking of wireshark and canbus, this video shows an interesting product:<br class=""></blockquote><br class=""></div><div>We have ‘re tools’ on the module itself, and that is pretty useful for reverse engineering. It can do dumps (including over wifi), and has a primarily textual console interface. There is the start of a web based interface. It does support streaming CAN bus dumps in both CRTD (ascii, textual, human readable) and PCAP (Wireshark) format.</div><div><br class=""></div><div><blockquote type="cite" class="">it has a mode that has a billboard which shows which can ids have been changing with lots of neat options like hiding and highlighting recently changed octets. </blockquote><br class=""></div><div>Sounds/looks like the ‘discover’ and ‘changed’ modes of RE TOOLS.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 9 Jun 2019, at 10:39 AM, Craig Leres <<a href="mailto:leres@xse.com" class="">leres@xse.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">After a long period of procrastination it's time for me to get a OVMS module working in my Cadillac. If I can get it to the point where it doesn't kill the battery and lets me see where the car is it'll be about as usable as my free onstar account and I'll be able to kill that off.<br class=""><br class="">The last time I worked on it I was able to decode/display/store the vin. I thought I had figured out the car awake messages but a capture I made today makes me doubt I have that correct. Either way I don't think I understand what it is I need.<br class=""><br class="">I assume when the vehicle is "off" the ovms module wakes up periodically to check location, upload current status. And when the vehicle is "on" it stays booted. And this driven by some metrics? Looking at other vehicles I was using:<br class=""><br class=""> StdMetrics.ms_v_env_on->SetValue();<br class=""> StdMetrics.ms_v_env_awake->SetValue();<br class=""><br class="">But I'm not sure what events should set/clear these. I'm used to thinking of a car being a few different states:<br class=""><br class=""> off<br class=""> accessories on<br class=""> engine on<br class=""> engine running<br class=""><br class="">So I guess "awake" is when something wakes up the bus (e.g. door unlock, key fob press, door open, etc.) and everybody starts sending their "I'm here" messages for awhile and if nothing else happens they go back to sleep. I see logic for this in vehicle_nissanleaf.cpp (awake on certain can ids, asleep from a 1 second watchdog if StandardMetrics.ms_v_env_awake->IsStale())<br class=""><br class="">Still looking at the leaf (which doesn't have an engine) StdMetrics.ms_v_env_on seems to indicate the car can be driven. Does that map to the engine running for a gas engine car? I also see logic in the mitsubishi but it's not obvious if the transition is accessories on or engine on.<br class=""><br class="">Are there other metrics I need to manage for miminal support?<br class=""><br class="">One of the things I was hoping to do with the Cadillac was capture the frames that onstar sends to the navigation head unit when you use the "send to in-dash navigation" feature of the onstar app. But the list of things you can do with the free onstar account has constantly gotten shorter over the last few years and it appears they've killed off this feature in the last month or so. Too bad because this would have been a neat feature to add to ovms.<br class=""><br class="">While I'm here...<br class=""><br class="">The J1850 tools I've built up are not at all helpful with canbus; but I have a raspberrypi 2 that isn't doing anything and I believe I can use it to get wireshark going with a <a href="http://skpang.co.uk" class="">skpang.co.uk</a> "PiCAN2 CAN-Bus Board" so I ordered one. Speaking of wireshark and canbus, this video shows an interesting product:<br class=""><br class=""> <a href="https://youtu.be/xZNszFTaP0A" class="">https://youtu.be/xZNszFTaP0A</a><br class=""><br class="">it has a mode that has a billboard which shows which can ids have been changing with lots of neat options like hiding and highlighting recently changed octets. I suspect it won't be difficult to write something with similar functionality. But I think my id mapping will go a lot faster if I can do things while watching a display.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Craig<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>