oSIST prEN 15430-1:2023
(Main)Winter and road service area maintenance equipment - Data acquisition and transmission - Part 1: In-vehicle data acquisition
Winter and road service area maintenance equipment - Data acquisition and transmission - Part 1: In-vehicle data acquisition
This document specifies a standardized protocol for downloading data from the equipment control box to an in vehicle board computer to ensure interchangeability between a vehicle and different equipment that the same vehicle can carry.
It specifies the interface connection as well as variables, records and reports which permit standardized protocol to cover applications with the greatest possible variety of equipment for performing winter maintenance and road service area maintenance.
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung - Teil 1: Datenerfassung im Fahrzeug
Dieses Dokument legt ein genormtes Protokoll für das Übertragen von Betriebsdaten von der Anbau-Gerätesteuerung (Steuergerät) zu einem im Fahrzeug befindlichen Bord-Computer fest, um die Kompatibilität zwischen dem Fahrzeug und den verschiedenen Anbau-Geräten, die an diesem Fahrzeug betrieben werden können, sicherzustellen.
Es legt sowohl Schnittstellen (Anschlüsse) als auch Variablen, Datensätze und Meldungen fest, die es in dem genormten Protokoll ermöglichen, eine größtmögliche Vielfalt bei Anwendungen von Anbau-Geräten beim Straßenbetriebs- und Winterdienst abzudecken.
Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et transmission des données - Partie 1 : Acquisition des données véhiculaires
Le présent document spécifie un protocole normalisé pour le téléchargement des données entre le boîtier de commande matériel et un ordinateur embarqué afin d’assurer l’interchangeabilité entre un véhicule et les différents matériels pouvant être embarqués à bord du véhicule.
Elle spécifie l’interface de connexion, ainsi que les variables, les enregistrements et les rapports qui permettent au protocole normalisé de couvrir des applications avec des matériels les plus variés pour réaliser la viabilité hivernale et l’entretien des dépendances routières.
Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem in prenos podatkov - 1. del: Zajem podatkov v vozilu
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN 15430-1:2023
01-marec-2023
Nadomešča:
SIST EN 15430-1:2015
Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem
in prenos podatkov - 1. del: Zajem podatkov v vozilu
Winter and road service area maintenance equipment - Data acquisition and
transmission - Part 1: In-vehicle data acquisition
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung
- Teil 1: Datenerfassung im Fahrzeug
Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et
transmission des données - Partie 1 : Acquisition des données véhiculaires
Ta slovenski standard je istoveten z: prEN 15430-1
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
43.160 Vozila za posebne namene Special purpose vehicles
oSIST prEN 15430-1:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 15430-1:2023
---------------------- Page: 2 ----------------------
oSIST prEN 15430-1:2023
DRAFT
EUROPEAN STANDARD
prEN 15430-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2023
ICS 35.240.60; 43.160 Will supersede EN 15430-1:2015
English Version
Winter and road service area maintenance equipment -
Data acquisition and transmission - Part 1: In-vehicle data
acquisition
Matériels de viabilité hivernale et d'entretien des Winterdienst- und Straßenbetriebsdienstausstattung -
dépendances routières - Acquisition et transmission Datenerfassung und -übertragung - Teil 1:
des données - Partie 1 : Acquisition des données Datenerfassung im Fahrzeug
véhiculaires
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 337.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15430-1:2023 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Abbreviations . 7
5 Communication between vehicle/equipment and board-computer . 8
5.1 General . 8
5.2 Communication through RS232 . 8
5.2.1 RS232 interface on vehicle/equipment “Data transmission handler” . 8
5.2.2 RS232 interface on “Board-computer” . 8
5.2.3 Communication protocol . 9
6 Definitions of variables, records and report . 13
6.1 General . 13
6.2 Data integrity check . 13
6.3 Variable types . 14
6.4 Recommended SLOTs for variable definitions . 17
6.5 Definition of variables . 19
6.5.1 General . 19
6.5.2 General variables . 19
6.5.3 General geographic position system variables . 20
6.5.4 General vehicle and route variables . 21
6.5.5 General road weather and road condition variables . 21
6.5.6 Plough/Broom variables . 22
6.5.7 Snow blower or cutter variables . 23
6.5.8 Spreader/sprayer variables . 23
6.5.9 Grass or branch cutting machine variables . 26
6.5.10 Sweeper variables . 27
6.5.11 Safety post cleaning machine variables . 27
6.5.12 Boat plants cutter variables . 28
6.5.13 Weight system variables . 28
6.6 Definition of records . 28
6.6.1 General . 28
6.6.2 Time synchronization record (record code 0) . 29
6.6.3 Standard header record (record code 1) . 29
6.6.4 Standard footer record (record code 2) . 30
6.6.5 Trigger conditions for record code 3 and higher . 30
6.6.6 Geographic position data record (record code 3) . 31
6.6.7 Vehicle and route data record (record code 4) . 32
6.6.8 Weather and road condition data record (record code 5) . 33
6.6.9 Snowplough/broom data record (record code 6/7) . 34
6.6.10 Spreader/sprayer data record (record code 8) . 35
6.6.11 Snow blower/cutter data record (record code 9) . 37
6.6.12 Grass/branch cutter data record (record code 10) . 38
6.6.13 Sweeper data record (record code 11) . 40
2
---------------------- Page: 4 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
6.6.14 Safety post cleaning machine data record (record code 12) . 42
6.6.15 Boat plants cutter data record (record code 13) . 43
6.6.16 Weight system data record (record code 14) . 44
6.6.17 Free definable data record (record code 10000 and higher) . 45
6.7 Report definition . 47
Bibliography . 48
3
---------------------- Page: 5 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
European foreword
This document (prEN 15430-1:2023) has been prepared by Technical Committee CEN/TC 337 "Road
operation equipment and products", the secretariat of which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 15430-1:2015.
The following changes have been implemented in this new edition:
— Multiple corrections and clarifications
Replaced ASCII with extended ASCII, Basic Date remarks, correction of typing errors.
— Excluded semicolon from the STRING_X specification
— Added ManufVersion to the general variables
This allows distinguishing between different interpretations of the manufacturer.
— Changed type of GeoAlt to allow negative altitudes
— Added MaxVehSpd indicating the maximum speed over the last period.
This allows a more precise interpretation of the spread amount.
— Both SprCntBrineL and SprCntBrineKg are mandatory
Both are needed for the data processing systems, remark that only one is mandatory is removed.
— Added Weight system data record
Allowing transmission of weight data collected by weighing cells.
— Several corrections on the sweeper variables and the sweeper data record
Corrected some typo’s and missing variables and variable definition.
4
---------------------- Page: 6 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Introduction
This protocol is meant to be used for data acquisition in fleet management applications in the field of
municipal vehicles. The purpose of the protocol is to define how data of a vehicle or equipment is
generated, stored and transferred to a board-computer system in the vehicle and from the board-
computer to the software application in the office (refer to Figure 1). On the equipment or vehicle the
data is generated by a “Data generator”. This data is stored, if present, into a buffer-memory. The “Data
transmission handler” will send the data present in the buffer-memory to the “Board-computer” or “Data
Acquisition System”. The buffer-memory is there to ensure that data does not get lost in case there is no
transmission possible. The size or type of the buffer is not defined in this proposal. If there is no buffer or
the buffer is too small to store new data, data will get lost.
To synchronize time-stamps of the vehicle/equipment with the Board-computer, a special record for time
synchronization is defined.
In this part, the data acquisition and communication from vehicle/equipment to the Board-computer is
defined.
Figure 1 — Architecture
In general, the data is a semi-colon (“;”) separated extended ASCII text for separation of record codes and
values of variables. CR+LF is used for separation of records (one record is one line of text).
5
---------------------- Page: 7 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Examples of an on-board system configuration.
Figure 2 — Diagram of possible connections
6
---------------------- Page: 8 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
1 Scope
This document specifies a standardized protocol for downloading data from the equipment control box
to an in-vehicle board computer to ensure interchangeability between a vehicle and different equipment
that the same vehicle can carry.
It specifies the interface connection as well as variables, records and reports which permit standardized
protocol to cover applications with the greatest possible variety of equipment for performing winter
maintenance and road service area maintenance.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
NMEA 0183, Interface Standard
TIA-232-F, Interface between data terminal equipment and data circuit-terminating equipment employing
serial binary data interchange (RS232)
SAE J1939/71, Recommended practice for serial control and communications vehicle network — Vehicle
application layer
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
4 Abbreviations
ACK Acknowledge (ASCII control code 06 )
h
ASCII American national Standard Code for Information Interchange
Bps Bits per second
CRC-16 Cyclic Redundancy Code with 16 bits
CRC-32 Cyclic Redundancy Code with 32 bits
CR Carriage Return (ASCII control code 0D )
h
EOT End Of Transmission (ASCII control code 04 )
h
Number before h is in hexadecimal notation
h
IEEE Institute of Electrical and Electronics Engineers
7
---------------------- Page: 9 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
LF Line Feed (ASCII control code 0A )
h
NAK Negative acknowledge (ASCII control code 15 )
h
SOH Start Of Header (ASCII control code 01 )
h
TBD To Be Defined
↲ CR + LF (carriage return + line feed)
5 Communication between vehicle/equipment and board-computer
5.1 General
The data exchange between vehicle/equipment “Data transmission handler” and the “Board-computer”
shall follow at least one of the communication standards described in the present document version or
future release. Until now, only the RS232 standard (TIA-232-F) is defined as a communication standard
so that means that at the present a compliant EN 15430 “Data transmission handler” has to supply a
RS232 interface, if in the future other standard interfaces will be defined (e.g. CAN BUS, USB .) a
compliant EN 15430 future “Data transmission handler” will have to supply at least one of the
communication standard until that time is defined.
5.2 Communication through RS232
5.2.1 RS232 interface on vehicle/equipment “Data transmission handler”
— Connector: SUB-D 9p female
— Pin 2 = Transmit Data
— Pin 3 = Receive Data
— Pin 5 = Signal Ground
— Baud rate: 1 200 Bps.115 200 Bps, default 9 600 Bps. Rate can be programmable (optional)
Remark: the baud rate shall be sufficient for a worst case amount of data to be send with retries.
— Data bits: 8
— Stop bits: 1
— Parity: No
— Data format: according to ISO/IEC 8859-1 (Extended ASCII)
— Handshaking: by software with ACK, NAK ASCII control codes, refer to 5.2.3
— Transmission control by SOH and EOT ASCII control codes, refer to 5.2.3
— Data validity check: CRC-16/CCITT, refer to 5.2.3
5.2.2 RS232 interface on “Board-computer”
— Connector: SUB-D 9p male
— Pin 2 = Receive Data
8
---------------------- Page: 10 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
— Pin 3 = Transmit Data
— Pin 5 = Signal Ground
— Baud rate: 1 200 Bps.115 200 Bps, default 9 600 Bps. Rate shall be programmable or automatically
detected (autobaud)
— Data bits: 8
— Stop bits: 1
— Parity: No
— Data format: according to ISO/IEC 8859-1 (Extended ASCII)
— Handshaking: by software with ACK, NAK ASCII control codes, refer to 5.2.3
— Transmission control by SOH and EOT ASCII control codes, refer to 5.2.3
— Data validity check: CRC-16/CCITT, refer to 5.2.3
5.2.3 Communication protocol
Transmission of a record.
In this definition a message to be communicated consists of one record. Records are terminated by CR+LF
(a record is one line of text). In general, a message is sent by the sender (e.g. the “Data transmission
handler” of a spreader) and received by the receiver (e.g. the Board-computer). After power up,
communication is always started by the vehicle/equipment “Data transmission handler” sending its first
message (this is the time synchronization record). Refer to Figure 4 for flow charts of the sender and
receiver algorithms.
The receiver will check the validity of a message by testing if the CRC-16 value corresponds to the data in
the message received. If the data is valid, the receiver sends an ACK. The sender can now send a new
message. If the data is invalid, the receiver sends a NAK. Then, the sender will try to send the same
message again for a maximum of 2 times. If the message still fails, the message is considered to be lost.
Preferably, a notification is given to the user (operator) that data has been lost by the sender and/or the
receiver.
NOTE 1 The receiver sends an ACK or a NAK as a single character without other data. The ACK or NAK refers to
the latest message sent by the sender. To avoid record synchronization problems between sender and receiver, the
sender has to ignore any ACK or NAK received during the transmission of a message until the last byte is sent (EOT
character). Also, the receiver is not allowed to send an ACK or NAK during the reception of a message until the last
byte is received (EOT character).
Numerical values have to be transmitted with ASCII characters in decimal code.
Calculation of the CRC-16 value.
The CRC value is calculated according to the CCITT definition. The CRC value is calculated over all record
bytes, starting with the record code, ending with CR+LF. The polynomial used is
16 12 5 0
x + x + x + x = 11021 (i.e. XOR mask 1021 ) and initial value FFFF .
h h h
NOTE 2 The value is written in ASCII characters in hexadecimal code with capitals (0.9,A.F).
9
---------------------- Page: 11 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Calculation of the CRC-32 value.
The CRC-32 value is calculated according to the CCITT definition. The CRC-32 value is calculated over all
record bytes, starting with the record code, ending with CR+LF. The polynomial used is
32 26 23 22 16 12 11 10 8 7 5 4 2
x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
NOTE 3 The value is written in ASCII characters in hexadecimal code with capitals (0.9,A.F).
Sender without receiving options for handshaking.
For old vehicle/equipment “Data transmission handlers”, it may be impossible to receive data. In this case
the sender cannot respond to an ACK or NAK, i.e. there is no handshaking feature. Hence, the sender will
send a new message. This may cause in the result that data gets lost, e.g. in case the Board-computer was
not started up yet or if transmission failed. It is up to the user to handle this problem (for example to
connect power supply such that power-up is always at the same time for sender and transmitter).
Synchronization of communication.
To synchronize communication between sender and receiver, a message always starts with an SOH and
ends with an EOT. If the receiver is not synchronized yet but the sender is already transmitting a message
(e.g. when the Board-computer starts up while the spreader “Data transmission handler” is sending), all
data before the first SOH will be ignored. If the receiver is synchronized but detects an SOH before an
EOT, the previous, unfinished message is ignored.
Time synchronization between sender and receiver.
In general, the sender system time and the receiver system time are not equal. To synchronize messages
to the system clock of the receiver, a time synchronization record is introduced. This Time Sync record
(refer to 6.5.2) contains the actual system time of the sender at the start of record transmission (with a
maximum error of ± 0,5 s). The receiver shall record its system time at the moment of reception of a
message. In case of the reception of a Time Sync record, the receiver can calculate the difference between
its own system clock and the system clock of the sender. Now, the receiver can time-synchronize every
message received from the sender and thereby synchronize this data to other data generated by other
sources. The board computer shall contain a real time clock which runs even if the board computer has
no power. The electronic system on the vehicle/equipment shall have a real time clock which runs even
when this system has no power, or, a software clock shall be implemented which starts at date 1-1-2000
and time 00:00:00 and is updated every second.
A Time Sync record, is sent by the sender:
— as the first message starting the communication;
— after 10 s if the receiver does not respond to a message with an ACK or a NAK; after a successful
transmission of this record, the latest message before the time synchronization record is transmitted
again;
— if the system clock of the sender is adjusted, reset or set to any value which would cause a jump in
time.
Loss of data.
Data will get lost in case of:
— a “Data transmission handler” without handshaking feature which is sending while reliable
communication is not possible;
— an overflow of the buffer-memory;
— 2 unsuccessful retransmissions after a NAK.
10
---------------------- Page: 12 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
In case the “Data transmission handler” supports handshaking, it is mandatory sending the header record
as the first record of a report (note: the Time Sync record is not part of the report). i.e. the header record
may not get lost.
Example of a message is shown in graphical form:
Start Data (codes + values, “;” separated) (x bytes) CR+LF CRC-16 End
(1 byte) (2 bytes) (2 bytes) (1 byte)
SOH 1;10;1602048;0461021;5;Abc;Equip1;;; CR LF 66D9 EOT
Extended ASCII characters in hexadecimal notation:
01 31 3B 31 30 3B 31 36 30 32 30 34 38 3B 30 34 36 31 0D 0A 36 36 44 3 04
30 32 31 3B 35 3B 41 62 63 3B 45 71 75 69 70 31 3B 9
3B 3B
Communication example:
Figure 3 — Flow diagram
11
---------------------- Page: 13 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Sender algorithm: Receiver algorithm:
Figure 4 — Flow chart
12
---------------------- Page: 14 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
6 Definitions of variables, records and report
6.1 General
A report is a file of records which in general is used to describe one ride. A report starts with a header
record, one or more status records of the vehicle/equipment(s) and a footer record. A record is a
structure of coherent variables in a predefined order. A member of a record is called a “field”.
Table 1 — Application or equipment types
Equipment Source ref.nr. Remark
Board computer 1
Vehicle 2 On board vehicle electronic generating data
Snow plough or broom 3 It is assumed that if there is more than one snow-
plough, the data is generated by one source only.
Snow blower or cutter 4
Spreader or sprayer 5 Remark: this equipment could also generate the data
for example for a snow plough, however, the source
reference number stays 5 (as the spreader is the data
generator).
Road weather and road 6
condition information
system
Grass or branch cutting 7
machine
Sweeper 8
Safety post cleaning 9
machine
Boat plants cutter 10 Used for cutting plants in canals or rivers
Other 11 To be used for any equipment not defined
6.2 Data integrity check
There are at least two methods required to assure integrity:
a) Data have to be checked for manipulation of the contents themselves.
b) Data have to be checked for completeness: Data have to be checked against any deletion of any parts
of them.
In the present standard these two requirements lead to the following methods of covering:
— Data manipulation (a) is checked by CRC.
— Data deletion (b) is checked by including the previously calculated CRC value into the new CRC
value.
13
---------------------- Page: 15 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
In order to ensure data integrity two CRC variables (CRC_REC and CRC_STREAM) are defined for each
record and generated by the board computer. CRC_REC contains the CRC-32 value calculated over all the
data contents of the record itself and CRC_STREAM contains the CRC-32 value calculated over the
CRC_STREAM of the preceding record and the current CRC_REC value. CRC_REC and CRC_STREAM are
both optional and are not available in the Time synchronization record (record code 0), Standard
header record (record code 1) and Standard footer record (record code 2) (see 6.6).
6.3 Variable types
All variables defined, have to comply to one of the following variable types. The column “Format” shows
how a variable is represented in one or more examples. A point (.) is defined as a decimal separator. Data
ranges are defined in the same way as SAE J1939/71 defines them:
Table 2 — Ranges
Range Name 1 byte 2 bytes 4 bytes ASCII
0 to 250 0 to 64 255 0 to 4211081215 1 to 254
Valid Signal
00h to FAh 0000h to FAFFh 00000000h to FAFFFFFFh 01h to FEh
251 64256 to 64 511 4211081216 to 4227858431
Parameter specific
None
indicator
FBh FB00h to FBFFh FBxxxxxxh
252 to 253 64512 to 65 023 4227858432 to 4261412863
Reserved range for
future indicator None
bits
FCh to FDh FC00h to FDFFh FC000000h to FDFFFFFFh
254 65 024 to 65 279 4261412864 to 4278190079 0
Error indicator
FEh FExxh FExxxxxxh 00h
255 65280 to 65 535 4278190080 to 4294967294255 255
Not available or
not requested
FFh FFxxh FFxxxxxxh FFh
14
---------------------- Page: 16 ----------------------
oSIST prEN 15430-1:2023
prEN 15430-1:2023 (E)
Table 3 — Basic variable types
Type Range Length Format Remark
00 = Value is 0, no errors
01 = Value is 1, no errors Definition taken from
BOOLEAN 0, 1 2 Bits
10 = Error SAE J1939
11 = not available
0.250, Offset -125
Definition taken from
CHAR -125.+125 1 byte 254 = Error
SAE J1939
255 = not available
0.250, Offset 0
UNSIGNED Definition taken from
0.250 1 byte 254 = Error
CHAR SAE J1939
255 = not available
0.64255, Offset 32768
SIGNED -32 127.+ 32 Definition taken from
2 bytes 65024.65279 = Error
SHORT 127 SAE J1939
65280.65535 = not available
0.64255, Offset 0
UNSIGNED Definition taken from
0.64255 2 bytes 65024.65279 = Error
SHORT SAE J1939
65280.65535 = not available
0 to 4211081215,
Offset -2105540608,
- 2105540608
SIGNED 4261412864 to Definition taken from
4 bytes
..
LONG 4278190079 = Error, SAE J1939
+2105540608
4278190080 to
4294967295 = not available
0 to 4211081215,
4261412864 to
UNSIGNED De
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.