Open Vehicle Monitor System (OVMS) - Technical Discussion

[Indian Steve]

@markwj ....... any update on when you think v3 OVMS will start shipping? Also, do you have pricing established, and if so, what will it be? I am trying to plan out all my upgrades (new radio, rotors, pads, OVMS, etc...). Oh, and thanks to you for your hard work on this awesome addition to the roadster. I can’t wait to get one installed!

+1

I am waiting for the V3. Is there a deposit needed?

 

[smorgasbord]

OK, so I have my new Hologram SIM, installed, and while some things work, none of the ACC features work. ... Anyone got any advice?

I ended up re-flashing the firmware to the latest 3.1.4/TR/V2/TRP8 version, then after a few failed reboot attempts trying to get into SETUP mode, I eventually got the car in a position where it could receive a cell signal and then was able to successfully send the ACC setup messages from the Hologram dashboard.

A test run away from home and back showed that automatic HOMELINK worked, and that the ACC charge at least stopped the default charge on plug-in. I'll see tonight whether it starts on time.

I'm assuming that OVMS V2 not only doesn't know your time zone, but also doesn't know whether DST is on or not. I ask only because the debug messages through the SETUP terminal do show a recognition of DST. If not already done, I hope V3 knows your timezone/DST status and so we won't need parameter #23 any more.

 

[markwj]

@markwj ....... any update on when you think v3 OVMS will start shipping? Also, do you have pricing established, and if so, what will it be? I am trying to plan out all my upgrades (new radio, rotors, pads, OVMS, etc...). Oh, and thanks to you for your hard work on this awesome addition to the roadster. I can’t wait to get one installed!

10 developer units went out yesterday. Assuming no problems with those, the first production batch (probably 200 modules) will be end of October. The order for the injection moulding has gone in (which takes about a month). General availability should be at the very beginning of November, with at least *basic* firmware for Tesla Roadster. Things like ACC will follow over time (but v3 has Over-The-Air update capability, so should be a lot easier to update than v2).

We haven't finalised pricing yet. It does a lot more than v2, with a lot more radios and other components, but we're trying to keep the pricing as low as possible. 3G modules are expensive, and 4G even more so. Best guess is that the wifi-only module will come in below the old v2 module price, and the version with optional 3G modem included will be slightly more.

 

[markwj]

I am waiting for the V3. Is there a deposit needed?

No, I'd rather not take money up front. Just keep an eye out here. I'll let you all know when the production run starts, which should be about 7 to 10 days prior to general availability. I'm going to discuss with Fasttech about doing something special for early adopters (early bird pricing, reservation, etc).

 

[markwj]

I ended up re-flashing the firmware to the latest 3.1.4/TR/V2/TRP8 version

For Tesla Roadster users (in particular with ACC enabled in the V2_Production firmware), I recommend sticking to the last 2.8.x series firmware (2.8.6, currently). That has been run for a long time in the field, and seems very stable. The 3.x.x code is much more bleeding edge.

 

[Indian Steve]

Great, sounds like its close! I'll stay tuned!

 

[smorgasbord]

For Tesla Roadster users (in particular with ACC enabled in the V2_Production firmware), I recommend sticking to the last 2.8.x series firmware (2.8.6, currently). That has been run for a long time in the field, and seems very stable. The 3.x.x code is much more bleeding edge.

I downgraded to 2.8.6 and it fixed the recent problem with connecting to the server.

BTW, if anyone in the Bay Area is having trouble with firmware updating, I'm willing to try to help them out.

 

[supersnoop]

OK, so I have my new Hologram SIM, installed, and while some things work, none of the ACC features work.

I got my phone number registered, including the reply SMS. But, I'm using the Hologram Dashboard to send.
The MODULE command worked, and MODULE? works.
The STAT? command works.
The GPS? command works.
The VERSION command works (without needing the password), and I"m running 2.6.5/TR/V2

I get in the app notification that it's receiving the ACC text messages, but I get no confirmation response. In the App, I don't see any changes to Parameters #16 - #19, which is where the ACC data is stored.

Anyone got any advice?

Have you installed the Roadster-specific firmware? ACC doesn’t work with the firmware that the unit ships with.

 

[smorgasbord]

Have you installed the Roadster-specific firmware?

Yeah, as I posted above, I'm up and running fine.

 

[shrink]

10 developer units went out yesterday. Assuming no problems with those, the first production batch (probably 200 modules) will be end of October. The order for the injection moulding has gone in (which takes about a month). General availability should be at the very beginning of November, with at least *basic* firmware for Tesla Roadster. Things like ACC will follow over time (but v3 has Over-The-Air update capability, so should be a lot easier to update than v2).

We haven't finalised pricing yet. It does a lot more than v2, with a lot more radios and other components, but we're trying to keep the pricing as low as possible. 3G modules are expensive, and 4G even more so. Best guess is that the wifi-only module will come in below the old v2 module price, and the version with optional 3G modem included will be slightly more.

Mark, any updates on OVMS V3? Just curious. I’d love to buy one if available.

 

[Roadster]

 

[EricUSC]

Me three!

 

[markwj]

Mark, any updates on OVMS V3? Just curious. I’d love to buy one if available.

Sorry for the delays, guys. Nobody wants this out there more than me, but it needs to be 100% right before we hit the button:

Current status summary:

• Firmware is pretty close. Major functionality is there, and basic vehicle support has been ported (Nissan Leaf, Renault Twizy, Tesla Roadster, etc). Still some reliability issues with modem connections to address, but that can be done over time. Initial release is not going to be as feature-rich as OVMS v2, but we can improve this over time and have Over-The-Air update capability for v3, so not too worried about this. All the normal base functionality will be there on day#1, as well as a solid foundation for the future.
• Firmware includes support for an OVMS v2 protocol connection, for compatibility with existing apps. iOS App works with that, and Android App has just been updated to support the new floating point metrics (OVMS v2 was integer only, mostly).
• Firmware also includes support for an OBDII HUD, which is really cool. The module can use one of the CAN buses to emulate an OBDII ECU, and map vehicle metrics to OBDII PIDs. Lots of OBDII HUDs are available, and these can now be used in cars like the Tesla Roadster (which don't have any native OBDII support).
• Enclosures are done. Injection mould has been created, and the first 500 enclosures produced in black colour. Looking good.
• Modems are done. Ready to go. We're initially launching with two versions of a 3G modem (one for EU market, one for US) to keep costs down (3G is _much_ cheaper than 4G).
• 4G will also be available (I've got one on my desk) but will come later. We want to wait a bit for this, to let 4G IoT stabilise - as that is the future and the carriers are just not ready yet. The modem is a pluggable module, so not worried about this.
• Hologram SIMs ordered and on the way. Each modem will include one as standard.
• One issue (SD CARD) is holding up production of the main board. That is the only thing delaying us now.

An issue was found with the SD CARD on the 10x developer units produced earlier. It just wasn't reliable. This has been delaying us for weeks now, trying to get it resolved. The chipset manufacturer hasn't been very helpful, and it has been very hard to get them to recognise the issue and engage to help resolve it. The issue seems to be a fundamental compatibility issue between the external SPI flash memory we are using and the SDIO SD CARD hardware interface. We are not sure if it is just a circuit issue (interference, bus timing, etc), a library issue in the SDK, or something more fundamental. The good news is that the chipset manufacturer has now engaged and is actively working on it - they ordered some custom PCBs to try to recreate the problem, which they received a couple of days ago. We're expecting to hear back any hour/day now; not going to hit that manufacture button until 100% certain the issue is in software (not hardware).

This SD CARD issue is the final issue we've identified. Everything else is ready to go. Timeframe for OVMS v3 to be available on FastTech is 14-to-21 days after the SD CARD issue is resolved.

In the meantime, here are some photos to wet your appetite.

Regards, Mark.

 

[shrink]

Sorry for the delays, guys. Nobody wants this out there more than me, but it needs to be 100% right before we hit the button:

Current status summary:

• Firmware is pretty close. Major functionality is there, and basic vehicle support has been ported (Nissan Leaf, Renault Twizy, Tesla Roadster, etc). Still some reliability issues with modem connections to address, but that can be done over time. Initial release is not going to be as feature-rich as OVMS v2, but we can improve this over time and have Over-The-Air update capability for v3, so not too worried about this. All the normal base functionality will be there on day#1, as well as a solid foundation for the future.
• Firmware includes support for an OVMS v2 protocol connection, for compatibility with existing apps. iOS App works with that, and Android App has just been updated to support the new floating point metrics (OVMS v2 was integer only, mostly).
• Firmware also includes support for an OBDII HUD, which is really cool. The module can use one of the CAN buses to emulate an OBDII ECU, and map vehicle metrics to OBDII PIDs. Lots of OBDII HUDs are available, and these can now be used in cars like the Tesla Roadster (which don't have any native OBDII support).
• Enclosures are done. Injection mould has been created, and the first 500 enclosures produced in black colour. Looking good.
• Modems are done. Ready to go. We're initially launching with two versions of a 3G modem (one for EU market, one for US) to keep costs down (3G is _much_ cheaper than 4G).
• 4G will also be available (I've got one on my desk) but will come later. We want to wait a bit for this, to let 4G IoT stabilise - as that is the future and the carriers are just not ready yet. The modem is a pluggable module, so not worried about this.
• Hologram SIMs ordered and on the way. Each modem will include one as standard.
• One issue (SD CARD) is holding up production of the main board. That is the only thing delaying us now.

An issue was found with the SD CARD on the 10x developer units produced earlier. It just wasn't reliable. This has been delaying us for weeks now, trying to get it resolved. The chipset manufacturer hasn't been very helpful, and it has been very hard to get them to recognise the issue and engage to help resolve it. The issue seems to be a fundamental compatibility issue between the external SPI flash memory we are using and the SDIO SD CARD hardware interface. We are not sure if it is just a circuit issue (interference, bus timing, etc), a library issue in the SDK, or something more fundamental. The good news is that the chipset manufacturer has now engaged and is actively working on it - they ordered some custom PCBs to try to recreate the problem, which they received a couple of days ago. We're expecting to hear back any hour/day now; not going to hit that manufacture button until 100% certain the issue is in software (not hardware).

This SD CARD issue is the final issue we've identified. Everything else is ready to go. Timeframe for OVMS v3 to be available on FastTech is 14-to-21 days after the SD CARD issue is resolved.

In the meantime, here are some photos to wet your appetite.

Regards, Mark.

View attachment 265039
View attachment 265040
View attachment 265041
View attachment 265037
View attachment 265038

Wow. Great work and thanks for the update! I'm very much looking forward to this. This small Roadster community cannot thank you enough!

 

[Jonathanm]

Great and looking forward to the V3..I still have the old V1 which has been working fine since my car rose from the dead last weekend...since yesterday I notice that I am not getting any temperature information on battery, PEM and motor....the boxes are blank...I just updated the available data on the card so it is not that...any one know why this could be the case?

Thanks,

 

[Jonathanm]

Great and looking forward to the V3..I still have the old V1 which has been working fine since my car rose from the dead last weekend...since yesterday I notice that I am not getting any temperature information on battery, PEM and motor....the boxes are blank...I just updated the available data on the card so it is not that...any one know why this could be the case?

Thanks,

For those who are interested Mark replied and informed me the car was asleep. Just needed to wake it up with a tap on the boot (trunk). All is good...

 

[smorgasbord]

Anyone try getting fancy with garage door and charging settings?

For many of us, I suspect we have a single location the opens the garage door as we approach AND contains the charging settings (Cooldown, delay of charge start, etc.). One issue is that when you leave, the garage door has to be manually closed.

With the Radius parameter, it might be possible to setup two Locations:
1) Inside the garage, for charging
2) Well outside the garage, to Open/Close the garage door

The idea would be that your two locations would each have pretty tight radii. So when you pass through the outside location, the car sends the garage open/close signal. By the time you actually reach the garage, you've exited the outside location and have entered the inside location, which has the charge settings. Then when you leave, you exist the inside location and when the car hits the outside location, the garage open/close signal is sent, thus automatically closing the garage.

I would imagine this requires that the GPS fix be quite good, even inside the garage, so that with a small enough radius such that the two locations don't intersect, getting into the locations is still reliable.

Is this do-able, or are the practicalities involved a deal killer?

 

[SteveHand]

First - thanks to Mark and the development team for all the work on V3.
Put me on the reservation list too(please).

Now to Smorgasbord’s Q: I found the accuracy of the GPS/ radius a little temperamental when combined with radio distance on the garage door receiver.
For instance, Timothy’s garage door would sometimes not open when he came home. I theorized that the GPS fence was triggering on the border of his opener’s range.

I drove his car past his garage another 40 feet and reset his home position. Garage door now works everytime.

An out of the box idea:
Separate software logic other than GPS sensors to arm and, later to trigger the garage door to shut?

Do we have accelerometers or ability to tell if car has moved x distance? If so then it’s possible for new optional setting...

Arriving home ==> do same as today plus set a flag “I’m home” to Arm the garage door shut feature.

Garage door shut feature:
If “I’m home” for longer than 10 minutes AND the car moves more than x distance, then trigger the garage door opener to shut, set flag to “I’m away”

But this can now create some unexpected closing behavior such as:
arrive home, (door opens), stop outside the garage ....
later, return to put car into garage. Move x distance towards the garage and surprise the door shuts.

Alternative Arming criteria:
“I’m home” AND I’ve charged (now it assumes charging happens in the garage and that it is charged every time it enters the garage).
The problem is that the behavior might not be clear to the driver and car seems possessed.

Other thoughts?

 

[gregd]

Other thoughts?

My first thought is that we're taking this automation thing a bit too far. Occam's Razor, and all that.

That said, the V3 OVMS has a very powerful scripting language built in (javascript), so perhaps it can be convinced to do what you want. But reading one's mind is not currently in the API, so be careful what you ask it to do.

 

[GJVR]

Sorry for the delays, guys. Nobody wants this out there more than me, but it needs to be 100% right before we hit the button:

Current status summary:

• Firmware is pretty close. Major functionality is there, and basic vehicle support has been ported (Nissan Leaf, Renault Twizy, Tesla Roadster, etc). Still some reliability issues with modem connections to address, but that can be done over time. Initial release is not going to be as feature-rich as OVMS v2, but we can improve this over time and have Over-The-Air update capability for v3, so not too worried about this. All the normal base functionality will be there on day#1, as well as a solid foundation for the future.
• Firmware includes support for an OVMS v2 protocol connection, for compatibility with existing apps. iOS App works with that, and Android App has just been updated to support the new floating point metrics (OVMS v2 was integer only, mostly).
• Firmware also includes support for an OBDII HUD, which is really cool. The module can use one of the CAN buses to emulate an OBDII ECU, and map vehicle metrics to OBDII PIDs. Lots of OBDII HUDs are available, and these can now be used in cars like the Tesla Roadster (which don't have any native OBDII support).
• Enclosures are done. Injection mould has been created, and the first 500 enclosures produced in black colour. Looking good.
• Modems are done. Ready to go. We're initially launching with two versions of a 3G modem (one for EU market, one for US) to keep costs down (3G is _much_ cheaper than 4G).
• 4G will also be available (I've got one on my desk) but will come later. We want to wait a bit for this, to let 4G IoT stabilise - as that is the future and the carriers are just not ready yet. The modem is a pluggable module, so not worried about this.
• Hologram SIMs ordered and on the way. Each modem will include one as standard.
• One issue (SD CARD) is holding up production of the main board. That is the only thing delaying us now.

An issue was found with the SD CARD on the 10x developer units produced earlier. It just wasn't reliable. This has been delaying us for weeks now, trying to get it resolved. The chipset manufacturer hasn't been very helpful, and it has been very hard to get them to recognise the issue and engage to help resolve it. The issue seems to be a fundamental compatibility issue between the external SPI flash memory we are using and the SDIO SD CARD hardware interface. We are not sure if it is just a circuit issue (interference, bus timing, etc), a library issue in the SDK, or something more fundamental. The good news is that the chipset manufacturer has now engaged and is actively working on it - they ordered some custom PCBs to try to recreate the problem, which they received a couple of days ago. We're expecting to hear back any hour/day now; not going to hit that manufacture button until 100% certain the issue is in software (not hardware).

This SD CARD issue is the final issue we've identified. Everything else is ready to go. Timeframe for OVMS v3 to be available on FastTech is 14-to-21 days after the SD CARD issue is resolved.

In the meantime, here are some photos to wet your appetite.

Regards, Mark.

View attachment 265039
View attachment 265040
View attachment 265041
View attachment 265037
View attachment 265038

Sign me up, please