VERSION = "0.1.0"
-DESTDIR ?= /usr/local/share/sigrok-dumps
+# TODO Ideally instructions would use autotools, cmake, or some other
+# higher level abstraction instead of DIY shell commands. Which would
+# improve portability and robustness (by picking the most appropriate
+# install tool that is available on the target), and would transparently
+# enable support for --prefix and DESTDIR et al, including out of source
+# builds when desired.
+PREFIX ?= /usr/local
+INSTALL_DIR = $(PREFIX)/share/sigrok-dumps
+
+# Be explicit about which files or subdirectories to install.
+# Update this list when adding a new top level subdirectory to the
+# set of example captures. It's assumed that this event is rare.
+# The list is phrased such that users can specify additional items
+# when they invoke the 'make install' command.
+FILES_DIRS += ac97 am230x arm_trace aud avr_isp avr_pdi
+FILES_DIRS += caliper can cec
+FILES_DIRS += dac dali dcc dcf77 display dmx512 dsi
+FILES_DIRS += flexray fsk
+FILES_DIRS += gpib graycode
+FILES_DIRS += i2c i2s ir
+FILES_DIRS += jtag
+FILES_DIRS += led lens_mounts lpc
+FILES_DIRS += maple_bus mcs48 mdio microwire miller misc morse mouse_sensors
+FILES_DIRS += nfc nonstandard_eeproms
+FILES_DIRS += onewire ook
+FILES_DIRS += pjon ps2 pwm
+FILES_DIRS += qi
+FILES_DIRS += rc rfid
+FILES_DIRS += sae-j1850 sdcard sdq sht7x signature sle44xx spdif spi
+FILES_DIRS += stepper_motor swd swim
+FILES_DIRS += tdm_audio
+FILES_DIRS += uart usb usb_power_delivery
+FILES_DIRS += vfd
+FILES_DIRS += wiegand
+FILES_DIRS += xy2-100
+FILES_DIRS += z80
all:
@echo "Run 'make dist' to create a tarball."
@rm -f ChangeLog
install:
- @mkdir -p $(DESTDIR)
- @cp -r * $(DESTDIR)
- @rm -f $(DESTDIR)/Makefile
-
+ @mkdir -p $(DESTDIR)$(INSTALL_DIR)
+ @cp -r $(FILES_DIRS) $(DESTDIR)$(INSTALL_DIR)
sigrok-dumps is in a usable state and has had official tarball releases.
+Installing
+----------
+
+Example captures need not get built or compiled, but can get installed.
+
+ $ git clone git://sigrok.org/sigrok-dumps
+ $ cd sigrok-dumps
+ $ make install
+
+Optional PREFIX or DESTDIR specs are supported as well.
+
+ $ make PREFIX=/usr install
+ $ make PREFIX=${HOME} install
+
+ $ make DESTDIR=$( pwd )/rootfs install
+
+
Contributing dumps
------------------
IRC
---
-You can find the sigrok developers in the #sigrok IRC channel on Freenode.
+You can find the sigrok developers in the #sigrok IRC channel on Libera.Chat.
Website
--- /dev/null
+-------------------------------------------------------------------------------
+AVR ISP / Atmel ATmega328/P
+-------------------------------------------------------------------------------
+
+This is an example capture of the AVR in-system programming (ISP) protocol.
+
+The device used for ISP was a Bus Pirate v3.5 with firmware v6.1.
+
+The target was an Arduino UNO board with an Atmel ATmega328/P chip.
+
+The PC software used for controlling the programmer was avrdude 7.1.
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Saleae Logic Clone (at 4MHz):
+
+ Probe AVR ISP header
+ -------------------------
+ 1 MOSI
+ 2 MISO
+ 3 SCK
+ 4 RST
+
+
+Data
+----
+
+The following avrdude commands were captured:
+
+ avrdude -p atmega328p -c buspirate -P /dev/ttyUSB0 -v
--- /dev/null
+-------------------------------------------------------------------------------
+AVR ISP / Atmel ATmega8L
+-------------------------------------------------------------------------------
+
+This is a set of example captures of the AVR in-system programming (ISP)
+protocol. The target was a board with an Atmel ATmega8L chip, and another
+microcontroller was used as master for the ISP process.
+
+Details:
+http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Saleae Logic (at 4MHz):
+
+ Probe AVR ISP header
+ -------------------------
+ 5 (green) MOSI
+ 6 (blue) CLK
+ 7 (violet) MOSI
--- /dev/null
+-------------------------------------------------------------------------------
+Analog Devices AD5626
+-------------------------------------------------------------------------------
+
+This is a set of example captures of an Analog Devices AD5626 12-bit nanoDAC.
+
+Details:
+https://www.analog.com/media/en/technical-documentation/data-sheets/AD5626.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was ADALM2000 (at 5MHz):
+
+ Probe AD5626
+ ------------------
+ 0 SCLK
+ 1 SDIN
+ 2 CS#
+
+
+Probing
+-------
+
+The sigrok command line used was:
+
+ sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -C 0-2 -o <file>
+
+
+ad5626_write_dac.sr
+-------------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=5000000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -o ad5626_write_dac.sr -C 0-2
--- /dev/null
+-------------------------------------------------------------------------------
+DCC model train captures
+-------------------------------------------------------------------------------
+
+These captures contain data that was recorded on a model railway setup that
+is based on the tams elektronik EasyControl controller. The booster used was
+a self-built tams elektronik B-2 booster.
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Saleae Logic clone (samplerate 1MHz). The
+signal was captured via a simple voltage clamping circuit.
+
+ Probe DCC
+ -------------------
+ 1 Data
+
+
+Captures
+--------
+
+Since the controller continuously resends the data, the captures do
+contain more than what is stated here.
+
+ Capture Action
+ ----------------------------------------------------------------------
+ decoder_2_light.sr switch light on train with address 2
+ decoder_45_light.sr switch light on train with address 45
+ decoder_120_121.sr switch state of decoder 120, 121
+ decoder_133.sr switch state of decoder 133
+ decoder_140.sr switch state of decoder 140
+ decoder_310.sr switch state of decoder 310
----------------------
Cycles through the numbers 0 to F with alternating dot.
+
+
+test_7_segment_all_alphabet.sr
+------------------------------
+
+Covers more combinations of LED segments, including alphanumeric codes
+(letters, punctuation).
+
+
+mystery_message.sr
+------------------
+
+Contains LED segment combinations that are not known to the decoder.
required by the spec. Other oddities like frequent changes of CS are caused by
specific library implementation.
+
+Dump with unknown command
+-------------------------
+
+Taken with the same setup as above on a 128x160 display with Arduino TFT library
+and the following code:
+
+ #include <TFT.h>
+ #include <SPI.h>
+
+ #define cs 10
+ #define dc 9 // A0
+ #define rst 8
+
+ TFT TFTscreen = TFT(cs, dc, rst);
+
+ void setup()
+ {
+ TFTscreen.begin();
+ TFTscreen.background(0, 255, 0);
+ }
+
+ void loop()
+ {
+ }
--- /dev/null
+-------------------------------------------------------------------------------
+Linear Technology Corporation LTC2607
+-------------------------------------------------------------------------------
+
+This is a set of example captures of LTC2607 16-bit rail-to-rail DACs.
+
+Details:
+https://www.analog.com/media/en/technical-documentation/data-sheets/26071727fa.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was ADALM2000 (at 500kHz):
+
+ Probe LTC2607
+ -------------------
+ 0 SCL
+ 1 SDA
+
+
+Probing
+-------
+
+The sigrok command line used was:
+
+ sigrok-cli -i - -I binary:numchannels=16:samplerate=500khz -C 0,1 -o <file>
+
+
+ltc2607_write_dac.sr
+--------------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=5000000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=500khz -o ltc2607_write_dac.sr -C 0,1
--- /dev/null
+-------------------------------------------------------------------------------
+Microchip MCP23017 I/O expander with I2C interface
+-------------------------------------------------------------------------------
+
+This is a set of example captures of the MCP23017 16-bit I/O expander with
+an I2C interface. For details see the MCP23017/MCP23S17 datasheet which is
+titled "16-Bit I/O Expander with Serial Interface":
+
+ http://ww1.microchip.com/downloads/en/DeviceDoc/20001952C.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Saleae clone (samplerate 1MHz). In addition
+to the I2C datalines, 6 output pins are captured too.
+
+The host was a Raspberry Pi using Python to access the I2C port. The bitrate
+decreased after a few 100ms.
+
+ Probe MCP23017
+ -------------------
+ 0 A0
+ 1 A1
+ 2 A2
+ 3 B0 / A3
+ 4 B1 / A4
+ 5 B2 / A5
+ 6 SDA
+ 7 SCL
+
+
+mcp23017_counter_a_write.sr
+---------------------------
+
+Count the Registers OLATA ascending. The lowest 6 bits of the Output A Port
+are captured too (A0 - A5).
+
+
+mcp23017_counter_init_ab_write.sr
+---------------------------------
+
+Reset all registers, then count the registers OLATA ascending and OLATB
+descending. Both registers are set using one word write operation. The
+lowest 3 bits of both output ports are captured too (A0 - A2, B0 - B2).
+
+
+mcp23017_counter_init_ab_write_read.sr
+-------------------------------------
+
+Reset all registers, then count the registers OLATA ascending and OLATB
+descending. Both registers are set and read using one word write operations.
+The lowest 3 bits of both output ports are captured too (A0 - A2, B0 - B2).
--- /dev/null
+-------------------------------------------------------------------------------
+Maxim Integrated DS3231 RTC
+-------------------------------------------------------------------------------
+
+Details:
+ - DS3231 datasheet: https://datasheets.maximintegrated.com/en/ds/DS3231.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was Geeetech Mini Board Cypress FX2(LP) eval board
+with fx2lafw firmware (at 4MHz):
+
+ Probe DS3231 pin
+ -------------------------
+ 0 SCL
+ 1 SDA
+
+
+ds3231_ex1.sr
+----------------------
+
+The file provides reading/writing of time keeping registers as well as
+control, control/status and temperature registers of the RTC chip, which
+was setup to 24-hours mode:
+
+- Read Control register
+- Write Control register - disable alarms
+- Read Control/Status register
+- Write Control/Status register - clear alarm's flags
+- Write Alarm 1 registers - set Alarm 1 at every 1st date
+- Write Alarm 2 registers - set Alarm 2 at every minute
+- Read date/time
+- Read temperature (MSB)
+
+
+ds3231_ex2.sr
+----------------------
+
+The file provides reading/writing of time keeping registers as well as
+control/status and temperature registers of the RTC chip, which was setup
+to 24-hours mode and after Alarm 2 occured:
+
+- Read Control/Status register
+- Write Control/Status register - clear alarm flag
+- Read date/time
+- Read temperature (MSB)
--- /dev/null
+------------------------------------------------------------------------
+Extended NEC infrared protocol
+------------------------------------------------------------------------
+
+See https://www.sbprojects.net/knowledge/ir/nec.php for a description of the
+NEC protocol including the extended protocol.
+
+These are random button presses, including a few repeat signals. The remote
+in question is unmarked and used for remote controlling ceiling lights.
+
+Logic analyzer setup
+--------------------
+
+ Probe NEC
+ -----------
+ 0 IR
--- /dev/null
+------------------------------------------------------------------------
+NEC infrared protocol
+------------------------------------------------------------------------
+
+These captures were taken with the "Joy-IT SBC IR01" remote control. File
+joy_it_sbc_irc01_all.sr contains data for all the buttons of that remote.
+File joy_it_sbc_irc01_enter_no_repeat.sr contains a single button that gets
+pressed repeatedly, but for a short period of time such that the remote
+won't send a repeat signal (each button press is new).
+
+There are several interesting aspects to these files:
+- The signal would not decode with 5% tolerance. A wider limit is needed
+ because this remote control's signal is outside of that narrow window.
+- The absence of IR frames for repeated button press could reveal an issue
+ with earlier decoder implementations, where the emission of annotations
+ for an IR frame was deferred until the start of the next IR frame.
+
+Logic analyzer setup
+--------------------
+
+ Probe NEC
+ -----------
+ 0 IR (carrier removed)
+ 1 RAW (includes carrier)
--- /dev/null
+------------------------------------------------------------------------
+Sony infrared remote control (SIRC)
+------------------------------------------------------------------------
+
+See https://www.sbprojects.net/knowledge/ir/sirc.php for a description
+of the SIRC protocol.
+
+Logic analyzer setup
+--------------------
+
+ Probe SIRC
+ -----------
+ 0 IR
--- /dev/null
+-------------------------------------------------------------------------------
+WS281x-based RGBW LED Strip
+-------------------------------------------------------------------------------
+
+This is for testing purposes a short sequence for 4 LEDs showing different colors and values
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Saleae Clone (at 4MHz)
+
+
+Data
+----
+Decoded it shows:
+red (Led0: 0, Led1: 63, Led2: 127, Led3: 255)
+green (0, 63, 127, 255)
+blue (0, 63, 127, 255)
+white (0, 63, 127, 255)
--- /dev/null
+-------------------------------------------------------------------------------
+Intel H55 LPC (low pin count) traffic
+-------------------------------------------------------------------------------
+
+This capture is an LPC (low pin count) I/O read transaction from an Intel H55
+chipset on a Foxconn H55MXV motherboard.
+
+Details:
+http://en.wikipedia.org/wiki/Low_Pin_Count
+
+
+Hardware setup
+--------------
+
+The capture was taken with an FPGA sampling at 200 MHz and imported into sigrok
+as 8bit binary data.
+
+ Probe LPC
+ ----------
+ 2 LCLK
+ 3 LFRAME#
+ 4 LAD0
+ 5 LAD1
+ 6 LAD2
+ 7 LAD3
+
+
+h55_lpc_io_write.sr
+---------------
+An I/O write to 0x2e (super IO index register) of 0x55.
--- /dev/null
+-------------------------------------------------------------------------------
+IBM POWER9 LPC (low pin count) traffic
+-------------------------------------------------------------------------------
+
+These captures are examples of various transaction types from an IBM POWER9 LPC
+(low pin count) interface.
+
+Details:
+http://en.wikipedia.org/wiki/Low_Pin_Count
+
+
+Hardware setup
+--------------
+
+The logic analyser used was a DreamSourceLab DSLogic U3Pro32. As support for
+this is not yet in sigrok, the traces were captured externally and imported.
+
+ Probe LPC
+ ----------
+ 0 LAD0
+ 1 LAD1
+ 2 LAD2
+ 3 LAD3
+ 4 LFRAME#
+ 5 LCLK
+
+
+power9_lpc_io_read.sr
+--------------
+An I/O read from 0x3fd (serial port) which returns 0x60.
+
+power9_lpc_io_write.sr
+---------------
+An I/O write to 0x3f8 (serial port) of 0x73.
+
+power9_lpc_firmware_read.sr
+--------------------
+A firmware read from 0xfff7000 which returns 0x54524150.
+
+power9_lpc_firmware_write.sr
+---------------------
+A firmware write to 0xc031360 of 0x0000.
+
+power9_lpc_io_write_abort.sr
+---------------------
+An I/O read that gets aborted because the peripheral never responded.
--- /dev/null
+--------------------------------------------------------------------------------------------------------
+Dumps of HydraNFC Shield v2 (STMicroelectronics ST25R3916 NFC chipset communication using SPI + IRQ pin)
+--------------------------------------------------------------------------------------------------------
+
+Dumps of HydraNFC Shield v2 (STMicroelectronics ST25R3916 NFC chipset communication using SPI + IRQ pin)
+Those dumps are intended to be analyzed with st25r3916_spi decoder
+
+Hardware setup for the capture
+------------------------------
+
+* HydraBus v1 Rev1.4 + HydraNFC Shield v2 R1.4
+ * Using firmware (https://github.com/hydrabus/hydrafw_hydranfc_shield_v2) HydraFW (HydraBus v1/HydraNFC Shield v2) v0.1-beta-11-g682a268 2020-07-13
+ * HydraBus SPI Master is configured with signal 0_CLK @10.5MHz, CLK Polarity=0, CLK Phase=1, Bit order=Send/receive MSB first
+
+Tag ISO/IEC 14443-A (106 kbps) ST25TA02K-P (CLOUD-ST25TA MB1207-B) NFC Forum Type 4 Tag (https://www.st.com/cloud-st25ta)
+ * Read UID of the tag
+ * nfc-a scan
+ * NFC-A UID:02A20071C84F90
+
+Tag ISO/IEC 14443-B
+ * Read UID of the tag (nfc-b scan)
+ * nfc-b scan
+ * NFC-B UID:00422099
+
+Tag ISO/IEC 15693 Vicinity ST25 (5cm x 5cm Tag)
+ * Read UID of the tag
+ * nfc-v scan
+ * NFC-V UID:E0022300265F64F2
+
+ST25R3916 Registers Space A & B after init
+ * Read all ST25R3916 Registers Space A & B
+ * show registers
+ * ST25R3916 Registers space A:
+ * 0x00 : 0x07
+ * 0x01 : 0x3c
+ * 0x02 : 0x83
+ * 0x03 : 0x08
+ * 0x04 : 0x00
+ * 0x05 : 0x00
+ * 0x06 : 0x00
+ * 0x07 : 0x00
+ * 0x08 : 0x50
+ * 0x09 : 0x00
+ * 0x0a : 0x00
+ * 0x0b : 0x08
+ * 0x0c : 0x2d
+ * 0x0d : 0xd8
+ * 0x0e : 0x00
+ * 0x0f : 0x0c
+ * 0x10 : 0x00
+ * 0x11 : 0x00
+ * 0x12 : 0x00
+ * 0x13 : 0x84
+ * 0x14 : 0x6c
+ * 0x15 : 0x80
+ * 0x16 : 0xff
+ * 0x17 : 0xff
+ * 0x18 : 0xff
+ * 0x19 : 0xfb
+ * 0x1a : 0x00
+ * 0x1b : 0x00
+ * 0x1c : 0x00
+ * 0x1d : 0x00
+ * 0x1e : 0x00
+ * 0x1f : 0x00
+ * 0x20 : 0x00
+ * 0x21 : 0x00
+ * 0x22 : 0x00
+ * 0x23 : 0x00
+ * 0x24 : 0x00
+ * 0x25 : 0xdf
+ * 0x26 : 0x49
+ * 0x27 : 0x45
+ * 0x28 : 0x70
+ * 0x29 : 0x5f
+ * 0x2a : 0x11
+ * 0x2b : 0x00
+ * 0x2c : 0x00
+ * 0x2d : 0x00
+ * 0x2e : 0x00
+ * 0x2f : 0x00
+ * 0x30 : 0x00
+ * 0x31 : 0x12
+ * 0x32 : 0x00
+ * 0x33 : 0x00
+ * 0x34 : 0x00
+ * 0x35 : 0x00
+ * 0x36 : 0x00
+ * 0x37 : 0x00
+ * 0x38 : 0x00
+ * 0x39 : 0x00
+ * 0x3a : 0x00
+ * 0x3b : 0x00
+ * 0x3c : 0x00
+ * 0x3d : 0x00
+ * 0x3e : 0x00
+ * 0x3f : 0x2a
+ * ST25R3916 Registers space B:
+ * 0x00 : 0x40
+ * 0x01 : 0x00
+ * 0x02 : 0x0c
+ * 0x03 : 0x93
+ * 0x04 : 0x00
+ * 0x05 : 0x00
+ * 0x06 : 0x33
+ * 0x07 : 0x10
+ * 0x08 : 0x7c
+ * 0x09 : 0x80
+ * 0x0a : 0x04
+ * 0x0b : 0xe0
+ * 0x0c : 0x00
+ * 0x0d : 0x00
+ * 0x0e : 0x00
+ * 0x0f : 0x00
+
+Capture details for all types of Tags
+-------------------------------------
+0_CLK: HydraBus v1/STM32F405 PB10 SPI2 Master CLK out connected to HydraNFC Shield v2/ST25R3916 SPI Slave SCLK pin30 in
+1_MISO: HydraBus v1/STM32F405 PC2 SPI2 Master MISO in connected to HydraNFC Shield v2/ST25R3916 SPI Slave MISO pin32 out
+2_MOSI: HydraBus v1/STM32F405 PC3 SPI2 Master MOSI out connected to HydraNFC Shield v2/ST25R3916 SPI Slave MOSI pin31 in
+3_CS#: HydraBus v1/STM32F405 PC1 SPI2 Master CS out connected to HydraNFC Shield v2/ST25R3916 SPI Slave BSS pin29 in
+4_IRQ: HydraBus v1/STM32F405 PA1 IRQ Input in connected to HydraNFC Shield v2/ST25R3916 IRQ pin27 out
+
+SPI / ST25R3916 Configuration:
+CS# Polarity active-low
+Clock polarity 0
+Clock phase 1
+Bit order msb-first
+Word size 8
+
--- /dev/null
+-------------------------------------------------------------------------------
+PJON protocol stack, project homepage https://www.pjon.org/
+-------------------------------------------------------------------------------
+
+This is a collection of example PJON communication. Subdirectories contain
+different types of communication (link layers, or setups).
+
+PJON protocol and PJDL link layer specs:
+https://www.pjon.org/PJON-protocol-specification-v3.2.php
+https://www.pjon.org/PJDL-specification-v4.1.php
--- /dev/null
+-------------------------------------------------------------------------------
+PJON over PJDL
+-------------------------------------------------------------------------------
+
+This is a collection of example PJON communication which uses the PJDL
+link layer. Which does serial communication on a single wire, and the
+reference library happens to implement it by means of software bitbang
+(which affects the timing of signals on the wire).
+
+
+Logic analyzer setup
+--------------------
+
+The capture was taken with a logic analyzer at a samplerate of 4MSa/s.
+Communication is done on a single channel.
+
+ Probe PJDL
+ ----------------
+ 1 data
+
+
+pjon-pjdl-glitch-and-ack-and-failed-ack.sr
+------------------------------------------
+
+Two STM32F103 (Blue Pill boards) run the example code which resides in
+the examples/ARDUINO/Local/SoftwareBitBang/SendAndReceive/Device1/ and
+Device2/ directories. Communication mode 1 translates to 44us and 116us
+for data and pad bits. Device addresses are 44 and 45. The letter 'B' is
+sent as the payload data in both directions. Synchronous responses get
+requested, but one device won't respond. The capture also contains a few
+glitches which as a byproduct exercise the decoder's robustness, and
+recovery after synchronization loss.
+
+
+pjon-pjdl-incomplete-frame-missing-ack-repetitive.sr
+----------------------------------------------------
+
+This is a longer capture taken from the above setup. Some of the glitches
+happen to fall into a PJON frame's period and can prevent or can disturb
+the accumulation of the frame's content.
--- /dev/null
+------------------------------------------------------------
+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
--- /dev/null
+------------------------------------------------------------------------
+SDQ (Texas Instruments, battery authentication)
+------------------------------------------------------------------------
+
+See https://www.ti.com/lit/ds/symlink/bq26100.pdf for the Texas Instruments
+bq26100 battery pack authentication. Apple uses SDQ in devices like MagSafe
+or Lightning connectors, as well as in some batteries.
+
+Logic analyzer setup
+--------------------
+
+ Probe Signal
+ -----------------
+ 0 SDQ
--- /dev/null
+------------------------------------------------------------------------
+Siemens SLE44xx Chip Card Protocol
+------------------------------------------------------------------------
+
+SLE 4418/4428/4432/4442 memory cards implement a 2-wire protocol for data
+communication (signals CLK and I/O). A RST signal can be used to terminate
+currently pending long memory reads, and resets the card's address counter
+when combined with CLK. The next response data then is the Answer to Reset
+(ATR) which identifies the chip's capabilities, and allows to adjust for
+subsequent communication of more requests.
+
+See the Siemens document for details:
+
+ ICs for Chip Cards
+ Intelligent 256-Byte EEPROM
+ SLE 4432/SLE 4442
+ Data Sheet 07.95
+
+
+Logic analyzer setup
+--------------------
+
+ Probe SLE44xx
+ ----------------
+ 0 I/O
+ 1 CLK
+ 2 RST
+
+See subdirectories for chip specific example files.
--- /dev/null
+-------------------------------------------------------------------------------
+Siemens SLE4442 Chip Card protocol capture
+-------------------------------------------------------------------------------
+
+See the parent directory for more general information. These captures
+correspond to the SLE4442 chip. Each file demonstrates an individual
+operation.
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was a Cypress FX2 no-brand device (at 500kHz):
+
+ Probe SLE4442 pin
+ -----------------------
+ 0 I/O
+ 1 CLK
+ 2 RST
+
+
+sle4442_atr.sr
+--------------
+
+Reset issued by the reader, ATR (Answer to Reset) response sent by the card.
+
+
+sle4442_psc_correct.sr
+----------------------
+
+Reader reset, correct PSC (Programmable Security Code) sent by the reader to
+the card, and gets accepted.
+
+
+sle4442_psc_wrong.sr
+--------------------
+
+Reader reset, incorrect PSC sent by the reader to the card, and gets refused.
+
+
+sle4442_read_main_memory.sr
+---------------------------
+
+Full read of the card's main memory (complete address range). Includes the
+ATR content at offset 0.
+
+
+sle4442_write_cafe1337_offset_30.sr
+-----------------------------------
+
+Write 0xCA 0xFE 0x13 0x37 to main memory at offset 0x30, then read back
+several main memory regions (starting slightly before the recently written
+address range, and starting from the beginning of the card's memory). Each
+read continues to the end of the card's capacity.
--- /dev/null
+Several .sr files for testing of SPDIF.
+
+Use channel D6 for testing. The test signal is a 44,1kHz 2 channel audio signal (2.822Mbit/s).
+
+spdif_16mhz_44khz.sr:
+Original decoder is lucky to enter the stream with pulses of medium length. OK.
+New decoder recognizes short pulses (width <= 3 samples) and reports an error. OK.
+
+spdif_16mhz_44khz_3.sr:
+Original decoder decodes wrong because of false pulse width detection at the beginning. Fail.
+New decoder recognizes short pulses (width <= 3 samples) and reports an error. OK.
+
+spdif_24mhz_44khz_1.sr:
+Original decoder doesn't find any frames because of long low level phase before the data stream. Fail.
+Now decoder correctly decodes stream after synchronisation (First frame is missed). OK.
--- /dev/null
+-------------------------------------------------------------------------------
+Analog Devices AD7920
+-------------------------------------------------------------------------------
+
+This is a set of example captures of an Analog Devices AD7920 12-bit ADC.
+
+Details:
+https://www.analog.com/media/en/technical-documentation/data-sheets/AD7910_7920.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was ADALM2000 (at 5MHz):
+
+ Probe AD7920
+ ------------------
+ 0 CLK
+ 1 MISO
+ 2 CS#
+
+
+Probing
+-------
+
+The sigrok command line used was:
+
+ sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -C 0-2 -o <file>
+
+
+ad7920_fast_read.sr
+-------------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=10000000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -o ad7920_fast_read.sr -C 0-2
--- /dev/null
+-------------------------------------------------------------------------------
+Analog Devices ADXL345
+-------------------------------------------------------------------------------
+
+This is a set of example captures of an Analog Devices ADXL345 accelerometer.
+
+Details:
+https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was ADALM2000 (at 2MHz):
+
+ Probe ADXL345
+ -------------------
+ 0 CLK (Pin 4)
+ 1 MOSI (Pin 2)
+ 2 MISO (Pin 3)
+ 3 CS# (Pin 1)
+
+
+Probing
+-------
+
+The sigrok command line used was:
+
+ sigrok-cli -i - -I binary:numchannels=16:samplerate=2mhz -C 0-3 -o <file>
+
+
+adxl345_registers.sr
+--------------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=640000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=2mhz -C 0-3 -o adxl345_registers.sr
+
+
+adxl345_axis.sr
+---------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=200000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=2mhz -C 0-3 -o adxl345_axis.sr
--- /dev/null
+-------------------------------------------------------------------------------
+Linear Technology Corporation LTC2422
+-------------------------------------------------------------------------------
+
+This is a set of example captures of an LTC2422 20-bit ADC.
+
+Details:
+https://www.analog.com/media/en/technical-documentation/data-sheets/24212f.pdf
+
+
+Logic analyzer setup
+--------------------
+
+The logic analyzer used was ADALM2000 (at 5MHz):
+
+ Probe LTC2422
+ -------------------
+ 0 SCK
+ 1 SDO
+ 2 CS#
+
+
+Probing
+-------
+
+The sigrok command line used was:
+
+ sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -C 0-2 -o <file>
+
+
+ltc2422_read_adc.sr
+--------------------
+
+m2kcli digital auto -c buffer_size=10000 nb_samples=10000000 format=binary | sigrok-cli -i - -I binary:numchannels=16:samplerate=5mhz -o ltc2422_read_adc.sr -C 0-2
--- /dev/null
+------------------------------------------------------------------------
+SQI communication (multi-I/O SPI)
+------------------------------------------------------------------------
+
+This capture demonstrates SQI communication, which is a form of SPI data
+exchange where transmitters use multiple I/O data lines in parallel to
+communicate the same amount of data in fewer clock cycles.
+
+In contrast to e.g. QuadSPI flash memory chips which may change the data
+line count or clock scheme several times within a transaction, SQI keeps
+the clock and the number of data lines used by the transmitter consistent
+across the full length of the SPI transaction. Only the direction of data
+lines could change, when e.g. a master first transmits a request which
+the slave then responds to, while both use the same number of data lines.
+Full duplex communication as with the traditional MISO/MOSI scheme is
+not possible with SQI.
+
+
+Logic analyzer setup
+--------------------
+
+The capture was taken at a samplerate of 100MHz.
+
+ Probe SPI
+ ----------------------------
+ 2 SCK (clock)
+ 3 CS (select)
+ 4 IO0 (data, LSB)
+ 5 IO1
+ 6 IO2
+ 7 IO3 (data, MSB)
+
+
+sqi-four-data-lines-one-transfer.sr
+-----------------------------------
+
+This capture uses four I/O data lines. Data gets sampled at the rising
+clock edge (single data rate). Data is sent in MSB first order. The SPI
+transaction's data byte sequence is:
+
+ 80 00 00 10 22 42 4f 4f 54 00 80 00 00 a8 85 77 00 20 4e 00 00
+
+
+sqi-four-data-lines-three-transfers.sr
+--------------------------------------
+
+This capture was constructed from the above single-transfer example
+capture. The SPI transfer is repeated three times.
projects / sigrok-dumps.git / commitdiff