From: pman92 Date: Sat, 2 May 2020 09:03:58 +0000 (+1000) Subject: sae_j1850_vpw: Add VPW sample data from P01 PCM X-Git-Url: https://sigrok.org/gitaction?a=commitdiff_plain;h=d8937b14bc161d537d19c1ae536919c4e775403b;p=sigrok-dumps.git sae_j1850_vpw: Add VPW sample data from P01 PCM [ gsi: changed directory layout, reworked README markup ] --- diff --git a/sae-j1850/vpw/P01_bench_by_itself/P01_bench_by_itself.sr b/sae-j1850/vpw/P01_bench_by_itself/P01_bench_by_itself.sr new file mode 100644 index 0000000..c58d63a Binary files /dev/null and b/sae-j1850/vpw/P01_bench_by_itself/P01_bench_by_itself.sr differ diff --git a/sae-j1850/vpw/P01_bench_by_itself/README b/sae-j1850/vpw/P01_bench_by_itself/README new file mode 100644 index 0000000..70b915d --- /dev/null +++ b/sae-j1850/vpw/P01_bench_by_itself/README @@ -0,0 +1,124 @@ +------------------------------------------------------------ +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