No OBD data received

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

    users: 1
    seconds: 1207
    since_t: 1603187880
    days: 0
    since_iso: '2020-10-20T09:58:00.085705'
    time: '0:20'
    state: discharging
    voltage: 12.5
    level: 90
    sleep: NONE
    wake: NONE
    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'
    down: sleeping
    up: 'on'
  sleep_interval: 0
  version: '2.1'
  current_state: 'on'
    down: stn
    up: ext

Do’s & dont’s

  • Do not write your unit-id anywhere.

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.

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.

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

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.

1 Like

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.

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([3:])/2.55",
  "unit": "%"

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

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.