Well, for my car this event has occurred twice in a few months, so the idea of running a CAN bus dump in a wifi session all the time is not practical. What we would need would be a CAN bus dump to rotating files, like the error message logging can do. -- Steve On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:
Steve,
What should I look for when this false alarm occurs? Is it likely that the alarm is issued when stable GPS operation is restored, so what I really would need to see is a log of conditions before the alarm?
What we would ideally need would be at the time of the issue:
metric list v.p CAN bus dump (can1) ID #100, B1=0x83,0x84,0x85
I appreciate that is hard. Perhaps just leave a CAN bus dump running over wifi throughout the event? You could leave that running for hours. We could then replay that back through a box to recreate the issue.
And now that I have issued some messages in the app, how do I switch back to other functions? Is there a way to make the keyboard drop and then find the buttons at the bottom of the screen? (I realize that restarting the app would be a solution.)
Just click on the screen, away from the keyboard.
Regards, Mark.
On 2 Apr 2019, at 5:47 AM, Stephen Casner <casner@acm.org> wrote:
Mark,
The false alarm occured again a few minutes ago. I wanted to use the web shell UI to check some status, but using the new messages feature of the iPhone app I found the wifi was wedged again. After I turned wifi off and then back to client mode I would log in from the web again. I issued a location status command that indicated good lock.
What should I look for when this false alarm occurs? Is it likely that the alarm is issued when stable GPS operation is restored, so what I really would need to see is a log of conditions before the alarm?
And now that I have issued some messages in the app, how do I switch back to other functions? Is there a way to make the keyboard drop and then find the buttons at the bottom of the screen? (I realize that restarting the app would be a solution.)
-- Steve
On Mon, 1 Apr 2019, Mark Webb-Johnson wrote:
I don't see this on the Model S vehicle.
I suspect the issue is not handling GPS lock indicator correctly in the vehicle modules. For the roadster, we use ID#100, B1=0x85 (GPS direction and altitude), B2==1 to control this, but that was always a 'best guess' without much data to back it up.
Regards, Mark.
On 31 Mar 2019, at 11:12 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
This message reminds me to mention that both Timothy Rodgers and I have received false alarm car-theft notifications from OVMS. Have you? I presume these are caused by temporary inaccuracy in the GPS signal.
-- Steve