Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/). sharkcow
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause. I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection. Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that. Regards, Michael Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position). So the bad antenna placement actually was the cause in my case, but we can solve that in software. I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds. Please verify. Regards, Michael Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement. Best regards, sharkcow Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position).
So the bad antenna placement actually was the cause in my case, but we can solve that in software.
I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds.
Please verify.
Regards, Michael
Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert? There's the option of raising the alert threshold. It's 500 meters by default (config vehicle flatbed.alarmdistance). But we should first determine the cause of the false alerts. Regards, Michael Am 12.02.21 um 10:28 schrieb sharkcow:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
Best regards,
sharkcow
Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position).
So the bad antenna placement actually was the cause in my case, but we can solve that in software.
I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds.
Please verify.
Regards, Michael
Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OK, in my case OVMS lost the GPS fix for one log entry, then apparently my car took a 400m dive! Strange theft approach... ;-) Took about 10mins. for GPS to be back in the correct position. So, would we want to implement a workaround? Maybe wait with the alert after fix is lost? But then again, if the car really is towed, I'd like to know asap... Thanks, sharkcow Am 12.02.21 um 10:35 schrieb Michael Balzer:
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert?
There's the option of raising the alert threshold. It's 500 meters by default (config vehicle flatbed.alarmdistance). But we should first determine the cause of the false alerts.
Regards, Michael
Am 12.02.21 um 10:28 schrieb sharkcow:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
Best regards,
sharkcow
Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position).
So the bad antenna placement actually was the cause in my case, but we can solve that in software.
I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds.
Please verify.
Regards, Michael
Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Just a side information. On Andorid phones it can take 10 minutes to find the satelites if the time of the phone and the satelites is out of sync. And in that case the position can also be a few 100 meters off track. As soon as the times are in sync the GPS signal is immediately there and the position is correct. Regards Chris Am Freitag, den 12.02.2021, 12:24 +0100 schrieb sharkcow:
OK, in my case OVMS lost the GPS fix for one log entry, then apparently my car took a 400m dive! Strange theft approach... ;-)
Took about 10mins. for GPS to be back in the correct position.
So, would we want to implement a workaround? Maybe wait with the alert after fix is lost? But then again, if the car really is towed, I'd like to know asap...
Thanks,
sharkcow
Am 12.02.21 um 10:35 schrieb Michael Balzer:
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert?
There's the option of raising the alert threshold. It's 500 meters by default (config vehicle flatbed.alarmdistance). But we should first determine the cause of the false alerts.
Regards, Michael
Am 12.02.21 um 10:28 schrieb sharkcow:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
Best regards,
sharkcow
Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position).
So the bad antenna placement actually was the cause in my case, but we can solve that in software.
I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds.
Please verify.
Regards, Michael
Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
> Twice in the last few weeks I've gotten the "possible > theft/flatbed"
alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Besides the GPS lock we've got some additional GPS detail: * Receiver mode (v.p.gpsmode) * Satellite count (v.p.satcount) * HDOP (v.p.gpshdop) * GPS speed (v.p.gpsspeed) Maybe these can help. I've added them to the L record and added a log output on flatbed alerts so we can see what they provide generally and during a false alert. Note: on Teslas we copy the car GPS data so we may need special handling there. Regards, Michael Am 12.02.21 um 12:36 schrieb Chris van der Meijden:
Just a side information.
On Andorid phones it can take 10 minutes to find the satelites if the time of the phone and the satelites is out of sync. And in that case the position can also be a few 100 meters off track. As soon as the times are in sync the GPS signal is immediately there and the position is correct.
Regards
Chris
Am Freitag, den 12.02.2021, 12:24 +0100 schrieb sharkcow:
OK, in my case OVMS lost the GPS fix for one log entry, then apparently my car took a 400m dive! Strange theft approach... ;-)
Took about 10mins. for GPS to be back in the correct position.
So, would we want to implement a workaround? Maybe wait with the alert after fix is lost? But then again, if the car really is towed, I'd like to know asap...
Thanks,
sharkcow
Am 12.02.21 um 10:35 schrieb Michael Balzer:
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert? There's the option of raising the alert threshold. It's 500 meters by default (config vehicle flatbed.alarmdistance). But we should first determine the cause of the false alerts. Regards, Michael Am 12.02.21 um 10:28 schrieb sharkcow:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement. Best regards, sharkcow Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position). So the bad antenna placement actually was the cause in my case, but we can solve that in software. I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds. Please verify. Regards, Michael Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause. I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection. Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that. Regards, Michael Am 09.02.21 um 09:57 schrieb sharkcow: > Hi all, >> Twice in the last few weeks I've gotten the "possible >> theft/flatbed" > alert just as I was backing out of the garage. I have never > received that alert before. I hadn't posted anything yet because > I was waiting to drive the other car and see if has the same > problem. I get this too every once in a while with my e-Up. > Mostly shortly after parking, I think (and tragically, the one > time I'd have needed it because I actually _did_ get towed, I > had crashed OVMS into a boot loop just before :-/). sharkcow _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/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.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I also had theft alerts in the past. The reason - gps stop updating location in the middle of the trip. I don't think it happens due to a bad signal. Regards, Alexander пт, 12 февр. 2021 г. в 11:29, sharkcow <sharkcow@gmx.de>:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
Best regards,
sharkcow
Am 09.02.21 um 18:40 schrieb Michael Balzer:
I found the reason for the false theft/flatbed alert in my case by checking my telemetry archive: the car lost GPS on the road. Coordinates were stale when I parked the car. The stale coordinates were taken as the initial park coordinates, causing an alert when the GPS receiver delivered the next valid data (the actual park position).
So the bad antenna placement actually was the cause in my case, but we can solve that in software.
I've just pushed a fix (untested) for this, consisting of a) making the location module aware of parking coordinate staleness and b) lowering the staleness thresholds for the GPS metrics to 10 seconds.
Please verify.
Regards, Michael
Am 09.02.21 um 10:29 schrieb Michael Balzer:
I had the alert once with my Mii, also shortly after parking. With the module being mounted with the GPS antenna placed under the hood, I assumed that to be the cause.
I doubt it, but I'll check if any of our changes could have had an impact on the GPS movement detection.
Regarding open changes to be included in 3.2.016: sharkcow is currently working on finishing the UpMiiGo TPMS feature, it's already been tested so we'll wait for that.
Regards, Michael
Am 09.02.21 um 09:57 schrieb sharkcow:
Hi all,
Twice in the last few weeks I've gotten the "possible theft/flatbed" alert just as I was backing out of the garage. I have never received that alert before. I hadn't posted anything yet because I was waiting to drive the other car and see if has the same problem.
I get this too every once in a while with my e-Up. Mostly shortly after parking, I think (and tragically, the one time I'd have needed it because I actually _did_ get towed, I had crashed OVMS into a boot loop just before :-/).
sharkcow
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2/12/21 1:28 AM, sharkcow wrote:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?! void OvmsLocations::CheckTheft() { if ((m_park_latitude == 0) && (m_park_longitude == 0)) return; if (StandardMetrics.ms_v_env_on->AsBool()) return; [...] I browsed changes to ovms_location.cpp over the last months and if anything I would think it was less likely to get a theft alert. It's difficult for me to see how upgrading my esp32 hardware could be causing this especially since the gps hardware is in the simcom. My GPS antennas haven't changed recently; the Cadillac is using the onstar antenna in the sharkfin on the roof and the Corvette is using the onestar antenna in the passenger windshield onstar brick. Reception is good in my garage, both cars are usually tracking ~8 satellites. I also have gps installed in my garage that I use for ntpd timekeeping -- there is aluminized insulation in the roof of my condo that all but blocks the signal but nothing like that in the garage roof. On 2/12/21 1:35 AM, Michael Balzer wrote:
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert?
Do I need to turn on logging to the sdcard to see this? As far as I know I'm not doing any logging right now. Craig
Craig, Am 12.02.21 um 19:25 schrieb Craig Leres:
On 2/12/21 1:28 AM, sharkcow wrote:
I got the theft alert again last night, the car had been standing for several hours... so at least in my case I would think the alert trigger is too sensitive compared to the resolution/accuracy of the GPS measurement.
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?!
The cadillac_c2_cts module did set ms_v_env_on before your recent change, the call is on line 113.
I browsed changes to ovms_location.cpp over the last months and if anything I would think it was less likely to get a theft alert.
My recent change of making the GPS coordinates persistent is the only thing that could have caused a change here, but I don't see how that could produce false alerts without a crash/reboot, which didn't happen in any of the reported cases.
It's difficult for me to see how upgrading my esp32 hardware could be causing this especially since the gps hardware is in the simcom. My GPS antennas haven't changed recently; the Cadillac is using the onstar antenna in the sharkfin on the roof and the Corvette is using the onestar antenna in the passenger windshield onstar brick. Reception is good in my garage, both cars are usually tracking ~8 satellites. I also have gps installed in my garage that I use for ntpd timekeeping -- there is aluminized insulation in the roof of my condo that all but blocks the signal but nothing like that in the garage roof.
Rumour has it… https://www.msn.com/en-za/news/other/is-russia-distorting-gps-signals-to-pro... …but there are no Putin palaces in Germany, at least none known yet… ;-)
On 2/12/21 1:35 AM, Michael Balzer wrote:
Please check your "L" log at the time of the alert: what did your GPS data look like just before the alert?
Do I need to turn on logging to the sdcard to see this? As far as I know I'm not doing any logging right now.
As Steve said, I meant the "L" records stored on a V2 server. https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#car-locati... The V2 server stores these, if configured, in the historical messages table, just like "h/H" messages. You can use the V2 perl client (also available at https://github.com/openvehicles/Open-Vehicle-Server/tree/master/clients) or the HTTP API to retrieve them. Or, if you're on my server, you can download the CSV directly from the web UI or using the underlying REST API. If your V2 server isn't configured to store the standard messages, you still can fetch them from your module's logfile by grepping for "ovms-server-v2: Send MP-0 L" lines. Regards, Michael
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2/12/21 1:32 PM, Michael Balzer wrote:
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?!
The cadillac_c2_cts module did set ms_v_env_on before your recent change, the call is on line 113.
I wasn't very clear here; after the first theft alert I saw around the beginning the of month Steve suggested checking ms_v_env_on and *then* I changed the module to manage the metric. So I believe at that time of my first alert there was nothing in the cadillac_c2_cts module itself that was ever changing ms_v_env_on. Craig
Craig, Am 12.02.21 um 22:42 schrieb Craig Leres:
On 2/12/21 1:32 PM, Michael Balzer wrote:
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?!
The cadillac_c2_cts module did set ms_v_env_on before your recent change, the call is on line 113.
I wasn't very clear here; after the first theft alert I saw around the beginning the of month Steve suggested checking ms_v_env_on and *then* I changed the module to manage the metric. So I believe at that time of my first alert there was nothing in the cadillac_c2_cts module itself that was ever changing ms_v_env_on.
According to the git log & git blame, the call on line 113 has been in the module unchanged since you initially added it (commit 4aaf421f9bfcbbd9e2db23f53ff0c7978e469887). Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Am 12.02.21 um 22:57 schrieb Michael Balzer:
Craig,
Am 12.02.21 um 22:42 schrieb Craig Leres:
On 2/12/21 1:32 PM, Michael Balzer wrote:
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?!
The cadillac_c2_cts module did set ms_v_env_on before your recent change, the call is on line 113.
I wasn't very clear here; after the first theft alert I saw around the beginning the of month Steve suggested checking ms_v_env_on and *then* I changed the module to manage the metric. So I believe at that time of my first alert there was nothing in the cadillac_c2_cts module itself that was ever changing ms_v_env_on.
According to the git log & git blame, the call on line 113 has been in the module unchanged since you initially added it (commit 4aaf421f9bfcbbd9e2db23f53ff0c7978e469887).
Ah, sorry, just saw the #ifdef around the case… and your local build also didn't set "notdef"? That's totally strange then. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Am 12.02.21 um 23:02 schrieb Michael Balzer:
Am 12.02.21 um 22:57 schrieb Michael Balzer:
Craig,
Am 12.02.21 um 22:42 schrieb Craig Leres:
On 2/12/21 1:32 PM, Michael Balzer wrote:
I also got a theft alert last night. Considering that I had never seen this alert until a few weeks ago it feels like something has changed. This includes the vehicle_cadillac_c2_cts which until a few days ago was not updating StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And looking at OvmsLocations::CheckTheft() it's not even clear to me that a vehicle module that never sets ms_v_env_on can even trigger an alert?!?!
The cadillac_c2_cts module did set ms_v_env_on before your recent change, the call is on line 113.
I wasn't very clear here; after the first theft alert I saw around the beginning the of month Steve suggested checking ms_v_env_on and *then* I changed the module to manage the metric. So I believe at that time of my first alert there was nothing in the cadillac_c2_cts module itself that was ever changing ms_v_env_on.
According to the git log & git blame, the call on line 113 has been in the module unchanged since you initially added it (commit 4aaf421f9bfcbbd9e2db23f53ff0c7978e469887).
Ah, sorry, just saw the #ifdef around the case… and your local build also didn't set "notdef"?
That's totally strange then.
Nonsense, sorry, it's late. Of course the check in CheckTheft()… if (StandardMetrics.ms_v_env_on->AsBool()) return; …will pass without setting ms_v_env_on, as the bool metric default is false. So your vehicle essentially was "off" all the time, which lets me think the location module could have picked the persistent coordinates as the park coordinates on boot. I'll have a look at that tomorrow. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Am 12.02.21 um 23:12 schrieb Michael Balzer:
So your vehicle essentially was "off" all the time, which lets me think the location module could have picked the persistent coordinates as the park coordinates on boot. I'll have a look at that tomorrow.
It did, and that's perfectly OK that way. What might be missing there is a check for an undefined "on" status: if a vehicle cannot tell driving from parking, there is no point in checking for position changes while parking. Now it would be simple to skip the theft/flatbed check if v.e.on is undefined, but I've done a quick check on the vehicle modules: in many cases the flag won't be set to false on module init (boot), which would mean the theft alert will be disabled after each reboot, for example from an OTA update, as "v.e.on" remains undefined until the vehicle gets awake. IOW, not testing if v.e.on is undefined is the safe option currently. (Btw, some vehicle modules apparently also won't clear the flag when the code misses the switch-off CAN frame or if the polled bus goes offline.) We could add setting v.e.on to false to all vehicles. To keep a persistent "on" value, it should be done like this: if (!StdMetrics.ms_v_env_on->AsBool()) StdMetrics.ms_v_env_on->SetValue(false); …but I hesitate changing logic in vehicle modules just to catch the case of a vehicle not being able to determine the "on" state. I suggest all vehicle developers check their v.e.on logic before we change this. So that explains how you got the theft alert from the persistent coordinates change when you had no v.e.on support. As you now have that support, your new alert isn't explained by this. Did you find some hint in your "L" log on that case? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Sat, 13 Feb 2021 at 12:39, Michael Balzer <dexter@expeedo.de> wrote:
I suggest all vehicle developers check their v.e.on logic before we change this.
Well the bmwi3 logic is like so: 1) v_env_on is initialised to false when the module is initialised 2) When the OBD-2 bus goes dead for 3 seconds I turn off my polling and set v_env_on to false 3) Otherwise, v_env_on is set to (pollerstate == POLLSTATE_READY && StdMetrics.ms_v_env_gear->AsInt() != 0) - i.e. OBD alive, car is responsive on the OBD, and its in gear. You can't put it in gear unless its "ready". This was the best I could do since I can't find an OBD2 that plainly distinguishes "on" (viz accessory position) from "ready" (let's go). If the module boots up and the OBD2 is alive there will be a brief interval of v.e.on being false and as soon as we see obd2 traffic and see the car in gear (that is polled every 4 seconds when the car is READY) then v.e.on will change to true. I suppose that may be enough time for this alarm to go off? Steve -- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
Steve, yes, that may be enough time to trigger an alert, as the modem also will need a couple of seconds to get the first fix after a reboot. If that happens on the highway, you may well reach the alert threshold. A better init option: if (!StdMetrics.ms_v_env_on->AsBool()) StdMetrics.ms_v_env_on->SetValue(false); That takes advantage of the new persistence of the flag. (Persistence cannot currently detect "false" as a defined value on boot, as that's the default bool value.) Furthermore, you can test the flag to see if you should directly set the poll state to your driving mode. Btw, the same applies to most status flags now, so you can for example also detect if a charge session was active before the reboot. Regards, Michael Am 13.02.21 um 19:25 schrieb Steve Davies:
On Sat, 13 Feb 2021 at 12:39, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I suggest all vehicle developers check their v.e.on logic before we change this.
Well the bmwi3 logic is like so:
1) v_env_on is initialised to false when the module is initialised 2) When the OBD-2 bus goes dead for 3 seconds I turn off my polling and set v_env_on to false 3) Otherwise, v_env_on is set to (pollerstate == POLLSTATE_READY && StdMetrics.ms_v_env_gear->AsInt() != 0) - i.e. OBD alive, car is responsive on the OBD, and its in gear. You can't put it in gear unless its "ready". This was the best I could do since I can't find an OBD2 that plainly distinguishes "on" (viz accessory position) from "ready" (let's go).
If the module boots up and the OBD2 is alive there will be a brief interval of v.e.on being false and as soon as we see obd2 traffic and see the car in gear (that is polled every 4 seconds when the car is READY) then v.e.on will change to true.
I suppose that may be enough time for this alarm to go off?
Steve
https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi, Thanks for the input - I'll push you a PR probably Monday - tomorrow Valentine's day and let's not take a chance on "you love that computer more than me" ;-) Steve On Sat, 13 Feb 2021 at 20:41, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
yes, that may be enough time to trigger an alert, as the modem also will need a couple of seconds to get the first fix after a reboot. If that happens on the highway, you may well reach the alert threshold.
A better init option:
if (!StdMetrics.ms_v_env_on->AsBool()) StdMetrics.ms_v_env_on->SetValue(false);
That takes advantage of the new persistence of the flag. (Persistence cannot currently detect "false" as a defined value on boot, as that's the default bool value.)
Furthermore, you can test the flag to see if you should directly set the poll state to your driving mode. Btw, the same applies to most status flags now, so you can for example also detect if a charge session was active before the reboot.
Regards, Michael
Am 13.02.21 um 19:25 schrieb Steve Davies:
On Sat, 13 Feb 2021 at 12:39, Michael Balzer <dexter@expeedo.de> wrote:
I suggest all vehicle developers check their v.e.on logic before we change this.
Well the bmwi3 logic is like so:
1) v_env_on is initialised to false when the module is initialised 2) When the OBD-2 bus goes dead for 3 seconds I turn off my polling and set v_env_on to false 3) Otherwise, v_env_on is set to (pollerstate == POLLSTATE_READY && StdMetrics.ms_v_env_gear->AsInt() != 0) - i.e. OBD alive, car is responsive on the OBD, and its in gear. You can't put it in gear unless its "ready". This was the best I could do since I can't find an OBD2 that plainly distinguishes "on" (viz accessory position) from "ready" (let's go).
If the module boots up and the OBD2 is alive there will be a brief interval of v.e.on being false and as soon as we see obd2 traffic and see the car in gear (that is polled every 4 seconds when the car is READY) then v.e.on will change to true.
I suppose that may be enough time for this alarm to go off?
Steve
https://www.telviva.co.za/legal/email-disclaimer
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>
I got another alert this morning with 3.2.015-655-g1fb83aac in the Cadillac. I believe I've been getting the alert 100% of the time with both cars now. I've appended some anonymized logs (with a slightly different layout from the perl script Steve sent -- I've been working on my own python version). When the alert fires the gps location is ~280 meters from home. But just before there's this: #10 C error - duplicate car login - clearing first connection I assume this is because the car was logged in via wifi and is now logging in via gsm? Some possibly useful info. I have one api.openvehicles.com account with 2 vehicles registered. This vehicle uses the vehicle_cadillac_c2_cts module. Both of my "production" modules were recently upgraded to esp32-wroom v3 modules and have much better wifi signal than before. I'm not driving much during the pandemic and I believe it's true that every theft alert has occurred the first run after rebooting (as a result of pdating firmware -- for example I did not get a theft alert when I started the car after grocery shopping this morning). It looks like both vehicle_cadillac_c2_cts and vehicle_chevrolet_c6_corvette are missing an explicit set of ms_v_env_on to false on init; is this my problem? I reviewed this thread and I think that's what you concluded. Craig Feb 15 06:09:24 2021-02-15 14:09:24 49628 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:09:24 2021-02-15 14:09:24 49629 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1266034,10,0,0,0,12.54,0,12.6,0,0,0,0 Feb 15 06:09:24 2021-02-15 14:09:24 49630 #10 C rx msg L 12.345678,-123.456789,80.9,-4.8,1,1,0,0,0,0,0,0,0,0,AN,9,1.0,0.0 Feb 15 06:09:24 2021-02-15 14:09:24 49631 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,26,1,C2CTS,Team America,-1,-1 Feb 15 06:10:24 2021-02-15 14:10:24 50033 #10 C rx msg a Feb 15 06:19:25 2021-02-15 14:19:25 53266 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:19:25 2021-02-15 14:19:25 53267 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1266635,10,0,0,0,12.56,0,12.6,0,0,0,0 Feb 15 06:19:25 2021-02-15 14:19:25 53268 #10 C rx msg L 12.345678,-123.456789,80.9,-4.7,1,1,0,0,0,0,0,0,0,0,AN,9,1.0,0.0 Feb 15 06:19:25 2021-02-15 14:19:25 53269 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,27,1,C2CTS,Team America,-1,-1 Feb 15 06:25:25 2021-02-15 14:25:25 55431 #10 C rx msg a Feb 15 06:29:26 2021-02-15 14:29:26 56686 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:29:26 2021-02-15 14:29:26 56687 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1267236,10,0,0,0,12.56,0,12.6,0,0,0,0 Feb 15 06:29:26 2021-02-15 14:29:26 56688 #10 C rx msg L 12.345678,-123.456789,80.9,-4.7,1,1,0,0,0,0,0,0,0,0,AN,9,1.0,0.0 Feb 15 06:29:26 2021-02-15 14:29:26 56689 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,26,1,C2CTS,Team America,-1,-1 Feb 15 06:39:27 2021-02-15 14:39:27 60191 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:39:27 2021-02-15 14:39:27 60192 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1267837,10,0,0,0,12.57,0,12.6,0,0,0,0 Feb 15 06:39:27 2021-02-15 14:39:27 60193 #10 C rx msg L 12.345678,-123.456789,80.9,-4.2,1,1,0,0,0,0,0,0,0,0,AN,7,1.5,0.0 Feb 15 06:39:27 2021-02-15 14:39:27 60194 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,26,1,C2CTS,Team America,-1,-1 Feb 15 06:40:27 2021-02-15 14:40:27 60590 #10 C rx msg a Feb 15 06:49:28 2021-02-15 14:49:28 63822 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:49:28 2021-02-15 14:49:28 63823 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1268438,10,0,0,0,12.56,0,12.6,0,0,0,0 Feb 15 06:49:28 2021-02-15 14:49:28 63824 #10 C rx msg L 12.345678,-123.456789,80.9,-3.3,1,1,0,0,0,0,0,0,0,0,AN,8,1.1,0.0 Feb 15 06:49:28 2021-02-15 14:49:28 63825 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,26,1,C2CTS,Team America,-1,-1 Feb 15 06:55:28 2021-02-15 14:55:28 492 #10 C rx msg a Feb 15 06:59:29 2021-02-15 14:59:29 1797 #10 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 06:59:29 2021-02-15 14:59:29 1798 #10 C rx msg D 0,0,5,14,0,85,0,0,0,1269039,10,0,0,0,12.16,0,12.6,0,0,0,0 Feb 15 06:59:29 2021-02-15 14:59:29 1799 #10 C rx msg L 12.345678,-123.456789,80.9,-4.2,1,1,0,0,0,0,0,0,0,0,AN,9,1.0,0.0 Feb 15 06:59:29 2021-02-15 14:59:29 1800 #10 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),,26,1,C2CTS,Team America,-1,-1 Feb 15 07:01:39 2021-02-15 15:01:39 2580 #264 C got proto #0/C login Feb 15 07:01:39 2021-02-15 15:01:39 2581 #10 C error - duplicate car login - clearing first connection Feb 15 07:02:09 2021-02-15 15:02:09 2747 #264 C rx msg L 12.345678,-123.456789,31.5,-3.7,1,1,0,0,0,0,0,0,0,0,AN,10,0.9,0.0 Feb 15 07:02:09 2021-02-15 15:02:09 2748 #264 C rx msg P AVehicle is being transported while parked - possible theft/flatbed (@12.345678;-123.456789) Feb 15 07:10:13 2021-02-15 15:10:13 5360 #264 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 07:10:13 2021-02-15 15:10:13 5361 #264 C rx msg D 0,0,5,14,0,85,0,0,0,1269640,10,0,0,0,12.38,0,12.6,0,0,0,0 Feb 15 07:10:13 2021-02-15 15:10:13 5362 #264 C rx msg L 12.345678,-123.456789,323.5,-6.7,1,1,0,0,0,0,0,0,0,0,AN,9,1.0,0.0 Feb 15 07:10:13 2021-02-15 15:10:13 5363 #264 C rx msg F 3.2.015-655-g1fb83aac/ota_0/main (build idf v3.3.4-846-ga5ee88178-dirty Feb 12 2021 10:27:19),1G6DV5EP9E0123456,18,1,C2CTS,T-Mobile Hologram,-1,-1 Feb 15 07:16:44 2021-02-15 15:16:44 7541 #264 C rx msg a Feb 15 07:19:45 2021-02-15 15:19:45 8541 #264 C rx msg S 27.0,M,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0,0.00,0.00 Feb 15 07:19:45 2021-02-15 15:19:45 8542 #264 C rx msg D 0,0,5,14,0,85,0,0,0,1270241,10,0,0,0,12.39,0,12.6,0,0,0,0
Craig, Am 15.02.21 um 21:53 schrieb Craig Leres:
I'm not driving much during the pandemic and I believe it's true that every theft alert has occurred the first run after rebooting (as a result of pdating firmware -- for example I did not get a theft alert when I started the car after grocery shopping this morning).
It looks like both vehicle_cadillac_c2_cts and vehicle_chevrolet_c6_corvette are missing an explicit set of ms_v_env_on to false on init; is this my problem? I reviewed this thread and I think that's what you concluded.
No, that wasn't my conclusion and that's not your problem. Your server log doesn't provide any insight. I cannot reproduce your alerts and I have no idea what causes them, and why only you seem to have the issue now. My best guess at the moment is that your v.e.on logic doesn't work as designed and sometimes fails to catch the vehicle switch-on. I've extended the log output of the location module now, hoping that may help. Please enable file logging with log level verbose for component "location" and level debug for component "events". The log file cannot catch the boot messages, so please also check a cold and a warm boot process once for the location messages. A cold boot should look like… I (313) location: Initialising LOCATIONS (1900) I (320) location: Expanding DUKTAPE javascript engine I (885) location: UpdateParkPosition: vehicle is parking @0.000000,0.000000 gpslock=0 satcount=0 hdop=0.0 invalid=1 I (58465) location: UpdateParkPosition: vehicle is parking @12.302444,7.389884 gpslock=1 satcount=14 hdop=1.0 invalid=0 D (58475) events: Signal(gps.lock.acquired) D (58475) events: Signal(system.modem.gotgps) V (59475) location: CheckTheft: vehicle parked @12.302444,7.389884 now @12.302319,7.389884 dist=14 smoothed=3 alarm=500 V (60485) location: CheckTheft: vehicle parked @12.302444,7.389884 now @12.302460,7.389893 dist=2 smoothed=4 alarm=500 V (61475) location: CheckTheft: vehicle parked @12.302444,7.389884 now @12.302383,7.389898 dist=7 smoothed=4 alarm=500 A warm boot should look like… I (347) location: Initialising LOCATIONS (1900) I (354) location: Expanding DUKTAPE javascript engine I (930) location: UpdateParkPosition: vehicle is parking @12.302380,7.389940 gpslock=0 satcount=0 hdop=0.0 invalid=1 I (36660) location: UpdateParkPosition: vehicle is parking @12.302277,7.389902 gpslock=1 satcount=10 hdop=2.0 invalid=0 D (36660) events: Signal(gps.lock.acquired) D (36670) events: Signal(system.modem.gotgps) V (39670) location: CheckTheft: vehicle parked @12.302277,7.389902 now @12.302265,7.389982 dist=6 smoothed=2 alarm=500 CheckTheft log entries are only written if the distance changes by 10 or more meters. When switching on the vehicle, you should see a log entry… I (176995) location: UpdateParkPosition: vehicle is driving When switching off after driving, it should look like… I (199415) location: UpdateParkPosition: vehicle is parking @12.302387,7.389946 gpslock=1 satcount=16 hdop=0.8 invalid=0 V (248415) location: CheckTheft: vehicle parked @12.302387,7.389946 now @12.302387,7.389945 dist=0 smoothed=0 alarm=500 Please provide your location and event log messages after the next false alert. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, thanks for pointers on sd card logging. Meanwhile I've figured out my problem is basic and the theft alert is just a symptom. Last week I get sd logging configured and the first time I drove I got to my destination (slightly more than 500m away) and happened to notice that the ovms ios app showed my car had been parked for > 20 days... Thanks to the persistent metrics feature I didn't notice but it appears that my modules haven't communicated with my cars since about the end of January; for example the fuel gauge was at 1/4 but the app showed 87%. So in fact my theft alert problem is that v.e.on is *never* true. Today I did some debugging. I tried running older builds (I keep an archive of everything I actually run) and even went back to the 3.2.015 and 3.2.014 factory builds but when the car is running I don't see any metrics getting updated. I did see a can bus error message but it looks like I didn't capture it. At this point I transitioned to the bench and my dev ovms module. I have a raspberry pi 2 that has a can shield I've used for other projects. I verified that candump/cansend could exchange canbus frames with a prototype arduino project I had sitting around and then plugged it into ovms module. I've appended my test session; I only tried sending from ovms with the pi running "candump any". Given that all three of my modules have canbus issues and the fact that this problem started around the time I swapped esp32 modules I think it's clear that I have a hardware problem related to the new esp32 modules. And it's probably not a bad solder joint as I inspected them with the stereo microscope (and it's not likely I'd botch the same pin(s) on all three modules). Unfortunately I don't have much debugging left this weekend but what do you suggest for my next move? Craig Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.015-718-g3f74c233/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3 OVMS# vehicle status Vehicle module 'Empty Vehicle' (code NONE) loaded and running OVMS# can list can1: Off/1000000 dbc none can2: Off/1000000 dbc none can3: Off/1000000 dbc none OVMS# can can1 start active 500000 Can bus can1 started in mode active at speed 500000bps OVMS# can list can1: Active/500000 dbc none can2: Off/1000000 dbc none can3: Off/1000000 dbc none OVMS# log level verbose can Logging level for can set to verbose OVMS# can log start vfs crtd /sd/can.crtd CAN logging to VFS active: Type:vfs Format:crtd(discard) Filter:off Vehicle:NONE Path:/sd/can.crtd OVMS# can can1 tx standard 87 DEAD E (982009) can: can1: intr=1 rxpkt=0 txpkt=0 errflags=0x8000a2 rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=11 rxpkt=0 txpkt=0 errflags=0x8040a2 rxerr=100 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=15 rxpkt=0 txpkt=0 errflags=0x204000 rxerr=135 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=19 rxpkt=0 txpkt=0 errflags=0x8040a2 rxerr=135 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
Craig, when connecting my bench module to my Arduino CAN shield, I need to add a terminal resistor in between. Did you try that? You could then test if can2 & can3 are also affected. can1 is the internal bus of the ESP32 module, can2/3 are external MCP2515 buses accessed via SPI. If it's can1 only, you could try running some CAN tester using the latest esp-idf driver. Maybe there are differences between the hardware revisions, revision 1 has some hardware bugs in the CAN controller as well. From a first look into the current esp-idf master, there is now a HAL for CAN (now called TWAI "two-way async interface" for whatever reason), and there seem to be some differences between the revisions. But AFAICT only minor ones: https://github.com/espressif/esp-idf/blob/master/components/soc/esp32/includ... Regards, Michael Am 01.03.21 um 02:28 schrieb Craig Leres:
Michael, thanks for pointers on sd card logging. Meanwhile I've figured out my problem is basic and the theft alert is just a symptom.
Last week I get sd logging configured and the first time I drove I got to my destination (slightly more than 500m away) and happened to notice that the ovms ios app showed my car had been parked for > 20 days... Thanks to the persistent metrics feature I didn't notice but it appears that my modules haven't communicated with my cars since about the end of January; for example the fuel gauge was at 1/4 but the app showed 87%. So in fact my theft alert problem is that v.e.on is *never* true.
Today I did some debugging. I tried running older builds (I keep an archive of everything I actually run) and even went back to the 3.2.015 and 3.2.014 factory builds but when the car is running I don't see any metrics getting updated. I did see a can bus error message but it looks like I didn't capture it.
At this point I transitioned to the bench and my dev ovms module. I have a raspberry pi 2 that has a can shield I've used for other projects. I verified that candump/cansend could exchange canbus frames with a prototype arduino project I had sitting around and then plugged it into ovms module. I've appended my test session; I only tried sending from ovms with the pi running "candump any".
Given that all three of my modules have canbus issues and the fact that this problem started around the time I swapped esp32 modules I think it's clear that I have a hardware problem related to the new esp32 modules. And it's probably not a bad solder joint as I inspected them with the stereo microscope (and it's not likely I'd botch the same pin(s) on all three modules).
Unfortunately I don't have much debugging left this weekend but what do you suggest for my next move?
Craig
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.015-718-g3f74c233/ota_0/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
OVMS# vehicle status Vehicle module 'Empty Vehicle' (code NONE) loaded and running OVMS# can list can1: Off/1000000 dbc none can2: Off/1000000 dbc none can3: Off/1000000 dbc none OVMS# can can1 start active 500000 Can bus can1 started in mode active at speed 500000bps OVMS# can list can1: Active/500000 dbc none can2: Off/1000000 dbc none can3: Off/1000000 dbc none OVMS# log level verbose can Logging level for can set to verbose OVMS# can log start vfs crtd /sd/can.crtd CAN logging to VFS active: Type:vfs Format:crtd(discard) Filter:off Vehicle:NONE Path:/sd/can.crtd OVMS# can can1 tx standard 87 DEAD E (982009) can: can1: intr=1 rxpkt=0 txpkt=0 errflags=0x8000a2 rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=11 rxpkt=0 txpkt=0 errflags=0x8040a2 rxerr=100 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=15 rxpkt=0 txpkt=0 errflags=0x204000 rxerr=135 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 E (982009) can: can1: intr=19 rxpkt=0 txpkt=0 errflags=0x8040a2 rxerr=135 txerr=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
(Michael, do you want to continue this thread on the mailing list or would you prefer I open a github issue?) On 2/28/21 11:39 PM, Michael Balzer wrote:
when connecting my bench module to my Arduino CAN shield, I need to add a terminal resistor in between. Did you try that?
My arduino board had a termination resistor, the pi shield did not.
You could then test if can2 & can3 are also affected. can1 is the internal bus of the ESP32 module, can2/3 are external MCP2515 buses accessed via SPI.
Great suggestion; adding a 120Ω termination resistor lets can2 or can3 exchange packets with the pi. (Well that plus learning how the can tx command works compared to the syntax of cansend -- it took me a bit to figure out why "can can2 tx standard 7DF 0201050000000000" was only sending 0x00...)
If it's can1 only, you could try running some CAN tester using the latest esp-idf driver.
Is there one you would suggest?
Maybe there are differences between the hardware revisions, revision 1 has some hardware bugs in the CAN controller as well.
I looked at the hardware errata: https://www.espressif.com/sites/default/files/documentation/eco_and_workarou... but I don't see any indication of V3-only canbus issues.
From a first look into the current esp-idf master, there is now a HAL for CAN (now called TWAI "two-way async interface" for whatever reason), and there seem to be some differences between the revisions. But AFAICT only minor ones:
https://github.com/espressif/esp-idf/blob/master/components/soc/esp32/includ...
The refactoring to twai is unfortunate as it makes it difficult to see relevant changes to can.c... I started by looking for the last version of can.c: git log --all --full-history -- components/driver/can.c that lead me to the last commit on 28-Dec-2020 (29e69a12d). Just prior to that were a couple of interesting commits: https://github.com/espressif/esp-idf/commit/4c3d49e3f083ac9c4114b4ef7d80433f... can: Fix semaphore take in critical section https://github.com/espressif/esp-idf/commit/3be94b69522b128da973ebee315b0593... Merge branch 'bugfix/can_critical_section_logs' into 'master' can: Fix critical section ESP_LOG functions I tried running a can.c from around then. With some include file change it compiled ok but trying to transmit a can frame on can1 results in loss of network connectivity and an infinite stream of can errors logged on the serial console. It might be just be the same errors but with interrupts locked out. Maybe you can make more sense out of these changes. Another strategy I want to try is to look for changes to twai.c, twai_hal_iram.c, and twai_hal.c between the refactoring and master. (A quick search didn't turn up many twai related github issues.) Here are some issues related to the above commits and can.c in general: https://github.com/espressif/esp-idf/issues/4412 ESP_LOG/vprintf fail inside critical section. It`s right? (IDFGH-2270) https://github.com/espressif/esp-idf/issues/4277 can.c calling xSemaphoreTake function from CRITICAL (IDFGH-2115) https://github.com/espressif/esp-idf/issues/3028 [TW#28658] Can driver bug I spent a little time decoding the errflags word. I started by verifying I could tx on can2 and receive with candump on my pi, then moved to can1. Here's an example first error message: E (460709) can: can1: intr=1 rxpkt=0 txpkt=0 errflags=0x8000d9 rxerr=0 txerr=8 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 There are 15 log lines in all with intr= ramping up from 1 to 17. errflags changes from 0x8000d9 to 0x8440d9, then 0x8040d9 and finally 0x204c00. I wrote a quick python script to decode the values, I'll append some decoded values. Meanwhile given the molex series 2004 connectors I used for my car wiring it was simple to switch active polling from can1 to can2 which solves my theft alert issue for my cars. Craig ice 631 % Decode-ovms-can-errflags -dv 0x8000d9 0x8440d9 0x8040d9 0x204c00 # 8000d9 # err_irqs 80 (10000000) err_irqs: bus-err # status 0 (0) status: bus-on, ok, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 8440d9 # err_irqs 84 (10000100) err_irqs: bus-err, err-warning # status 40 (1000000) status: bus-on, error, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 8040d9 # err_irqs 80 (10000000) err_irqs: bus-err # status 40 (1000000) status: bus-on, error, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 204c00 # err_irqs 20 (100000) err_irqs: passive-err # status 4c (1001100) status: bus-on, error, tx-idle, rx-idle, tx-complete, released, no-overrun, rx-buf-empty # ecc 0 (0) ecc: ERR="bit error", TX, FUNCTION="?"
This issue will be solved with this pull request: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/585 Starting with revision 2 of the ESP32, the function of the "enable wakeup interrupt" bit in the interrupt enable register changed to mean "divide BRP by 2". The OVMS SJA1000 code enables "all interrupts except arbitration loss" which includes the wakeup interrupt/divide BRP bit. This causes the can baud to be configured at half the requested speed; a workaround is to set the speed to 2X desired. The (minimal) fix is to clear this bit when revision is >= 2. Since we're not using sleep, we could also just always clear that bit. But in the long run I'm hopeful that the ability to use effectively larger BRP values will mean V3 hardware will be able to run can1 at lower speeds, e.g. 33K. At first I was looking at the can module in the esp-idf; even the old version we're running has code to do with this issue! But cleverly, it's a compile time #ifdef instead of run time check based on observed version (?!?!) I think the way it works is you define CONFIG_ESP32_REV_MIN to the lowest hardware version you want to support and it assumes you have at least that. Which seems silly to me. I tried converting it to a run time check and it didn't work -- that's when I figured out OVMS uses it's own SAJ1000 driver code. Thanks to Thomas Heuer for reaching out to me and giving a pointer to this forum post: https://www.esp32.com/viewtopic.php?t=15581#p59670 which was key in figuring this out. Craig
Craig, nice analysis & solution, merged. Using the config macro would have been OK though, we will need to introduce separate builds for revision 3 anyway to benefit from the fixed SPIRAM issue. Btw: did you find some time to do the performance tests I suggested? Doesn't take long, just a couple of minutes. Regards, Michael Am 10.03.21 um 05:47 schrieb Craig Leres:
This issue will be solved with this pull request:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/585
Starting with revision 2 of the ESP32, the function of the "enable wakeup interrupt" bit in the interrupt enable register changed to mean "divide BRP by 2". The OVMS SJA1000 code enables "all interrupts except arbitration loss" which includes the wakeup interrupt/divide BRP bit. This causes the can baud to be configured at half the requested speed; a workaround is to set the speed to 2X desired.
The (minimal) fix is to clear this bit when revision is >= 2. Since we're not using sleep, we could also just always clear that bit. But in the long run I'm hopeful that the ability to use effectively larger BRP values will mean V3 hardware will be able to run can1 at lower speeds, e.g. 33K.
At first I was looking at the can module in the esp-idf; even the old version we're running has code to do with this issue! But cleverly, it's a compile time #ifdef instead of run time check based on observed version (?!?!) I think the way it works is you define CONFIG_ESP32_REV_MIN to the lowest hardware version you want to support and it assumes you have at least that. Which seems silly to me. I tried converting it to a run time check and it didn't work -- that's when I figured out OVMS uses it's own SAJ1000 driver code.
Thanks to Thomas Heuer for reaching out to me and giving a pointer to this forum post:
https://www.esp32.com/viewtopic.php?t=15581#p59670
which was key in figuring this out.
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 3/10/21 7:09 AM, Michael Balzer wrote:
Using the config macro would have been OK though, we will need to introduce separate builds for revision 3 anyway to benefit from the fixed SPIRAM issue.
And I am already turning off CONFIG_SPIRAM_CACHE_WORKAROUND since all of my modules are V3 so if we were using the esp-idf version of the SAJ1000 driver I could have just set CONFIG_ESP32_REV_MIN to 3. (But I also wouldn't have had a problem since I don't think the esp-idf driver ever turns on the sleep interrupt.) I guess I'd like us to be able to produce a factory image that runs on everything, even if it's not optimal. Currently there are no factory image I can run on my upgraded modules.
Btw: did you find some time to do the performance tests I suggested? Doesn't take long, just a couple of minutes.
I did but my numbers were slightly worse than yours and I got side tracked before looking into it further. Will try again this weekend. Craig
participants (6)
-
Alexander K -
Chris van der Meijden -
Craig Leres -
Michael Balzer -
sharkcow -
Steve Davies