China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? I plan to cut release candidate for 2.3.1 on Sunday. Regards, Mark.
I've not got any more bugs to report here. Sent from my iPhone On 11 Apr 2013, at 15:41, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, Nikki, I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. Nikki, I attached the latest version in case you'd like to test as well. Regards, Michael Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-( Regards, Michael Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
No worries Michael. Let me know when you have a stable version for me to test. The next big drive for me is Monday (I have the leaf today for an 80 mile trip but the twizy is only doing 15!) Sent from my iPhone On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- 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
Michael, Any new firmware for me to test this weekend? Nikki. On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- 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
Nikki, yes, see attachment. I could not make out any possible source of that strange error I had yesterday (completely garbled data). I made a clean build with a freshly started MPLAB and got no errors up to now. May have been something completely different, not related to my last changes. Regards, Michael Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- 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 <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
Mark, I just checked in my latest changes. In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look. I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one. Regards, Michael Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- 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 <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
_______________________________________________ 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
Am 12.04.2013 20:51, schrieb Michael Balzer:
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function?
...I see, it's got support for thousands separators. So it's meant especially for human readable formatting. The comment could be clearer on this ;-) Support for negative values could be useful. Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
For the moment, we've renamed the human-readable function stp_l2f_h() and both co-exist. Long-term we'll try to merge stp_l2f_h() and stp_l2f(), or just formalise and have both _h() and normal versions of the functions. Regards, Mark. On 13 Apr, 2013, at 6:31 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 12.04.2013 20:51, schrieb Michael Balzer:
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function?
...I see, it's got support for thousands separators.
So it's meant especially for human readable formatting. The comment could be clearer on this ;-)
Support for negative values could be useful.
Regards, Michael
-- 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
All seems ok. I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server). I've just flashed and it will go in my car tomorrow. Regards, Mark On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
-- 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
_______________________________________________ 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
_______________________________________________ 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
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China. It is in my car now, and seems ok. I'll do more testing tomorrow. I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems. Regards, Mark. On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday.
Nikki, I attached the latest version in case you'd like to test as well.
Regards, Michael
Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: > China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. > > I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. > > Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? > > I plan to cut release candidate for 2.3.1 on Sunday. > > 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
-- 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
_______________________________________________ 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
_______________________________________________ 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
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Does this incorporate the twizy fork? Sent from my iPhone On 14 Apr 2013, at 15:29, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer: > Mark, Nikki, > > I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. > > Nikki, I attached the latest version in case you'd like to test as well. > > Regards, > Michael > > > Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >> China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. >> >> I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. >> >> Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? >> >> I plan to cut release candidate for 2.3.1 on Sunday. >> >> 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
-- 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
_______________________________________________ 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
_______________________________________________ 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
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
Mark, I've got the last but one version in my car, just lacking the new VEHICLE commands. I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion. But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect: MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61 As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values). As the module behaves weird afterwards I suppose more variables have been corrupted. I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well? I'll continue checking the source for possible buffer overruns... Regards, Michael Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-(
Regards, Michael
Am 11.04.2013 19:22, schrieb Michael Balzer: > Mark, Nikki, > > I'm currently trying to fix a last bug with the power statistics > (the distance counter still went wrong), and I'm trying to get > the 12V A/D conversion to work without these strange "peaks" by > raising the automatic acquisition time. I will finish testing > this ASAP or tell you in time before sunday. > > Nikki, I attached the latest version in case you'd like to test > as well. > > Regards, > Michael > > > Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >> China is bugging me for final firmware for the next batch of >> hardware. I need to get them this early next week. >> >> I've committed what I need for the Tesla Roadster (and >> framework). Last outstanding small change to make is to send >> CAC as 999.99, rather than the current 99999, using Tom's new >> library function. >> >> Michael B & J: can you check Twizzy and Volt/Ampera, to see if >> everything is ok with current firmware or there is anything you >> need changed? >> >> I plan to cut release candidate for 2.3.1 on Sunday. >> >> 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
-- 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 <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
_______________________________________________ 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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption. Am 14.04.2013 17:54, schrieb Michael Balzer:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
> I think I was a bit too fast on this, Nikki, don't use that > version, it seems to have some new bug causing frequent > crashes... :-( > > Regards, > Michael > > > Am 11.04.2013 19:22, schrieb Michael Balzer: >> Mark, Nikki, >> >> I'm currently trying to fix a last bug with the power >> statistics (the distance counter still went wrong), and I'm >> trying to get the 12V A/D conversion to work without these >> strange "peaks" by raising the automatic acquisition time. I >> will finish testing this ASAP or tell you in time before sunday. >> >> Nikki, I attached the latest version in case you'd like to test >> as well. >> >> Regards, >> Michael >> >> >> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>> China is bugging me for final firmware for the next batch of >>> hardware. I need to get them this early next week. >>> >>> I've committed what I need for the Tesla Roadster (and >>> framework). Last outstanding small change to make is to send >>> CAC as 999.99, rather than the current 99999, using Tom's new >>> library function. >>> >>> Michael B & J: can you check Twizzy and Volt/Ampera, to see if >>> everything is ok with current firmware or there is anything >>> you need changed? >>> >>> I plan to cut release candidate for 2.3.1 on Sunday. >>> >>> 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 > > -- > 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 <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
_______________________________________________ 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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
_______________________________________________ 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
Just a head up: I flashed my Twizy firmware and it immediately started working. I flashed Kevin's firmware on his Roadster, and it took about 10 minutes to start working. Not sure why -- but thought you'd all appreciate the report. :) I've got a 35 mile round-trip tonight to Bath, and about 120 miles of work-related travel this week in the Twizy, so plenty of time to test it! Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki@littleCollie.com tel: +44 7901 553308 On 14 Apr 2013, at 17:04, Michael Balzer <dexter@expeedo.de> wrote:
I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption.
Am 14.04.2013 17:54, schrieb Michael Balzer:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: > Michael, > > Any new firmware for me to test this weekend? > > Nikki. > > On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote: > >> I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-( >> >> Regards, >> Michael >> >> >> Am 11.04.2013 19:22, schrieb Michael Balzer: >>> Mark, Nikki, >>> >>> I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. >>> >>> Nikki, I attached the latest version in case you'd like to test as well. >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>>> China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. >>>> >>>> I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. >>>> >>>> Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? >>>> >>>> I plan to cut release candidate for 2.3.1 on Sunday. >>>> >>>> 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 >> >> -- >> 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 > > > > _______________________________________________ > 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
_______________________________________________ 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
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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
I also had the perl client running in a loop to log all data. I found the bug occured both times just after a perl client restart. That could mean the "peer connected" reaction (net_msg.c line 660) could somehow be involved, or -- as my perl client copy also sends a command 41 to query the SIM account balance -- the USSD handling could be the source of the bug. I'm pretty sure it's the USSD reply handling. It's not completely well coded yet (sorry!), and it could behave bad in a situation with much regular data traffic going on... and that again matches. I'll fix this ASAP, but I can't fix it now (too late). As triggering this bug seems to be unlikely, I would not consider this a problem for the release. Regards, Michael PS: I checked in the A/D converter change though, that seems to solve the 12V readings! Am 14.04.2013 18:04, schrieb Michael Balzer:
I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption.
Am 14.04.2013 17:54, schrieb Michael Balzer:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: > Michael, > > Any new firmware for me to test this weekend? > > Nikki. > > On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de > <mailto:dexter@expeedo.de>> wrote: > >> I think I was a bit too fast on this, Nikki, don't use that >> version, it seems to have some new bug causing frequent >> crashes... :-( >> >> Regards, >> Michael >> >> >> Am 11.04.2013 19:22, schrieb Michael Balzer: >>> Mark, Nikki, >>> >>> I'm currently trying to fix a last bug with the power >>> statistics (the distance counter still went wrong), and I'm >>> trying to get the 12V A/D conversion to work without these >>> strange "peaks" by raising the automatic acquisition time. I >>> will finish testing this ASAP or tell you in time before sunday. >>> >>> Nikki, I attached the latest version in case you'd like to >>> test as well. >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>>> China is bugging me for final firmware for the next batch of >>>> hardware. I need to get them this early next week. >>>> >>>> I've committed what I need for the Tesla Roadster (and >>>> framework). Last outstanding small change to make is to send >>>> CAC as 999.99, rather than the current 99999, using Tom's new >>>> library function. >>>> >>>> Michael B & J: can you check Twizzy and Volt/Ampera, to see >>>> if everything is ok with current firmware or there is >>>> anything you need changed? >>>> >>>> I plan to cut release candidate for 2.3.1 on Sunday. >>>> >>>> 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 >> >> -- >> 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 <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
_______________________________________________ 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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
_______________________________________________ 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
_______________________________________________ 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
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem. My tests show there still is an issue with streaming enabled: if I let a client open (perl / App), very few GPS points now get through, both to the App and to the GPS log. Could be due to the modem not getting the per second GPS requests or due to some msg queue issue. I'll debug that ASAP. I also reactivated the 12V input filtering as the false peaks still occur and I've got no more ideas for the A/D conversion. Any hint on this is appreciated. Regards, Michael Am 14.04.2013 23:02, schrieb Michael Balzer:
I also had the perl client running in a loop to log all data.
I found the bug occured both times just after a perl client restart. That could mean the "peer connected" reaction (net_msg.c line 660) could somehow be involved, or -- as my perl client copy also sends a command 41 to query the SIM account balance -- the USSD handling could be the source of the bug.
I'm pretty sure it's the USSD reply handling. It's not completely well coded yet (sorry!), and it could behave bad in a situation with much regular data traffic going on... and that again matches.
I'll fix this ASAP, but I can't fix it now (too late).
As triggering this bug seems to be unlikely, I would not consider this a problem for the release.
Regards, Michael
PS: I checked in the A/D converter change though, that seems to solve the 12V readings!
Am 14.04.2013 18:04, schrieb Michael Balzer:
I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption.
Am 14.04.2013 17:54, schrieb Michael Balzer:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer: > Nikki, > > yes, see attachment. > > I could not make out any possible source of that strange error I > had yesterday (completely garbled data). > > I made a clean build with a freshly started MPLAB and got no > errors up to now. > > May have been something completely different, not related to my > last changes. > > Regards, > Michael > > > Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: >> Michael, >> >> Any new firmware for me to test this weekend? >> >> Nikki. >> >> On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de >> <mailto:dexter@expeedo.de>> wrote: >> >>> I think I was a bit too fast on this, Nikki, don't use that >>> version, it seems to have some new bug causing frequent >>> crashes... :-( >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.04.2013 19:22, schrieb Michael Balzer: >>>> Mark, Nikki, >>>> >>>> I'm currently trying to fix a last bug with the power >>>> statistics (the distance counter still went wrong), and I'm >>>> trying to get the 12V A/D conversion to work without these >>>> strange "peaks" by raising the automatic acquisition time. I >>>> will finish testing this ASAP or tell you in time before sunday. >>>> >>>> Nikki, I attached the latest version in case you'd like to >>>> test as well. >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>>>> China is bugging me for final firmware for the next batch of >>>>> hardware. I need to get them this early next week. >>>>> >>>>> I've committed what I need for the Tesla Roadster (and >>>>> framework). Last outstanding small change to make is to send >>>>> CAC as 999.99, rather than the current 99999, using Tom's >>>>> new library function. >>>>> >>>>> Michael B & J: can you check Twizzy and Volt/Ampera, to see >>>>> if everything is ok with current firmware or there is >>>>> anything you need changed? >>>>> >>>>> I plan to cut release candidate for 2.3.1 on Sunday. >>>>> >>>>> 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 >>> >>> -- >>> 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 <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 > > > _______________________________________________ > 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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems. Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now? Thanks, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode. http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_... This is GSM 7.10 TE-MS multiplexor protocol. The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other. The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]). It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term. SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900: http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_a... Regards, Mark. On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems.
Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
Thanks, Michael
-- 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
Mark, I also see the current modem communication layer as a problem source. The read buffer only takes 128 bytes, which will not be sufficient for many situations -- e.g. a GPS response now needs already two NMEA sentences adding up to about 108 bytes -- come in another modem answer before the buffer gets handled, and bang we go... The multiplex mode is quite interesting, didn't know this before -- although a really fully asynchronous modem comm handling would not need that, I think. But it would need more buffer RAM... Hm... the SIM908 manual says: "In Multiplex mode, it is recommended to use the hardware flow control." As far as I understand the circuit schemes the current hardware does not connect RTS/CTS (pins 66+67) -- right? Regards, Michael Am 30.04.2013 03:28, schrieb Mark Webb-Johnson:
Michael,
Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.
http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_...
This is GSM 7.10 TE-MS multiplexor protocol.
The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.
The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).
It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.
SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:
http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_a...
Regards, Mark.
On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems.
Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
Thanks, Michael
-- 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 <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
Michael, No hardware flow control in OVMS circuit. But, we are only 9600baud and interrupt-driven - I think it should be ok. My concern is RAM - say we have two channels open, we're going to need 2 more line buffers. Here is the latest 'map' file: Section Type Address Location Size(Bytes) --------- --------- --------- --------- --------- TX_CRYPTO udata 0x000100 data 0x000100 RX_CRYPTO udata 0x000200 data 0x000100 PM_CRYPTO udata 0x000300 data 0x000100 .stack udata 0x000c00 data 0x000100 .udata_crypt_hmac.o udata 0x000400 data 0x0000d8 NETMSG_SP udata 0x000500 data 0x0000c8 NETBUF_SP udata 0x000600 data 0x0000c8 NETBUF udata 0x000700 data 0x0000c8 .udata_UARTIntC.o udata 0x000800 data 0x0000c7 LOGGING udata 0x000060 data 0x000088 SFR_UNBANKED1 udata 0x000f80 data 0x000080 .idata_ovms.o idata 0x000900 data 0x000070 vehicle_overlay_data udata 0x000970 data 0x00006e .idata_net_sms.o idata 0x000a00 data 0x000063 SFR_BANKED12 udata 0x000f00 data 0x000060 SFR_BANKED11 udata 0x000e20 data 0x000060 .idata_net_msg.o idata 0x000a63 data 0x000045 .udata_crypt_md5.o udata 0x000aa8 data 0x000040 .idata_crypt_md5.o idata 0x000b00 data 0x000040 .idata_net.o idata 0x0005c8 data 0x000035 .udata_ovms.o udata 0x0006c8 data 0x000030 .idata_vehicle.o idata 0x0007c8 data 0x00002b .udata_net_msg.o udata 0x0004d8 data 0x000026 .udata_params.o udata 0x0009de data 0x000020 .idata_diag.o idata 0x0008c7 data 0x00001b SFR_UNBANKED0 udata 0x000f60 data 0x000018 .idata_vehicle_twizy.o idata 0x0000e8 data 0x000014 MATH_DATA udata 0x000020 data 0x000014 .udata_vehicle.o udata 0x000ae8 data 0x000012 SFR_BANKED2 udata 0x000d80 data 0x00000c SFR_BANKED1 udata 0x000d70 data 0x00000c SFR_BANKED0 udata 0x000d60 data 0x00000c .udata_c018i.o udata 0x0007f3 data 0x00000a .udata_crypt_base64.o udata 0x0006f8 data 0x000008 SFR_BANKED6 udata 0x000de0 data 0x000008 .udata_net_sms.o udata 0x0008e2 data 0x000007 .idata_led.o idata 0x000afa data 0x000005 SFR_BANKED7 udata 0x000df0 data 0x000004 SFR_BANKED3 udata 0x000d90 data 0x000004 .udata_net.o udata 0x0005fd data 0x000003 .idata_stokpr.o idata 0x0009fe data 0x000002 SFR_BANKED4 udata 0x000dd4 data 0x000002 SEED_DATA idata 0x0004fe data 0x000002 .idata_logging.o idata 0x0007fd data 0x000001 SFR_BANKED10 udata 0x000dfc data 0x000001 .udata_led.o udata 0x000aff data 0x000001 SFR_BANKED9 udata 0x000dfa data 0x000001 SFR_BANKED8 udata 0x000df8 data 0x000001 SFR_BANKED5 udata 0x000dd8 data 0x000001 DELAYDAT1 udata 0x000034 data 0x000001 Stack definitely seems separately accounted for. The TX_CRYPTO and RX_CRYPTO are the rc4 contexts. The PM_CRYPTO is for Paranoid Mode (a lot of RAM for that, considering how few use it). The crypt_hmac needs 64 bytes for iPad, 64 bytes for oPad, then 70 bytes for a MD5_CTX. Looking at the code, a lot could be saved. It looks like the iPad and oPad could be merged (slightly slower code, but saves a lot). Then, the pad and context could be on the stack (134 bytes of 256 bytes) - scary but a big win. The crypt_md5 PADDING (64 bytes) seems to be able to be moved to rom with little impact. From there, the returns seem to diminish. Regards, Mark. On 1 May, 2013, at 6:18 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I also see the current modem communication layer as a problem source. The read buffer only takes 128 bytes, which will not be sufficient for many situations -- e.g. a GPS response now needs already two NMEA sentences adding up to about 108 bytes -- come in another modem answer before the buffer gets handled, and bang we go...
The multiplex mode is quite interesting, didn't know this before -- although a really fully asynchronous modem comm handling would not need that, I think. But it would need more buffer RAM...
Hm... the SIM908 manual says: "In Multiplex mode, it is recommended to use the hardware flow control."
As far as I understand the circuit schemes the current hardware does not connect RTS/CTS (pins 66+67) -- right?
Regards, Michael
Am 30.04.2013 03:28, schrieb Mark Webb-Johnson:
Michael,
Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.
http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_...
This is GSM 7.10 TE-MS multiplexor protocol.
The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.
The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).
It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.
SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:
http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_a...
<Mail Attachment.png>
Regards, Mark.
On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems.
Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
Thanks, Michael
-- 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
_______________________________________________ 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
Mark, List, I just checked in some changes that have improved my GPS streaming stability on all my latest test drives to 100%. https://github.com/markwj/Open-Vehicle-Monitoring-System/commit/df459b6b5b07... I still don't know why or how the modem rx buffer full condition could lead to real crashes, but eliminating those also eliminated the crashes. A major part in the buffer filling up was played by the massive delays needed on net_msg_start() to make sure the modem is ready without polling for it's status prompts. That indirectly also played a role in the other problem source, being my network functions assuming the modem is basically "ready" if net_msg_sendpending is 0. But it is not ready if it still processes some command -- like the GPS NMEA request. I now insert another hard coded delay to make sure the modem is ready. These hard delays don't really feel good and they do add up. Any net msg now already needs at least 1.5 seconds just for the net_msg_start() part, so this also disturbs the ticker timing. I think we could eliminate most hard delays by introducing some sort of modem status following. A simple inline modem reply waiting loop might already solve most problems. This could basically be a loop of net_poll() calls with exit condition on checking the buffer for "OK" / "ERROR" / other prompts -- maybe with an additional timeout. Problem could be this net_poll() loop would run outside the main loop, so it would omit all "idle" and "ticker" callbacks until the response comes in (or timeout occurs). The benefit would be a much tighter and faster coupling of the modem, and being able to react according to the modem status responses for certain commands. Have there been any thoughts on this before? Shall I follow this path a bit more or isn't it worth the effort? Regards, Michael Am 01.05.2013 15:05, schrieb Mark Webb-Johnson:
Michael,
No hardware flow control in OVMS circuit. But, we are only 9600baud and interrupt-driven - I think it should be ok.
My concern is RAM - say we have two channels open, we're going to need 2 more line buffers.
Here is the latest 'map' file:
Section Type Address Location Size(Bytes) --------- --------- --------- --------- --------- TX_CRYPTO udata 0x000100 data 0x000100 RX_CRYPTO udata 0x000200 data 0x000100 PM_CRYPTO udata 0x000300 data 0x000100 .stack udata 0x000c00 data 0x000100 .udata_crypt_hmac.o udata 0x000400 data 0x0000d8 NETMSG_SP udata 0x000500 data 0x0000c8 NETBUF_SP udata 0x000600 data 0x0000c8 NETBUF udata 0x000700 data 0x0000c8 .udata_UARTIntC.o udata 0x000800 data 0x0000c7 LOGGING udata 0x000060 data 0x000088 SFR_UNBANKED1 udata 0x000f80 data 0x000080 .idata_ovms.o idata 0x000900 data 0x000070 vehicle_overlay_data udata 0x000970 data 0x00006e .idata_net_sms.o idata 0x000a00 data 0x000063 SFR_BANKED12 udata 0x000f00 data 0x000060 SFR_BANKED11 udata 0x000e20 data 0x000060 .idata_net_msg.o idata 0x000a63 data 0x000045 .udata_crypt_md5.o udata 0x000aa8 data 0x000040 .idata_crypt_md5.o idata 0x000b00 data 0x000040 .idata_net.o idata 0x0005c8 data 0x000035 .udata_ovms.o udata 0x0006c8 data 0x000030 .idata_vehicle.o idata 0x0007c8 data 0x00002b .udata_net_msg.o udata 0x0004d8 data 0x000026 .udata_params.o udata 0x0009de data 0x000020 .idata_diag.o idata 0x0008c7 data 0x00001b SFR_UNBANKED0 udata 0x000f60 data 0x000018 .idata_vehicle_twizy.o idata 0x0000e8 data 0x000014 MATH_DATA udata 0x000020 data 0x000014 .udata_vehicle.o udata 0x000ae8 data 0x000012 SFR_BANKED2 udata 0x000d80 data 0x00000c SFR_BANKED1 udata 0x000d70 data 0x00000c SFR_BANKED0 udata 0x000d60 data 0x00000c .udata_c018i.o udata 0x0007f3 data 0x00000a .udata_crypt_base64.o udata 0x0006f8 data 0x000008 SFR_BANKED6 udata 0x000de0 data 0x000008 .udata_net_sms.o udata 0x0008e2 data 0x000007 .idata_led.o idata 0x000afa data 0x000005 SFR_BANKED7 udata 0x000df0 data 0x000004 SFR_BANKED3 udata 0x000d90 data 0x000004 .udata_net.o udata 0x0005fd data 0x000003 .idata_stokpr.o idata 0x0009fe data 0x000002 SFR_BANKED4 udata 0x000dd4 data 0x000002 SEED_DATA idata 0x0004fe data 0x000002 .idata_logging.o idata 0x0007fd data 0x000001 SFR_BANKED10 udata 0x000dfc data 0x000001 .udata_led.o udata 0x000aff data 0x000001 SFR_BANKED9 udata 0x000dfa data 0x000001 SFR_BANKED8 udata 0x000df8 data 0x000001 SFR_BANKED5 udata 0x000dd8 data 0x000001 DELAYDAT1 udata 0x000034 data 0x000001
Stack definitely seems separately accounted for. The TX_CRYPTO and RX_CRYPTO are the rc4 contexts. The PM_CRYPTO is for Paranoid Mode (a lot of RAM for that, considering how few use it).
The crypt_hmac needs 64 bytes for iPad, 64 bytes for oPad, then 70 bytes for a MD5_CTX. Looking at the code, a lot could be saved. It looks like the iPad and oPad could be merged (slightly slower code, but saves a lot). Then, the pad and context could be on the stack (134 bytes of 256 bytes) - scary but a big win.
The crypt_md5 PADDING (64 bytes) seems to be able to be moved to rom with little impact.
From there, the returns seem to diminish.
Regards, Mark.
On 1 May, 2013, at 6:18 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I also see the current modem communication layer as a problem source. The read buffer only takes 128 bytes, which will not be sufficient for many situations -- e.g. a GPS response now needs already two NMEA sentences adding up to about 108 bytes -- come in another modem answer before the buffer gets handled, and bang we go...
The multiplex mode is quite interesting, didn't know this before -- although a really fully asynchronous modem comm handling would not need that, I think. But it would need more buffer RAM...
Hm... the SIM908 manual says: "In Multiplex mode, it is recommended to use the hardware flow control."
As far as I understand the circuit schemes the current hardware does not connect RTS/CTS (pins 66+67) -- right?
Regards, Michael
Am 30.04.2013 03:28, schrieb Mark Webb-Johnson:
Michael,
Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.
http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_...
This is GSM 7.10 TE-MS multiplexor protocol.
The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.
The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).
It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.
SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:
http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_a...
<Mail Attachment.png>
Regards, Mark.
On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems.
Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
Thanks, Michael
-- 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 <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 <dexter.vcf>_______________________________________________ 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
Michael, I reviewed the patch. It seems fine. When I originally wrote the net.{c,h} framework, I thought about doing some sort of send-expect (chat) control. It was just hard to implement with limited ram, while keeping the state based system. A lot of the lower state transitions are event based (most of the initialisation works that way), but once we get into the main online state it stays there. Is it possible to introduce some more READY states to handle this? Maybe even a transition system based on a modem result (i.e.; wait until you get string "OK" then go to this state, or time-out after N seconds)? Last point is that some of the delays are because there is no response for some modem commands, and if you send too fast that causes a loss of data. Regards, Mark. On 8 May, 2013, at 2:52 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark, List,
I just checked in some changes that have improved my GPS streaming stability on all my latest test drives to 100%.
https://github.com/markwj/Open-Vehicle-Monitoring-System/commit/df459b6b5b07...
I still don't know why or how the modem rx buffer full condition could lead to real crashes, but eliminating those also eliminated the crashes.
A major part in the buffer filling up was played by the massive delays needed on net_msg_start() to make sure the modem is ready without polling for it's status prompts. That indirectly also played a role in the other problem source, being my network functions assuming the modem is basically "ready" if net_msg_sendpending is 0.
But it is not ready if it still processes some command -- like the GPS NMEA request. I now insert another hard coded delay to make sure the modem is ready.
These hard delays don't really feel good and they do add up. Any net msg now already needs at least 1.5 seconds just for the net_msg_start() part, so this also disturbs the ticker timing.
I think we could eliminate most hard delays by introducing some sort of modem status following. A simple inline modem reply waiting loop might already solve most problems. This could basically be a loop of net_poll() calls with exit condition on checking the buffer for "OK" / "ERROR" / other prompts -- maybe with an additional timeout.
Problem could be this net_poll() loop would run outside the main loop, so it would omit all "idle" and "ticker" callbacks until the response comes in (or timeout occurs).
The benefit would be a much tighter and faster coupling of the modem, and being able to react according to the modem status responses for certain commands.
Have there been any thoughts on this before? Shall I follow this path a bit more or isn't it worth the effort?
Regards, Michael
Am 01.05.2013 15:05, schrieb Mark Webb-Johnson:
Michael,
No hardware flow control in OVMS circuit. But, we are only 9600baud and interrupt-driven - I think it should be ok.
My concern is RAM - say we have two channels open, we're going to need 2 more line buffers.
Here is the latest 'map' file:
Section Type Address Location Size(Bytes) --------- --------- --------- --------- --------- TX_CRYPTO udata 0x000100 data 0x000100 RX_CRYPTO udata 0x000200 data 0x000100 PM_CRYPTO udata 0x000300 data 0x000100 .stack udata 0x000c00 data 0x000100 .udata_crypt_hmac.o udata 0x000400 data 0x0000d8 NETMSG_SP udata 0x000500 data 0x0000c8 NETBUF_SP udata 0x000600 data 0x0000c8 NETBUF udata 0x000700 data 0x0000c8 .udata_UARTIntC.o udata 0x000800 data 0x0000c7 LOGGING udata 0x000060 data 0x000088 SFR_UNBANKED1 udata 0x000f80 data 0x000080 .idata_ovms.o idata 0x000900 data 0x000070 vehicle_overlay_data udata 0x000970 data 0x00006e .idata_net_sms.o idata 0x000a00 data 0x000063 SFR_BANKED12 udata 0x000f00 data 0x000060 SFR_BANKED11 udata 0x000e20 data 0x000060 .idata_net_msg.o idata 0x000a63 data 0x000045 .udata_crypt_md5.o udata 0x000aa8 data 0x000040 .idata_crypt_md5.o idata 0x000b00 data 0x000040 .idata_net.o idata 0x0005c8 data 0x000035 .udata_ovms.o udata 0x0006c8 data 0x000030 .idata_vehicle.o idata 0x0007c8 data 0x00002b .udata_net_msg.o udata 0x0004d8 data 0x000026 .udata_params.o udata 0x0009de data 0x000020 .idata_diag.o idata 0x0008c7 data 0x00001b SFR_UNBANKED0 udata 0x000f60 data 0x000018 .idata_vehicle_twizy.o idata 0x0000e8 data 0x000014 MATH_DATA udata 0x000020 data 0x000014 .udata_vehicle.o udata 0x000ae8 data 0x000012 SFR_BANKED2 udata 0x000d80 data 0x00000c SFR_BANKED1 udata 0x000d70 data 0x00000c SFR_BANKED0 udata 0x000d60 data 0x00000c .udata_c018i.o udata 0x0007f3 data 0x00000a .udata_crypt_base64.o udata 0x0006f8 data 0x000008 SFR_BANKED6 udata 0x000de0 data 0x000008 .udata_net_sms.o udata 0x0008e2 data 0x000007 .idata_led.o idata 0x000afa data 0x000005 SFR_BANKED7 udata 0x000df0 data 0x000004 SFR_BANKED3 udata 0x000d90 data 0x000004 .udata_net.o udata 0x0005fd data 0x000003 .idata_stokpr.o idata 0x0009fe data 0x000002 SFR_BANKED4 udata 0x000dd4 data 0x000002 SEED_DATA idata 0x0004fe data 0x000002 .idata_logging.o idata 0x0007fd data 0x000001 SFR_BANKED10 udata 0x000dfc data 0x000001 .udata_led.o udata 0x000aff data 0x000001 SFR_BANKED9 udata 0x000dfa data 0x000001 SFR_BANKED8 udata 0x000df8 data 0x000001 SFR_BANKED5 udata 0x000dd8 data 0x000001 DELAYDAT1 udata 0x000034 data 0x000001
Stack definitely seems separately accounted for. The TX_CRYPTO and RX_CRYPTO are the rc4 contexts. The PM_CRYPTO is for Paranoid Mode (a lot of RAM for that, considering how few use it).
The crypt_hmac needs 64 bytes for iPad, 64 bytes for oPad, then 70 bytes for a MD5_CTX. Looking at the code, a lot could be saved. It looks like the iPad and oPad could be merged (slightly slower code, but saves a lot). Then, the pad and context could be on the stack (134 bytes of 256 bytes) - scary but a big win.
The crypt_md5 PADDING (64 bytes) seems to be able to be moved to rom with little impact.
From there, the returns seem to diminish.
Regards, Mark.
On 1 May, 2013, at 6:18 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I also see the current modem communication layer as a problem source. The read buffer only takes 128 bytes, which will not be sufficient for many situations -- e.g. a GPS response now needs already two NMEA sentences adding up to about 108 bytes -- come in another modem answer before the buffer gets handled, and bang we go...
The multiplex mode is quite interesting, didn't know this before -- although a really fully asynchronous modem comm handling would not need that, I think. But it would need more buffer RAM...
Hm... the SIM908 manual says: "In Multiplex mode, it is recommended to use the hardware flow control."
As far as I understand the circuit schemes the current hardware does not connect RTS/CTS (pins 66+67) -- right?
Regards, Michael
Am 30.04.2013 03:28, schrieb Mark Webb-Johnson:
Michael,
Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.
http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_...
This is GSM 7.10 TE-MS multiplexor protocol.
The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.
The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).
It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.
SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:
http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_a...
<Mail Attachment.png>
Regards, Mark.
On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
Am 28.04.2013 17:06, schrieb Michael Balzer:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
I was wrong, it's still crashing. I have to dig deeper it seems.
Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
Thanks, Michael
-- 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
_______________________________________________ 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
_______________________________________________ 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
On the 12v filtering, all I can think is to average it, perhaps over a minute, or for a set number of readings. Or perhaps require 2 readings higher than the current reading before increasing it (or generally 2 readings before it is changed). This could be done in the function to handle reading the value. For example, say we kept a total, a count and the last value. Then, input_voltage() would read the value, add it to the total and increment the count. If count > 5 (say), set last value = total / count, then reset total,count=0. It would return last value as the result. Do you have any historical list of the values reported from the function? Does it go 11.5, 11.6, 11.5, 11.5, 13.2, 11.5, 11.6, etc? Of stay falsely high for multiple readings? Regards, Mark. On 28 Apr, 2013, at 11:06 PM, Michael Balzer wrote:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
My tests show there still is an issue with streaming enabled: if I let a client open (perl / App), very few GPS points now get through, both to the App and to the GPS log. Could be due to the modem not getting the per second GPS requests or due to some msg queue issue. I'll debug that ASAP.
I also reactivated the 12V input filtering as the false peaks still occur and I've got no more ideas for the A/D conversion. Any hint on this is appreciated.
Regards, Michael
Am 14.04.2013 23:02, schrieb Michael Balzer:
I also had the perl client running in a loop to log all data.
I found the bug occured both times just after a perl client restart. That could mean the "peer connected" reaction (net_msg.c line 660) could somehow be involved, or -- as my perl client copy also sends a command 41 to query the SIM account balance -- the USSD handling could be the source of the bug.
I'm pretty sure it's the USSD reply handling. It's not completely well coded yet (sorry!), and it could behave bad in a situation with much regular data traffic going on... and that again matches.
I'll fix this ASAP, but I can't fix it now (too late).
As triggering this bug seems to be unlikely, I would not consider this a problem for the release.
Regards, Michael
PS: I checked in the A/D converter change though, that seems to solve the 12V readings!
Am 14.04.2013 18:04, schrieb Michael Balzer:
I've had GPS streaming enabled during the last days, and neither GPS nor GSM connectivity are good at the moment. May be related, as streaming means more data communication. But still that should not lead to RAM corruption.
Am 14.04.2013 17:54, schrieb Michael Balzer:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
> Mark, > > I just checked in my latest changes. > > In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look. > > I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? > Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one. > > Regards, > Michael > > > Am 12.04.2013 20:16, schrieb Michael Balzer: >> Nikki, >> >> yes, see attachment. >> >> I could not make out any possible source of that strange error I had yesterday (completely garbled data). >> >> I made a clean build with a freshly started MPLAB and got no errors up to now. >> >> May have been something completely different, not related to my last changes. >> >> Regards, >> Michael >> >> >> Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: >>> Michael, >>> >>> Any new firmware for me to test this weekend? >>> >>> Nikki. >>> >>> On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote: >>> >>>> I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-( >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 11.04.2013 19:22, schrieb Michael Balzer: >>>>> Mark, Nikki, >>>>> >>>>> I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. >>>>> >>>>> Nikki, I attached the latest version in case you'd like to test as well. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>>>>> China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. >>>>>> >>>>>> I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. >>>>>> >>>>>> Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? >>>>>> >>>>>> I plan to cut release candidate for 2.3.1 on Sunday. >>>>>> >>>>>> 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 >>>> >>>> -- >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Mark, it's only single false peaks with max offsets around 1.0 V, and the false readings are always on the low side. That's what lead me to assuming it's the A/D hold capacitor charge time. Example: 12,8 12,8 12,8 11,8 12,8 12,8 12,8 My filtering solution (damping by 1:1 averaging with last reading, see net.c line 1394) has been sufficient up to now, so I don't think we need to use additional RAM for this. If the peaks would be higher off we could try another damping ratio first, 2:1 for example. Regards, Michael Am 30.04.2013 04:56, schrieb Mark Webb-Johnson:
On the 12v filtering, all I can think is to average it, perhaps over a minute, or for a set number of readings. Or perhaps require 2 readings higher than the current reading before increasing it (or generally 2 readings before it is changed). This could be done in the function to handle reading the value.
For example, say we kept a total, a count and the last value. Then, input_voltage() would read the value, add it to the total and increment the count. If count > 5 (say), set last value = total / count, then reset total,count=0. It would return last value as the result.
Do you have any historical list of the values reported from the function? Does it go 11.5, 11.6, 11.5, 11.5, 13.2, 11.5, 11.6, etc? Of stay falsely high for multiple readings?
Regards, Mark.
On 28 Apr, 2013, at 11:06 PM, Michael Balzer wrote:
I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
My tests show there still is an issue with streaming enabled: if I let a client open (perl / App), very few GPS points now get through, both to the App and to the GPS log. Could be due to the modem not getting the per second GPS requests or due to some msg queue issue. I'll debug that ASAP.
I also reactivated the 12V input filtering as the false peaks still occur and I've got no more ideas for the A/D conversion. Any hint on this is appreciated.
Regards, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, By the way, the new VEHICLE commands are intended for the QC guys in China - they need a quick way to set it to TR for QC testing, then clear it after testing. I'll document them today, but I don't think they'll be a lot of use for end users. Regarding the DebuCrash, my car seems ok - I'll keep monitoring today, but so far so good. Regards, Mark. On 14 Apr, 2013, at 11:54 PM, Michael Balzer wrote:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this weekend?
Nikki.
On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de> wrote:
> I think I was a bit too fast on this, Nikki, don't use that version, it seems to have some new bug causing frequent crashes... :-( > > Regards, > Michael > > > Am 11.04.2013 19:22, schrieb Michael Balzer: >> Mark, Nikki, >> >> I'm currently trying to fix a last bug with the power statistics (the distance counter still went wrong), and I'm trying to get the 12V A/D conversion to work without these strange "peaks" by raising the automatic acquisition time. I will finish testing this ASAP or tell you in time before sunday. >> >> Nikki, I attached the latest version in case you'd like to test as well. >> >> Regards, >> Michael >> >> >> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>> China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week. >>> >>> I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function. >>> >>> Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed? >>> >>> I plan to cut release candidate for 2.3.1 on Sunday. >>> >>> 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 > > -- > 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
_______________________________________________ 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
_______________________________________________ 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
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
-- 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
Good news is, without GPS streaming I had no crashes, so the problem will not occur under normal usage conditions. Little bad news is, the 12V A/D conversion still produces false values occasionally. Less often though. As 20 TAD is the maximum time, I've run out of options for now. Peak filtering can be enabled again, but that IMO just cloaks the problem, I'd rather solve it. Regards, Michael Am 15.04.2013 02:59, schrieb Mark Webb-Johnson:
Michael,
By the way, the new VEHICLE commands are intended for the QC guys in China - they need a quick way to set it to TR for QC testing, then clear it after testing. I'll document them today, but I don't think they'll be a lot of use for end users.
Regarding the DebuCrash, my car seems ok - I'll keep monitoring today, but so far so good.
Regards, Mark.
On 14 Apr, 2013, at 11:54 PM, Michael Balzer wrote:
Mark,
I've got the last but one version in my car, just lacking the new VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V auto acquisition time even more, as the faults have become better but it's not yet perfect. I'm trying 20 TAD now, as we don't need to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14 14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20 MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14 14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug variables have been overwritten, was the same with the first occurence (but other values).
As the module behaves weird afterwards I suppose more variables have been corrupted.
I've looked through the last changes several times, I'm pretty sure none could have introduced this kind of bug... if I'm the only one experiencing this, maybe I've got some hardware issue as well?
I'll continue checking the source for possible buffer overruns...
Regards, Michael
Am 14.04.2013 16:29, schrieb Mark Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release candidate, and I have 24 hours to test before i need to send it to China.
It is in my car now, and seems ok. I'll do more testing tomorrow.
I'd be grateful if others could grab it and put it in their cars to ensure there are no major problems.
Regards, Mark.
On 13 Apr, 2013, at 10:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
All seems ok.
I've committed and pushed my changes (just the stp_ltf_h() function, and change to report cac as 999.99 to server).
I've just flashed and it will go in my car tomorrow.
Regards, Mark
On 13 Apr, 2013, at 2:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the new net_notify_errorcode send, I think that should be correct, but please have a look.
I saw the new stp_f() function, but I don't understand it's purpose yet. What's the difference to my stp_l2f() function? Btw: l2f = "long to float" -- I think "_f" should be reserved for an stp call with a real float type parameter, if we once really need one.
Regards, Michael
Am 12.04.2013 20:16, schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that strange error I had yesterday (completely garbled data).
I made a clean build with a freshly started MPLAB and got no errors up to now.
May have been something completely different, not related to my last changes.
Regards, Michael
Am 12.04.2013 17:01, schrieb Nikki Gordon-Bloomfield: > Michael, > > Any new firmware for me to test this weekend? > > Nikki. > > On 11 Apr 2013, at 18:33, Michael Balzer <dexter@expeedo.de > <mailto:dexter@expeedo.de>> wrote: > >> I think I was a bit too fast on this, Nikki, don't use that >> version, it seems to have some new bug causing frequent >> crashes... :-( >> >> Regards, >> Michael >> >> >> Am 11.04.2013 19:22, schrieb Michael Balzer: >>> Mark, Nikki, >>> >>> I'm currently trying to fix a last bug with the power >>> statistics (the distance counter still went wrong), and I'm >>> trying to get the 12V A/D conversion to work without these >>> strange "peaks" by raising the automatic acquisition time. I >>> will finish testing this ASAP or tell you in time before sunday. >>> >>> Nikki, I attached the latest version in case you'd like to >>> test as well. >>> >>> Regards, >>> Michael >>> >>> >>> Am 11.04.2013 16:41, schrieb Mark Webb-Johnson: >>>> China is bugging me for final firmware for the next batch of >>>> hardware. I need to get them this early next week. >>>> >>>> I've committed what I need for the Tesla Roadster (and >>>> framework). Last outstanding small change to make is to send >>>> CAC as 999.99, rather than the current 99999, using Tom's new >>>> library function. >>>> >>>> Michael B & J: can you check Twizzy and Volt/Ampera, to see >>>> if everything is ok with current firmware or there is >>>> anything you need changed? >>>> >>>> I plan to cut release candidate for 2.3.1 on Sunday. >>>> >>>> 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 >> >> -- >> 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 <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
_______________________________________________ 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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 <dexter.vcf>_______________________________________________ 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
Mark, I think the CAC code is ready for release. I am continuing to work on a method to detect precisely when CAC changes but that's not as important as getting the already excellent CAC support out there. I've largely confirmed that CAC updates happen along with the SOC settling that occurs typically about 10 minutes after a charge or drive event, and at no other time. That seemed to be the case in my manual checking over the last couple of months and has held up since I've started doing careful monitoring and logging. For testing, I have created custom firmware that checks the CAC value according to your code, plus on the charge settle after a drive or charge, and also every five minutes. It records timestamps for these various events, including when it gets a changed CAC value. So far, all four of my recent CAC updates have fit this model. I may be the only Roadster owner on the planet who cares about knowing exactly when the CAC changes, because I'm correlating that with data in the VMS log file. I think what you have now is ready for the 2.3.1 release, and is a big win for people contributing to the Roadster battery survey where I don't care about the small day-to-day variations in CAC. I may eventually propose a change to when OVMS queries the CAC, assuming the data continues to hold up. I'd also like to test on a v2.x Roadster to make sure they behave the same way. In case anyone else cares, below is a log of my test results so far. Tom ------- April 8: 17:46:50 drive ended, car turned off 17:56:53 SOC updated (triggers a CAC request) 17:56:53 CAC updated from 149.62 to 149.60 23:01:09 drive ended, car turned off 23:10:52 CAC updated to 149.57 (note: about 10 minutes after drive end) 23:49:51 SOC updated The CAC happened about 10 minutes after the charge ended. I suspect there was an SOC update at that point, otherwise the CAC update would not have been noticed until the second 5-minute update after the drive end at 23:11:11 (periodic updates happen every 5:01). I believe another SOC adjust happened and got recorded over the timestamp of the first. April 9: 05:07:40 charge ended (according to VMS log) 05:17:50 CAC value updated to 149.82 05:22:11 SOC update (probably a second update after the charge) The charge end time was not recorded due to a bug, but I pulled the charge end time from the VMS log and confirmed that the CAC update happened about 10 minutes after the charge end. Again, the SOC update time probably got clobbered by second update. At this point, I fixed the code to record only the first SOC update after a charge or drive, and fixed the bug that prevented the end-of-charge from being recorded. April 10: When I actually recorded the end-of-charge event, it overflowed the 160-character SMS message limit on the status message, so I couldn't retrieve the data. Fortunately, the CAC apparently didn't change with the overnight charge. I created a new CAC command to give me enough room to show all of the recorded events. 16:27:20 charge ended 16:37:23 SOC updated (triggers a CAC request) 16:37:23 CAC value updated to 149.86 on 4/11/13 7:41 AM, Mark Webb-Johnson wrote:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Tom, I'm not seeing any change to my CAC, for the past few weeks. It has kept stable at 156.94. Here are some "msg S" logs from my last short charge: 2013-04-10 05:27:48.271709 -0400 info main: #55 C EV915 rx msg S 77,K,-1,0,stopped,standard,238,230,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-10 05:37:46.636673 -0400 info main: #55 C EV915 rx msg S 75,K,-1,0,stopped,standard,230,219,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-10 05:47:45.101954 -0400 info main: #55 C EV915 rx msg S 71,K,-1,0,stopped,standard,218,200,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-10 05:50:25.720999 -0400 info main: #55 C EV915 rx msg S 72,K,-1,0,prepare,standard,218,198,56,0,100,0,7,13,0,0,0,-1,15694 2013-04-10 05:50:26.476525 -0400 info main: #55 C EV915 rx msg S 71,K,1,0,stopped,standard,218,198,56,0,100,0,2,14,0,0,0,-1,15694 2013-04-10 05:58:58.340823 -0400 info main: #88 C EV915 rx msg S 71,K,-1,127,stopped,standard,218,198,56,-1,100,0,2,14,0,0,0,-1,15694 2013-04-10 08:26:37.482147 -0400 info main: #70 C EV915 rx msg S 95,K,220,22,charging,standard,299,270,56,84,100,15,5,1,0,0,0,-1,15694 2013-04-10 08:26:37.483320 -0400 info main: #70 C EV915 rx msg S 95,K,219,23,charging,standard,299,270,56,85,100,15,5,1,0,0,0,-1,15694 2013-04-10 09:35:06.517705 -0400 info main: #84 C EV915 rx msg S 97,K,-1,127,done,standard,301,274,56,-1,100,16,9,4,0,0,0,-1,15694 2013-04-10 15:29:18.779202 -0400 info main: #58 C EV915 rx msg S 95,K,-1,127,done,standard,299,272,56,-1,100,16,9,4,0,0,0,-1,15694 2013-04-10 19:54:10.541853 -0400 info main: #64 C EV915 rx msg S 95,K,-1,0,done,standard,299,272,56,93,100,16,7,4,0,0,0,-1,15694 2013-04-10 19:54:11.262363 -0400 info main: #64 C EV915 rx msg S 95,K,1,0,stopped,standard,299,272,56,93,100,16,2,14,0,0,0,-1,15694 2013-04-10 19:54:22.804888 -0400 info main: #64 C EV915 rx msg S 95,K,-1,0,stopped,standard,299,272,56,93,100,16,7,21,0,0,0,-1,15694 2013-04-10 20:00:33.214413 -0400 info main: #64 C EV915 rx msg S 93,K,-1,0,stopped,standard,291,243,56,93,100,16,7,21,0,0,0,-1,15694 2013-04-10 20:10:31.481348 -0400 info main: #64 C EV915 rx msg S 93,K,-1,0,stopped,standard,291,261,56,93,100,16,7,21,0,0,0,-1,15694 2013-04-10 20:20:29.937143 -0400 info main: #64 C EV915 rx msg S 91,K,-1,0,stopped,standard,285,253,56,93,100,16,7,21,0,0,0,-1,15694 2013-04-10 20:30:28.360917 -0400 info main: #64 C EV915 rx msg S 89,K,-1,0,stopped,standard,280,275,56,93,100,16,7,21,0,0,0,-1,15694 Also, a much longer range mode charge: 2013-04-08 04:30:22.542501 -0400 info main: #73 C EV915 rx msg S 85,K,-1,0,done,standard,264,254,56,110,100,18,7,4,0,0,0,-1,15694 2013-04-08 04:35:10.908411 -0400 info main: #73 C EV915 rx msg S 85,K,-1,0,prepare,standard,262,253,70,0,100,0,7,13,0,0,0,-1,15694 2013-04-08 04:35:34.211210 -0400 info main: #73 C EV915 rx msg S 85,K,222,0,prepare,standard,262,253,70,0,100,0,1,13,0,0,0,-1,15694 2013-04-08 04:35:42.630484 -0400 info main: #73 C EV915 rx msg S 85,K,223,0,charging,standard,262,253,70,0,100,0,5,1,0,0,0,-1,15694 2013-04-08 04:35:56.749439 -0400 info main: #73 C EV915 rx msg S 85,K,224,0,charging,standard,262,253,70,0,100,0,5,1,0,0,0,-1,15694 2013-04-08 04:36:34.847780 -0400 info main: #73 C EV915 rx msg S 85,K,219,10,charging,standard,262,253,10,0,100,0,5,1,0,0,0,-1,15694 2013-04-08 04:40:36.487838 -0400 info main: #73 C EV915 rx msg S 77,K,215,13,charging,range,304,291,70,4,100,0,5,1,3,0,0,-1,15694 2013-04-08 04:46:44.002641 -0400 info main: #73 C EV915 rx msg S 77,K,215,13,charging,range,306,293,70,11,100,0,5,1,3,0,0,-1,15694 2013-04-08 04:50:35.999907 -0400 info main: #73 C EV915 rx msg S 77,K,216,13,charging,range,306,294,70,14,100,1,5,1,3,0,0,-1,15694 2013-04-08 05:00:34.672173 -0400 info main: #73 C EV915 rx msg S 78,K,216,13,charging,range,309,296,70,24,100,1,5,1,3,0,0,-1,15694 2013-04-08 05:10:33.043550 -0400 info main: #73 C EV915 rx msg S 78,K,216,13,charging,range,309,298,70,34,100,2,5,1,3,0,0,-1,15694 2013-04-08 05:17:23.176676 -0400 info main: #73 C EV915 rx msg S 79,K,216,13,charging,range,312,299,70,41,100,2,5,1,3,0,0,-1,15694 2013-04-08 05:17:34.076335 -0400 info main: #73 C EV915 rx msg S 79,K,217,13,charging,range,312,299,70,41,100,2,5,1,3,0,0,-1,15694 2013-04-08 05:17:56.236221 -0400 info main: #73 C EV915 rx msg S 79,K,216,13,charging,range,312,299,70,42,100,2,5,1,3,0,0,-1,15694 2013-04-08 05:20:35.556179 -0400 info main: #73 C EV915 rx msg S 79,K,216,13,charging,range,312,299,70,44,100,2,5,1,3,0,0,-1,15694 2013-04-08 05:30:33.844531 -0400 info main: #73 C EV915 rx msg S 79,K,215,13,charging,range,314,301,70,54,100,3,5,1,3,0,0,-1,15694 2013-04-08 05:40:32.059737 -0400 info main: #73 C EV915 rx msg S 80,K,217,13,charging,range,315,302,70,64,100,3,5,1,3,0,0,-1,15694 2013-04-08 05:45:32.754435 -0400 info main: #73 C EV915 rx msg S 80,K,215,13,charging,range,317,304,70,69,100,3,5,1,3,0,0,-1,15694 2013-04-08 05:50:31.511723 -0400 info main: #73 C EV915 rx msg S 80,K,216,13,charging,range,318,306,70,74,100,3,5,1,3,0,0,-1,15694 2013-04-08 06:00:29.763518 -0400 info main: #73 C EV915 rx msg S 81,K,216,13,charging,range,320,307,70,84,100,4,5,1,3,0,0,-1,15694 2013-04-08 06:05:22.418132 -0400 info main: #73 C EV915 rx msg S 81,K,217,13,charging,range,320,307,70,89,100,4,5,1,3,0,0,-1,15694 2013-04-08 06:05:31.398379 -0400 info main: #73 C EV915 rx msg S 81,K,215,13,charging,range,320,307,70,89,100,4,5,1,3,0,0,-1,15694 2013-04-08 06:10:30.872432 -0400 info main: #73 C EV915 rx msg S 81,K,218,13,charging,range,322,309,70,94,100,4,5,1,3,0,0,-1,15694 2013-04-08 06:20:29.124775 -0400 info main: #73 C EV915 rx msg S 82,K,216,13,charging,range,323,310,70,104,100,5,5,1,3,0,0,-1,15694 2013-04-08 06:30:27.399827 -0400 info main: #73 C EV915 rx msg S 82,K,216,13,charging,range,326,312,70,114,100,5,5,1,3,0,0,-1,15694 2013-04-08 06:40:25.688407 -0400 info main: #73 C EV915 rx msg S 83,K,218,13,charging,range,328,315,70,124,100,6,5,1,3,0,0,-1,15694 2013-04-08 06:50:23.940541 -0400 info main: #73 C EV915 rx msg S 83,K,216,13,charging,range,330,317,70,134,100,6,5,1,3,0,0,-1,15694 2013-04-08 07:00:22.252044 -0400 info main: #73 C EV915 rx msg S 84,K,213,13,charging,range,333,318,70,144,100,7,5,1,3,0,0,-1,15694 2013-04-08 07:10:20.587542 -0400 info main: #73 C EV915 rx msg S 84,K,216,13,charging,range,334,320,70,154,100,7,5,1,3,0,0,-1,15694 2013-04-08 07:20:18.839412 -0400 info main: #73 C EV915 rx msg S 85,K,218,13,charging,range,336,323,70,164,100,8,5,1,3,0,0,-1,15694 2013-04-08 07:30:17.128107 -0400 info main: #73 C EV915 rx msg S 85,K,213,13,charging,range,339,325,70,174,100,8,5,1,3,0,0,-1,15694 2013-04-08 07:40:15.422571 -0400 info main: #73 C EV915 rx msg S 86,K,213,13,charging,range,341,326,70,184,100,9,5,1,3,0,0,-1,15694 2013-04-08 07:42:40.421643 -0400 info main: #73 C EV915 rx msg S 86,K,215,13,charging,range,341,328,70,187,100,9,5,1,3,0,0,-1,15694 2013-04-08 07:50:14.574173 -0400 info main: #73 C EV915 rx msg S 86,K,215,13,charging,range,342,330,70,194,100,9,5,1,3,0,0,-1,15694 2013-04-08 08:00:12.826296 -0400 info main: #73 C EV915 rx msg S 87,K,215,13,charging,range,346,331,70,204,100,10,5,1,3,0,0,-1,15694 2013-04-08 08:10:11.179094 -0400 info main: #73 C EV915 rx msg S 87,K,216,13,charging,range,346,333,70,214,100,10,5,1,3,0,0,-1,15694 2013-04-08 08:15:19.455610 -0400 info main: #73 C EV915 rx msg S 87,K,215,13,charging,range,347,333,70,219,100,10,5,1,3,0,0,-1,15694 2013-04-08 08:20:11.147716 -0400 info main: #73 C EV915 rx msg S 87,K,214,13,charging,range,349,334,70,224,100,10,5,1,3,0,0,-1,15694 2013-04-08 08:30:09.422786 -0400 info main: #73 C EV915 rx msg S 88,K,216,13,charging,range,350,336,70,234,100,11,5,1,3,0,0,-1,15694 2013-04-08 08:40:07.675200 -0400 info main: #73 C EV915 rx msg S 88,K,216,13,charging,range,352,338,70,244,100,11,5,1,3,0,0,-1,15694 2013-04-08 08:50:05.963453 -0400 info main: #73 C EV915 rx msg S 89,K,214,13,charging,range,355,341,70,254,100,12,5,1,3,0,0,-1,15694 2013-04-08 09:00:04.437511 -0400 info main: #73 C EV915 rx msg S 89,K,215,13,charging,range,357,342,70,264,100,12,5,1,3,0,0,-1,15694 2013-04-08 09:10:02.767390 -0400 info main: #73 C EV915 rx msg S 90,K,216,13,charging,range,358,344,70,274,100,13,5,1,3,0,0,-1,15694 2013-04-08 09:20:00.982712 -0400 info main: #73 C EV915 rx msg S 90,K,217,13,charging,range,360,346,70,284,100,13,5,1,3,0,0,-1,15694 2013-04-08 09:29:59.271424 -0400 info main: #73 C EV915 rx msg S 91,K,216,13,charging,range,362,347,70,294,100,14,5,1,3,0,0,-1,15694 2013-04-08 09:39:44.187207 -0400 info main: #73 C EV915 rx msg S 91,K,217,13,charging,range,365,349,70,304,100,14,5,1,3,0,0,-1,15694 2013-04-08 09:49:57.298501 -0400 info main: #73 C EV915 rx msg S 92,K,216,13,charging,range,366,352,70,314,100,15,5,1,3,0,0,-1,15694 2013-04-08 09:59:55.509340 -0400 info main: #73 C EV915 rx msg S 92,K,214,13,charging,range,368,352,70,324,100,15,5,1,3,0,0,-1,15694 2013-04-08 10:07:13.521919 -0400 info main: #73 C EV915 rx msg S 92,K,214,13,charging,range,370,354,70,331,100,15,5,1,3,0,0,-1,15694 2013-04-08 10:07:23.503918 -0400 info main: #73 C EV915 rx msg S 92,K,224,0,stopped,range,370,354,70,331,100,15,3,21,3,0,0,-1,15694 2013-04-08 10:07:27.626560 -0400 info main: #73 C EV915 rx msg S 92,K,223,0,stopped,range,370,354,70,331,100,15,3,21,3,0,0,-1,15694 2013-04-08 10:09:10.722202 -0400 info main: #73 C EV915 rx msg S 100,K,-1,0,stopped,standard,328,315,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 10:20:08.263231 -0400 info main: #73 C EV915 rx msg S 100,K,-1,0,stopped,standard,322,288,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 10:30:06.636182 -0400 info main: #73 C EV915 rx msg S 100,K,-1,0,stopped,standard,312,302,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 21:04:15.700838 -0400 info main: #53 C EV915 rx msg S 97,K,-1,0,stopped,standard,301,267,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 21:04:25.600929 -0400 info main: #53 C EV915 rx msg S 97,K,-1,0,stopped,standard,301,267,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 21:14:45.856350 -0400 info main: #53 C EV915 rx msg S 95,K,-1,0,stopped,standard,293,272,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 21:24:35.054786 -0400 info main: #53 C EV915 rx msg S 93,K,-1,0,stopped,standard,290,282,70,331,100,15,7,21,0,0,0,-1,15694 2013-04-08 21:34:33.704216 -0400 info main: #53 C EV915 rx msg S 92,K,-1,0,stopped,standard,285,283,70,331,100,15,7,21,0,0,0,-1,15694 (sorry for the gaps - lousy cellular reception in my garage makes connectivity spotty) It has got me a little worried, thinking perhaps that there is something else that 'triggers' the CAC recalculation (perhaps in the DIAG screens). Regards, Mark. On 12 Apr, 2013, at 1:43 AM, Tom Saxton wrote:
Mark,
I think the CAC code is ready for release. I am continuing to work on a method to detect precisely when CAC changes but that's not as important as getting the already excellent CAC support out there.
I've largely confirmed that CAC updates happen along with the SOC settling that occurs typically about 10 minutes after a charge or drive event, and at no other time. That seemed to be the case in my manual checking over the last couple of months and has held up since I've started doing careful monitoring and logging.
For testing, I have created custom firmware that checks the CAC value according to your code, plus on the charge settle after a drive or charge, and also every five minutes. It records timestamps for these various events, including when it gets a changed CAC value. So far, all four of my recent CAC updates have fit this model.
I may be the only Roadster owner on the planet who cares about knowing exactly when the CAC changes, because I'm correlating that with data in the VMS log file. I think what you have now is ready for the 2.3.1 release, and is a big win for people contributing to the Roadster battery survey where I don't care about the small day-to-day variations in CAC.
I may eventually propose a change to when OVMS queries the CAC, assuming the data continues to hold up.
I'd also like to test on a v2.x Roadster to make sure they behave the same way.
In case anyone else cares, below is a log of my test results so far.
Tom
-------
April 8:
17:46:50 drive ended, car turned off 17:56:53 SOC updated (triggers a CAC request) 17:56:53 CAC updated from 149.62 to 149.60
23:01:09 drive ended, car turned off 23:10:52 CAC updated to 149.57 (note: about 10 minutes after drive end) 23:49:51 SOC updated
The CAC happened about 10 minutes after the charge ended. I suspect there was an SOC update at that point, otherwise the CAC update would not have been noticed until the second 5-minute update after the drive end at 23:11:11 (periodic updates happen every 5:01). I believe another SOC adjust happened and got recorded over the timestamp of the first.
April 9:
05:07:40 charge ended (according to VMS log) 05:17:50 CAC value updated to 149.82 05:22:11 SOC update (probably a second update after the charge)
The charge end time was not recorded due to a bug, but I pulled the charge end time from the VMS log and confirmed that the CAC update happened about 10 minutes after the charge end. Again, the SOC update time probably got clobbered by second update.
At this point, I fixed the code to record only the first SOC update after a charge or drive, and fixed the bug that prevented the end-of-charge from being recorded.
April 10:
When I actually recorded the end-of-charge event, it overflowed the 160-character SMS message limit on the status message, so I couldn't retrieve the data. Fortunately, the CAC apparently didn't change with the overnight charge. I created a new CAC command to give me enough room to show all of the recorded events.
16:27:20 charge ended 16:37:23 SOC updated (triggers a CAC request) 16:37:23 CAC value updated to 149.86
on 4/11/13 7:41 AM, Mark Webb-Johnson wrote:
China is bugging me for final firmware for the next batch of hardware. I need to get them this early next week.
I've committed what I need for the Tesla Roadster (and framework). Last outstanding small change to make is to send CAC as 999.99, rather than the current 99999, using Tom's new library function.
Michael B & J: can you check Twizzy and Volt/Ampera, to see if everything is ok with current firmware or there is anything you need changed?
I plan to cut release candidate for 2.3.1 on Sunday.
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
Mark, I wouldn¹t expect the CAC to change during a charge, even if your firmware is querying for new values during that time. I¹m only seeing the CAC change about 10 minutes after a charge, or drive, and not every time. My CAC changes pretty often when I do a drive/charge cycle: sometimes after the drive, sometimes after the charge, sometimes both, occasionally neither. Perhaps the v2.x Roadsters have a different CAC calculation that¹s less volatile than the v1.5 Roadsters. I¹d be interested to hear from other v2.x Roadster owners about how their CAC values change. If anyone is interested, I can share my custom firmware that records info on when the CAC changes. Send me a private message if you¹d like to geek out on CAC values. Tell me your hardware version and time zone offset, as I have to do a special build for each time zone so I can convert from GMT to local time correctly. Tom From: Mark Webb-Johnson <mark@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Fri, 12 Apr 2013 09:04:08 +0800 To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Subject: Re: [Ovmsdev] Release Firmware Tom, I'm not seeing any change to my CAC, for the past few weeks. It has kept stable at 156.94. <snip charge records> It has got me a little worried, thinking perhaps that there is something else that 'triggers' the CAC recalculation (perhaps in the DIAG screens). Regards, Mark.
participants (4)
-
Mark Webb-Johnson -
Michael Balzer -
Nikki Gordon-Bloomfield -
Tom Saxton