<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">but something seems broken in the latest firmware. I can’t get CAN2 to receive. Probably related to the last hardware revision for sleep mode on the SN65 transceivers. I’m working on that now, as a matter of urgency.</div></div></blockquote><br class=""></div><div class="">Done, and committed. Just some power control wierdisms - nothing that a few minutes with a logic probe couldn’t solve. All seems ok for all three CAN buses now.</div><div class=""><br class=""></div><div class="">In fact:</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="F34C49E8-ADAD-4BF4-B25D-4936D98C061F" src="cid:93B7C548-4049-4015-A968-4E2452563536" class=""></div><div class=""><br class=""></div><div class="">Looking good.</div><div class=""><br class=""></div><div class="">Still need to tidy up the CAN drivers and put in a lot of error checking and reset code, but at least they run...</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class="">P.S. That is Greg’s OBDII HUD (driven off CAN3 - one of the MCP2515 controller buses).</div><div class=""><br class=""></div><div class="">P.P.S. I never knew rolling back odometers was so easy:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">OVMS > metric set v.p.odometer 20000</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">Metric set</span></font></div></div></blockquote><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 30 Sep 2017, at 4:35 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Tom,<div class=""><br class=""></div><div class="">Some of the driver support is very very basic at the moment. Almost ‘proof of concept’ only to verify hardware is working. Still a lot of work to be done on it. In particular:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">SIMCOM support is very very simple. Just power control, the ability to print out on the console what SIMCOM replies, and to send commands to the modem. A lot of work to do on this. Overall plan is to have a layer-2 (AT command) control that initialises the modem, gets details on the modem type, SIM card, etc, and then switches to layer-3 (MUX). Then, in layer-3, we need to implement GPS NMEA channel, AT command and control channel, and a PPP driver for the ESP32/FreeRTOS networking stack (this exists already, in example code, so should be the simplest step). Then, SMS. Lastly we have to implement the overall control over when to establish GSM connections, what to do if WIFI comes up, etc.<br class=""><br class=""></li><li class="">MCP2515 support is rudimentary and we don’t check state of the controller correctly (particularly during initialisation). We need to support transmission errors, etc. Basic support for this is there, and we can transmit and receive messages, but it seems to have problems under load. We’ve also got to finalise the power control for this. All the blocks are there - just need to harden it.<br class=""><br class=""></li><li class="">On-board can (esp32 controller) should be fine. Just power control needs finalising (since we added the SN65 sleep line control in the last hardware revision).<br class=""><br class=""></li><li class="">OVMS server v2 just connects and does crypto at the moment. It doesn’t send any vehicle metrics.</li></ul></div><div class=""><br class=""></div><div class="">Wifi works fine.</div><div class=""><br class=""></div><div class="">Regarding the documentation improvements/suggestions; if you or others find stuff like this, please use google docs comment feature to suggest the change. That provides a todo style list of changes that are relatively simple to go through and accept into the main code. It works really well, and a bunch of changes have started to come in that way already.</div><div class=""><br class=""></div><div class="">I’ve updated the Developer’s Guide today with a bunch of hardware information (an entire section on the circuit) that has all the information on expansion connectors, as well as GPIO/EGPIO wiring). I hope it helps.</div><div class=""><br class=""></div><div class="">Regarding CAN, we have:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">CAN1 - on-board ESP32 controller, and SN65 3.3v transceiver. This is on the OVMS v2 compatible DB9 connector as pins #2 and #7. The OVMS v2 vehicle cables should support this.</li><li class="">CAN2 - MCP2515 SPI controller, and SN65 3.3v transceiver. DB9 pins #4 and #5. This was actually specified in OVMS v2 (but never used as we had only one CAN bus on that platform). If you have a recent OVMS v2 Nissan Leaf cable, you should find these pins already wired up and ready to go.</li><li class="">CAN3 - MCP2515 SPI controller, and SN65 3.3v transceiver. DB9 pins #6 and #8. Not used by OVMS v2 and not on any of the cables we have. We are currently using this for the HUD (via the DA26 expansion connector), but it is free for use by vehicles if they require a third bus.</li></ol><div class=""><br class=""></div></div><div class="">Take care, as these are labelled on the circuit diagrams as CAN0/CAN1/CAN2, but the firmware and framework refers to them as CAN1/CAN2/CAN3. I tried to address this in the developer’s documentation.</div><div class=""><br class=""></div><div class="">I’m working on the HUD with Greg (as the first user of these external CAN buses), but something seems broken in the latest firmware. I can’t get CAN2 to receive. Probably related to the last hardware revision for sleep mode on the SN65 transceivers. I’m working on that now, as a matter of urgency.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 30 Sep 2017, at 6:38 AM, Tom Parker <<a href="mailto:tom@carrott.org" class="">tom@carrott.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    On 22/09/17 19:22, Mark Webb-Johnson wrote:<br class="">
    <blockquote type="cite" cite="mid:503F03A9-C48E-4FA2-BE27-0E31E68FF6AE@webb-johnson.net" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      For those of you about to receive OVMS v3 modules, and for others
      listening in, here is a ‘getting started’ guide.
      <div class=""><br class="">
      </div>
    </blockquote>
    <br class="">
    I've got mine working on wifi with dexter's v2 server. I haven't
    tried the cellular modem or a car module yet.<br class="">
    <br class="">
    <blockquote type="cite" cite="mid:503F03A9-C48E-4FA2-BE27-0E31E68FF6AE@webb-johnson.net" class="">
      <div class="">Developer’s documentation is here:</div>
      <div class=""><br class="">
      </div>
      <blockquote style="margin: 0 0 0 40px; border: none; padding:
        0px;" class="">
        <div class=""><a href="https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEixr0/edit?usp=sharing" class="" moz-do-not-send="true">https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEixr0/edit?usp=sharing</a></div>
      </blockquote>
    </blockquote>
    <br class="">
    I did my setup in an ubuntu xenial vagrant box. I might try a
    container based on one of the one on the docker hub now that I've
    done it "natively".<br class="">
    <br class="">
    A couple of gotchas:<br class="">
    <br class="">
    Vehicle Firmware Development tools in the above google doc suggests
    following the instructions at <a class="moz-txt-link-freetext" href="https://github.com/espressif/esp-idf">https://github.com/espressif/esp-idf</a>
    but then goes on to say refer to the documentation at
<a class="moz-txt-link-freetext" href="http://esp-idf.readthedocs.io/en/v2.1/get-started/index.html#standard-setup-of-toolchain">http://esp-idf.readthedocs.io/en/v2.1/get-started/index.html#standard-setup-of-toolchain</a>
    and be careful to get the right version of the documentation to get
    the right version of the tools. I followed the first instructions
    and got the latest version which doesn't work. When it didn't work I
    remembered the note to ensure to follow the right version of the
    instructions. Could you reverse the order of these, putting the
    readthedocs link first and suggest following those instructions, and
    put the github link afterwards as an aside.<br class="">
    <br class="">
    On xenial you need to apt-get install
    linux-image-extra-4.4.0-96-generic to get the cp210 serial port
    driver.<br class="">
    <br class="">
    You have to update the "Default serial port" to /dev/ttyUSB0 in
    "Serial flasher config" in make menuconfig so that make flash can
    find the serial port.<br class="">
    <br class="">
    <a class="moz-txt-link-freetext" href="http://esp-idf.readthedocs.io/en/latest/get-started/idf-monitor.html">http://esp-idf.readthedocs.io/en/latest/get-started/idf-monitor.html</a>
    has some useful instructions about the monitor, notably ctrl-]
    quits.<br class="">
    <br class="">
    Thank you Mark for bringing this together -- it looks like a very
    capable platform. Basic vehicle support looks pretty easy to port
    over, hopefully I'll have some leaf code to contribute later this
    week.<br class="">
    <br class="">
    How do we manipulate the other can buses? I see
    MyPcpApp.FindDeviceByName("can1"); in the Tesla Roadster code, is
    there a can0 or a can2? How are they mapped to the hardware?<br class="">
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class=""><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>