-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Here's a good checklist to narrow it down. At the end is a list of SMS messages to run and send us the output (via eMail listed on that page):
Support FAQ | Open Vehicles
Regards, Mark
Still a prototype, but getting real close to production. Remaining hardware tasks are the final validation of all the peripherals, and trying to get standby consumption down to <1mA; then good to go.
P.S. That's a 3G modem in the picture, but the MDM1.0 board we have supports both 3G and 4G modem modules (we just solder in the one we want - the circuit board is the same for both).
P.S. That's a 3G modem in the picture, but the MDM1.0 board we have supports both 3G and 4G modem modules (we just solder in the one we want - the circuit board is the same for both).
Really looking forward to the new module arrives!
Btw, I have experienced a strange problem with my version 2 module. I have just received a new SIM card from the danish provider Oister. It works fine in 2 different mobiles I which have tested the SIM card. Both data and SMS are working with the mobiles. I have removed the SIM lock. After resetting the module it boots and flashes error code 3. Re-tested with two other SIM cards, no problem both ok. The Oister SIM is not recognised?
Can any of you help me to solve this problem?
Regards Nis
Botbldr45
Member
Help!
Out of town and need to change charging mode with OVMS. When I try I get a " Failed: Unable to write to CAN." What setting did I have wrong?
I am trying to do this from my iPad and IPhone.
Out of town and need to change charging mode with OVMS. When I try I get a " Failed: Unable to write to CAN." What setting did I have wrong?
I am trying to do this from my iPad and IPhone.
Here's an update on OVMS v3:
On the software side, Steve (who is using a DEVKIT-C for development) has been doing some great work on the command interface, including USB serial and now TELNET consoles (over wifi). This is looking pretty elegant (dare I say ‘polished’) now, with on-line help, tab option expansion, etc; and I’m very grateful to Steve for all his hard work on this. The same command interface will be used for SMS, scripting, event triggers, and pretty much all interactions with the module; so it is important that we get this right. I’ve been working on the framework; things like metrics, configuration, power management, peripheral support, etc. All is looking good with this now, and coming together nicely. I’m particularly happy with the extensibility of the framework - really easy to add commands or other functionality that will then be available through all the different interfaces. Everything is in github, so you can follow progress there.
On the circuit board side, all the peripherals are now working with the exception of the MAX7317 I/O expander. The MISO line on that is not tri-state buffered so is interfering with responses from the two MCP2515 on the same SPI bus. That was a nightmare to troubleshoot (everything looks good, but the MCP2515 responses simply couldn't be seen on the SPI bus - it took us a while to work out that the MCP2515 were working; we just couldn’t see any data out). Solution is relatively simple and is to add an external tri-state buffer chip driven by the !CS line of the MAX7317 - we’re testing this now on a patched board and it seems to work. All the other peripherals (including the three CAN buses) are working, and basic driver support is in the firmware. The issue that is taking the most time is the power management - making sure that we can deep sleep the board and all it’s peripherals. This has proven to be much harder than originally expected - we’ve got so much on this board that identifying each user of power and addressing them one by one is just taking time. The good news is that we’re almost done with this now. The last three power hogs (the CP2102, BTS45R, and SN65 chips) have been identified and we are testing solutions to power each down properly during deep sleep. It seems that we are going to be able to achieve low single digits mA during deep sleep, which is under 1/10th to 1/20th the power of the v2 OVMS hardware; lower than that will hopefully be achievable in software (doing things like powering down the external flash during deep sleep), but we are fast reaching diminishing returns. Espressif will also release other sleep modes in their upcoming SDK, that we hope to be able to take advantage of. The plan now is to make a Release Candidate (RC#1) board (our third revision of board) with these power control fixes and size adjusted to fit the enclosure (primarily the four mounting posts). Hopefully I’ll have that in my hands next week. We have a prototype modem board which looks good, and have started to work on firmware support for that.
These power control issues have taken so much longer than expected and have been the real hold-up in recent weeks. We originally thought that the power usage in OVMS v2 was primarily the modem and linear power supply choices we had made on that platform, but it has turned out that it is much more complex than that. Even things like the CAN transceivers (we tie the power control line to GND in both v2 and v3) take 5mA each - three of them in OVMS v3 is 15mA - so we need to re-work the power control line to be able to deep sleep these under the control of the MCP2515 controllers (and MAX7317 EGPIO in the case of the on-board CAN bus). Then, the CP2102 USB controller can’t deep-sleep from the output side (only from the USB side), so we have to re-work that so it is powered from the USB bus (so it will have zero consumption if USB is disconnected). That means re-working our CTS/RTS/DTR control line logic for flash programming over USB. Lots of little changes, and a steep learning curve. One on-board CAN bus, no SDCARD, no SPI, no EGPIO, etc, would have been much simpler ;-)
On the enclosure side, we’ve completed the 3D design (including logo directly in the plastic so we don’t need top sticker, and cut-out area for serial number / certification sticker on the base). Renders look like this:
Final enclosure will be in black/gray plastic. Just easier to see fit in white. Using plastic avoids any bluetooth/wifi antenna issues that a metal case brings.
Production schedule will depend on outcome of RC#1 board next week. If that is OK, we’ll go ahead and proceed to build a limited-run set of boards for developers based on that design. If people want enclosures, we can 3D print for the moment, until the injection mold is ready.
The actual production run is relatively simple. We give the go ahead and one-to-two weeks later get hundreds of modules. The issue is getting to the stage where we are brave enough to say ‘go ahead’.
On the software side, Steve (who is using a DEVKIT-C for development) has been doing some great work on the command interface, including USB serial and now TELNET consoles (over wifi). This is looking pretty elegant (dare I say ‘polished’) now, with on-line help, tab option expansion, etc; and I’m very grateful to Steve for all his hard work on this. The same command interface will be used for SMS, scripting, event triggers, and pretty much all interactions with the module; so it is important that we get this right. I’ve been working on the framework; things like metrics, configuration, power management, peripheral support, etc. All is looking good with this now, and coming together nicely. I’m particularly happy with the extensibility of the framework - really easy to add commands or other functionality that will then be available through all the different interfaces. Everything is in github, so you can follow progress there.
On the circuit board side, all the peripherals are now working with the exception of the MAX7317 I/O expander. The MISO line on that is not tri-state buffered so is interfering with responses from the two MCP2515 on the same SPI bus. That was a nightmare to troubleshoot (everything looks good, but the MCP2515 responses simply couldn't be seen on the SPI bus - it took us a while to work out that the MCP2515 were working; we just couldn’t see any data out). Solution is relatively simple and is to add an external tri-state buffer chip driven by the !CS line of the MAX7317 - we’re testing this now on a patched board and it seems to work. All the other peripherals (including the three CAN buses) are working, and basic driver support is in the firmware. The issue that is taking the most time is the power management - making sure that we can deep sleep the board and all it’s peripherals. This has proven to be much harder than originally expected - we’ve got so much on this board that identifying each user of power and addressing them one by one is just taking time. The good news is that we’re almost done with this now. The last three power hogs (the CP2102, BTS45R, and SN65 chips) have been identified and we are testing solutions to power each down properly during deep sleep. It seems that we are going to be able to achieve low single digits mA during deep sleep, which is under 1/10th to 1/20th the power of the v2 OVMS hardware; lower than that will hopefully be achievable in software (doing things like powering down the external flash during deep sleep), but we are fast reaching diminishing returns. Espressif will also release other sleep modes in their upcoming SDK, that we hope to be able to take advantage of. The plan now is to make a Release Candidate (RC#1) board (our third revision of board) with these power control fixes and size adjusted to fit the enclosure (primarily the four mounting posts). Hopefully I’ll have that in my hands next week. We have a prototype modem board which looks good, and have started to work on firmware support for that.
These power control issues have taken so much longer than expected and have been the real hold-up in recent weeks. We originally thought that the power usage in OVMS v2 was primarily the modem and linear power supply choices we had made on that platform, but it has turned out that it is much more complex than that. Even things like the CAN transceivers (we tie the power control line to GND in both v2 and v3) take 5mA each - three of them in OVMS v3 is 15mA - so we need to re-work the power control line to be able to deep sleep these under the control of the MCP2515 controllers (and MAX7317 EGPIO in the case of the on-board CAN bus). Then, the CP2102 USB controller can’t deep-sleep from the output side (only from the USB side), so we have to re-work that so it is powered from the USB bus (so it will have zero consumption if USB is disconnected). That means re-working our CTS/RTS/DTR control line logic for flash programming over USB. Lots of little changes, and a steep learning curve. One on-board CAN bus, no SDCARD, no SPI, no EGPIO, etc, would have been much simpler ;-)
On the enclosure side, we’ve completed the 3D design (including logo directly in the plastic so we don’t need top sticker, and cut-out area for serial number / certification sticker on the base). Renders look like this:
Final enclosure will be in black/gray plastic. Just easier to see fit in white. Using plastic avoids any bluetooth/wifi antenna issues that a metal case brings.
Production schedule will depend on outcome of RC#1 board next week. If that is OK, we’ll go ahead and proceed to build a limited-run set of boards for developers based on that design. If people want enclosures, we can 3D print for the moment, until the injection mold is ready.
The actual production run is relatively simple. We give the go ahead and one-to-two weeks later get hundreds of modules. The issue is getting to the stage where we are brave enough to say ‘go ahead’.
smorgasbord
Active Member
Just wanted to give a huge Thank You to the Mark, Steve and the entire OVMS team.
Your efforts are appreciated!
Your efforts are appreciated!
+1 Thx for the update, Mark. Funds standing by once the production release is ready!
I'm surprised there's enough of a market to enable injection molding parts. Now that I think about it there's a lot of other brands of cars that this has been ported to even if there aren't many Roadsters. Maybe it will find a use with Model 3 owners.
When I actually got the prices, it was surprisingly cheap. Lots of little entrepreneur business over the border willing to help. We've got to do a run of 1,000 to make it worthwhile; the first few hundred are the same price as the existing metal shell, and the remainder are free.
It's going to have a HUD feature, so perhaps so ;-)
Joking aside, it's got three CAN buses, and one will be able to be used as a simulated OBDII ECU so you can plug in one of those OBDII displays, or other such dongles.
Does it have compatibility with that special GM CAN bus on the Volt / Ampera that was mentioned up the thread?
Nvbob
Roadster 1256
Sign me up!
Our 2G disappeared (just like most) at the beginning of '17 and no other provider's 2G cover our area so, we have been in OVMS withdrawal.
Thanks again for all you do for us!!
Our 2G disappeared (just like most) at the beginning of '17 and no other provider's 2G cover our area so, we have been in OVMS withdrawal.
Thanks again for all you do for us!!
Can I be cheeky? If your OVMS 2.0 is no longer needed, I've been after another one for the Zoe. I'd be happy to take it off your hands please
Nvbob
Roadster 1256
Can I be cheeky? If your OVMS 2.0 is no longer needed, I've been after another one for the Zoe. I'd be happy to take it off your hands please
"Cheeky"? It's been a while since I have heard that!
Sure, you can have my 2.0 once we have the 3.0 in place and working in our Roadster. I am not sure if we will need to keep the antenna, though.
Mark, does the 3.0 use the same GSM antenna?
Similar threads
- Article
