DauntlessOBD Developer & API Info

Developer and serial terminal user information for the DauntlessOBD device and our CAN Interface board

Notices

All information and app compatibility is provided as-is with no guarantee or warranty of any kind, and is subject to change without notice. Dauntless Devices LLC shall not be liable for your use, misuse, or inability to use these or other features.

DauntlessOBD, Dauntless Devices, and associated logos are trademarks of Dauntless Devices LLC. This product and its documentation are Copyright © 2024 Dauntless Devices LLC. All Rights Reserved.

We do not claim any endorsement by, or affiliation with, ELM Electronics, or any other product or manufacturer, unless explicitly stated. All trademarks are property of their respective owners, and are referenced to provide compatibility information.

You may not represent yourself, your apps, or other products as originating from us, or being officially endorsed by us unless we choose to make such a statement ourselves. Instead, please use appropriate referential language such as “works with DauntlessOBD by Dauntless Devices LLC” or “YourApp for DauntlessOBD”, provided that it is in a manner that would not cause consumers to believe that your app or product came from us or is endorsed by us.

Wired Communications

The wired communications port is compatible with USB 2.0 via a USB-C type connector. It functions as a CDC Serial device. This should show up as a “COMx:” port in Windows, and something like /dev/tty.usbmodemXXXX in macOS and /dev/ttyACM0 in Linux (Ubuntu and others; make sure your user account has permission to access it). The baud rate setting shouldn’t really matter, and you can enter 115200.

In addition to supporting the ELM327 command set and DauntlessOBD commands described here, the wired communications mode also accepts the GVRET protocol for use with tools such as SavvyCAN.

Wireless Communications: LE Mode (DauntlessOBD devices)

Users should first use the official Dauntless OBD app to securely pair this product to their mobile device, and then afterwards other compatible apps running on that same mobile device can easily communicate with it. Although this product will always appear in scans (unless in sleep mode), serial communications will not function unless the devices have been paired with each other, and pairing attempts will not be successful unless the device is in pairing mode at the time (which requires the user to press a button on the device to enter). Our app streamlines all of that first-time setup for the user, and can provide them with any future firmware updates, etc.

This product implements serial communications in a manner compatible with many serial-over-BLE implementations, using common generic 16-bit service and characteristic UUIDs. This will work with most serial terminal apps that support BLE, and most general purpose serial-over-BLE sample code should also be relevant, when provided with the correct UUIDs.

  • Device Name: DauntlessOBD_XXXXXX (where XXXXXX is the last 6 characters of the serial number)
  • Service UUID: fff0 (16-bit) / 0000fff0-0000-1000-8000-00805f9b34fb (128-bit)
  • Read Characteristic UUID: fff1 (16-bit) / 0000fff1-0000-1000-8000-00805f9b34fb (128-bit)
  • Write Characteristic UUID: fff2 (16-bit) / 0000fff2-0000-1000-8000-00805f9b34fb (128-bit)

Wireless Communications: Wi-Fi Mode Option (DauntlessOBD devices)

In addition to the default LE wireless communications, it is also possible to temporarily switch this device to use Wi-Fi communications instead. This requires Firmware v1.3.3 or newer.

Generally, LE mode is preferred for ease of use / setup and more consistent data stream sampling rates for apps, while Wi-Fi mode can offer much higher total performance, especially when transferring larger data payloads. However its latency may be less consistent when handling large numbers of small packets, such as typical OBD PID or data stream polling.

Wi-Fi Mode will need to be enabled before use. Once enabled, the status light will indicate this by changing from a slow occasional flash (LE mode) to steady medium-speed on/off flashing (Wi-Fi mode).

To enable Wi-Fi mode, either press the device button 3 times fast, or connect via LE wireless or USB and send the command “DD WR 1”. It can be disabled by sending “DD WR 0” to return to LE mode. It will also automatically return to LE mode upon the next power cycle.

  • WiFi Access Point Name: DauntlessOBD_XXXXXX (where XXXXXX is the last 6 characters of the serial number)
  • Default Password: 12345678
  • IP Address: 192.168.0.10
  • TCP Port: 35000
  • (for app compatibility, this IP & Port is the same as many other ELM327 compatible devices)

Quick Start Examples

Get Current Engine RPM (OBD-II)

DDWD       (set defaults like "ATD", and turn headers and line-feeds on)
ATSP A6    (automatic OBD protocol detection; start with Protocol 6, CAN-11 500k)
DIPR RPM   (request current Engine RPM - Formatted value)
-or-
01 0C      (request current Engine RPM - Raw OBD-II HEX data)

View Available Parameters (OBD-II)

DDWD       (set defaults like "ATD", and turn headers and line-feeds on)
ATSP A6    (automatic OBD protocol detection; start with Protocol 6, CAN-11 500k)
DIPQ       (query all supported parameters; for use with "DIPR" and others)
DIPR RPM   (request current Engine RPM - Formatted value)
DIPR SPD   (request current Vehicle Speed - Formatted value)
DIPR xxxx  (request your choice of parameter from the DIPQ results)

Monitor Live CAN Traffic

(Most newer vehicles will not have CAN traffic visible via the OBD port due to the use of a gateway. This works better for many mid-2000’s to mid-2010’s vehicles, notably excluding VW/Audi/Porsche and certain others, or when using our CAN Interface wired directly into a specific CAN bus behind the gateway)

DDWD       (set defaults like "ATD", and turn headers and line-feeds on)
DDTR       (detect CAN rate and traffic type)
-or-
DDTRV      (same as above, then adds snapshot of traffic and observed entropy)
DDWD       (set defaults like "ATD", and turn headers and line-feeds on)
ATTP 81    (temp set protocol to Raw CAN 500k; see Protocol ID list for others) 
DDSS 1     (turn CAN snapshots on)
DDSS       (report snapshot of latest value for each CAN Frame ID)
-or-
DDSSV      (report snapshot with interval and age in milliseconds)
DDWD       (set defaults like "ATD", and turn headers and line-feeds on)
ATTP 81    (temp set protocol to Raw CAN 500k; see Protocol ID list for others) 
DDMOF 1    (don't stop monitoring if buffer overflows)
DDMA       (monitor all traffic)
(send any character to exit monitor)

Supported Protocol IDs

Supported Protocol ID list for use with “ATSP” / “ATTP” / “STP” commands.

Command Set

For maximum compatibility and control, DauntlessOBD accepts the ELM327 v2.2 “AT” command set, as applicable to CAN communications (excluding J1939), as well as our “DD” and “DI” command sets which are summarized below:

Common “DD” Commands

(These common commands are shared across other products. Be sure to also see the second “DD” command list further below, for commands specific to this product.)

CommandNameNotes
DD CTDevice Core TemperatureTypically higher than the ambient air temp, may not be very accurate
DD HWHardware and Firmware InfoTechnical information unlikely to be useful to 3rd party apps. Most future feature or API changes will be based on the version reported by “DD I”
DD IProduct Name & VersionExample: “DauntlessOBD v1.0”

We also anticipate a future “DauntlessOBD+” product, which may have different configurations and will include a list of capabilities.
Example: “DauntlessOBD+ v1.0.13 (CAN 6/14, CAN_3/11, K-Line)”
Example: “DauntlessOBD+ v1.0.13 (CAN 6/14, CAN_SW_1)”
DD LEFAST 0/1Enable Fast LE CommunicationsEnables faster LE comms for the current session. Off by default to mitigate race conditions within some older apps (particularly on Android). Requires Firmware v1.4.2
DD PWRDevice / Vehicle Power Level (Volts)Similar to “AT RV”, which is also supported. Note that this requires a DauntlessOBD device, and will not produce a valid result on our bare CAN Interface board.
DD SNDevice Serial NumberHexadecimal device serial number
DD SSCAN Traffic SnapshotReports the most recent data packet received for each CAN ID. Like “DD TRV” but an instant one-shot. Send “DD SS 1” to enable before first use.
DD SSVCAN Traffic Snapshot – VerboseLike “DD SS”, adds includes data age and interval (in milliseconds)
DD TRCAN Traffic ReportPassively detects bus data rate (if not already set), type (11 vs 29 bit or mixed), and message volume of connected CAN. Requires traffic to be present on the CAN (unlikely if connected via the OBD port on modern cars, due to gateway).
May be followed by a ‘1’ – ‘9’ indicating time (250ms increments) to monitor each data rate tested; traffic at the detected rate will be monitored for 4x this value.
DD TRVCAN Traffic Report – VerboseLike “DD TR”, adds specific observed IDs, frame data / entropy, and counts
DD TRR
DD TRRV
CAN Traffic Report – Refresh Bus RateSame as “DD TR” / “DD TRV”, but guarantees a fresh bus rate detection
DD UPDevice UptimeHow long device has been running since power-up or last reboot

DauntlessOBD Enhanced “DD” Commands

CommandNameNotes
DD ACCELGet Data Acceleration SettingReturns “1” or “0”, followed by a list of decoders in use
DD ACCEL 0/1Turn Data Acceleration Off / OnPotentially extreme performance boost for SAE data PIDs (Service 01 and 22) on supported vehicles; CAUTION: This setting is stored and will be applied to future sessions as well; please use “DI ACCEL T” for temporary changes
DD ACCEL T 0/1Temporarily Turn Data Accel Off / OnSame as “DD ACCEL”, but does not store the setting; next power cycle will return to previous setting
DD AB (base64)Base64-encoded Data Request & Response w/ Auto ISO-15765 ProcessingSends request in BASE-64 format and returns response as BASE-64 (both are case-sensitive); 50% more space-efficient than using HEX.
Automates ISO-15765 multi-frame sends and processing of any multi-frame replies.
Caution: very long Tx or Rx messages may encounter communication buffer issues, limit to 256 bytes if practical.
DD AH (hex)Hex Data Request w/ Auto ISO-15765 ProcessingSends request in HEX format and returns response as a simple HEX string.
Automates ISO-15765 multi-frame sends and processing of any multi-frame replies.
Caution: very long Tx or Rx messages may encounter communication buffer issues, limit to 256 bytes if practical.
DD AT (hex)Hex Data Request w/ Auto ISO-15765  – Print Response as TextSame as “DD AH (hex)”, but interprets the response in ASCII text characters. Non-text bytes are replaced with a ‘?’. The service mode response byte is not included, however the first character or two may still appear as junk (typically from binary data indicating the requested pid or a count)
DD CRAReset CAN FiltersSame as sending “AT CRA” with no parameters
DD CRA hhh / hhhhhhhhAdd CAN Filter for a Receive AddressSame format as “AT CRA”, but can be used repeatedly to add multiple filters: Parameter is a single address to listen for (3 or 8 hex characters); ‘X’ character may be used as a wildcard
DD CRA pattern, maskAdd CAN Filter with Pattern and MaskParameters are Pattern and Mask, same formats used as “AT CF” and “AT CM”, but combined into one command and allows multiple filters
DD GVRETEnter GVRET Binary Command InterpeterRequires USB connection; Also works automatically if sending GVRET binary commands after 30 sec of other command inactivity; exit it with “+++EXIT” followed by a Carriage Return character
DD MAMonitor All TrafficLike “AT MA” but shows all traffic, rather than applying filters; see also “DD SS” for an instant snapshot
DD MFMonitor Filtered TrafficLike “AT MA”, shows traffic subject to current filter settings, if set. If no filters have been set, shows all traffic
DD MIMonitor InputsFor device troubleshooting; Send any character to exit
DD MOF 0/1Monitor Overflow AllowedIf enabled, “BUFFER FULL” errors will be reported but will not cause Monitor modes to exit; if encountering overflows, consider using a USB connection or use the “DD SS” command as needed instead of live monitoring
DD PCProtocol CloseSame as “AT PC”
DD PM A intervalMs, txId, dataAdd a Periodic MessageAdds a new periodic message (max 16), and returns a Handle ID (hex character, starting with zero); intervalMs is milliseconds (min = 10 ms), txId = Header ID, data = frame bytes (if protocol is ISO-15765, then the PCI byte will automatically be inserted)
DD PM A intervalMs, txId, dlc, dataAdd a Periodic MessageAdds a new raw CAN periodic message with variable length; dlc = length of frame; data may be up to 8 bytes, this will not insert an ISO-15765 PCI byte, and will pad with zeros if DLC is higher than the number of bytes in data; if dlc=0 with no data, an RTR frame will be sent
DD PM CClear all Periodic MessagesClears all periodic messages
DD PM R hRemove a periodic MessageRemoves the periodic message for the given Handle ID
DD POProtocol OpenOpens the current protocol; see “DD PC” to close it
DD SMA (hex)Send and Monitor All TrafficSends a hex data string as normal (single frame), then immediately enters “DD MA” mode, eliminating the possibility of missing a response before entering Monitor mode as a separate command
DD SMF (hex)Send and Monitor Filtered TrafficSends a hex data string as normal (single frame), then immediately enters “DD MF” mode; very similar to a normal send, but keeps listening until you send a character to exit Monitor mode
DD WDSet Defaults for Terminal SessionLike “AT D”, but enables line feeds and headers
DD WR 0/1Wi-Fi Radio Off / OnControls the Wi-Fi mode option. When it is off (default), LE wireless will be active. Device will also return to default LE mode after a power cycle. Required Firmware v1.3.3 or newer.

DauntlessOBD Data Interpreter “DI” Commands

“DI” commands are designed to simplify OBD and enhanced data, typically using default settings and automatic protocol selection. However, many lower-level settings will be applied here if set. It can be good practice to send an “AT D” and your other desired init commands first, to ensure consistent results.

For maximum data stream performance, subscribe to desired parameters via “DI PS”, then enter monitor mode with “DI PM” to monitor the stream or “DI PSS” for a single snapshot; this is faster than “DI PR” requests which can be limited by wireless communication lag.

* Module-specific commands will always include the module address “header”, regardless of the Response Header setting.

CommandNameNotes
DI CAL* Calibration IDsComma-separated list of Calibration ID strings for each module
DI CVN* Calibration Verification NumbersComma-separated list of 32-bit CVNs (in HEX format) for each module
DI DCLRClear Diagnostic DataCommands all modules unless Header is set to a physical address. Clears DTCs and resets diagnostics data via Services 04 and 14 (UDS). Permanent DTCs and ongoing faults may not be cleared.
DI DCLR hhhClear Diagnostic Data on Specific ModuleSame as DCLR but only applies to one specific module (specify its response ID as reported by “DI DTC” or “DI ECU” commands). Requires Firmware v1.4.1 or newer.
DI DTCReport DTCs as Text LinesQueries all modules unless Header is set to a physical address. Aggregates DTCs from Services 03, 07, 0A, and 19 (UDS). Sends  “NO DTCS FOUND” if none set. Turn on Response Headers to see which module the DTC is from.
DI ECU* Electronic Control Unit ListDiscovers ECU module response IDs and names (covers standard OBD modules, plus additional modules on supported vehicles)
DI METRIC 0/1Metric Units Off/OnMetric is default, turn off for US Imperial
DI MONEmissions Monitor Status since Codes ClearedFormatted as multiple text lines; see also “DI TEST” for actual test values
DI MONCEmissions Monitor Status for this Drive CycleFormatted as multiple text lines
DI PC n, hhh, …Set Custom CAN ParameterEnables custom parameter “CANn”. hhh is the ID, followed by the DBC Signal String for decoding. Example: “DI PC 0, 0x123, RPM : 0|16@1+ (0.25,0)”. Requires Firmware v1.0.4 or newer.
DI PMMonitor Parameter Data Stream (Text Lines)Streams subscribed data parameters in simple text format, like “DI PR” or “DI PSS” requests but automatically sends all subscribed parameters, avoiding wireless polling lag; prefixed with the sample time in milliseconds; send any character to exit
DI PM nnnnMonitor Parameter Data Stream with Rate Limit“DI PM” with a configurable reporting rate limit; helpful for comm buffer overflows or lags, especially with wireless comms; Parameter is the minimum time between individual parameters, in units of 100 microseconds (eg 0.1 milliseconds); range: 0 – 10000 (1 second)
DI PQQuery Parameters SupportedLists this vehicle’s supported Parameter IDs, acceleration status, and descriptions
DI PQ RQuery Parameters Supported – Force RefreshSame as “DI PQ”, but forces a refresh (useful if a module wasn’t responding during a previous automatic query)
DI PR wxyzParameter Data Request (Text)Returns parameter data as a simple text string. Support varies by vehicle; Use “DI PQ” to get options supported on the connected vehicle; See DI Parameter List for master list. Reponse will not include module address
DI PS XXXXClear Subscribed ParametersResets the parameter list so that you can start fresh
DI PS ALLSubscribe to All ParametersSubscribes to all supported parameters; Caution: this will reduce individual parameter performance. For best results, only subscribe to specific desired parameters
DI PS DFLTSubscribe to Default ParametersResets the parameter list to the most common parameters
DI PS wxyzSubscribe to Parameter(s)Adds the specified parameter(s) to the data reported by “DI PM” and “DI PSS”; May be one Parameter ID or a comma-separated list; Support varies by vehicle; Use “DI PQ” to get options supported on the connected vehicle; See DI Parameter List for master list
DI PSSSnapshot of Parameter Data Stream (Text Lines)Reports every supported subscribed parameter and its current value; params not supported by the vehicle generally will not be included in this list
DI TESTEmissions Monitor Test DataReports monitor test values (Service 06 data on CAN OBD vehicles); Names/Descriptions provided are for convenience and may not always be accurate; Refer to vehicle’s Service Manual for test descriptions and result interpretation; See also “DI MON” for monitor summaries.
DI VINReport the VINReturns VIN on first line, and a basic North American year & make decode on second line, if available (decoding will vary between firmware versions; model names only available for select vehicles); single response, reports first VIN response received from any module
DI VINRReport the VIN (force refresh)Same as DI VIN, but forces a refresh of the data from the car. Requires Firmware v1.2.3 or newer.