Vehicles with keyless entry keep sending CAN messages, keeping VI alive

[zacnelson]

I've encountered an issue where the VI does not completely go to sleep after the vehicle powers down and the driver has left the vehicle and locked the car. And so begins the story of the VI lights:

Chapter 1:
When I first lock the car, I see the blue light turn to red (bluetooth is disconnected this whole time). The red light then goes off after about 5 seconds. This is expected. After about 5 more seconds, the red light comes back on and remains on for 5 seconds. The light then turns off for a brief moment (~0.1 seconds) and then turns back on. This process repeats about 10 times maybe and then the light stays off.

Chapter 2:
After about 30 seconds of peace, the red light turns back ON for a little bit and then turns blue. The blue light then turns off. The light remains off for about 5-10 seconds and then this process repeats.

I think this is the PID response power mode. Shouldn't this be disabled with SILENT_CAN= DEFAULT_POWER_MANAGEMENT? Also, when the red light turns blue as described in Chapter 2, would that mean that the vehicle BUS is now active and we're getting a PID response back?

I've tried a build with the latest version of vi-firmware. The compile options I am using are as follows:

-      FORDBOARD = PLATFORM
-      1         = BOOTLOADER
-      0         = DEBUG
-      0         = DEFAULT_METRICS_STATUS
-      1         = DEFAULT_ALLOW_RAW_WRITE_USB
-      0         = DEFAULT_ALLOW_RAW_WRITE_UART
-      0         = DEFAULT_ALLOW_RAW_WRITE_NETWORK
-      0         = DEFAULT_UART_LOGGING_STATUS
-      JSON      = DEFAULT_OUTPUT_FORMAT
-      0         = DEFAULT_EMULATED_DATA_STATUS
-      SILENT_CAN= DEFAULT_POWER_MANAGEMENT
-      0x1       = DEFAULT_USB_PRODUCT_ID
-      0         = DEFAULT_CAN_ACK_STATUS
-      0         = DEFAULT_OBD2_BUS
-      0         = DEFAULT_RECURRING_OBD2_REQUESTS_STATUS

Also got the same result with:

-      1         = DEFAULT_OBD2_BUS

[creitz]

I can confirm the behavior of chapter 1.

[peplin]

Chapter 1 is the expected behavior with the DEFAULT_POWER_MANAGEMENT set to OBD2_IGNITION_CHECK, and yeah, it should not do that if it's SILENT_CAN. Did you try or can you make sure to run make clean after changing any of the flags? The Makefile doesn't properly detect and recompile files if the flags have changed (#231).

For Chapter 2,

Also, when the red light turns blue as described in Chapter 2, would that mean that the vehicle BUS is now active and we're getting a PID response back?

Yes, sounds like it's getting a response.

[zacnelson]

hey @peplin, for Ch. 1 I did confirm that I did a make clean between compiles. Maybe we tackle this issue before getting into Ch 2. Might be the same thing causing both.

[peplin]

I think somehow either:

• The 'make clean' isn't working as intended, and the firmware isn't re-built properly
• The re-flashing isn't working, and the VI is actually still running an older firmware with power management set to OBD2_IGNITION_CHECK

I just tried this a couple of times with the exact same options with PLATFORM=FORDBORD exported as an environment variable:

> export PLATFORM=FORDBOARD
> make clean
rm -rf build/FORDBOARD
rm -rf build/tests

> make -j4
....
Compiled with options:
-      FORDBOARD = PLATFORM 
-      1         = BOOTLOADER 
-      0         = DEBUG 
-      0         = DEFAULT_METRICS_STATUS 
-      1         = DEFAULT_ALLOW_RAW_WRITE_USB 
-      0         = DEFAULT_ALLOW_RAW_WRITE_UART 
-      0         = DEFAULT_ALLOW_RAW_WRITE_NETWORK 
-      0         = DEFAULT_UART_LOGGING_STATUS 
-      JSON      = DEFAULT_OUTPUT_FORMAT 
-      0         = DEFAULT_EMULATED_DATA_STATUS 
-      SILENT_CAN= DEFAULT_POWER_MANAGEMENT 
-      0x1       = DEFAULT_USB_PRODUCT_ID 
-      0         = DEFAULT_CAN_ACK_STATUS 
-      1         = DEFAULT_OBD2_BUS 
-      0         = DEFAULT_RECURRING_OBD2_REQUESTS_STATUS 
Compiled successfully for FORDBOARD running under a bootloader.

Here are two videos that show the expected LED behavior:

No CAN Bus Attached

Video 1

• No CAN bus attached
• VI wakes up when powered via USB and defaults to red LED because no CAN activity is detected
• Interface LED flashes green briefly as the USB subsystem is initialized, and we detect nobody is reading from USB yet
• After 5 seconds of no CAN activity, the VI suspends and does not wake up as no CAN activity is ever detected.

CAN awake, then sleeping

Video 2

• VI is plugged in and suspended
• I unlock the doors, which wakes up the CAN bus - the CAN activity LED immediately goes to blue
• After 30 seconds, the CAN bus sleeps.
• 5 seconds after that, the VI detects no further CAN activity and suspends. It does not wake up again unless I unlock the doors, open the door start the car, etc - anything to wak up the bus again.

What's next?

Zac, can you try changing the version number temporarily in config.cpp to make sure your VI is actually running the intended build?

[zacnelson]

@peplin thanks for the notes and videos. I agree that what you saw is the expected behavior I'm looking for.

I just tried again this time with v6.0.2 (so the config.cpp file was updated) but unfortunately I got the same results. I also updated openxc-python prior to compiling.

I saw the update about using Vagrant. I'm not sure if something is getting lost in Cygwin, but I'd like to get it to a place where it's working before switching to Vagrant.

[peplin]

Very weird!

I just tried again this time with v6.0.2 (so the config.cpp file was updated) but unfortunately I got the same results.

Triple-checking: you ran openxc-control version and it reported back v6.0.2 after flashing the new build?

[zacnelson]

I didn't run that originally, but I just did and yes, Device is running version 6.0.2 (type-6)

[zacnelson]

@creitz what firmware and vehicle were you testing with?

[creitz]

@zacnelson 6.0.1 Fordboard binary release, 2013 Escape.

[zacnelson]

okay @peplin @creitz i did a bit more testing. It looks like there is a periodic signal on the CAN bus every few seconds. My guess is that this is for keyless ignition (push button start/stop) vehicles like the 2013 Escape that Charles tested and the 2014 Fiesta ST that I tested. The VI wakes up every few seconds after receiving CAN traffic and I get ignition_status over USB.

It looks like this isn't an issue with the vi-firmware and @peplin's testing in the Mustang confirms this.

This does bring up the question: with more and more vehicles going towards keyless ignition, how do we minimize the power draw from the VI if there's still periodic CAN traffic? If the vehicle CAN bus never completely goes to sleep then I don't think we can have a good SILENT_CAN trigger (it does go to sleep for at least 50% of the time based on my testing).

I want to test this in a few more vehicles to confirm, but I think we're good for a release in its current state.

[peplin]

Interesting - I think we can come up with a good solution. We can't avoid the wakeup on CAN traffic (it's an external interrupt from the CAN controller that wakes the MCU), but we can check the value of the ignition_status if a signal with that name is defined and we received it. This is similar to what the OBD2_IGNITION_STATUS power mode does - it wakes up in the lowest possible power state, and only fires up the rest of the VI (USB, BT, etc) if the ignition is on.

[zacnelson]

That makes sense - I like the idea.

I know we don't have ignition_status signals sorted out in the public binary releases due to different vehicles having keyed vs. keyless ignition.

What about waiting for multiple CAN signals to be received? We could say something like:

if (at least 4 mapped signals have been received OR ignition_status != OFF) {
    fully_wake_up();
} else {
    stay in low power state until CAN goes to sleep();