I've released firmware v2.2.2 to the github repository. The change log is as follows: 2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1 The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters. Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter. Regards, Mark.
Mark, Nikolay, I just checked in a new Twizy release (2.6). I had to introduce a second overlay section, as my variables now exceed the 256 byte section limit of the C18 linker. There seems to be another solution configuring the linker to assign fixed addresses and sizes to sections, but that doesn't seem to be necessary. There is no RAM loss from the section split. Nevertheless, this needs to be known to other vehicle implementors (Nikolay) as well: if your variables exceed 256 bytes, distribute them over two sections. The second overlay section is addressed using: #pragma udata overlay vehicle_overlay_data2 Sections can be switched as needed, I'm currently assigning my battery vars to "data2". This leads me to another issue: precompiled firmware images... I would like to point users to www.openvehicles.com for all updates, but the "firmware" page links to another site with no Twizy images at all. ("User guide" btw also just links to the Tesla guide...) I would also like to provide full featured firmware versions, including the battery monitoring. Mark, as RAM usage has proven to be non-critical, could you include the feature by default now? If you're still in doubt, maybe we could define "V2_Production" as "without battmon" and include it only in "V2_Experimental"? Regards, Michael Am 13.01.2013 09:29, schrieb Mark Webb-Johnson:
I've released firmware v2.2.2 to the github repository. The change log is as follows:
2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1
The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters.
Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, I'll update the developers guide with vehicle_overlay_data2. For the battery monitor stuff, give me a few days to have a look at ram usage. I agree it is not causing crashes, but we need to make sure we have enough free for future expansion. For the firmware, Tom Saxton stepped forward some time ago and handled this for us. I think he is on this mailing list. He owns a Tesla, but also a Leaf (and still other EVs? RAV4?). Tom: Do you want to continue with this, and if so, can you help? The requirement is to make the firmware upgrade / download page cover all the supported vehicles. For the user guide, I think it best to restructure as we discussed in recent eMails. We'll split to have a single common user guide (concerning setup), then individual vehicle guides covering installation in specific vehicles and anything else vehicle specific. Or is it better to just have one guide covering everything? Regards, Mark. On 14 Jan, 2013, at 9:45 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, Nikolay,
I just checked in a new Twizy release (2.6). I had to introduce a second overlay section, as my variables now exceed the 256 byte section limit of the C18 linker. There seems to be another solution configuring the linker to assign fixed addresses and sizes to sections, but that doesn't seem to be necessary. There is no RAM loss from the section split. Nevertheless, this needs to be known to other vehicle implementors (Nikolay) as well: if your variables exceed 256 bytes, distribute them over two sections. The second overlay section is addressed using:
#pragma udata overlay vehicle_overlay_data2
Sections can be switched as needed, I'm currently assigning my battery vars to "data2".
This leads me to another issue: precompiled firmware images...
I would like to point users to www.openvehicles.com for all updates, but the "firmware" page links to another site with no Twizy images at all. ("User guide" btw also just links to the Tesla guide...)
I would also like to provide full featured firmware versions, including the battery monitoring. Mark, as RAM usage has proven to be non-critical, could you include the feature by default now? If you're still in doubt, maybe we could define "V2_Production" as "without battmon" and include it only in "V2_Experimental"?
Regards, Michael
Am 13.01.2013 09:29, schrieb Mark Webb-Johnson:
I've released firmware v2.2.2 to the github repository. The change log is as follows:
2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1
The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters.
Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The firmware update guide page now has version 2.2.2 builds up. http://www.idleloop.com/tesla/ovms/ Tom
Thanks, Tom! Hm... to optimize the rollout, have you tried to link directly to the repository files? The links in vehicle/firmware don't work, but using the github file browser I can get for example... https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/... I'm new to github, but that URL scheme looks like being designed as a permanent link. Regards, Michael Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status. The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well. Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort). Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve. Tom on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/... MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I think this approach is ok, and given github's approach probably the best way. I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history. I've got a git guru on staff here at work - I'll ask him for his advise. Regards, Mark. On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/... MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ 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 think I may have a solution for this (going forward). If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see: https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle... And an example link to the v2.2.2 V2 production firmware is: https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/... That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release: Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version What do people think? Sensible? Regards, Mark. On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/... MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ 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
The idea of permanent links sounds great, but now I'm confused. I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example, vehicle/OVMS.X/dist/RT_V2_Experimental Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle. Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on? Tom on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle... irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/... rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle /OV MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ 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
Tom, For firmware v2.x builds, there are now just 4: V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command). It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark. On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle... irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/... rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle /OV MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton:
The firmware update guide page now has version 2.2.2 builds up.
http://www.idleloop.com/tesla/ovms/
Tom
_______________________________________________ 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
Go it! The firmware update page is now updated with links straight to the github files, with the note to Roadster owners as well as the link to the release notes. Is Twizzy and Volt support built into the V2 hardware production build, or just the experimental? I'm just wondering if I need to direct those owners to one build or the other. Tom on 1/16/13 7:53 PM, Mark Webb-Johnson wrote:
Tom,
For firmware v2.x builds, there are now just 4:
V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware
A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command).
It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle /f irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/ fi rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
Thanks, Tom!
Hm... to optimize the rollout, have you tried to link directly to the repository files?
The links in vehicle/firmware don't work, but using the github file browser I can get for example...
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehic le /OV MS.X/dist/V2_Experimental/production/OVMS.X.production.hex
I'm new to github, but that URL scheme looks like being designed as a permanent link.
Regards, Michael
Am 14.01.2013 21:13, schrieb Tom Saxton: > The firmware update guide page now has version 2.2.2 builds up. > > http://www.idleloop.com/tesla/ovms/ > > Tom > > > _______________________________________________ > 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
Tom, Looks good. The V1 firmware (both experimental and production) only contains vehicle_none and vehicle_roadster. The V2 firmware (both experimental and production) contains all supported vehicles. So, no need to direct owners to particular builds. Note that in future we may need to split the V2 firmware into vehicle groups (eg; V2_production_group1, V2_production_group2, etc) if we run out of code space due to too many vehicles being supported - but that would be a good place to be at :-) For current level of vehicle support, you can refer to: http://www.openvehicles.com/vehiclesupport The difference between experimental and production is currently only that experimental includes the Tesla Roadster v2.x digital speedo code. Regards, Mark. P.S. I've removed those old firmware .hex files (VA_*, TR_*, RT_*, etc). I'm also going to .gitignore the vehicle/OVMS.x/dist tree entirely, to stop future confusion, and rely on manual copy to vehicle/firmware when we actually release. On 17 Jan, 2013, at 1:33 PM, Tom Saxton wrote:
Go it! The firmware update page is now updated with links straight to the github files, with the note to Roadster owners as well as the link to the release notes.
Is Twizzy and Volt support built into the V2 hardware production build, or just the experimental? I'm just wondering if I need to direct those owners to one build or the other.
Tom
on 1/16/13 7:53 PM, Mark Webb-Johnson wrote:
Tom,
For firmware v2.x builds, there are now just 4:
V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware
A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command).
It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle /f irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/ fi rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
> Thanks, Tom! > > Hm... to optimize the rollout, have you tried to link directly to the > repository files? > > The links in vehicle/firmware don't work, but using the github file > browser I can get for example... > > https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehic > le > /OV > MS.X/dist/V2_Experimental/production/OVMS.X.production.hex > > I'm new to github, but that URL scheme looks like being designed as a > permanent link. > > Regards, > Michael > > > Am 14.01.2013 21:13, schrieb Tom Saxton: >> The firmware update guide page now has version 2.2.2 builds up. >> >> http://www.idleloop.com/tesla/ovms/ >> >> Tom >> >> >> _______________________________________________ >> 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
That's all great. I've updated the firmware page to include a link to the OVMS Vehicle Support page. I notice that the vehicle support matrix says that Digital Speedo is "Yes" on Roadster v1.x and "Not Yet" on 2.x. Shouldn't it be "No" for 1.x? Tom on 1/16/13 9:53 PM, Mark Webb-Johnson wrote:
Tom,
Looks good.
The V1 firmware (both experimental and production) only contains vehicle_none and vehicle_roadster. The V2 firmware (both experimental and production) contains all supported vehicles.
So, no need to direct owners to particular builds. Note that in future we may need to split the V2 firmware into vehicle groups (eg; V2_production_group1, V2_production_group2, etc) if we run out of code space due to too many vehicles being supported - but that would be a good place to be at :-)
For current level of vehicle support, you can refer to: http://www.openvehicles.com/vehiclesupport
The difference between experimental and production is currently only that experimental includes the Tesla Roadster v2.x digital speedo code.
Regards, Mark.
P.S. I've removed those old firmware .hex files (VA_*, TR_*, RT_*, etc). I'm also going to .gitignore the vehicle/OVMS.x/dist tree entirely, to stop future confusion, and rely on manual copy to vehicle/firmware when we actually release.
On 17 Jan, 2013, at 1:33 PM, Tom Saxton wrote:
Go it! The firmware update page is now updated with links straight to the github files, with the note to Roadster owners as well as the link to the release notes.
Is Twizzy and Volt support built into the V2 hardware production build, or just the experimental? I'm just wondering if I need to direct those owners to one build or the other.
Tom
on 1/16/13 7:53 PM, Mark Webb-Johnson wrote:
Tom,
For firmware v2.x builds, there are now just 4:
V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware
A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command).
It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehic le /f irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicl e/ fi rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
> That directory structure changes about as often as there are new > official > releases, as you can tell by all of the orphan build directories. > Linking > straight into the repository won't let me pick up new vehicles, and will > break when vehicles go from "experimental" to "production" status. > > The release notes aren't in the repository (AFAIK), so I have to enter > those > links manually as well. > > Given that I have to manually update the page, I figure it's more > reliable > to ferret out the right versions for each vehicle and copy them to my > site. > This way, my page keeps working even if the repository changes, which > means > less work maintaining the page between releases (which is currently zero > effort). > > Anyone who's really into getting the latest builds can just grab the > files > from the repository. My page is to support those who don't care enough > to > climb that learning curve. > > Tom > > on 1/14/13 1:23 PM, Michael Balzer wrote: > >> Thanks, Tom! >> >> Hm... to optimize the rollout, have you tried to link directly to the >> repository files? >> >> The links in vehicle/firmware don't work, but using the github file >> browser I can get for example... >> >> https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/veh >> ic >> le >> /OV >> MS.X/dist/V2_Experimental/production/OVMS.X.production.hex >> >> I'm new to github, but that URL scheme looks like being designed as a >> permanent link. >> >> Regards, >> Michael >> >> >> Am 14.01.2013 21:13, schrieb Tom Saxton: >>> The firmware update guide page now has version 2.2.2 builds up. >>> >>> http://www.idleloop.com/tesla/ovms/ >>> >>> Tom >>> >>> >>> _______________________________________________ >>> 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
I notice that the vehicle support matrix says that Digital Speedo is "Yes" on Roadster v1.x and "Not Yet" on 2.x. Shouldn't it be "No" for 1.x?
Fixed. Regards, Mark. On 17 Jan, 2013, at 2:09 PM, Tom Saxton wrote:
That's all great. I've updated the firmware page to include a link to the OVMS Vehicle Support page.
I notice that the vehicle support matrix says that Digital Speedo is "Yes" on Roadster v1.x and "Not Yet" on 2.x. Shouldn't it be "No" for 1.x?
Tom
on 1/16/13 9:53 PM, Mark Webb-Johnson wrote:
Tom,
Looks good.
The V1 firmware (both experimental and production) only contains vehicle_none and vehicle_roadster. The V2 firmware (both experimental and production) contains all supported vehicles.
So, no need to direct owners to particular builds. Note that in future we may need to split the V2 firmware into vehicle groups (eg; V2_production_group1, V2_production_group2, etc) if we run out of code space due to too many vehicles being supported - but that would be a good place to be at :-)
For current level of vehicle support, you can refer to: http://www.openvehicles.com/vehiclesupport
The difference between experimental and production is currently only that experimental includes the Tesla Roadster v2.x digital speedo code.
Regards, Mark.
P.S. I've removed those old firmware .hex files (VA_*, TR_*, RT_*, etc). I'm also going to .gitignore the vehicle/OVMS.x/dist tree entirely, to stop future confusion, and rely on manual copy to vehicle/firmware when we actually release.
On 17 Jan, 2013, at 1:33 PM, Tom Saxton wrote:
Go it! The firmware update page is now updated with links straight to the github files, with the note to Roadster owners as well as the link to the release notes.
Is Twizzy and Volt support built into the V2 hardware production build, or just the experimental? I'm just wondering if I need to direct those owners to one build or the other.
Tom
on 1/16/13 7:53 PM, Mark Webb-Johnson wrote:
Tom,
For firmware v2.x builds, there are now just 4:
V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware
A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command).
It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehic le /f irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicl e/ fi rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
> > I think this approach is ok, and given github's approach probably the > best > way. > > I really wish that github had a 'files' repository (like sourceforge) > that > we > could put fixed (not revision controlled) files. Release, not > development, > files. I tried to create symlinks (in the 'firmware' folder), but they > don't > work (the symlink text file is just downloaded, not the thing it linked > to), > and anyway that doesn't give us history. > > I've got a git guru on staff here at work - I'll ask him for his advise. > > Regards, Mark. > > On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote: > >> That directory structure changes about as often as there are new >> official >> releases, as you can tell by all of the orphan build directories. >> Linking >> straight into the repository won't let me pick up new vehicles, and will >> break when vehicles go from "experimental" to "production" status. >> >> The release notes aren't in the repository (AFAIK), so I have to enter >> those >> links manually as well. >> >> Given that I have to manually update the page, I figure it's more >> reliable >> to ferret out the right versions for each vehicle and copy them to my >> site. >> This way, my page keeps working even if the repository changes, which >> means >> less work maintaining the page between releases (which is currently zero >> effort). >> >> Anyone who's really into getting the latest builds can just grab the >> files >> from the repository. My page is to support those who don't care enough >> to >> climb that learning curve. >> >> Tom >> >> on 1/14/13 1:23 PM, Michael Balzer wrote: >> >>> Thanks, Tom! >>> >>> Hm... to optimize the rollout, have you tried to link directly to the >>> repository files? >>> >>> The links in vehicle/firmware don't work, but using the github file >>> browser I can get for example... >>> >>> https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/veh >>> ic >>> le >>> /OV >>> MS.X/dist/V2_Experimental/production/OVMS.X.production.hex >>> >>> I'm new to github, but that URL scheme looks like being designed as a >>> permanent link. >>> >>> Regards, >>> Michael >>> >>> >>> Am 14.01.2013 21:13, schrieb Tom Saxton: >>>> The firmware update guide page now has version 2.2.2 builds up. >>>> >>>> http://www.idleloop.com/tesla/ovms/ >>>> >>>> Tom >>>> >>>> >>>> _______________________________________________ >>>> 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
I've been running v2.2.2 in my car for a week now, and I've gotta say that this seems to be the most stable OVMS firmware I've seen to date. My car's connection to the server has been rock-solid (only one GPRS re-connection due to poor cellular coverage), and zero module reboots. An average of about 10KB of cellular data a day (an all-time low). I'd like to give a big public thanks to Michael Balzer for all his hard work on this (and the v2 framework in general). His DebugCrash diagnostics, and re-working of the sprintf calls to his own library routines, seems to have nailed those strange random module reboots we were seeing. Thanks, Michael - most appreciated. Rollout of this version has been slow. On the TMC server, today, there are just 6 cars running v2.x code. I really would like to encourage people to upgrade to this version, to let us get more data on it - you'll hopefully also get the benefit of more stability, lower cellular data usage, and a few bugs have been fixed since v1.5.1. Regards, Mark. On 13 Jan, 2013, at 4:29 PM, Mark Webb-Johnson wrote:
I've released firmware v2.2.2 to the github repository. The change log is as follows:
2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1
The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters.
Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
My pleasure, really :-) And I would've been stranded right away without your great support, Mark. Thanks! Michael Am 17.01.2013 02:22, schrieb Mark Webb-Johnson:
I've been running v2.2.2 in my car for a week now, and I've gotta say that this seems to be the most stable OVMS firmware I've seen to date. My car's connection to the server has been rock-solid (only one GPRS re-connection due to poor cellular coverage), and zero module reboots. An average of about 10KB of cellular data a day (an all-time low).
I'd like to give a big public thanks to Michael Balzer for all his hard work on this (and the v2 framework in general). His DebugCrash diagnostics, and re-working of the sprintf calls to his own library routines, seems to have nailed those strange random module reboots we were seeing. Thanks, Michael - most appreciated.
Rollout of this version has been slow. On the TMC server, today, there are just 6 cars running v2.x code. I really would like to encourage people to upgrade to this version, to let us get more data on it - you'll hopefully also get the benefit of more stability, lower cellular data usage, and a few bugs have been fixed since v1.5.1.
Regards, Mark.
On 13 Jan, 2013, at 4:29 PM, Mark Webb-Johnson wrote:
I've released firmware v2.2.2 to the github repository. The change log is as follows:
2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1
The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters.
Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
participants (4)
-
Mark Webb-Johnson -
Mark Webb-Johnson -
Michael Balzer -
Tom Saxton