[sigrok-dumps.git] / sae-j1850 / vpw / P01_bench_by_itself / README

------------------------------------------------------------
J1850 VPW transmission from GM P01 Powertrain Control Module
------------------------------------------------------------

Captured by pman92 - 2 May 2020

This is a capture of data from a General Motors "P01" Powertrain Control
Module. The control module was wired on the bench in a minimal setup
with nothing else connected. An ignition switch was included to provide
ignition power to the PCM. The following information was then obtained
from the module with PCMHammer 012 and an X-Pro VT interface (see
https://github.com/LegacyNsfw/PcmHacks/wiki/PCM-Hammer and
https://obdxpro.com/x-pro-vt/).

  VIN: 6H8WHY19F2L857286
  OS ID: 12202088
  Calibration ID: 92113609
  Hardware ID: 9386530
  Serial Number: 2EB2TZJT2070
  Broad Cast Code: DFNN
  MEC: 0

An Arduino was connected to the data line via a basic interface circuit
that used a voltage comparator to monitor the J1850 VPW bus voltage
(high or low). The Arduino was programmed using pin change interrupts to
measure the time difference between changes of bus state (active or
passive). The Arduino would watch for SOF signals and then count the
following bus state/time changes to calculate the data within the packet.
It would calculate and confirm the checksum matched to ensure the data
was OK. It would then transmit the complete received packet back to the
PC via USB and was displayed on the Arduino serial monitor. The returned
data included a timestamp. If a checksum didn't match, an error message
would be returned instead of the relavent data packet.


Logic analyzer setup
--------------------

The capture was taken with a Saleae Logic 8 Channel clone at 16MHz for
50M samples. The ignition switch on the bench wiring was turned on and
the PCM started transmitting data.

  Probe   VPW
  -------------
  1       data


Capture verification
--------------------

1. Arduino checksum calculation and confirmation

J1850 VPW packets contain a checksum. If a bad or incorrect checksum was
found, an error message would be transmitted back to the PC by the Arduino
instead of that data packet/frame. No error messages were recorded during
the capturing of this data, so the Arduino checksum calculations were all
correct, and it considered the data intact.

2. Visual inspection of first data packet in Pulseview

The first data packet (+616.8ms to +622.1ms) was visually inspected in
PulseView and the bit values written down by hand. They were then split
into groups of 8 bit values, which were converted each to a single hex
value. The single hex values of the first data packet were then confirmed
to match the hex values that the Arduino had returned as the first packet.

3. Timing between first and last data

There is a total of 33 packets visible. PulseView shows the first packet
ending at 622ms, and the last packet ends at 3059ms, meaning 2437ms between
the "end of the first" and "end of the last" packets in the capture. The
Arduino also returned a time stamp of when the packet was processed and
sent to the PC. Between the first and 33rd packet, the difference in
Arduino time stamps was 2438ms. The difference of only 1ms confirms the
PulseView capture and Arduino are looking at the same range of data.

NOTE that there are glitches within the capture. There is a series of
short glitches/pulses around 506-507ms within the capture. I'm unsure of
the cause, but this was around the time when the ignition switch on the
bench was turned on. Maybe it was noise caused by the switch or maybe it
was noise coming from the PCM when it powered up. Either way this could
be a good example to make sure the decoder can ignore/skip bad data or
glitches.


Data
----

The Arduino returned the following data packets, written in hex, from
first to last within the PulseView capture:

  68 13 10 11 00 46
  68 EA 10 0A 01 AE
  88 15 10 01 C8
  88 1B 10 10 00 00 46
  8A EA 10 20 8A 00 10
  A9 CE 10 07 69
  A8 F3 10 11 02 2B
  C8 3B 10 3C 04 48
  68 EA 10 0A 01 AE
  88 15 10 01 C8
  8A EA 10 20 8A 00 10
  A9 CE 10 07 69
  49 92 10 01 BE
  49 92 10 01 BE
  8A EA 10 20 82 00 4A
  8A EA 10 20 82 00 4A
  68 49 10 10 0B CF
  68 EA 10 0A 01 AE
  88 15 10 01 C8
  8A EA 10 20 8A 00 10
  A9 CE 10 07 69
  E9 2A 10 3C EE
  49 92 10 01 BE
  E9 2A 10 3C EE
  8A EA 10 20 82 00 4A
  68 EA 10 0A 01 AE
  88 15 10 01 C8
  8A EA 10 20 8A 00 10
  A9 CE 10 07 69
  E8 FF 10 03 B3
  49 92 10 01 BE
  E9 2A 10 3C EE
  8A EA 10 20 82 00 4A
Commit	Line	Data
d8937b14	1	------------------------------------------------------------
	2	J1850 VPW transmission from GM P01 Powertrain Control Module
	3	------------------------------------------------------------
	4
	5	Captured by pman92 - 2 May 2020
	6
	7	This is a capture of data from a General Motors "P01" Powertrain Control
	8	Module. The control module was wired on the bench in a minimal setup
	9	with nothing else connected. An ignition switch was included to provide
	10	ignition power to the PCM. The following information was then obtained
	11	from the module with PCMHammer 012 and an X-Pro VT interface (see
	12	https://github.com/LegacyNsfw/PcmHacks/wiki/PCM-Hammer and
	13	https://obdxpro.com/x-pro-vt/).
	14
	15	VIN: 6H8WHY19F2L857286
	16	OS ID: 12202088
	17	Calibration ID: 92113609
	18	Hardware ID: 9386530
	19	Serial Number: 2EB2TZJT2070
	20	Broad Cast Code: DFNN
	21	MEC: 0
	22
	23	An Arduino was connected to the data line via a basic interface circuit
	24	that used a voltage comparator to monitor the J1850 VPW bus voltage
	25	(high or low). The Arduino was programmed using pin change interrupts to
	26	measure the time difference between changes of bus state (active or
	27	passive). The Arduino would watch for SOF signals and then count the
	28	following bus state/time changes to calculate the data within the packet.
	29	It would calculate and confirm the checksum matched to ensure the data
	30	was OK. It would then transmit the complete received packet back to the
	31	PC via USB and was displayed on the Arduino serial monitor. The returned
	32	data included a timestamp. If a checksum didn't match, an error message
	33	would be returned instead of the relavent data packet.
	34
	35
	36	Logic analyzer setup
	37	--------------------
	38
	39	The capture was taken with a Saleae Logic 8 Channel clone at 16MHz for
	40	50M samples. The ignition switch on the bench wiring was turned on and
	41	the PCM started transmitting data.
	42
	43	Probe VPW
	44	-------------
	45	1 data
	46
	47
	48	Capture verification
	49	--------------------
	50
	51	1. Arduino checksum calculation and confirmation
	52
	53	J1850 VPW packets contain a checksum. If a bad or incorrect checksum was
	54	found, an error message would be transmitted back to the PC by the Arduino
	55	instead of that data packet/frame. No error messages were recorded during
	56	the capturing of this data, so the Arduino checksum calculations were all
	57	correct, and it considered the data intact.
	58
	59	2. Visual inspection of first data packet in Pulseview
	60
	61	The first data packet (+616.8ms to +622.1ms) was visually inspected in
	62	PulseView and the bit values written down by hand. They were then split
	63	into groups of 8 bit values, which were converted each to a single hex
	64	value. The single hex values of the first data packet were then confirmed
65	to match the hex values that the Arduino had returned as the first packet.
66
67	3. Timing between first and last data
68
69	There is a total of 33 packets visible. PulseView shows the first packet
70	ending at 622ms, and the last packet ends at 3059ms, meaning 2437ms between
71	the "end of the first" and "end of the last" packets in the capture. The
72	Arduino also returned a time stamp of when the packet was processed and
73	sent to the PC. Between the first and 33rd packet, the difference in
74	Arduino time stamps was 2438ms. The difference of only 1ms confirms the
75	PulseView capture and Arduino are looking at the same range of data.
76
77	NOTE that there are glitches within the capture. There is a series of
78	short glitches/pulses around 506-507ms within the capture. I'm unsure of
79	the cause, but this was around the time when the ignition switch on the
80	bench was turned on. Maybe it was noise caused by the switch or maybe it
81	was noise coming from the PCM when it powered up. Either way this could
82	be a good example to make sure the decoder can ignore/skip bad data or
83	glitches.
84
85
86	Data
87	----
88
89	The Arduino returned the following data packets, written in hex, from
90	first to last within the PulseView capture:
91
92	68 13 10 11 00 46
93	68 EA 10 0A 01 AE
94	88 15 10 01 C8
95	88 1B 10 10 00 00 46
96	8A EA 10 20 8A 00 10
97	A9 CE 10 07 69
98	A8 F3 10 11 02 2B
99	C8 3B 10 3C 04 48
100	68 EA 10 0A 01 AE
101	88 15 10 01 C8
102	8A EA 10 20 8A 00 10
103	A9 CE 10 07 69
104	49 92 10 01 BE
105	49 92 10 01 BE
106	8A EA 10 20 82 00 4A
107	8A EA 10 20 82 00 4A
108	68 49 10 10 0B CF
109	68 EA 10 0A 01 AE
110	88 15 10 01 C8
111	8A EA 10 20 8A 00 10
112	A9 CE 10 07 69
113	E9 2A 10 3C EE
114	49 92 10 01 BE
115	E9 2A 10 3C EE
116	8A EA 10 20 82 00 4A
117	68 EA 10 0A 01 AE
118	88 15 10 01 C8
119	8A EA 10 20 8A 00 10
120	A9 CE 10 07 69
121	E8 FF 10 03 B3
122	49 92 10 01 BE
123	E9 2A 10 3C EE
124	8A EA 10 20 82 00 4A