Apologies for the length of this eMail, but lots to go through... We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0. The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry. The problems we've had with the current hardware include: Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-) Once we add in using this in other cars, we also get: Concerns over 12V battery load Lack of GPS in some cars Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made. Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well. Here are the changes we have come up with: Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock. I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars. As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners. For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary. We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks. Regards, Mark.
This is great stuff, Mark. I'm glad to see OVMS moving forward. As a Leaf owner, the number one thing I want in an OBD gizmo is a visible SOC meter in the cabin. The stock SOC instrumentation on the Leaf is worse than useless and being able to see an actual SOC estimate easily adds 10% to the usable range of Leaf. We have the Gary Giddings SOC meter in our Leaf and it makes us feel empowered to really drive the Leaf to its full capability. In order for OVMS to go mainstream for Leaf owners, it will need to support some sort of display. This could be an external display driven from the DIAG DB9. Having power on that connector would be a big bonus. The Leaf OBD port has two power lines, one that's always on and one that's on only when the car is on. It would be great to pass the car-on power through the DIAG DB9. (Unfortunately, that power line is off when the car is charging unless you turn the car on, so it probably doesn't make sense to power the OVMS board from there. Gary's box has a switch so you can manually select the power source, which is handy when we want to monitor a charge.) On a somewhat related note, when I display the Roadster at a car show, I print out a sheet of paper that says "25,536 Oil-Free Miles Driven" with an estimate of what my odometer will say when I arrive at the show. I have this fantasy of putting an LED reader board in the rear window that shows that message with the live odometer reading. Is there enough room in the V1 board flash to push reader board command strings out of the DIAG DB9? Tom on 6/7/12 5:33 PM, Mark Webb-Johnson wrote:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom,
Is there enough room in the V1 board flash to push reader board command strings out of the DIAG DB9?
The Diag DB9 is really just a backdoor to the modem comms channel. Can't really be used for much except diagnostics. What we have done with the v1 PIC controller board is expose all unused pins as headers. It should be quite simple to take a display off those. Probably drive it with I2C or the hitachi LCD protocol.
In order for OVMS to go mainstream for Leaf owners, it will need to support some sort of display. This could be an external display driven from the DIAG DB9. Having power on that connector would be a
We're trying to keep the price of the hardware module down, and simplify the arrangement. An alternative layout is to put a box up on the dashboard, then a longer cable to the can bus and power. The box could have a little touch-screen display and could then do some amazing things. Something like one of those satnav units. But, that drives up the price and complexity of installation. The third alternative is to then put a 32bit processor, possibly running linux or some other rtos, to give us the ability to do things like wifi hotspot. Regards, Mark. On 8 Jun, 2012, at 11:42 PM, Tom Saxton wrote:
This is great stuff, Mark. I'm glad to see OVMS moving forward.
As a Leaf owner, the number one thing I want in an OBD gizmo is a visible SOC meter in the cabin. The stock SOC instrumentation on the Leaf is worse than useless and being able to see an actual SOC estimate easily adds 10% to the usable range of Leaf. We have the Gary Giddings SOC meter in our Leaf and it makes us feel empowered to really drive the Leaf to its full capability.
In order for OVMS to go mainstream for Leaf owners, it will need to support some sort of display. This could be an external display driven from the DIAG DB9. Having power on that connector would be a big bonus.
The Leaf OBD port has two power lines, one that's always on and one that's on only when the car is on. It would be great to pass the car-on power through the DIAG DB9. (Unfortunately, that power line is off when the car is charging unless you turn the car on, so it probably doesn't make sense to power the OVMS board from there. Gary's box has a switch so you can manually select the power source, which is handy when we want to monitor a charge.)
On a somewhat related note, when I display the Roadster at a car show, I print out a sheet of paper that says "25,536 Oil-Free Miles Driven" with an estimate of what my odometer will say when I arrive at the show. I have this fantasy of putting an LED reader board in the rear window that shows that message with the live odometer reading.
Is there enough room in the V1 board flash to push reader board command strings out of the DIAG DB9?
Tom
on 6/7/12 5:33 PM, Mark Webb-Johnson wrote:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data. One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!). Bye michael Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael, We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module. Regards, Mark. On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen. http://www.st.com/internet/mcu/subclass/1169.jsp The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range. The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available. Tom on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, I kind of think that there are two camps out there: Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc) While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do. We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems. In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath. There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)? The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp. Regards, Mark. P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-) On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'd say option 2. I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed<http://www.sparkfun.com/products/9564>which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.) As I remember you can use a serial GLCD w/ SD slot as your display. Something like this <http://www.sparkfun.com/products/11075>. My $0.02, spend it wisely. William On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Tom,
I kind of think that there are two camps out there:
1. Cheap, simple, just do one function (remote monitoring and control) 2. Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys:
http://www.rechargecar.com/content/first-glimpse-macchina
have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky
to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work.
I think you are on the right way. Dont put to much in it. A loop through
connector for the CAN Bus could be very help full.
I think the next step could be a separate Module with LCD, SD-Card Slot, etc.
for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many
can you handle at the same time?
I thing i could be a good idea to have the possibility connect to more than
one. The Volt/Ampera has 5 (five!).
Bye
michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are
significant minimum-order-quantities for things like circuit boards, so we
are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have
it, or are waiting for Tesla's solution. So, we're trying to think mostly of
the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's
ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory
Quality issues (particularly soldering) with the factory
Too fiddly to produce and too many components
Too hard to diagnose problems
QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load
Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype
with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor
cables) to the current 1.2 (little white 4pin and 2pin connectors), but
still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware
design. As what we have works so well, there seems little point in making
any dramatic shifts - we've considered switching to a 32bit processor,
built-in touch-screen display, etc - as that would be something completely
different. We just want to incrementally improve the points that are
'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will
contain the controller and SIMCOM GSM/GPRS system in one.
The board external connectors will be exposed through the box. We'll use a
standard DB9 (male), then adaptor cables from that to each car's
requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V.
The existing diag DB9 (female) is unchanged, but should be externally
accessible.
IPC pins to also be externally accessible, so firmware can be updated
without opening the case.
Upgrade the processor from 2680 to 2685. Gives us more flash (useful for
cars other than roadster), but otherwise completely compatible.
Connection of 12V line to microprocessor ADC. This will allow us to measure
supply voltage and take appropriate actions.
Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have
it - this can be powered up/down by AT commands.
LEDs go to the bottom of the board, to be closer to the holes and hence more
visible.
QC and logistics done in china - a partnership with a website there to
handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an
'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster
is covered, and work really well with v1.x hardware. New roadster owners
will be able to use v2.x hardware as well, but there is no point in
'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x
hardware is primarily intended to make it easier so support other types of
cars.
As I mentioned at the top of this email, we're down to the last few v1.x
modules - there was a recent unexpected rush of orders. So, today, we've
taken down the hardware offering at www.openvehicles.com, until the v2.x
hardware arrives. If someone _really_ needs a v1.x module, we still have
some and can let you have it, but we really want to keep as many of the
modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera,
etc) don't worry - we'll look after you and swap you v2.x hardware if
necessary.
We're just now entering prototype stage with the factory, so if anyone has
any comments/suggestions please send them in. I'm working hard on this. So
long as the prototypes are ok, we should have production ready in 4-to-6
weeks.
Regards, Mark.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Interesting browsing: 4x CAN! Mark On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Yeah, the TM VMS is pretty impressive when you start looking through the log files to determine the specs. William On Sun, Jun 10, 2012 at 5:19 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Interesting browsing:
4x CAN!
Mark
On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed<http://www.sparkfun.com/products/9564>which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this <http://www.sparkfun.com/products/11075>.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net
wrote:
Tom,
I kind of think that there are two camps out there:
1. Cheap, simple, just do one function (remote monitoring and control) 2. Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys:
http://www.rechargecar.com/content/first-glimpse-macchina
have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky
to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work.
I think you are on the right way. Dont put to much in it. A loop through
connector for the CAN Bus could be very help full.
I think the next step could be a separate Module with LCD, SD-Card Slot, etc.
for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many
can you handle at the same time?
I thing i could be a good idea to have the possibility connect to more than
one. The Volt/Ampera has 5 (five!).
Bye
michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are
significant minimum-order-quantities for things like circuit boards, so we
are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have
it, or are waiting for Tesla's solution. So, we're trying to think mostly of
the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's
ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory
Quality issues (particularly soldering) with the factory
Too fiddly to produce and too many components
Too hard to diagnose problems
QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load
Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype
with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor
cables) to the current 1.2 (little white 4pin and 2pin connectors), but
still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware
design. As what we have works so well, there seems little point in making
any dramatic shifts - we've considered switching to a 32bit processor,
built-in touch-screen display, etc - as that would be something completely
different. We just want to incrementally improve the points that are
'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will
contain the controller and SIMCOM GSM/GPRS system in one.
The board external connectors will be exposed through the box. We'll use a
standard DB9 (male), then adaptor cables from that to each car's
requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V.
The existing diag DB9 (female) is unchanged, but should be externally
accessible.
IPC pins to also be externally accessible, so firmware can be updated
without opening the case.
Upgrade the processor from 2680 to 2685. Gives us more flash (useful for
cars other than roadster), but otherwise completely compatible.
Connection of 12V line to microprocessor ADC. This will allow us to measure
supply voltage and take appropriate actions.
Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have
it - this can be powered up/down by AT commands.
LEDs go to the bottom of the board, to be closer to the holes and hence more
visible.
QC and logistics done in china - a partnership with a website there to
handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an
'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster
is covered, and work really well with v1.x hardware. New roadster owners
will be able to use v2.x hardware as well, but there is no point in
'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x
hardware is primarily intended to make it easier so support other types of
cars.
As I mentioned at the top of this email, we're down to the last few v1.x
modules - there was a recent unexpected rush of orders. So, today, we've
taken down the hardware offering at www.openvehicles.com, until the v2.x
hardware arrives. If someone _really_ needs a v1.x module, we still have
some and can let you have it, but we really want to keep as many of the
modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera,
etc) don't worry - we'll look after you and swap you v2.x hardware if
necessary.
We're just now entering prototype stage with the factory, so if anyone has
any comments/suggestions please send them in. I'm working hard on this. So
long as the prototypes are ok, we should have production ready in 4-to-6
weeks.
Regards, Mark.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Forgot the link: http://www.olimex.com/dev/lpc-e2294rb.html On 10 Jun, 2012, at 6:19 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Interesting browsing:
4x CAN!
Mark
On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Check here <http://mbed.org/blog/entry/mbed-and-Arduino-shields/>. Cool thing is, the xbee can be replaced with this<http://www.sparkfun.com/products/11047>. And it eats arduino shields. William On Sun, Jun 10, 2012 at 5:25 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Forgot the link:
http://www.olimex.com/dev/lpc-e2294rb.html
[image: image.jpeg]
On 10 Jun, 2012, at 6:19 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Interesting browsing:
4x CAN!
Mark
On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed<http://www.sparkfun.com/products/9564>which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this <http://www.sparkfun.com/products/11075>.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net
wrote:
Tom,
I kind of think that there are two camps out there:
1. Cheap, simple, just do one function (remote monitoring and control) 2. Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys:
http://www.rechargecar.com/content/first-glimpse-macchina
have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky
to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work.
I think you are on the right way. Dont put to much in it. A loop through
connector for the CAN Bus could be very help full.
I think the next step could be a separate Module with LCD, SD-Card Slot, etc.
for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many
can you handle at the same time?
I thing i could be a good idea to have the possibility connect to more than
one. The Volt/Ampera has 5 (five!).
Bye
michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are
significant minimum-order-quantities for things like circuit boards, so we
are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have
it, or are waiting for Tesla's solution. So, we're trying to think mostly of
the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's
ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory
Quality issues (particularly soldering) with the factory
Too fiddly to produce and too many components
Too hard to diagnose problems
QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load
Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype
with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor
cables) to the current 1.2 (little white 4pin and 2pin connectors), but
still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware
design. As what we have works so well, there seems little point in making
any dramatic shifts - we've considered switching to a 32bit processor,
built-in touch-screen display, etc - as that would be something completely
different. We just want to incrementally improve the points that are
'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will
contain the controller and SIMCOM GSM/GPRS system in one.
The board external connectors will be exposed through the box. We'll use a
standard DB9 (male), then adaptor cables from that to each car's
requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V.
The existing diag DB9 (female) is unchanged, but should be externally
accessible.
IPC pins to also be externally accessible, so firmware can be updated
without opening the case.
Upgrade the processor from 2680 to 2685. Gives us more flash (useful for
cars other than roadster), but otherwise completely compatible.
Connection of 12V line to microprocessor ADC. This will allow us to measure
supply voltage and take appropriate actions.
Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have
it - this can be powered up/down by AT commands.
LEDs go to the bottom of the board, to be closer to the holes and hence more
visible.
QC and logistics done in china - a partnership with a website there to
handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an
'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster
is covered, and work really well with v1.x hardware. New roadster owners
will be able to use v2.x hardware as well, but there is no point in
'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x
hardware is primarily intended to make it easier so support other types of
cars.
As I mentioned at the top of this email, we're down to the last few v1.x
modules - there was a recent unexpected rush of orders. So, today, we've
taken down the hardware offering at www.openvehicles.com, until the v2.x
hardware arrives. If someone _really_ needs a v1.x module, we still have
some and can let you have it, but we really want to keep as many of the
modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera,
etc) don't worry - we'll look after you and swap you v2.x hardware if
necessary.
We're just now entering prototype stage with the factory, so if anyone has
any comments/suggestions please send them in. I'm working hard on this. So
long as the prototypes are ok, we should have production ready in 4-to-6
weeks.
Regards, Mark.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
William, Not really familiar with mbed, I take it this won't run linux? The requirement regarding wifi seems to be twofold - for the module to be able to use wifi when in your home garage (low cellular signal, and save money on cellular costs) and for the module to act as a wifi hotspot, sharing it's sim's dataplan. I don't think the xbee replacement will handle that second mode, but it seems pretty cool for the first one (off-loading tcp/ip stack like the simcom does for gprs). Regards, Mark. On 10 Jun, 2012, at 6:42 PM, William Petefish wrote:
Check here. Cool thing is, the xbee can be replaced with this. And it eats arduino shields.
William
On Sun, Jun 10, 2012 at 5:25 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Forgot the link:
http://www.olimex.com/dev/lpc-e2294rb.html
<image.jpeg>
On 10 Jun, 2012, at 6:19 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Interesting browsing:
4x CAN!
Mark
On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
> > Apologies for the length of this eMail, but lots to go through... > > We've come to the end of our initial batch of boards, and there are > significant minimum-order-quantities for things like circuit boards, so we > are taking the opportunity to switch to hardware v2.0. > > The roadster owners who wanted something like this presumably already have > it, or are waiting for Tesla's solution. So, we're trying to think mostly of > the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's > ICE Nissan children ferry. > > The problems we've had with the current hardware include: > > Production reliability issues with the factory > Quality issues (particularly soldering) with the factory > Too fiddly to produce and too many components > Too hard to diagnose problems > QC and Logistics is just a hassle for Sonny and myself - not fun ;-) > > Once we add in using this in other cars, we also get: > > Concerns over 12V battery load > Lack of GPS in some cars > > Things got better as the existing hardware went from 1.0 (initial prototype > with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor > cables) to the current 1.2 (little white 4pin and 2pin connectors), but > still just too much work to get these made. > > Accordingly, what we are trying to do is come up with a v2.0 hardware > design. As what we have works so well, there seems little point in making > any dramatic shifts - we've considered switching to a 32bit processor, > built-in touch-screen display, etc - as that would be something completely > different. We just want to incrementally improve the points that are > 'hurting' now. Keep it a very low cost module that does what it does well. > > Here are the changes we have come up with: > > Change to a single-board approach, made by a single factory. The board will > contain the controller and SIMCOM GSM/GPRS system in one. > The board external connectors will be exposed through the box. We'll use a > standard DB9 (male), then adaptor cables from that to each car's > requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. > The existing diag DB9 (female) is unchanged, but should be externally > accessible. > IPC pins to also be externally accessible, so firmware can be updated > without opening the case. > Upgrade the processor from 2680 to 2685. Gives us more flash (useful for > cars other than roadster), but otherwise completely compatible. > Connection of 12V line to microprocessor ADC. This will allow us to measure > supply voltage and take appropriate actions. > Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have > it - this can be powered up/down by AT commands. > LEDs go to the bottom of the board, to be closer to the holes and hence more > visible. > QC and logistics done in china - a partnership with a website there to > handle order processing and logistics from stock. > > <ovms_v2_layoutdiagram.png> > > I really want to make something very very clear - this is not intended as an > 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster > is covered, and work really well with v1.x hardware. New roadster owners > will be able to use v2.x hardware as well, but there is no point in > 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x > hardware is primarily intended to make it easier so support other types of > cars. > > As I mentioned at the top of this email, we're down to the last few v1.x > modules - there was a recent unexpected rush of orders. So, today, we've > taken down the hardware offering at www.openvehicles.com, until the v2.x > hardware arrives. If someone _really_ needs a v1.x module, we still have > some and can let you have it, but we really want to keep as many of the > modules we have left as repair spares for existing owners. > > For those working with us on OVMS in other cars (Michael on Volt/Ampera, > etc) don't worry - we'll look after you and swap you v2.x hardware if > necessary. > > We're just now entering prototype stage with the factory, so if anyone has > any comments/suggestions please send them in. I'm working hard on this. So > long as the prototypes are ok, we should have production ready in 4-to-6 > weeks. > > Regards, Mark. > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Ok, I'll bite... Anyone know of / can find: - as low power as possible - multiple can - on-board, or option for, wifi - on-board, or option for, GPS - on-board, or option for, GSM GPRS - Linux - 3.5" touch-screen color display Mark On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish@gmail.com> wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Here is what I know in terms of low cost linux boards: http://www.8devices.com/product/3/carambola Dominik On Jun 10, 2012, at 11:52 AM, William Petefish wrote:
I'd say option 2.
I've looked into some processors. The one that the roadster uses in the vms (LPC2294) is a little overkill but it would work as you can load a linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is also a good choice as the best dev kit is the mbed which uses a web-based IDE and is USB natively upgradable. (Note: Both require the MCP2551 or the TJA1048.)
As I remember you can use a serial GLCD w/ SD slot as your display. Something like this.
My $0.02, spend it wisely. William
On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
By the way, does anyone know what the Tattler uses? Any pictures? I'm guessing a development board with CAN, something like those boards on the olimex site. Regards, Mark. On 10 Jun, 2012, at 1:29 PM, Mark Webb-Johnson wrote:
Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
From what scott has said, it runs an embedded linux kernel. The Tattler, again going from what has been said in the past, is using off-the shelf hardware with a custom cable for interfacing with the car. (I'd bet it is a geode w/ serial to CAN and a USB GPRS modem.) Pictures from forum here<http://www.teslamotorsclub.com/showthread.php/5055-New-cell-phone-app-Tesla-Tattler-works-on-all-cell-phones/page9> .
There is one major advantage that the mbed has over other MCUs. Upgrading FW becomes as easy as using a flash drive. The mbed is based on an ARM Cortex-M3 (LPC1768). So, it could run linux. For what it's worth, it would be easy enough to whip up a board to go between the mbed and the simcom board that is in current use. That board could house the CAN transceivers as well. Here <http://mbed.org/handbook/mbed-NXP-LPC1768> is the mbed HW reference. William On Sun, Jun 10, 2012 at 6:36 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
By the way, does anyone know what the Tattler uses? Any pictures? I'm guessing a development board with CAN, something like those boards on the olimex site.
Regards, Mark.
on 6/10/12 4:36 AM, Mark Webb-Johnson wrote:
By the way, does anyone know what the Tattler uses? Any pictures? I'm guessing a development board with CAN, something like those boards on the olimex site.
The Tattler uses this board: http://www.embeddedarm.com/products/board-detail.php?product=TS-7553 Scott was using an SD card to store the OS and the Tattler program, but those cards were getting corrupted. Losing power can corrupt the file system, for example. After mine got completely wedged, Scott redid it to store everything in on-board flash. The OVMS board has been working so well I haven't been very motivated to swap back to the Tattler to try it out. Tom
Tom, That board could do so much more than GSM SMS. Power requirements are a little worrying, though. 3.2watts without modem. OVMS v1 uses about 0.48watts at idle, and 0.96watts worst case - but those are with the modem. Without the modem, probably 1/10th of that. I actually prefer the TS-7552 (same site). A much nicer enclosure, and 4 external USB ports. Also, lower power (can be reduced to 1.7watts). Interestingly, I don't see any option for 12v power via the DB9. I guess Scott modified it by internal patch cable. Regards, Mark. On 10 Jun, 2012, at 11:50 PM, Tom Saxton wrote:
on 6/10/12 4:36 AM, Mark Webb-Johnson wrote:
By the way, does anyone know what the Tattler uses? Any pictures? I'm guessing a development board with CAN, something like those boards on the olimex site.
The Tattler uses this board:
http://www.embeddedarm.com/products/board-detail.php?product=TS-7553
Scott was using an SD card to store the OS and the Tattler program, but those cards were getting corrupted. Losing power can corrupt the file system, for example.
After mine got completely wedged, Scott redid it to store everything in on-board flash. The OVMS board has been working so well I haven't been very motivated to swap back to the Tattler to try it out.
Tom
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
To keep this simple, let's split the requirements into two: Cheap, simple, just do one function (remote monitoring and control) Budget: Around US$100 end-user price Requirements here are: Compatibility with OVMS v1firmware GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line Kitchen sink Budget: tba, but probably in the US$200-US$300 range Requirements here are: Linux base (incompatible with OVMS v1 firmware, so will need a port) As low power consumption as possible Wifi as a client Wifi as a car hotspot GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard With the exception of the multi-can requirement, those seem to meet everyone's needs. Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible. The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1]) For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful. Regards, Mark. On 10 Jun, 2012, at 1:29 PM, Mark Webb-Johnson wrote:
Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Do you See this: http://apc.io/about/ ? Bye Michael Von unterwegs gesendet Am 11.06.2012 um 06:56 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
To keep this simple, let's split the requirements into two:
Cheap, simple, just do one function (remote monitoring and control)
Budget: Around US$100 end-user price
Requirements here are: Compatibility with OVMS v1firmware GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line
Kitchen sink
Budget: tba, but probably in the US$200-US$300 range
Requirements here are: Linux base (incompatible with OVMS v1 firmware, so will need a port) As low power consumption as possible Wifi as a client Wifi as a car hotspot GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard
With the exception of the multi-can requirement, those seem to meet everyone's needs.
Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible.
The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1])
For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful.
Regards, Mark.
On 10 Jun, 2012, at 1:29 PM, Mark Webb-Johnson wrote:
Tom,
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control) Kitchen sink (touch LCD, wifi hotspot, etc)
While Sonny and I have looked at 32bit embedded processors, including the PIC and ARM varieties, it feels like half way between the two camps. It will give us more than [1], but can't really do the more advanced things that [2] can do.
We already know that [1] comes in around US$100 in the quantities we are talking about. I've seen [2] around US$200-US$300. My biggest concern with [2] is power requirements to keep the thing running when the vehicle is off - not so much a concern for the roadster, but a big issue for little lead-acid 12V battery based systems.
In an ideal world, I'd go for camp [3], rip out the pos Alpine and replace it with a double-din in-car-computer that does the job better for 1/3rd the price - can you imaging having a 7" display with exactly what we want, as well as 3G hotspot, OVMS remote control and decent navigation? Sadly, I just don't have the free time and the power requirements are truly terrifying [not to mention the fear of what the Tesla engineer would say next time I took it in for warranty repair / service] :-( I do hold out hope that Tesla will allow us to run some powerful apps on the model S / X displays, but I'm a realist and am not holding my breath.
There is another interesting approach - Arduino. These guys: http://www.rechargecar.com/content/first-glimpse-macchina have approached us, and there may be an interesting partnership there. I really like the way they work. Very focussed and in the EV community. They are more into the hardware side of things, and are looking for open source software partners - exactly the opposite of us, and very complementary. I think they signed up for this list, and perhaps can comment here (or maybe too early, but the product is up on their website, so I guess no harm mentioning it)?
The reason we initially kept away from Arduino was cost. We were fixated on <US$100 all-in, and to meet that we had to keep things simple and well-and-truly in the [1] camp.
Regards, Mark.
P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18 combination is cheap and simple as hell. It would not be hard to just put multiple microprocessors in their, each handling decoding of their own bus, and multiplexing it all back to the main controller on an I2C style bus. Not elegant, but very expandable :-)
On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
Cathy and I went to a tech/sales seminar from ST Micro. They have a line of 32-bit ARM chips that includes chips with support for 2 CAN buses, the first I've seen.
http://www.st.com/internet/mcu/subclass/1169.jsp
The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line adds Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit pricing for the STM32F105 chips in the $4 to $10 range.
The tools story is not awesome. Although there was some mention of GCC, it's not clear to me that there are quality, free tools available.
Tom
on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
What about Rasberrypi? http://www.raspberrypi.org/faqs Regards Pierre _____ Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Montag, 11. Juni 2012 06:56 An: OVMS Developers Betreff: Re: [Ovmsdev] OVMS Hardware v2.0 To keep this simple, let's split the requirements into two: 1. Cheap, simple, just do one function (remote monitoring and control) Budget: Around US$100 end-user price Requirements here are: * Compatibility with OVMS v1firmware * GPS as well as the current GPRS * Easier to manufacture, QC and support * Monitoring of the 12V line 2. Kitchen sink Budget: tba, but probably in the US$200-US$300 range Requirements here are: * Linux base (incompatible with OVMS v1 firmware, so will need a port) * As low power consumption as possible * Wifi as a client * Wifi as a car hotspot * GPS as well as the current GPRS * Easier to manufacture, QC and support * Monitoring of the 12V line * Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard With the exception of the multi-can requirement, those seem to meet everyone's needs. Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible. The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1]) For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful. Regards, Mark.
I don't think that the rasbrrypi will work. The controller/sbc has to have CAN bus. William On Mon, Jun 11, 2012 at 5:57 PM, Pierre Uhl <pi.uhl@bluewin.ch> wrote:
**
What about Rasberrypi?****
** **
http://www.raspberrypi.org/faqs****
** **
Regards****
** **
Pierre****
** ** ------------------------------
*Von:* **ovmsdev-bounces@lists.teslaclub.hk** [mailto:** ovmsdev-bounces@lists.teslaclub.hk**] *Im Auftrag von *Mark Webb-Johnson *Gesendet:* Montag, 11. Juni 2012 06:56 *An:* OVMS Developers *Betreff:* Re: [Ovmsdev] OVMS Hardware v2.0****
** **
** **
To keep this simple, let's split the requirements into two:****
** **
1. Cheap, simple, just do one function (remote monitoring and control)
Budget: Around US$100 end-user price
Requirements here are:****
- Compatibility with OVMS v1firmware**** - GPS as well as the current GPRS**** - Easier to manufacture, QC and support**** - Monitoring of the 12V line****
1. Kitchen sink
Budget: tba, but probably in the US$200-US$300 range
Requirements here are:****
- Linux base (incompatible with OVMS v1 firmware, so will need a port) **** - As low power consumption as possible**** - Wifi as a client**** - Wifi as a car hotspot**** - GPS as well as the current GPRS**** - Easier to manufacture, QC and support**** - Monitoring of the 12V line**** - Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard****
** **
With the exception of the multi-can requirement, those seem to meet everyone's needs.****
** **
Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible.****
** **
The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1])****
** **
For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful.****
** **
Regards, Mark.****
** **
** **
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Has anybody get one? I still waiting for mine. Signed in since month. Bye michael Am 12.06.2012 um 01:22 schrieb William Petefish:
I don't think that the rasbrrypi will work. The controller/sbc has to have CAN bus.
William
On Mon, Jun 11, 2012 at 5:57 PM, Pierre Uhl <pi.uhl@bluewin.ch> wrote: What about Rasberrypi?
http://www.raspberrypi.org/faqs
Regards
Pierre
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Montag, 11. Juni 2012 06:56 An: OVMS Developers Betreff: Re: [Ovmsdev] OVMS Hardware v2.0
To keep this simple, let's split the requirements into two:
Cheap, simple, just do one function (remote monitoring and control)
Budget: Around US$100 end-user price
Requirements here are: Compatibility with OVMS v1firmware GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line Kitchen sink
Budget: tba, but probably in the US$200-US$300 range
Requirements here are: Linux base (incompatible with OVMS v1 firmware, so will need a port) As low power consumption as possible Wifi as a client Wifi as a car hotspot GPS as well as the current GPRS Easier to manufacture, QC and support Monitoring of the 12V line Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard
With the exception of the multi-can requirement, those seem to meet everyone's needs.
Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible.
The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1])
For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I got mine ... actually I got 2 one from Farnell and one from RS ;-) Dominik On Jun 12, 2012, at 9:58 AM, Michael Jochum wrote:
Has anybody get one? I still waiting for mine. Signed in since month.
Bye michael
Am 12.06.2012 um 01:22 schrieb William Petefish:
I don't think that the rasbrrypi will work. The controller/sbc has to have CAN bus.
William
On Mon, Jun 11, 2012 at 5:57 PM, Pierre Uhl <pi.uhl@bluewin.ch> wrote: What about Rasberrypi?
http://www.raspberrypi.org/faqs
Regards
Pierre
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Montag, 11. Juni 2012 06:56 An: OVMS Developers Betreff: Re: [Ovmsdev] OVMS Hardware v2.0
To keep this simple, let's split the requirements into two:
• Cheap, simple, just do one function (remote monitoring and control)
Budget: Around US$100 end-user price
Requirements here are: • Compatibility with OVMS v1firmware • GPS as well as the current GPRS • Easier to manufacture, QC and support • Monitoring of the 12V line • Kitchen sink
Budget: tba, but probably in the US$200-US$300 range
Requirements here are: • Linux base (incompatible with OVMS v1 firmware, so will need a port) • As low power consumption as possible • Wifi as a client • Wifi as a car hotspot • GPS as well as the current GPRS • Easier to manufacture, QC and support • Monitoring of the 12V line • Optional little 3.5" - 5" touch display, in a housing, to go up on the dashboard
With the exception of the multi-can requirement, those seem to meet everyone's needs.
Irrespective of what happens with [2], I still think we need [1]. That is the base requirement to get OVMS in a car, and needs to be as cheap and simple as possible.
The big question is, does anyone see a need for [2] (the kitchen sink)? (if necessary, trying to put aside that you already have [1])
For me personally, doing development on this, I really like the idea of [2], and would be willing to spend the money. To be able to directly ssh to the car and get access to the can bus would be extremely useful for development, and firmware updates could be done over the air (either GPRS cellular or WIFI). I have lousy cellular coverage at home, and the car being able to switch to wifi would be really useful.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Mark, my idea is to have a "Master" Module with all the function in it. And one or more "Slaves". The smallest possible µP with CAN. These Module only receive the CAN Data from one Bus and sends only the necessary (filtered) to the Master (I2C, TWI,....). For Tesla only the Master. For Volt/Ampera up to 4 Slaves, depending what we need/found. ;-) The Hardware for the slaves are every time the same, different only in Software. Very small. No Power Unit, only µC, Transceiver and sub-d Connector. Backpack on the Master. Bye Michael Am 09.06.2012 um 16:55 schrieb Mark Webb-Johnson:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
Concerns over 12V battery load Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png>
I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Overkill would be a BeagleBone <http://beagleboard.org/bone>. Although, I think that I may be able to talk with CircuitCO about a BeagleBone cape for the OVMS. (or at least they'd be willing to work with us for assembly.) BeagleBone has 2xCAN, USB Host (for wifi if we want), UART i/o, display out capability, and still has GPIOs left over for other things. Best of all it fits in the current box. Extreme overkill would be the PandaBoard. Onboard wifi, Runs Linux, display out capability, and room for expansion. (no CAN though, but able to be added later through add-on module.) William On Sat, Jun 9, 2012 at 2:47 PM, Michael Jochum <mikeljo@me.com> wrote:
Hi Mark,
my idea is to have a "Master" Module with all the function in it. And one or more "Slaves". The smallest possible µP with CAN. These Module only receive the CAN Data from one Bus and sends only the necessary (filtered) to the Master (I2C, TWI,....). For Tesla only the Master. For Volt/Ampera up to 4 Slaves, depending what we need/found. ;-) The Hardware for the slaves are every time the same, different only in Software. Very small. No Power Unit, only µC, Transceiver and sub-d Connector. Backpack on the Master.
Bye Michael
Am 09.06.2012 um 16:55 schrieb Mark Webb-Johnson:
Michael,
We can only connect to one CAN bus at the moment. I think it is quite tricky to do more, as most of the chips I can find have only 1 ECAN module.
Regards, Mark.
On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
Hi,
nice work. I think you are on the right way. Dont put to much in it. A loop through connector for the CAN Bus could be very help full. I think the next step could be a separate Module with LCD, SD-Card Slot, etc. for showing and Logging live Data.
One Thing: to how many CAN Buses can you simultaneously connect to? How many can you handle at the same time? I thing i could be a good idea to have the possibility connect to more than one. The Volt/Ampera has 5 (five!).
Bye michael
Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
Apologies for the length of this eMail, but lots to go through...
We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0.
The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry.
The problems we've had with the current hardware include:
- Production reliability issues with the factory - Quality issues (particularly soldering) with the factory - Too fiddly to produce and too many components - Too hard to diagnose problems - QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
Once we add in using this in other cars, we also get:
- Concerns over 12V battery load - Lack of GPS in some cars
Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made.
Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well.
Here are the changes we have come up with:
1. Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. 2. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. 3. The existing diag DB9 (female) is unchanged, but should be externally accessible. 4. IPC pins to also be externally accessible, so firmware can be updated without opening the case. 5. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. 6. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. 7. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. 8. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. 9. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock.
<ovms_v2_layoutdiagram.png> * * I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars.
As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners.
For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary.
We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (7)
-
Dominik Westner -
Mark Webb-Johnson -
Michael Jochum -
Michael Jochum -
Pierre Uhl -
Tom Saxton -
William Petefish