[Ovmsdev] OVMS v3 getting started

Sat Sep 30 22:14:36 HKT 2017

> 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.

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.

In fact:

Looking good.

Still need to tidy up the CAN drivers and put in a lot of error checking and reset code, but at least they run...

Regards, Mark.

P.S. That is Greg’s OBDII HUD (driven off CAN3 - one of the MCP2515 controller buses).

P.P.S. I never knew rolling back odometers was so easy:

OVMS > metric set v.p.odometer 20000
Metric set

> On 30 Sep 2017, at 4:35 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Tom,
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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).
> 
> OVMS server v2 just connects and does crypto at the moment. It doesn’t send any vehicle metrics.
> 
> Wifi works fine.
> 
> 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.
> 
> 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.
> 
> Regarding CAN, we have:
> 
> 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.
> 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.
> 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.
> 
> 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.
> 
> 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.
> 
> Regards, Mark.
> 
>> On 30 Sep 2017, at 6:38 AM, Tom Parker <tom at carrott.org <mailto:tom at carrott.org>> wrote:
>> 
>> On 22/09/17 19:22, Mark Webb-Johnson wrote:
>>> For those of you about to receive OVMS v3 modules, and for others listening in, here is a ‘getting started’ guide.
>>> 
>> 
>> I've got mine working on wifi with dexter's v2 server. I haven't tried the cellular modem or a car module yet.
>> 
>>> Developer’s documentation is here:
>>> 
>>> https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEixr0/edit?usp=sharing <https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEixr0/edit?usp=sharing>
>> 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".
>> 
>> A couple of gotchas:
>> 
>> Vehicle Firmware Development tools in the above google doc suggests following the instructions at https://github.com/espressif/esp-idf <https://github.com/espressif/esp-idf> but then goes on to say refer to the documentation at 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> 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.
>> 
>> On xenial you need to apt-get install linux-image-extra-4.4.0-96-generic to get the cp210 serial port driver.
>> 
>> 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.
>> 
>> http://esp-idf.readthedocs.io/en/latest/get-started/idf-monitor.html <http://esp-idf.readthedocs.io/en/latest/get-started/idf-monitor.html> has some useful instructions about the monitor, notably ctrl-] quits.
>> 
>> 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.
>> 
>> 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?
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170930/6b4542fd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 397104 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170930/6b4542fd/attachment-0002.tiff>