No OBD data received

[topeju]

Subject of the issue

For some reason, I’m not able to receive OBD data with my AutoPi from my 1996 Chevrolet Suburban (6.5TD). This did work intermittently yesterday when I received and installed the device, but not today (and not late yesterday evening either).

I do get battery voltage, location and CPU temperature data. Soon after starting, I have heard AutoPi report that the minion is offline.

Your environment

• AutoPi Telematics Unit 4G/LTE Pi3 (3rd gen), software 2020.10.05
• Chevrolet Suburban 6.5TD 1996, using SAE J1850 VPW at 10417 baud
• I have loggers configured for:
  • TIMING_ADVANCE: Timing Advance OBD-II PID Auto
  • THROTTLE_POS: Throttle Position OBD-II PID Auto
  • ENGINE_RPM: Engine RPM PID Auto
  • BOOST_PRESSURE: Boost Pressure PID Auto
  • ENGINE_FUEL_RATE_LH: Engine Fuel Rate [l/h] PID Auto
  • CYLINDER_FUEL_RATE: Cylinder Fuel Rate [mg/stroke] PID Auto
  • ENGINE_FUEL_RATE: Engine Fuel Rate [mm3] PID Auto
  • INTAKE_TEMP: Intake Air Temp OBD-II PID Auto
  • COOLANT_TEMP: Engine Coolant Temperature OBD-II PID Auto
  • ENGINE_LOAD: Calculated Engine Load OBD-II PID Auto
  • SPEED: Vehicle Speed OBD-II PID Auto
  • GET_DTC: Get DTCs OBD-II PID Auto
  • RPM: Engine RPM OBD-II PID Auto

Steps to reproduce

Start car

Expected behaviour

RPM and other PID data should appear in the dashboard.

Actual behaviour

Only non-OBD data shows up in the dashboard.

I saw this in the error output:

2020-10-20 09:53:00,350 [salt.loaded.ext.engines.obd_manager:1375][ERROR][854] Battery event trigger got error result: OBD connection is no longer available as it has been permanently closed
2020-10-20 09:53:09,437 [messaging:208][ERROR][855] Exception in worker thread 'xyz_logger' while running workflow for message: {'filter':  'alternating_readout', 'handler': 'interrupt_query', 'returner': 'cloud',  'args': ['xyz'], 'kwargs': {'decimals': 1}}
2020-10-20 09:53:10,142 [messaging:206][ERROR][855] Recurring exception (2 times) in worker thread 'xyz_logger' while running workflow for message: {'filter': 'alternating_readout', 'handler': 'interrupt_query', 'returner': 'cloud', 'args': ['xyz'], 'kwargs': {'decimals': 1}}
2020-10-20 09:53:10,179 [salt.loaded.ext.engines.obd_manager:1511][ERROR][854] Failed to start OBD manager

(Whitespace mangling above by me, copy-pasting from the console messed up line breaks etc.)

Output of power.status command

rpi:
  uptime:
    users: 1
    seconds: 1207
    since_t: 1603187880
    days: 0
    since_iso: '2020-10-20T09:58:00.085705'
    time: '0:20'
stn:
  battery:
    state: discharging
    voltage: 12.5
    level: 90
  last_trigger:
    sleep: NONE
    wake: NONE
  trigger_config:
    vl_wake: '  >13.00V FOR 3 s'
    vchg_wake: '  +0.50V IN 1000 ms'
    uart_sleep: '  900 s'
    vl_sleep: '  <12.20V FOR 240 s'
    ext_sleep: '  LOW FOR 3000 ms'
    ext_wake: '  HIGH FOR 500 ms'
spm:
  last_state:
    down: sleeping
    up: 'on'
  sleep_interval: 0
  version: '2.1'
  current_state: 'on'
  last_trigger:
    down: stn
    up: ext

Do’s & dont’s

• Do not write your unit-id anywhere.

[topeju]

Oh, I should add that a Wi-Fi OBD-II dongle has worked just fine and has been able to read all of the data I referred to above. Haven’t tried it today though.

[topeju]

Looks like this issue is related to either using too much logging, or the OBD-II interface crashing if unsupported data is requested. The car is one of the first generation with OBD-II ports, so it could be either. I’ve dropped most of the loggers and library commands, and now it seems to work quite stably.

[dgbeatty]

I am having the same problem. 1997 Subaru Legacy and 2016 Nissan Leaf.
No solution as of yet.

[topeju]

OBD-II has been working quite well for me since the end of October. The older OBD-II interfaces only support up to ten queries per second, so I’ve had to set up loggers so that I don’t exceed that amount.

I also had to set up workers manually to query the GM-specific PIDs which require a 24-bit header to be set, as the GUI only supports 12-bit headers.

[carrrl]

Do you have an example of workers logging those extended headers? My vehicle ONLY supports extended headers so this device has been useless to me. Your solution sounds like I could implement all my PIDs this way.

[topeju]

You will have to set the workers up manually through Advanced -> Services -> obd_manager -> Workers. Here, create one or more new workers:

• Name (as desired)
• Start delay (as needed)
• Interval (as needed – I have several workers logging different data at different intervals with start delays set so that they don’t exceed the 10-queries-per-second limit in my old car)
• Add New workflows for the workers (you can have several workflows for each worker, to log different data)
  • Handler: query
  • Args: [ "name_for_the_metric" ] (this is how it will be listed in the graphs etc)
  • kwargs: {"force":true, "pid":"pidInHex", "header":"headerInHex", "mode":"modeInHex", "formula":"yourCustomFormula(...)","unit":"unitsReturned"}
  • Converter: empty
  • Trigger: empty
  • Filter: alternating_readout
  • Enricher: empty
  • Returner: cloud

The workflows here support the extended headers, so for example in my case, to query the throttle position in my Chevy, I use:

{
  "force": true,
  "pid": "5101",
  "mode": "2211",
  "header": "6C10F1",
  "formula": "bytes_to_int(message.data[3:])/2.55",
  "unit": "%"
}

Actually, I don’t have that division by 2.55 or that unit in my setup, oops. But that is somewhat besides the point of the above.