Happy new year everyone :) As you may have seen, I submitted a rework of the network framework yesterday. My goals were to a) eliminate hard coded delays as far as possible to get faster command responses, b) more stable/reliable tickers and c) higher frequency logging. I've managed to achieve goals a & b. Commands are now processed in around one second instead of three, and logging is now very stable, for example GPS streaming will be very close to one entry every three seconds. Higher frequency logging would be possible, but I've run into a hardware issue with this: the modem (both 908 and 808 versions) runs into under voltage problems if GPRS sends occur faster than once every three seconds on average. This will even work when the GSM cell does not change, but if the modem also needs to switch cells on the road, it occasionally just powers down without warning. This may also happen when the modem needs very high send power levels, i.e. if the next GSM tower is far away. The hardware design document says: /"The transmitting burst will cause voltage drop and the power supply must be able to provide sufficient current up to 2A. For the VBAT// //input, a decoupling capacitor (low ESR) such as a 100 μF is strongly recommended."// / ...and the same problem could be solved here by adding a 10 µF buffer capacitor to the power supply line: https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7 So higher frequency logging may be possible when the modem does not need to power up its own GPS circuit, i.e. when the car supplies GPS coordinates. One GPS (speed) mark every three seconds is still sufficient, now it's stable. Btw, I also think I fixed the buffer overrun issue. I could reproduce the bug by timing a command send to arrive at the module at the moment the module starts a send itself. I then found some potential buffer problems with this case in the net_poll() code. Since fixing them I had no more events and can no longer trigger the bug with that command timing. Please let me know if you run into new issues with this rework. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two? At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes). I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend. I'll read out the EEPROM and test with your updated framework tomorrow.
Sorry, haven't done a batch build before checking in... Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them? Your description matches what could happen with the buffer bug. Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict. Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;) Regards, Michael Am 03.01.2017 um 23:55 schrieb Tom Parker:
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two?
At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes).
I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend.
I'll read out the EEPROM and test with your updated framework tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
I will have a look at this tonight, and move things around as necessary. Regards, Mark.
On 4 Jan 2017, at 7:57 AM, Michael Balzer <dexter@expeedo.de> wrote:
Sorry, haven't done a batch build before checking in...
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
Regards, Michael
Am 03.01.2017 um 23:55 schrieb Tom Parker:
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two?
At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes).
I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend.
I'll read out the EEPROM and test with your updated framework tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OK. That was a bit of a mess and took some tidying up. I moved NissanLeaf and Mitsubishi to production (and removed them from experimental). Also fixed a small twizy compilation issue (for compiling without twizy config option enabled). Memory status is now: V1_Production: 91% data, 92% program V2_Experimental: 99% data, 85% program V2_Production: 96% data, 76% program V2_TR_Production: 93% data, 76% program V2_RT_Production: 97% data, 100% program - about 130 bytes free All pushed to github. Regards, Mark.
On 4 Jan 2017, at 9:11 AM, Mark Webb-Johnson <mark@openvehicles.com> wrote:
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
I will have a look at this tonight, and move things around as necessary.
Regards, Mark.
On 4 Jan 2017, at 7:57 AM, Michael Balzer <dexter@expeedo.de> wrote:
Sorry, haven't done a batch build before checking in...
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
Regards, Michael
Am 03.01.2017 um 23:55 schrieb Tom Parker:
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two?
At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes).
I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend.
I'll read out the EEPROM and test with your updated framework tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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, thanks for tidying up :) Btw: I removed the private and generated MPLAB IDE files from the git repository and extended the .gitignore accordingly, but I got two of those files back from your commit: vehicle/OVMS.X/nbproject/Makefile-impl.mk vehicle/OVMS.X/nbproject/private/configurations.xml Maybe that's because you had already checked in these files in commit 0ed00448471ae3e5cab22b0e831bb3bacbfb2581 before merging my repository cleanup. I've just checked in their removal again, please check if you need to remove them manually though. Thanks, Michael Am 04.01.2017 um 14:50 schrieb Mark Webb-Johnson:
OK. That was a bit of a mess and took some tidying up.
I moved NissanLeaf and Mitsubishi to production (and removed them from experimental).
Also fixed a small twizy compilation issue (for compiling without twizy config option enabled).
Memory status is now:
1. V1_Production: 91% data, 92% program 2. V2_Experimental: 99% data, 85% program 3. V2_Production: 96% data, 76% program 4. V2_TR_Production: 93% data, 76% program 5. V2_RT_Production: 97% data, 100% program - about 130 bytes free
All pushed to github.
Regards, Mark.
On 4 Jan 2017, at 9:11 AM, Mark Webb-Johnson <mark@openvehicles.com <mailto:mark@openvehicles.com>> wrote:
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
I will have a look at this tonight, and move things around as necessary.
Regards, Mark.
On 4 Jan 2017, at 7:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Sorry, haven't done a batch build before checking in...
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
Regards, Michael
Am 03.01.2017 um 23:55 schrieb Tom Parker:
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two?
At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes).
I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend.
I'll read out the EEPROM and test with your updated framework tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Looks good. Nothing to be done at my end. Regards, Mark
On 8 Jan 2017, at 1:40 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
thanks for tidying up :)
Btw: I removed the private and generated MPLAB IDE files from the git repository and extended the .gitignore accordingly, but I got two of those files back from your commit:
vehicle/OVMS.X/nbproject/Makefile-impl.mk vehicle/OVMS.X/nbproject/private/configurations.xml
Maybe that's because you had already checked in these files in commit 0ed00448471ae3e5cab22b0e831bb3bacbfb2581 before merging my repository cleanup. I've just checked in their removal again, please check if you need to remove them manually though.
Thanks, Michael
Am 04.01.2017 um 14:50 schrieb Mark Webb-Johnson:
OK. That was a bit of a mess and took some tidying up.
I moved NissanLeaf and Mitsubishi to production (and removed them from experimental).
Also fixed a small twizy compilation issue (for compiling without twizy config option enabled).
Memory status is now:
V1_Production: 91% data, 92% program V2_Experimental: 99% data, 85% program V2_Production: 96% data, 76% program V2_TR_Production: 93% data, 76% program V2_RT_Production: 97% data, 100% program - about 130 bytes free
All pushed to github.
Regards, Mark.
On 4 Jan 2017, at 9:11 AM, Mark Webb-Johnson <mark@openvehicles.com <mailto:mark@openvehicles.com>> wrote:
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
I will have a look at this tonight, and move things around as necessary.
Regards, Mark.
On 4 Jan 2017, at 7:57 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Sorry, haven't done a batch build before checking in...
Maybe it's time to move the Leaf & Mitsubishi modules to the production build? Is there anything still experimental about them?
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
Regards, Michael
Am 03.01.2017 um 23:55 schrieb Tom Parker:
On 03/01/17 00:44, Michael Balzer wrote:
As you may have seen, I submitted a rework of the network framework yesterday.
The experimental firmware doesn't build anymore -- there isn't enough space during linking. I removed some of the other cars and it builds again, do we need to split the experimental configuration in two?
At the weekend I rebased onto master immediately prior to your changes and then managed to mess up my OVMS while doing some development, I haven't looked into what happened but I saw garbage messages relayed through the server, the OVMS android app crashed on startup (sorry no logs), many "Vehicle authentication failed" messages by email and also a "Vehicle is stopped turned on" via SMS and email (I'm using Dexter's server which sends me emails sometimes).
I'm not sure if I ran some bad code of my own or if I fell victim to the buffer problem you've hopefully fixed. My OVMS has been very solid for the last 6 months or so, but I haven't taken any updates until the weekend.
I'll read out the EEPROM and test with your updated framework tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 04/01/17 12:57, Michael Balzer wrote:
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Actually the garbage in the messages is due to a new bug in stp_l2f. This is causing the app to crash because there is junk in the location messages: Wed Jan 4 15:05:08 2017 Server message decodes to: MP-0 L3���52.042460,-3���3.944089,0,0,0,0,0,0,00,0.0,0,0 I've sent a pull request to fix it. I'm not sure why I'm getting alternating authentication failed and authentication succeeded emails from Dexter's server. The "Vehicle is stopped turned on" message is the new "you've left the car on feature" which doesn't work so well because decoding the car's speed isn't implemented in the Leaf. I'll hard code a non-zero value for now and prioritize decoding the speed.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
I'm always keen to hear how well the Nissan support is working. I especially want to hear about the remote climate control as not all Gen 2 cars work and I wonder if models with the Nissan telematics don't work, or vice versa. I really should tidy up and commit the (rather extensive) pile of improvements I have in my personal branch.
Oops... thanks for the stp_l2f fix :) Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur. Am 04.01.2017 um 12:38 schrieb Tom Parker:
On 04/01/17 12:57, Michael Balzer wrote:
Your description matches what could happen with the buffer bug.
Regarding the App crashing: hardening it against garbage data is on my list. It happened also with the buffer bug on the Twizy, because the data parser is a bit too strict.
Actually the garbage in the messages is due to a new bug in stp_l2f. This is causing the app to crash because there is junk in the location messages:
Wed Jan 4 15:05:08 2017 Server message decodes to: MP-0 L3���52.042460,-3���3.944089,0,0,0,0,0,0,00,0.0,0,0
I've sent a pull request to fix it.
I'm not sure why I'm getting alternating authentication failed and authentication succeeded emails from Dexter's server.
The "Vehicle is stopped turned on" message is the new "you've left the car on feature" which doesn't work so well because decoding the car's speed isn't implemented in the Leaf. I'll hard code a non-zero value for now and prioritize decoding the speed.
Btw: I've been in contact with an enthusiastic Leaf owner named Slava from the Ukraine, told him to get in contact with you. He thinks about setting up an OVMS server for his region. As you may have guessed, there is no NissanConnect in the Ukraine... ;)
I'm always keen to hear how well the Nissan support is working. I especially want to hear about the remote climate control as not all Gen 2 cars work and I wonder if models with the Nissan telematics don't work, or vice versa.
I really should tidy up and commit the (rather extensive) pile of improvements I have in my personal branch.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring. At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware. I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is. Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0 I think there must still be a corruption bug somewhere. It might be time to bisect.
Tom, from my logs archive: a) I found "duplicate car login" and "unable to decode" errors from your car beginning on 2016-12-14 15:50 (UTC) ...that was with firmware 2.8.7/NL1.0/V2/V2E9 b) garbage characters first occurred in the "S" messages beginning with 2017-01-01 12:16 ...that was right after changing your firmware to 2.9.2/NL1.0/V2/V2E9 The "L" message corruptions due to the stp_l2f bug started on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9. The "S" corruptions only occur with your car (on my server). My earliest log kept is from 2016-12-10, and your car messages were clean and error free until 2016-12-14 15:50. Can you tell what has changed on 2016-12-14 15:50? Regards, Michael Am 05.01.2017 um 04:08 schrieb Tom Parker:
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring.
At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware.
I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is.
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0
I think there must still be a corruption bug somewhere. It might be time to bisect. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Also, the "S" corruption originates from just a single wrong character inserted in the encoded protocol message, i.e. +cGF352j_<F3>_FeLiJ59cMLlOXpRJhGa7sMGM9Rg/WeXeJuwKGCiuqv8p4FVNCKiHEsEnf9WeNbnm6JGPz7yxD7KjlQtOSVFtHXH2DGUa+C0x5ZaZRiSv6HpLxBkvIEBEu0f4EBPjF+X or +dUShf7R71hcb7msV8SCXu55xEwG9Z3Dx9G4UNuO9V7t7JFnGYwSmrf5aWouO+rm1PdZfQgLENbGLMVbv/tRfkEA+vZRPapkU_<DB>_KSO92hqvnrVcgJOVYNiglaXPqMt92lKXatEVO1 -- IMO that cannot originate from the base64 encoding, so can only come from some UART TX related problem (?) May be a serial log can show what's happening here. Am 05.01.2017 um 13:06 schrieb Michael Balzer:
Tom,
from my logs archive:
a) I found "duplicate car login" and "unable to decode" errors from your car beginning on 2016-12-14 15:50 (UTC) ...that was with firmware 2.8.7/NL1.0/V2/V2E9
b) garbage characters first occurred in the "S" messages beginning with 2017-01-01 12:16 ...that was right after changing your firmware to 2.9.2/NL1.0/V2/V2E9
The "L" message corruptions due to the stp_l2f bug started on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9.
The "S" corruptions only occur with your car (on my server).
My earliest log kept is from 2016-12-10, and your car messages were clean and error free until 2016-12-14 15:50. Can you tell what has changed on 2016-12-14 15:50?
Regards, Michael
Am 05.01.2017 um 04:08 schrieb Tom Parker:
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring.
At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware.
I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is.
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0
I think there must still be a corruption bug somewhere. It might be time to bisect. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Tom, I did some more log digging: a) Since yesterday, your log entries haven't contained any garbage characters. b) "Unable to decode" messages now/still occur on a regular and quite predictable base. The rule seems to be: the next message sent by the car after a "H NL-COM-CAN" message will be broken. This happens independant of the time span between the "H" message and the next, and as the following messages are of varying sizes also independant of the message type. So this looks like a memory corruption coupled to the "H NL-COM-CAN" message generation process, that kills your encryption (or more...). Examples: 2017-01-06 07:40:32.557128 +0100 info main: #26 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A120070020000003B 2017-01-06 07:41:13.198896 +0100 info main: #26 C NZLLEAF rx 6Rm2CahmvSvTu/P7nJMLkUiRqFS1rww6BrxQY7zBF0sQwamaOHBMRbuWby0Gs8P9nrMcW45Ft73uZT93u6sHGTOkUgcdh/fzeGF4gcPSpql4/cC+bksNFJKEjykWVMLJ+cNrvlh5E7DCmA== 2017-01-06 07:41:13.199028 +0100 error main: #26 NZLLEAF error - Unable to decode message - aborting connection 2017-01-06 13:10:03.385363 +0100 info main: #41 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054AA00070020000003A 2017-01-06 13:10:12.587657 +0100 info main: #41 C NZLLEAF rx zZ186U6RmvLkP272bNAP5xk3bRXt5P6Z/X+F86EaNtymnduvZT1o2UKu6+r4LUDGRCXe4vd/jQ== 2017-01-06 13:10:12.587918 +0100 error main: #41 NZLLEAF error - Unable to decode message - aborting connection 2017-01-06 20:35:34.710329 +0100 info main: #68 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A1200700200000039 2017-01-06 20:35:39.556488 +0100 info main: #68 C NZLLEAF rx Tl4PXkvivM+Iq+eeIgNCHKcwqUhY4i/+0igGrXgx/kR89xTBlY3uYQVwRXZfZQnvwDAi+IsojhjncnNVDDhEZ9B6YTv/RGjtx0qdtAEOwBEQPRIwejEtBnNaHpNu8Cu2dwHDUQ8c 2017-01-06 20:35:39.556746 +0100 error main: #68 NZLLEAF error - Unable to decode message - aborting connection Regards, Michael Am 05.01.2017 um 13:20 schrieb Michael Balzer:
Also, the "S" corruption originates from just a single wrong character inserted in the encoded protocol message, i.e.
+cGF352j_<F3>_FeLiJ59cMLlOXpRJhGa7sMGM9Rg/WeXeJuwKGCiuqv8p4FVNCKiHEsEnf9WeNbnm6JGPz7yxD7KjlQtOSVFtHXH2DGUa+C0x5ZaZRiSv6HpLxBkvIEBEu0f4EBPjF+X or +dUShf7R71hcb7msV8SCXu55xEwG9Z3Dx9G4UNuO9V7t7JFnGYwSmrf5aWouO+rm1PdZfQgLENbGLMVbv/tRfkEA+vZRPapkU_<DB>_KSO92hqvnrVcgJOVYNiglaXPqMt92lKXatEVO1
-- IMO that cannot originate from the base64 encoding, so can only come from some UART TX related problem (?)
May be a serial log can show what's happening here.
Am 05.01.2017 um 13:06 schrieb Michael Balzer:
Tom,
from my logs archive:
a) I found "duplicate car login" and "unable to decode" errors from your car beginning on 2016-12-14 15:50 (UTC) ...that was with firmware 2.8.7/NL1.0/V2/V2E9
b) garbage characters first occurred in the "S" messages beginning with 2017-01-01 12:16 ...that was right after changing your firmware to 2.9.2/NL1.0/V2/V2E9
The "L" message corruptions due to the stp_l2f bug started on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9.
The "S" corruptions only occur with your car (on my server).
My earliest log kept is from 2016-12-10, and your car messages were clean and error free until 2016-12-14 15:50. Can you tell what has changed on 2016-12-14 15:50?
Regards, Michael
Am 05.01.2017 um 04:08 schrieb Tom Parker:
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring.
At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware.
I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is.
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0
I think there must still be a corruption bug somewhere. It might be time to bisect. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Interesting. I haven't changed anything in that code for a long time, but I also hadn't noticed it was causing problems so might have been broken for a long time? How do I see these errors? Running my own server? Watching the comms with the modem? It's supposed to send me up to the most recent of 3 different CAN frames (chosen at compile time), once per minute. Looking through the server logs (nice email feature on your server) I see it fairly reliably sends the first frame each minute, but usually not the others. The car is moving, so it's on, so all three frames are present on the bus, so I'm reasonably sure it is trying to send the other 2. I'm sending 3 messages one after the other in this code triggered from ticker60 https://carrott.org/git/Open-Vehicle-Monitoring-System.git/blob/refs/heads/r... Can I just send messages one after the other? The message framework was... complicated. I see in the twizzy telemetry it may only send one message each time it's called? On 07/01/17 08:52, Michael Balzer wrote:
Tom,
I did some more log digging:
a) Since yesterday, your log entries haven't contained any garbage characters.
b) "Unable to decode" messages now/still occur on a regular and quite predictable base.
The rule seems to be: the next message sent by the car after a "H NL-COM-CAN" message will be broken.
This happens independant of the time span between the "H" message and the next, and as the following messages are of varying sizes also independant of the message type.
So this looks like a memory corruption coupled to the "H NL-COM-CAN" message generation process, that kills your encryption (or more...).
Examples:
2017-01-06 07:40:32.557128 +0100 info main: #26 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A120070020000003B 2017-01-06 07:41:13.198896 +0100 info main: #26 C NZLLEAF rx 6Rm2CahmvSvTu/P7nJMLkUiRqFS1rww6BrxQY7zBF0sQwamaOHBMRbuWby0Gs8P9nrMcW45Ft73uZT93u6sHGTOkUgcdh/fzeGF4gcPSpql4/cC+bksNFJKEjykWVMLJ+cNrvlh5E7DCmA== 2017-01-06 07:41:13.199028 +0100 error main: #26 NZLLEAF error - Unable to decode message - aborting connection
2017-01-06 13:10:03.385363 +0100 info main: #41 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054AA00070020000003A 2017-01-06 13:10:12.587657 +0100 info main: #41 C NZLLEAF rx zZ186U6RmvLkP272bNAP5xk3bRXt5P6Z/X+F86EaNtymnduvZT1o2UKu6+r4LUDGRCXe4vd/jQ== 2017-01-06 13:10:12.587918 +0100 error main: #41 NZLLEAF error - Unable to decode message - aborting connection
2017-01-06 20:35:34.710329 +0100 info main: #68 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A1200700200000039 2017-01-06 20:35:39.556488 +0100 info main: #68 C NZLLEAF rx Tl4PXkvivM+Iq+eeIgNCHKcwqUhY4i/+0igGrXgx/kR89xTBlY3uYQVwRXZfZQnvwDAi+IsojhjncnNVDDhEZ9B6YTv/RGjtx0qdtAEOwBEQPRIwejEtBnNaHpNu8Cu2dwHDUQ8c 2017-01-06 20:35:39.556746 +0100 error main: #68 NZLLEAF error - Unable to decode message - aborting connection
Regards, Michael
Am 05.01.2017 um 13:20 schrieb Michael Balzer:
Also, the "S" corruption originates from just a single wrong character inserted in the encoded protocol message, i.e.
+cGF352j_<F3>_FeLiJ59cMLlOXpRJhGa7sMGM9Rg/WeXeJuwKGCiuqv8p4FVNCKiHEsEnf9WeNbnm6JGPz7yxD7KjlQtOSVFtHXH2DGUa+C0x5ZaZRiSv6HpLxBkvIEBEu0f4EBPjF+X or +dUShf7R71hcb7msV8SCXu55xEwG9Z3Dx9G4UNuO9V7t7JFnGYwSmrf5aWouO+rm1PdZfQgLENbGLMVbv/tRfkEA+vZRPapkU_<DB>_KSO92hqvnrVcgJOVYNiglaXPqMt92lKXatEVO1
-- IMO that cannot originate from the base64 encoding, so can only come from some UART TX related problem (?)
May be a serial log can show what's happening here.
Am 05.01.2017 um 13:06 schrieb Michael Balzer:
Tom,
from my logs archive:
a) I found "duplicate car login" and "unable to decode" errors from your car beginning on 2016-12-14 15:50 (UTC) ...that was with firmware 2.8.7/NL1.0/V2/V2E9
b) garbage characters first occurred in the "S" messages beginning with 2017-01-01 12:16 ...that was right after changing your firmware to 2.9.2/NL1.0/V2/V2E9
The "L" message corruptions due to the stp_l2f bug started on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9.
The "S" corruptions only occur with your car (on my server).
My earliest log kept is from 2016-12-10, and your car messages were clean and error free until 2016-12-14 15:50. Can you tell what has changed on 2016-12-14 15:50?
Regards, Michael
Am 05.01.2017 um 04:08 schrieb Tom Parker:
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring.
At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware.
I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is.
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0
I think there must still be a corruption bug somewhere. It might be time to bisect. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
You can now see these error in the "*-OVM-ServerLogs" CSV as well, I've just extended the logging a bit to also capture logins and terminations. For sending data, it's mostly a question of the available modem send buffer and actual network MTU. You can query the available max send size by... AT+CIPSEND=? ...which will normally be around 1460. You need to add base64 encoding and line termination overhead, but that still allows for multiple data rows to be added to one send. That's done simply by doing multiple net_msg_encode_puts() between net_msg_start() and net_msg_send(). Doing multiple net_msg_start() in series without adding proper delays will not work reliably, because the modem needs time to transmit an IPSEND and flush the buffer. The new net_wait4modem() function will assume the modem is ready after 50 ms of RX silence, but that may not be enough to really get the modem ready for the next IPSEND. That's the reason the framework uses the net_msg_sendpending semaphore to know when the modem is definitely available again. So: - If your messages fit (encoded!) into the 1460 byte MTU (better leave some headroom), you can just do this: net_msg_start(); for (index = 0; index < MAX_CAN_DUMP; index++) { prep net_scratchpad, call net_msg_encode_puts() } net_msg_send(); This is the most efficient way. - If they don't fit, you need to split your send. Good practice is to use some notification flags and hook into the idle() or ticker() calls, checking the net_msg_sendpending semaphore. - If you really need to do multiple sends in series, add at least a 3 seconds delay after the net_msg_send() to give the modem enough time to finish the transmission. Regard, Michael Am 07.01.2017 um 09:30 schrieb Tom Parker:
Interesting. I haven't changed anything in that code for a long time, but I also hadn't noticed it was causing problems so might have been broken for a long time? How do I see these errors? Running my own server? Watching the comms with the modem?
It's supposed to send me up to the most recent of 3 different CAN frames (chosen at compile time), once per minute. Looking through the server logs (nice email feature on your server) I see it fairly reliably sends the first frame each minute, but usually not the others. The car is moving, so it's on, so all three frames are present on the bus, so I'm reasonably sure it is trying to send the other 2. I'm sending 3 messages one after the other in this code triggered from ticker60 https://carrott.org/git/Open-Vehicle-Monitoring-System.git/blob/refs/heads/r...
Can I just send messages one after the other? The message framework was... complicated. I see in the twizzy telemetry it may only send one message each time it's called?
On 07/01/17 08:52, Michael Balzer wrote:
Tom,
I did some more log digging:
a) Since yesterday, your log entries haven't contained any garbage characters.
b) "Unable to decode" messages now/still occur on a regular and quite predictable base.
The rule seems to be: the next message sent by the car after a "H NL-COM-CAN" message will be broken.
This happens independant of the time span between the "H" message and the next, and as the following messages are of varying sizes also independant of the message type.
So this looks like a memory corruption coupled to the "H NL-COM-CAN" message generation process, that kills your encryption (or more...).
Examples:
2017-01-06 07:40:32.557128 +0100 info main: #26 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A120070020000003B 2017-01-06 07:41:13.198896 +0100 info main: #26 C NZLLEAF rx 6Rm2CahmvSvTu/P7nJMLkUiRqFS1rww6BrxQY7zBF0sQwamaOHBMRbuWby0Gs8P9nrMcW45Ft73uZT93u6sHGTOkUgcdh/fzeGF4gcPSpql4/cC+bksNFJKEjykWVMLJ+cNrvlh5E7DCmA== 2017-01-06 07:41:13.199028 +0100 error main: #26 NZLLEAF error - Unable to decode message - aborting connection
2017-01-06 13:10:03.385363 +0100 info main: #41 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054AA00070020000003A 2017-01-06 13:10:12.587657 +0100 info main: #41 C NZLLEAF rx zZ186U6RmvLkP272bNAP5xk3bRXt5P6Z/X+F86EaNtymnduvZT1o2UKu6+r4LUDGRCXe4vd/jQ== 2017-01-06 13:10:12.587918 +0100 error main: #41 NZLLEAF error - Unable to decode message - aborting connection
2017-01-06 20:35:34.710329 +0100 info main: #68 C NZLLEAF rx msg H NL-COM-CAN,3,86400,054A1200700200000039 2017-01-06 20:35:39.556488 +0100 info main: #68 C NZLLEAF rx Tl4PXkvivM+Iq+eeIgNCHKcwqUhY4i/+0igGrXgx/kR89xTBlY3uYQVwRXZfZQnvwDAi+IsojhjncnNVDDhEZ9B6YTv/RGjtx0qdtAEOwBEQPRIwejEtBnNaHpNu8Cu2dwHDUQ8c 2017-01-06 20:35:39.556746 +0100 error main: #68 NZLLEAF error - Unable to decode message - aborting connection
Regards, Michael
Am 05.01.2017 um 13:20 schrieb Michael Balzer:
Also, the "S" corruption originates from just a single wrong character inserted in the encoded protocol message, i.e.
+cGF352j_<F3>_FeLiJ59cMLlOXpRJhGa7sMGM9Rg/WeXeJuwKGCiuqv8p4FVNCKiHEsEnf9WeNbnm6JGPz7yxD7KjlQtOSVFtHXH2DGUa+C0x5ZaZRiSv6HpLxBkvIEBEu0f4EBPjF+X or +dUShf7R71hcb7msV8SCXu55xEwG9Z3Dx9G4UNuO9V7t7JFnGYwSmrf5aWouO+rm1PdZfQgLENbGLMVbv/tRfkEA+vZRPapkU_<DB>_KSO92hqvnrVcgJOVYNiglaXPqMt92lKXatEVO1
-- IMO that cannot originate from the base64 encoding, so can only come from some UART TX related problem (?)
May be a serial log can show what's happening here.
Am 05.01.2017 um 13:06 schrieb Michael Balzer:
Tom,
from my logs archive:
a) I found "duplicate car login" and "unable to decode" errors from your car beginning on 2016-12-14 15:50 (UTC) ...that was with firmware 2.8.7/NL1.0/V2/V2E9
b) garbage characters first occurred in the "S" messages beginning with 2017-01-01 12:16 ...that was right after changing your firmware to 2.9.2/NL1.0/V2/V2E9
The "L" message corruptions due to the stp_l2f bug started on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9.
The "S" corruptions only occur with your car (on my server).
My earliest log kept is from 2016-12-10, and your car messages were clean and error free until 2016-12-14 15:50. Can you tell what has changed on 2016-12-14 15:50?
Regards, Michael
Am 05.01.2017 um 04:08 schrieb Tom Parker:
On 05/01/17 02:00, Michael Balzer wrote:
Checking the server log I found another bug I introduced some time ago in the server push notification code. I just restarted the fixed server, tell me if the authentication notifications still occur.
The authentication success/failed messages are still occurring.
At 10:39 today I got a trunk open while in valet mode alert via SMS but not via email and communication stopped. I'm not setting the trunk or valet bits in the leaf firmware.
I'm logging the server traffic with client.pl and I see this, where <FA> represents the raw hex 0xfa and ^E is probably whatever ctrl-e is.
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA> ~^N Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 T0 Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0 Z0 Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0 Z1 Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0 Z0
I think there must still be a corruption bug somewhere. It might be time to bisect. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ 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 * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 08/01/17 01:38, Michael Balzer wrote:
You can now see these error in the "*-OVM-ServerLogs" CSV as well, I've just extended the logging a bit to also capture logins and terminations.
Thank you, that was helpful.
For sending data, it's mostly a question of the available modem send buffer and actual network MTU. You can query the available max send size by...
AT+CIPSEND=?
...which will normally be around 1460. You need to add base64 encoding and line termination overhead, but that still allows for multiple data rows to be added to one send.
I'm not checking the size, can it ever be very low? By sending all the messages in one packet I'm now reliably sending 5 reasonably short messages. I did uncover a bug in the server, I'm sending 4 NL-COM-CAN messages and a NL-COM-HIS message in one packet, I can see all of them arrive in the server logs: 2017-01-13 02:35:09,28654,'#22 C rx msg H NL-COM-CAN,3,86400,054A120070072600003F' 2017-01-13 02:35:09,28655,'#22 C rx msg H NL-COM-CAN,3,86400,054B0078880924000001' 2017-01-13 02:35:09,28656,'#22 C rx msg H NL-COM-CAN,3,86400,054C6566C00000807E00' 2017-01-13 02:35:09,28657,'#22 C rx msg H NL-COM-CAN,3,86400,054F4801090007808836' 2017-01-13 02:35:09,28658,'#22 C rx msg H NL-COM-HIS,0,86400,003F0305001F00B000E000D9' But only the first NL-COM-CAN and the NL-COM-HIS show up in the separate .csv files for the message types. It looks like it's only taking the first message per packet or per second and recording that? I'll be putting this firmware back into my car soon but right now it's not sending those messages.
Am 18.01.2017 um 10:10 schrieb Tom Parker:
AT+CIPSEND=?
...which will normally be around 1460. You need to add base64 encoding and line termination overhead, but that still allows for multiple data rows to be added to one send.
I'm not checking the size, can it ever be very low?
Not sure about that, haven't found any clear info on this. Technically it may get low, but I don't think that really happens on current networks anywhere. I've seen no problems with my largest packet, which is around 1100 bytes (encoded).
By sending all the messages in one packet I'm now reliably sending 5 reasonably short messages.
That looks very good now, no more garbage chars and "unable to decode" errors in the log. Also no broken pipes.
I did uncover a bug in the server, I'm sending 4 NL-COM-CAN messages and a NL-COM-HIS message in one packet, I can see all of them arrive in the server logs:
2017-01-13 02:35:09,28654,'#22 C rx msg H NL-COM-CAN,3,86400,054A120070072600003F' 2017-01-13 02:35:09,28655,'#22 C rx msg H NL-COM-CAN,3,86400,054B0078880924000001' 2017-01-13 02:35:09,28656,'#22 C rx msg H NL-COM-CAN,3,86400,054C6566C00000807E00' 2017-01-13 02:35:09,28657,'#22 C rx msg H NL-COM-CAN,3,86400,054F4801090007808836' 2017-01-13 02:35:09,28658,'#22 C rx msg H NL-COM-HIS,0,86400,003F0305001F00B000E000D9'
But only the first NL-COM-CAN and the NL-COM-HIS show up in the separate .csv files for the message types. It looks like it's only taking the first message per packet or per second and recording that?
Works as designed ;) -- a history entry needs to be unique for ( type, number, timestamp ). Maybe you can just use the loop index as the record number? Regards Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Looks good. But I do see some compilation issues regarding flash space now. Regarding the voltage drop, that is strange. We did test the hell out of this, back-in-the-day, but that was without GPS. Scoped it, and everything seems very smooth even under COPS searching for cellular towers. We have a big capacitor on the 12V side (before the power regulator). Maybe we’re hitting a limit on the power regulator and need extra smoothing on the 3.3V side? Regards, Mark. On 2 Jan 2017, at 7:44 PM, Michael Balzer <dexter@expeedo.de> wrote:
Happy new year everyone :)
As you may have seen, I submitted a rework of the network framework yesterday.
My goals were to a) eliminate hard coded delays as far as possible to get faster command responses, b) more stable/reliable tickers and c) higher frequency logging.
I've managed to achieve goals a & b. Commands are now processed in around one second instead of three, and logging is now very stable, for example GPS streaming will be very close to one entry every three seconds.
Higher frequency logging would be possible, but I've run into a hardware issue with this: the modem (both 908 and 808 versions) runs into under voltage problems if GPRS sends occur faster than once every three seconds on average. This will even work when the GSM cell does not change, but if the modem also needs to switch cells on the road, it occasionally just powers down without warning. This may also happen when the modem needs very high send power levels, i.e. if the next GSM tower is far away.
The hardware design document says: "The transmitting burst will cause voltage drop and the power supply must be able to provide sufficient current up to 2A. For the VBAT input, a decoupling capacitor (low ESR) such as a 100 μF is strongly recommended."
...and the same problem could be solved here by adding a 10 µF buffer capacitor to the power supply line: https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7 <https://forums.tessel.io/t/gprs-module-turns-off-randomly/250/7>
So higher frequency logging may be possible when the modem does not need to power up its own GPS circuit, i.e. when the car supplies GPS coordinates.
One GPS (speed) mark every three seconds is still sufficient, now it's stable.
Btw, I also think I fixed the buffer overrun issue. I could reproduce the bug by timing a command send to arrive at the module at the moment the module starts a send itself. I then found some potential buffer problems with this case in the net_poll() code. Since fixing them I had no more events and can no longer trigger the bug with that command timing.
Please let me know if you run into new issues with this rework.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Mark Webb-Johnson -
Mark Webb-Johnson -
Michael Balzer -
Tom Parker