LEMON Manuals: Even more car manuals for everyone: 1960-2025
Home >> Mercedes Benz >> 2024 >> Sprinter 3500XD Van Cargo, RWD >> Repair and Diagnosis (Single Page) >> TMC Recommended Practices >> Onboard Vehicle Electronics >> RP 1227 - Mobile Device Communication API >> RP 1227 - Mobile Device Communication API >> 6. Functional Specification >> 6.1 Required High-Level Functionality (Single Application)
April 5, 2026: LEMON Manuals is launched! Read the announcement.

6.1 Required High-Level Functionality (Single Application)

Item Notes
Single Application The VDA API shall support a minimum of one executable application using the VDA at a time (Single Application). This application can spawn sub-processes, threads, applets, ActiveX controls, etc that share the data bus connection.
From that single application, the VDA API shall allow up to 16 RP1210_Client-Connect ()  calls to any number of protocols, or the same protocol. Each client will have its' own filter sets and RP1210 variables, allowing each client to be complete separate from one another.
Supporting 16 J1939 Addresses The VDA API shall support the protection of 16 different J1939 addresses, including handling of RTS/CTS messages for those 16 addresses. These addresses can be claimed from one or more clients, and the VDA API will respond with address/NAME data for each upon request.
This is an RP1210B addition. In order for an application to know if an API has implemented this feature, a new variable [Vendorlnformation]-> J1939Addresses=X  is present. This variable should not exist (not known), or should be 16 or greater if the VDA vendor has implemented this feature.
Automatic Bit Rate Detection on CAN Related Protocols The VDA API shall support automatic baud rate detection for all CAN-related protocols when a client connects using "Protocol:Baud=Auto" (i.e. "J1939:-Baud=Auto").  When doing the automatic baud detection, the VDA may not cause error frames to appear on the CAN bus.
Send/Receive Message Buffering Since Microsoft Windows™ is event-driven; an API satisfying this RP must support this feature. There must be implicit support for asynchronous communication. Blocking (synchronous) requirements have been removed from all functions except RP1210_ReadMessage ()  in this revision 09/2011.
Time-Stamping of Messages Since messages received from the vehicle data link are buffered by the API, there must be a time-stamp associated with each message to resolve ambiguity and establish an order of precedence between successive messages. The timestamp is four bytes in length and is in Big Endian (MSB) or Motorola format. See the 15. RP1210_READMESSAGE  function for the definition and layout of the timestamp. The resolution of the timestamp is implementation-dependent and is given in the API vendor's INI file.
Version Reporting The API shall be able to report its software version information. In RP1210B, there was a more detailed function implemented called RP1210_ReadDetailed-Version. 
RP1210 Variables/Filters Each client gets their own set of RP1210 variables (i.e., J1708 Raw/Converted Mode, Echo On/Off)  and complete set of filters, that are independent from all other clients.
Message Filtering The API must support message filtering as specified in the definition of the RP1210_SendCommand  function. An implementation of the API shall provide each client with exactly those messages as are specified in its filter specification. Each client gets their own separate set of message filters that are completely independent from all other clients.
scientia non olet · About LEMON Manuals