sigrok - User contributions [en]

Downloads

2016-01-03T22:13:58Z

Danielk: Advertise my Ubuntu PPA

== Releases ==

You can download the latest released tarballs of the following subprojects from [http://sigrok.org/download/ the sigrok.org download directory]:

{| border="0" style="font-size: smaller; white-space: nowrap;" class="alternategrey sigroktable"
|-
!Project
!Release/download
!News

|-
| [[libserialport]]
| [http://sigrok.org/download/source/libserialport/libserialport-0.1.0.tar.gz libserialport-0.1.0.tar.gz]
| [http://sigrok.org/gitweb/?p=libserialport.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[libsigrok]]
| [http://sigrok.org/download/source/libsigrok/libsigrok-0.3.0.tar.gz libsigrok-0.3.0.tar.gz]
| [http://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[libsigrokdecode]]
| [http://sigrok.org/download/source/libsigrokdecode/libsigrokdecode-0.3.1.tar.gz libsigrokdecode-0.3.1.tar.gz]
| [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[sigrok-cli]]
| [http://sigrok.org/download/source/sigrok-cli/sigrok-cli-0.5.0.tar.gz sigrok-cli-0.5.0.tar.gz]
| [http://sigrok.org/gitweb/?p=sigrok-cli.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[PulseView]]
| [http://sigrok.org/download/source/pulseview/pulseview-0.2.0.tar.gz pulseview-0.2.0.tar.gz]
| [http://sigrok.org/gitweb/?p=pulseview.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[Example dumps|sigrok-dumps]]
| [http://sigrok.org/download/source/sigrok-dumps/sigrok-dumps-0.1.0.tar.gz sigrok-dumps-0.1.0.tar.gz]
| [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[fx2lafw|sigrok-firmware-fx2lafw]] (source code)
| [http://sigrok.org/download/source/sigrok-firmware-fx2lafw/sigrok-firmware-fx2lafw-0.1.3.tar.gz sigrok-firmware-fx2lafw-0.1.3.tar.gz]
| [http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=NEWS;hb=HEAD release notes]

|-
| [[fx2lafw|sigrok-firmware-fx2lafw]] (prebuilt firmware)
| [http://sigrok.org/download/binary/sigrok-firmware-fx2lafw/sigrok-firmware-fx2lafw-bin-0.1.3.tar.gz sigrok-firmware-fx2lafw-bin-0.1.3.tar.gz]
| [http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=NEWS;hb=HEAD release notes]

|}

== Binaries and distribution packages ==

* '''Debian:''' [http://packages.qa.debian.org/s/sigrok.html sigrok] (pulls [http://packages.qa.debian.org/libs/libserialport.html libserialport], [http://packages.qa.debian.org/libs/libsigrok.html libsigrok], [http://packages.qa.debian.org/libs/libsigrokdecode.html libsigrokdecode], [http://packages.qa.debian.org/s/sigrok-cli.html sigrok-cli], [http://packages.qa.debian.org/p/pulseview.html pulseview], [http://packages.qa.debian.org/s/sigrok-firmware-fx2lafw.html sigrok-firmware-fx2lafw])
* '''Ubuntu:''' [http://launchpad.net/ubuntu/+source/sigrok sigrok] (pulls [http://launchpad.net/ubuntu/+source/libserialport libserialport], [http://launchpad.net/ubuntu/+source/libsigrok libsigrok], [http://launchpad.net/ubuntu/+source/libsigrokdecode libsigrokdecode], [http://launchpad.net/ubuntu/+source/sigrok-cli sigrok-cli], [http://launchpad.net/ubuntu/+source/pulseview pulseview], [http://launchpad.net/ubuntu/+source/sigrok-firmware-fx2lafw sigrok-firmware-fx2lafw])
* '''Ubuntu PPA:''' [https://launchpad.net/~daniel-elstner/+archive/ubuntu/sigrok PPA for sigrok] (recent sigrok builds from git, including firmware)
* '''Arch Linux:''' [https://aur.archlinux.org/packages.php?O=0&K=sigrok&do_Search=Go AUR (Arch Linux User Repository)], [https://aur.archlinux.org/packages/libserialport/ libserialport], [https://aur.archlinux.org/packages/libsigrok/ libsigrok], [https://aur.archlinux.org/packages/libsigrokdecode/ libsigrokdecode], [https://aur.archlinux.org/packages/sigrok-cli/ sigrok-cli], [https://aur.archlinux.org/packages/pulseview/ pulseview], [https://aur.archlinux.org/packages/sigrok-firmware-fx2lafw/ sigrok-firmware-fx2lafw]
* '''Slackware:''' [http://slackbuilds.org/repository/14.1/libraries/libserialport/?search=libserialport libserialport], [http://slackbuilds.org/repository/14.1/libraries/libsigrok/ libsigrok], [http://slackbuilds.org/repository/14.1/libraries/libsigrokdecode/ libsigrokdecode], [http://slackbuilds.org/repository/14.1/academic/sigrok-cli/?search=sigrok-cli sigrok-cli], [http://slackbuilds.org/repository/14.1/academic/pulseview/?search=pulseview pulseview], [http://slackbuilds.org/repository/14.1/misc/sigrok-firmware-fx2lafw/?search=sigrok-firmware-fx2lafw sigrok-firmware-fx2lafw]
* '''Fedora:''' [http://pkgs.fedoraproject.org/cgit/libserialport.git/ libserialport], [http://pkgs.fedoraproject.org/cgit/libsigrok.git/ libsigrok], [http://pkgs.fedoraproject.org/cgit/libsigrokdecode.git libsigrokdecode], [http://pkgs.fedoraproject.org/cgit/sigrok-cli.git sigrok-cli], [http://pkgs.fedoraproject.org/cgit/pulseview.git pulseview], [http://pkgs.fedoraproject.org/cgit/sigrok-firmware-fx2lafw.git sigrok-firmware-fx2lafw], [http://pkgs.fedoraproject.org/cgit/sigrok-firmware.git sigrok-firmware] (see also: [[Linux/Fedora]])
* '''Gentoo:''' [http://packages.gentoo.org/package/dev-libs/libserialport libserialport], [http://packages.gentoo.org/package/sci-libs/libsigrok libsigrok], [http://packages.gentoo.org/package/sci-libs/libsigrokdecode libsigrokdecode], [http://packages.gentoo.org/package/sci-electronics/sigrok-cli sigrok-cli], [http://packages.gentoo.org/package/sci-electronics/pulseview pulseview], [http://packages.gentoo.org/package/sys-firmware/sigrok-firmware-fx2lafw sigrok-firmware-fx2lafw]
* '''openSUSE:''' [https://build.opensuse.org/package/show/electronics/libserialport libserialport], [https://build.opensuse.org/package/show/electronics/libsigrok libsigrok], [https://build.opensuse.org/package/show/electronics/libsigrokdecode libsigrokdecode], [https://build.opensuse.org/package/show/electronics/sigrok-cli sigrok-cli], [https://build.opensuse.org/package/show/electronics/pulseview pulseview], [https://build.opensuse.org/package/show/electronics/sigrok-firmware-fx2lafw sigrok-firmware-fx2lafw]
* '''Windows:'''
** Nightly installer binaries: [http://sigrok.org/jenkins/job/sigrok-cross-mingw/platform=cross-i686-w64-mingw32/lastSuccessfulBuild/artifact/pulseview-NIGHTLY-installer.exe pulseview-NIGHTLY-installer.exe], [http://sigrok.org/jenkins/job/sigrok-cross-mingw/platform=cross-i686-w64-mingw32/lastSuccessfulBuild/artifact/sigrok-cli-NIGHTLY-installer.exe sigrok-cli-NIGHTLY-installer.exe]
** See also [[Windows#Windows_installers|Windows]] for more information, including driver and firmware handling.
* '''Mac OS X:''' There are [[Mac_OS_X#Building_using_Homebrew|Homebrew packages]] ([https://github.com/rene-dev/homebrew-sigrok github repo]), but you can also [[Mac_OS_X#Building_manually|compile sigrok from source]].
* '''FreeBSD:''' [http://www.freshports.org/devel/libserialport/ libserialport], [http://www.freshports.org/devel/libsigrok/ libsigrok], [http://www.freshports.org/devel/libsigrokdecode/ libsigrokdecode], [http://www.freshports.org/science/sigrok-cli/ sigrok-cli], [http://www.freshports.org/science/pulseview/ pulseview], [http://www.freshports.org/science/sigrok-firmware-fx2lafw/ sigrok-firmware-fx2lafw], [http://www.freshports.org/science/sigrok-firmware/ sigrok-firmware], [http://www.freshports.org/science/sigrok-firmware-utils/ sigrok-firmware-utils]
* '''OpenBSD:''' There are no ports/packages yet, contributors welcome!
* '''Android:'''
** [[PulseView]] nightly build: [http://sigrok.org/jenkins/job/sigrok-cross-android/platform=cross-arm-linux-androideabi/lastSuccessfulBuild/artifact/PulseView-NIGHTLY.apk PulseView-NIGHTLY.apk (ARM)], [http://sigrok.org/jenkins/job/sigrok-cross-android/platform=cross-i686-linux-android/lastSuccessfulBuild/artifact/PulseView-NIGHTLY.apk PulseView-NIGHTLY.apk (x86)]
** See also [[Android]] for more information.

Please contact us if you want to work on packages for other Linux distributions or OSes.

== Source code ==

The development is done in various [http://sigrok.org/gitweb/ git repositories].

See [[Building]] for build instructions.

== Example data ==

See the [[Example dumps]] wiki page.

== Firmware files ==

See the [[Firmware]] wiki page.

Supported hardware

2015-11-28T14:43:27Z

Danielk: SysClk LWLA1016 now supported

sigrok is intended as a flexible, cross-platform, and '''hardware-independent''' software suite, i.e., it supports various devices from many different vendors.

Here is a list of currently supported devices (various stages of completeness) and devices we plan to support in the near future.

The lists are sorted by category ([[File:Nuvola OK.png|16px]] supported: [[:Category:Supported|{{PAGESINCATEGORY:Supported|pages}}]], [[File:Nuvola Orange.png|16px]] in progress: [[:Category:In progress|{{PAGESINCATEGORY:In progress|pages}}]], [[File:Nuvola Red.png|16px]] planned: [[:Category:Planned|{{PAGESINCATEGORY:Planned|pages}}]]), and alphabetically within those categories.

== Logic analyzers ==

<gallery widths="100px" heights="100px">
File:ARMFLY MINI LOGIC.png|link=ARMFLY Mini-Logic|[[File:Nuvola OK.png|16px]] [[ARMFLY Mini-Logic]] (8ch, 24MHz)
File:ASIX SIGMA 2.png|link=ASIX SIGMA|[[File:Nuvola OK.png|16px]] [[ASIX SIGMA]] (16ch, 200MHz)
File:BeagleLogic.jpg|link=BeagleLogic|[[File:Nuvola OK.png|16px]] [[BeagleLogic]] (12(max 14)ch, 100MHz)
File:Braintechnology_usb_interface_v26.png|link=Braintechnology USB Interface V2.x|[[File:Nuvola OK.png|16px]] [[Braintechnology USB Interface V2.x]] (8/16ch, 24/12MHz)
File:Braintechnology_usb_lps.png|link=Braintechnology USB-LPS|[[File:Nuvola OK.png|16px]] [[Braintechnology USB-LPS]] (8/16ch, 24/12MHz)
File:Chronovu la8 front.png|link=ChronoVu LA8|[[File:Nuvola OK.png|16px]] [[ChronoVu LA8]] (8ch, 100MHz)
File:Chronovu la16.png|link=ChronoVu LA16|[[File:Nuvola OK.png|16px]] [[ChronoVu LA16]] (16ch, 200MHz)
File:Cwav_usbee_sx.png|link=CWAV USBee SX|[[File:Nuvola OK.png|16px]] [[CWAV USBee SX]] (8ch, 24MHz)
File:Buspirate_v3.png|link=Dangerous Prototypes Buspirate|[[File:Nuvola OK.png|16px]] [[Dangerous Prototypes Buspirate]] (5ch, 1MHz)
File:Dangerous prototypes irtoy mugshot.png|link=Dangerous Prototypes USB IR Toy|[[File:Nuvola OK.png|16px]] [[Dangerous Prototypes USB IR Toy]] (1ch, 10kHz)
File:Eeelec xla esla100.png|link=EE Electronics ESLA100|[[File:Nuvola OK.png|16px]] [[EE Electronics ESLA100]] (8ch, 24MHz)
File:Ikalogic_scanalogic2.png|link=IKALOGIC Scanalogic-2|[[File:Nuvola OK.png|16px]] [[IKALOGIC Scanalogic-2]] (4ch, 20MHz)
File:Ikalogic scanaplus mugshot.png|link=IKALOGIC ScanaPLUS|[[File:Nuvola OK.png|16px]] [[IKALOGIC ScanaPLUS]] (9ch, 100MHz)
File:Kingst kqs3506 la16100.png|link=KingST KQS3506-LA16100|[[File:Nuvola OK.png|16px]] [[KingST KQS3506-LA16100]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Lcsoft-miniboard-front.png|link=Lcsoft Mini Board|[[File:Nuvola OK.png|16px]] [[Lcsoft Mini Board]] (8/16ch, 24/12MHz)
File:logic-shrimp-front.png|link=Logic Shrimp|[[File:Nuvola OK.png|16px]] [[Logic Shrimp]] (4ch, 20MHz)
File:Mcu123 saleae logic clone.png|link=MCU123 Saleae Logic clone|[[File:Nuvola OK.png|16px]] [[MCU123 Saleae Logic clone]] (8ch, 24MHz)
File:Usbee_ax_clone_front.png|link=MCU123 USBee AX Pro clone|[[File:Nuvola OK.png|16px]] [[MCU123 USBee AX Pro clone]] (8ch, 24MHz)
File:Mcupro_Logic16_overview.png|link=mcupro Logic16 clone|[[File:Nuvola OK.png|16px]] [[mcupro Logic16 clone]] (16ch, 100MHz)
File:Openbench logic sniffer front.png|link=Openbench Logic Sniffer|[[File:Nuvola OK.png|16px]] [[Openbench Logic Sniffer]] (32ch, 100MHz)
File:Prist akip 9101 mugshot.png|link=Prist AKIP-9101|[[File:Nuvola OK.png|16px]] [[Prist AKIP-9101]] (16ch, 200MHz)
File:Robomotic buglogic3.png|link=Robomotic BugLogic 3|[[File:Nuvola OK.png|16px]] [[Robomotic BugLogic 3]] (8ch, 24MHz)
File:Robomotic_minilogic.png|link=Robomotic MiniLogic|[[File:Nuvola OK.png|16px]] [[Robomotic MiniLogic]] (8ch, 24MHz)
File:Saleae Logic.png|link=Saleae Logic|[[File:Nuvola OK.png|16px]] [[Saleae Logic]] (8ch, 24MHz)
File:Saleae_Logic16_bottom.png|link=Saleae Logic16|[[File:Nuvola OK.png|16px]] [[Saleae Logic16]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Saanlima Pipistrello-OLS.png|link=Saanlima Pipistrello OLS|[[File:Nuvola OK.png|16px]] [[Saanlima Pipistrello OLS]] (32ch, 100MHz)
File:Sysclk lwla1016.png|link=Sysclk LWLA1016|[[File:Nuvola OK.png|16px]] [[Sysclk LWLA1016]] (16ch, 100MHz)
File:Sysclk lwla1034 mugshot.png|link=Sysclk LWLA1034|[[File:Nuvola OK.png|16px]] [[Sysclk LWLA1034]] (34ch, 125MHz)
File:Wayengineer saleae16.png|link=WayEngineer Saleae16|[[File:Nuvola OK.png|16px]] [[WayEngineer Saleae16]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Zeroplus Logic Cube.png|link=ZEROPLUS Logic Cube LAP-C(16032)|[[File:Nuvola OK.png|16px]] [[ZEROPLUS Logic Cube LAP-C(16032)]] (16ch, 100MHz)
File:Zeroplus Logic Cube.png|link=ZEROPLUS Logic Cube LAP-C(322000)|[[File:Nuvola OK.png|16px]] [[ZEROPLUS Logic Cube LAP-C(322000)]] (32ch, 200MHz)
File:Zeroplus_lap-16128u.png|link=ZEROPLUS LAP-16128U|[[File:Nuvola OK.png|16px]] [[ZEROPLUS LAP-16128U]] (16ch, 200MHz)

File:ASIX Omega.png|link=ASIX OMEGA|[[File:Nuvola Orange.png|16px]] [[ASIX OMEGA]] (16ch, 400MHz)
File:DSLogic.png|link=DreamSourceLab DSLogic|[[File:Nuvola Orange.png|16px]] [[DreamSourceLab DSLogic]] (16ch, 400MHz)
File:Hsa-logic.png|link=HSA Logic|[[File:Nuvola Orange.png|16px]] [[HSA Logic]] (8ch, 6.25MHz)
File:RockyLogic Ant18e.png|link=RockyLogic Ant18e|[[File:Nuvola Orange.png|16px]] [[RockyLogic Ant18e]] (8ch, 1GHz)
File:Sysclk sla5032 mugshot.png|link=Sysclk SLA5032|[[File:Nuvola Orange.png|16px]] [[Sysclk SLA5032]] (32ch, 500MHz)

File:Acute_pkla1216.png|link=Acute PKLA-1216|[[File:Nuvola Red.png|16px]] [[Acute PKLA-1216]] (16ch, 200MHz)
File:Hantek 4032l mugshot.png|link=Hantek 4032L|[[File:Nuvola Red.png|16px]] [[Hantek 4032L]] (32ch, 400MHz)
File:Ideofy_la_08.png|link=Ideofy LA-08|[[File:Nuvola Red.png|16px]] [[Ideofy LA-08]] (8ch, 96/60/30MHz @ 2/4/8ch)
File:Intronix Logicport.png|link=Intronix Logicport LA1034|[[File:Nuvola Red.png|16px]] [[Intronix Logicport LA1034]] (34ch, 500MHz)
File:Sigrok_logo_no_text_transparent_512.png|link=Link Instruments LA-5580|[[File:Nuvola Red.png|16px]] [[Link Instruments LA-5580]] (80ch, 500MHz)
File:Microchip_pickit2.png|link=Microchip PICkit2|[[File:Nuvola Red.png|16px]] [[Microchip PICkit2]] (3ch, 1MHz)
File:Minila parport.png|link=MiniLA|[[File:Nuvola Red.png|16px]] [[MiniLA]] (32ch, 100MHz)
File:Minila_mockup.png|link=MiniLA Mockup|[[File:Nuvola Red.png|16px]] [[MiniLA Mockup]] (32ch, 100MHz)
File:Noname_la16_mugshot.png|link=Noname LA16|[[File:Nuvola Red.png|16px]] [[Noname LA16]] (16ch, 100MHz)
File:Noname xl logic16 100m mugshot.png|link=Noname XL-LOGIC16-100M|[[File:Nuvola Red.png|16px]] [[Noname XL-LOGIC16-100M]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Rockylogic_ant8.png|link=RockyLogic Ant8|[[File:Nuvola Red.png|16px]] [[RockyLogic Ant8]] (8ch, 500MHz)
File:Sysclk lwla2034 mugshot.png|link=Sysclk LWLA2034|[[File:Nuvola Red.png|16px]] [[Sysclk LWLA2034]] (34ch, 200MHz)
File:Techtools_digiview_dv1-100.png|link=TechTools DigiView DV1-100|[[File:Nuvola Red.png|16px]] [[TechTools DigiView DV1-100]] (18ch, 100MHz)
File:Xmos xtag2.png|link=XMOS XTAG-2|[[File:Nuvola Red.png|16px]] [[XMOS XTAG-2]] (?ch, 50MHz)
File:Zlg_la1032.png|link=ZLG LA1032|[[File:Nuvola Red.png|16px]] [[ZLG LA1032]] (32ch, 100MHz)
</gallery>

== Mixed-signal devices ==

<gallery widths=105px heights=105px>
File:Armfly_ax_pro.png|link=ARMFLY AX-Pro|[[File:Nuvola OK.png|16px]] [[ARMFLY AX-Pro]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:Sysclk ax pro mugshot.png|link=Sysclk AX-Pro|[[File:Nuvola OK.png|16px]] [[Sysclk AX-Pro]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 3MHz BW)
File:Esla201a.png|link=EE Electronics ESLA201A|[[File:Nuvola OK.png|16px]] [[EE Electronics ESLA201A]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:Rigol DS1052E.png|link=Rigol DS1000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS1000 series|Rigol DS1000D series]] (16ch, 2ch analog, 50-150MHz BW)
File:Rigol_VS5202D.png|link=Rigol VS5000 series|[[File:Nuvola OK.png|16px]] [[Rigol VS5000 series|Rigol VS5000D series]] (16ch, 2ch analog, 20-200MHz BW
File:Yokogawa DLM2000 front.png|link=Yokogawa DLM2000 series|[[File:Nuvola OK.png|16px]] [[Yokogawa DLM2000 series]] (8ch, 2/4ch analog, 2.5GSa/s, 200/350/500MHz BW)
File:Xzl studio ax mugshot.png|link=XZL_Studio AX|[[File:Nuvola OK.png|16px]] [[XZL_Studio AX]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:BitScope BS10.png|link=BitScope BS10|[[File:Nuvola Orange.png|16px]] [[BitScope BS10]] (8ch, 40MHz; 2ch analog, 20MSa/s, ? BW)
File:Link Instruments MSO-19 front.png|link=Link Instruments MSO-19|[[File:Nuvola Orange.png|16px]] [[Link Instruments MSO-19]] (8ch, 200MHz; 1ch analog, 200MSa/s, 60MHz BW)

File:Agilent_MSO7104A.png|link=Agilent MSO7104A|[[File:Nuvola Red.png|16px]] [[Agilent MSO7104A]] (16ch, ?; 4ch analog, 2GSa/s, 1GHz BW)
File:Digilent_analog_discovery.png|link=Digilent Analog Discovery|[[File:Nuvola Red.png|16px]] [[Digilent Analog Discovery]] (16ch, 100MHz; 2ch analog, 100MSa/s, 5MHz BW)
File:Hantek_1008C.png|link=Hantek 1008C|[[File:Nuvola Red.png|16px]] [[Hantek 1008C]] (8ch)
File:Lab nation smartscope mugshot.png|link=LabNation SmartScope|[[File:Nuvola Red.png|16px]] [[LabNation SmartScope]] (8ch, 100MHz; 2ch analog, 100MSa/s, 45MHz BW)
File:Meilhaus_mephisto_scope1.png|link=Meilhaus MEphisto Scope1|[[File:Nuvola Red.png|16px]] [[Meilhaus MEphisto Scope1]] (16ch, 100kHz; 2ch analog, 1MSa/s, 500kHz BW)
File:Polabs_poscope_basic2.png|link=PoLabs PoScope Basic2|[[File:Nuvola Red.png|16px]] [[PoLabs PoScope Basic2]] (16ch, 8MHz; 2ch analog, 200kSa/s, ? BW)
File:QuantAsylum QA100.png|link=QuantAsylum QA100|[[File:Nuvola Red.png|16px]] [[QuantAsylum QA100]] (12ch; 2ch analog)
File:Saleae Logic Pro 16 bottom.jpg|link=Saleae Logic Pro 16|[[File:Nuvola Red.png|16px]] [[Saleae Logic Pro 16]] (4/16ch, 500/100MHz; 16ch analog, 50MSa/s, 5MHz BW)
File:Sigrok_logo_no_text_transparent_512.png|link=XZL_Studio DX|[[File:Nuvola Red.png|16px]] [[XZL_Studio DX]] (16ch, 24MHz; 2ch analog)
</gallery>


1 Only the logic analyzer functionality is supported so far, analog support is work in progress. 


== Oscilloscopes ==

<gallery widths=100px heights=100px>
File:Agilent DSO1014A.png|link=Agilent DSO1000 series|[[File:Nuvola OK.png|16px]] [[Agilent DSO1000 series]] (2-4ch, 2GS/s, 60-200MHz BW)
File:Fluke_Scopemeter_199B.png|link=Fluke ScopeMeter 199B|[[File:Nuvola OK.png|16px]] [[Fluke ScopeMeter 199B]] (2ch, 2.5GS/s, 200MHz BW)
File:Voltcraft dso-6060c mugshot.png|link=GW Instek GDS-800 series|[[File:Nuvola OK.png|16px]] [[GW Instek GDS-800 series]] (2ch, 25GS/s, 60-250MHz BW)
File:Hameg HMO2024.png|link=Hameg HMO compact series|[[File:Nuvola OK.png|16px]] [[Hameg HMO compact series]] (2-4ch, 2GS/s, 70-200MHz BW)
File:Hantek DSO-2090.png|link=Hantek DSO-2090|[[File:Nuvola OK.png|16px]] [[Hantek DSO-2090]] (2ch, 100MS/s, 40MHz)
File:Hung chang dso 2100 mugshot.png|link=Hung-Chang_DSO-2100|[[File:Nuvola OK.png|16px]] [[Hung-Chang DSO-2100]] (2ch, 100MS/s, 30MHz BW)
File:Rigol DS1052E.png|link=Rigol DS1000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS1000 series|Rigol DS1000E series]] (2ch, 1GS/s, 50-150MHz BW)
File:Rigol DS1074Z front.png|link=Rigol DS1000Z series|[[File:Nuvola OK.png|16px]] [[Rigol DS1000Z series|Rigol DS1000Z series]] (4ch, 1GS/s, 50-100MHz BW)
File:Rigol-ds2072 mugshot.png|link=Rigol DS2000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS2000 series]] (2ch, 2GS/s, 70-200MHz BW)
File:Rigol_VS5202D.png|link=Rigol VS5000 series|[[File:Nuvola OK.png|16px]] [[Rigol VS5000 series]] (2ch, 20-200MHz BW)

File:Hantek dso2250 mugshot.png|link=Hantek DSO-2250|[[File:Nuvola Orange.png|16px]] [[Hantek DSO-2250]] (2ch, 250MS/s, 100MHz BW)
File:Hantek dso-5200a device front.png|link=Hantek DSO-5200A|[[File:Nuvola Orange.png|16px]] [[Hantek DSO-5200A]] (2ch, 250MS/s, 200MHz BW)
File:OsciPrime.png|link=Nexus-Computing OsciPrime|[[File:Nuvola Orange.png|16px]] [[Nexus-Computing OsciPrime]] (2ch, ?MS/s, 3.3MHz-8MHz BW)
File:Velleman PCSU1000.png|link=Velleman PCSU1000|[[File:Nuvola Orange.png|16px]] [[Velleman PCSU1000]] (2ch, 1GS/s, 50MHz BW)

File:Fluke scopemeter123.png|link=Fluke ScopeMeter 123|[[File:Nuvola Red.png|16px]] [[Fluke ScopeMeter 123]] (2ch, 25MS/s, 20MHz BW)
File:Focussz_fosc21_mugshot.png|link=Focussz Fosc21|[[File:Nuvola Red.png|16px]] [[Focussz Fosc21]] (2ch, 8kS/s, 3kHz BW)
File:Hantek 6022be.jpg|link=Hantek 6022BE|[[File:Nuvola Red.png|16px]] [[Hantek 6022BE]] (2ch, 48MS/s, 20MHz BW)
File:Hantek front.jpg|link=Hantek 6052BE|[[File:Nuvola Red.png|16px]] [[Hantek 6052BE]] (2ch, 150MS/s, 50MHz BW)
File:Sigrok_logo_no_text_transparent_512.png|link=Hantek DSO-1200|[[File:Nuvola Red.png|16px]] [[Hantek DSO-1200]] (2ch, 500MS/s, 200MHz BW)
File:Usbduxfast.png|link=Incite Technology USB-DUXfast|[[File:Nuvola Red.png|16px]] [[Incite Technology USB-DUXfast]] (16ch, 3MHz, ? BW)
File:Sigrok_logo_no_text_transparent_512.png|link=Owon SDS series|[[File:Nuvola Red.png|16px]] [[Owon SDS series]] (2ch, 0.5-3.2GS/s, 60-300MHz BW)
File:Picoscope 2203.png|link=Pico Technology PicoScope 2203|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 2203]] (40/20MS/s, 5MHz BW)
File:PicoScope_2205.png|link=Pico Technology PicoScope 2205|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 2205]] (200/100MS/s, 25MHz BW)
File:Picoscope 3206.png|link=Pico Technology PicoScope 3206|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 3206]] (200/100MS/s, 200MHz BW)
File:Picoscope 5203.png|link=Pico Technology PicoScope 5203|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 5203]] (1/0.5GS/s, 250MHz BW)
File:Tektronix tds2024b mugshot.png|link=Tektronix TDS2000B series|[[File:Nuvola Red.png|16px]] [[Tektronix TDS2000B series]] (2-4ch, 1-2GS/s, 60-200MHz BW)
File:UNI-T UTD2042C.png|link=UNI-T UTD2042C|[[File:Nuvola Red.png|16px]] [[UNI-T UTD2042C]] (2ch, 500MS/s, 40MHz BW)
File:VellemanWFS210.png|link=Velleman WFS210|[[File:Nuvola Red.png|16px]] [[Velleman WFS210]] (2ch, 10MS/s, ?? MHz BW)
File:Voltcraft dso-220 usb.png|link=Voltcraft DSO-220|[[File:Nuvola Red.png|16px]] [[Voltcraft DSO-220]] (2ch, 60MS/s, 20MHz BW)
File:Voltcraft DSO-3062C.png|link=Voltcraft DSO-3062C|[[File:Nuvola Red.png|16px]] [[Voltcraft DSO-3062C]] (2ch, 1GS/s, 60MHz BW)
</gallery>

== Multimeters ==

<gallery widths="100px" heights="100px">
File:Agilent U1232A.png|link=Agilent U12xxx series|[[File:Nuvola OK.png|16px]] [[Agilent U12xxx series]] (USB/Bluetooth)
File:Bbc gm m2110 mugshot.png|link=BBC Goertz Metrawatt M2110|[[File:Nuvola OK.png|16px]] [[BBC Goertz Metrawatt M2110]] (30000 counts, RS232)
File:Brymen BM257.png|link=Brymen BM257|[[File:Nuvola OK.png|16px]] [[Brymen BM257]] (6000 counts, RS232/USB)
File:Brymen bm257s mugshot.png|link=Brymen BM257s|[[File:Nuvola OK.png|16px]] [[Brymen BM257s]] (6000 counts, RS232/USB)
File:Bm_857_mugshot_500000.png|link=Brymen BM857|[[File:Nuvola OK.png|16px]] [[Brymen BM857]] (50000 counts, RS232)
File:Bm869_mugshot.png|link=Brymen BM869|[[File:Nuvola OK.png|16px]] [[Brymen BM869]] (50000 counts, USB)
File:Digitek_dt4000zc_device_front.png|link=Digitek DT4000ZC|[[File:Nuvola OK.png|16px]] [[Digitek DT4000ZC]] (4000 counts, RS232)
File:Fluke 187.png|link=Fluke 187/189|[[File:Nuvola OK.png|16px]] [[Fluke 187/189]] (50000 counts, RS232)
File:Fluke 287.png|link=Fluke 287/289|[[File:Nuvola OK.png|16px]] [[Fluke 287/289]] (50000 counts, RS232)
File:Gmc metrahit 14a logo.png|link=Gossen Metrawatt Metrahit 14A|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 14A]] (3100 counts, RS232)
File:Gossen Metrawatt Metrahit 16I small.png|link=Gossen Metrawatt Metrahit 16I|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 16I]] (3100 counts, RS232)
File:Gossen Metrawatt Metrahit 18S small.png|link=Gossen Metrawatt Metrahit 18S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 18S]] (31000 counts, RS232)
File:Gossen Metrawatt Metrahit 25S Logo.png|link=Gossen Metrawatt Metrahit 25S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 25S]] (31000 counts, RS232/USB)
File:Gmc kmm2002 logo.png|link=Gossen Metrawatt T-Com KMM2002|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt T-Com KMM2002]] (3100 counts, RS232)
File:Gmc metrahit 29s logo.png|link=Gossen Metrawatt Metrahit 29S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 29S]] (310000 counts, RS232/USB)
File:HT410 logo.png|link=HT Instruments HT410|[[File:Nuvola OK.png|16px]] [[HT Instruments HT410]] (3100 counts, RS232)
File:100px_Idm103n.png|link=ISO-TECH IDM103N|[[File:Nuvola OK.png|16px]] [[ISO-TECH IDM103N]] (4000 counts, RS232)
File:Mastech mas345 device front.png|link=MASTECH MAS345|[[File:Nuvola OK.png|16px]] [[MASTECH MAS345]] (4000 counts, RS232)
File:Mastech ms8250b mugshot.png|link=MASTECH MS8250B|[[File:Nuvola OK.png|16px]] [[MASTECH MS8250B]] (4000 counts, USB)
File:Metex m4650cr mugshot.png|link=Metex M-4650CR|[[File:Nuvola OK.png|16px]] [[Metex M-4650CR]] (20000 counts, RS232)
File:Metex_me-31.png|link=Metex ME-31|[[File:Nuvola OK.png|16px]] [[Metex ME-31]] (4000 counts, RS232)
File:Norma dm950.png|link=Norma DM950|[[File:Nuvola OK.png|16px]] [[Norma DM950]] (21000 counts, RS232)
File:Pce-pce-dm32.png|link=PCE PCE-DM32|[[File:Nuvola OK.png|16px]] [[PCE PCE-DM32]] (4000 counts, RS232)
File:Metex_me-31.png|link=PeakTech 3410|[[File:Nuvola OK.png|16px]] [[PeakTech 3410]] (4000 counts, RS232)
File:Peaktech 4370 device front.png|link=PeakTech 4370|[[File:Nuvola OK.png|16px]] [[PeakTech 4370]] (2000 counts, RS232)
File:Rs_22_168_mugshot.png|link=RadioShack 22-168|[[File:Nuvola OK.png|16px]] [[RadioShack 22-168]] (2000 counts, RS232)
File:Rs_22-805_front.png|link=RadioShack 22-805|[[File:Nuvola OK.png|16px]] [[RadioShack 22-805]] (4000 counts, RS232)
File:radioshack_22_812_front.png|link=RadioShack 22-812|[[File:Nuvola OK.png|16px]] [[RadioShack 22-812]] (4000 counts, RS232)
File:siemens_b1026_logo.png|link=Siemens B1026|[[File:Nuvola OK.png|16px]] [[Siemens B1026]] (21000 counts, RS232)
File:Siemens B1105 small.png|link=Siemens B1105|[[File:Nuvola OK.png|16px]] [[Siemens B1105]] (310000 counts, RS232/USB)
File:Tecpel dmm8061.png|link=Tecpel DMM-8061|[[File:Nuvola OK.png|16px]] [[Tecpel DMM-8061]] (4000 counts, RS232/USB)
File:Tp4000zc_front.png|link=TekPower TP4000ZC|[[File:Nuvola OK.png|16px]] [[TekPower TP4000ZC]] (4000 counts, RS232)
File:Tenma 72-7745.png|link=Tenma 72-7745|[[File:Nuvola OK.png|16px]] [[Tenma 72-7745]] (4000 counts, RS232/USB)
File:Ut60e_-_front_-_alpha.png|link=UNI-T UT60E|[[File:Nuvola OK.png|16px]] [[UNI-T UT60E]] (4000 counts, RS232/USB)
File:Uni-t ut61b mugshot.png|link=UNI-T UT61B|[[File:Nuvola OK.png|16px]] [[UNI-T UT61B]] (4000 counts, RS232/USB)
File:Uni-t ut61c mugshot.png|link=UNI-T UT61C|[[File:Nuvola OK.png|16px]] [[UNI-T UT61C]] (6000 counts, RS232/USB)
File:Uni t ut61d device.png|link=UNI-T UT61D|[[File:Nuvola OK.png|16px]] [[UNI-T UT61D]] (6000 counts, RS232/USB)
File:Old ver front.png|link=UNI-T UT61E|[[File:Nuvola OK.png|16px]] [[UNI-T UT61E]] (22000 counts, RS232/USB)
File:Ut71c mugshot.png|link=UNI-T UT71C|[[File:Nuvola OK.png|16px]] [[UNI-T UT71C]] (40000 counts, RS232/USB)
File:Va_va18b.png|link=V&A VA18B|[[File:Nuvola OK.png|16px]] [[V&A VA18B]] (6000 counts, USB)
File:Va va40b mugshot.png|link=V&A VA40B|link=V&A VA40B|[[File:Nuvola OK.png|16px]] [[V&A VA40B]] (6000 counts, USB)
File:DVM4100.png|link=Velleman DVM4100|link=Velleman DVM4100|[[File:Nuvola OK.png|16px]] [[Velleman DVM4100]] (6000 counts, USB)
File:Victor 70C.png|link=Victor 70C|[[File:Nuvola OK.png|16px]] [[Victor 70C]] (4000 counts, USB)
File:Victor 86c device front.png|link=Victor 86C|[[File:Nuvola OK.png|16px]] [[Victor 86C]] (4000 counts, USB)
File:Voltcraft m-3650cr.png|link=Voltcraft M-3650CR|[[File:Nuvola OK.png|16px]] [[Voltcraft M-3650CR]] (2000 counts, RS232)
File:Voltcraft_M-3650D_transparent.png|link=Voltcraft M-3650D|[[File:Nuvola OK.png|16px]] [[Voltcraft M-3650D]] (2000 counts, RS232)
File:Voltcraft m4650cr.png|link=Voltcraft M-4650CR|[[File:Nuvola OK.png|16px]] [[Voltcraft M-4650CR]] (20000 counts, RS232)
File:Voltcraft ME-42 logo.png|link=Voltcraft ME-42|[[File:Nuvola OK.png|16px]] [[Voltcraft ME-42]] (4000 counts, RS232)
File:Voltcraft vc820 device.png|link=Voltcraft VC-820|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-820]] (4000 counts, RS232/USB)
File:Voltcraft vc830.png|link=Voltcraft VC-830|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-830]] (6000 counts, RS232/USB)
File:Voltcraft vc840 device front.png|link=Voltcraft VC-840|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-840]] (4000 counts, RS232/USB)
File:Voltcraft vc920.png|link=Voltcraft VC-920|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-920]] (40000/4000 counts, RS232/USB)
File:Voltcraft vc940.png|link=Voltcraft VC-940|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-940]] (40000/4000 counts, RS232/USB)

File:Tenma 72-1016.png|link=Tenma 72-1016|[[File:Nuvola Orange.png|16px]] [[Tenma 72-1016]] (6000 counts, RS232/USB)
File:Tenma 72-7730.png|link=Tenma 72-7730|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7730]] (20000 counts, RS232/USB)
File:Tenma 72-7732.png|link=Tenma 72-7732|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7732]] (40000 counts, RS232/USB)
File:Tenma 72-7750.png|link=Tenma 72-7750|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7750]] (6000 counts, RS232/USB)
File:Tenma 72-9380A.png|link=Tenma 72-9380A|[[File:Nuvola Orange.png|16px]] [[Tenma 72-9380A]] (40000 counts, RS232/USB)

File:Appa 107.png|link=APPA 107|[[File:Nuvola Red.png|16px]] [[APPA 107]] (4000 / 20000 counts, RS232)
File:Digitek dt8000.png|link=Digitek DT8000|[[File:Nuvola Red.png|16px]] [[Digitek DT8000]] (8000 counts, RS232)
File:Digitek dt80000.png|link=Digitek DT80000|[[File:Nuvola Red.png|16px]] [[Digitek DT80000]] (80000 counts, RS232)
File:Escort 179 device front.png|link=Escort 179|[[File:Nuvola Red.png|16px]] [[Escort 179]] (10000 counts, RS232)
File:Gossen metrahit 30m.png|link=Gossen-Metrawatt METRAHIT 30M|[[File:Nuvola Red.png|16px]] [[Gossen-Metrawatt METRAHIT 30M]] (1200000 counts, RS232/USB)
File:Sigrok_logo_no_text_transparent_512.png|link=HYELEC MS8236|[[File:Nuvola Red.png|16px]] [[HYELEC MS8236]] (6000 counts, USB)
File:800px-Mastech m9803r device front.png|link=MASTECH M9803R|[[File:Nuvola Red.png|16px]] [[MASTECH M9803R]] (4000 counts, RS232)
File:Metrix mx53.png|link=Metrix MX53|[[File:Nuvola Red.png|16px]] [[Metrix MX53]] (50000 counts, RS232)
File:Metrix mx56c.png|link=Metrix MX56C|[[File:Nuvola Red.png|16px]] [[Metrix MX56C]] (50000 counts, RS232)
File:Peaktech 4380 mugshot.png|link=PeakTech 4380|[[File:Nuvola Red.png|16px]] [[PeakTech 4380]] (4000 counts, RS232)
File:Sigrok_logo_no_text_transparent_512.png|link=Protek 6500|[[File:Nuvola Red.png|16px]] [[Protek 6500]] (50000 counts, RS232)
File:Rigol DM3068 front.png|link=Rigol DM3068|[[File:Nuvola Red.png|16px]] [[Rigol DM3068]] (2200000 counts, LAN/USB/GPIB/RS232)
File:Voltcraft m3890dt usb.png|link=Voltcraft M-3890DT|[[File:Nuvola Red.png|16px]] [[Voltcraft M-3890DT]] (4000 counts, USB)
File:Voltcraft m4660a device front.png|link=Voltcraft M-4660A|[[File:Nuvola Red.png|16px]] [[Voltcraft M-4660A]] (20000 counts, RS232)
File:Sigrok_logo_no_text_transparent_512.png|link=Voltcraft VC-870|[[File:Nuvola Red.png|16px]] [[Voltcraft VC-870]] (40000 counts, RS232/USB)
</gallery>

== LCR meters ==

<gallery widths="100px" heights="100px">
File:Voltcraft4080_2.png|link=Voltcraft 4080|[[File:Nuvola Orange.png|16px]] [[Voltcraft 4080]] (serial)
</gallery>

== Sound level meters ==

<gallery widths="100px" heights="100px">
File:CEM DT-8852.png|link=CEM DT-8852|[[File:Nuvola OK.png|16px]] [[CEM DT-8852]] (USB)
File:Colead SL-5868P.png|link=Colead SL-5868P|[[File:Nuvola OK.png|16px]] [[Colead SL-5868P]] (RS232)
File:Kecheng KC-330B.png|link=Kecheng KC-330B|[[File:Nuvola OK.png|16px]] [[Kecheng KC-330B]] (RS232)
File:Tondaj sl-814.png|link=Tondaj SL-814|[[File:Nuvola OK.png|16px]] [[Tondaj SL-814]] (USB)
File:Voltcraft_DL-161S.png|link=Voltcraft DL-161S|[[File:Nuvola Orange.png|16px]] [[Voltcraft DL-161S]] (USB)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (also: light-/thermo-/hygrometer; RS232)
File:Voltcraft_dl_160s.png|link=Voltcraft DL-160S|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-160S]] (USB)
</gallery>

== Thermometers ==

<gallery widths="100px" heights="100px">
File:rs55ii.png|link=APPA 55II|[[File:Nuvola OK.png|16px]] [[APPA 55II]] (2xtemp, RS232)
File:EL-USB-2.png|link=Lascar Electronics EL-USB-2|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-2]] (1xtemp, 1xhum, USB)
File:Mic 98581.png|link=MIC 98581|[[File:Nuvola OK.png|16px]] [[MIC 98581]] (1xtemp, USB)
File:Mic 98583.png|link=MIC 98583|[[File:Nuvola OK.png|16px]] [[MIC 98583]] (1xtemp, 1xhum, USB)
File:Uni-t ut325 front.png|link=UNI-T UT325|[[File:Nuvola OK.png|16px]] [[UNI-T UT325]] (2xtemp, USB)
File:Voltcraft k204.png|link=Voltcraft K204|[[File:Nuvola OK.png|16px]] [[Voltcraft K204]] (4xtemp, RS232)
File:Elitech rc3.png|link=Elitech RC-3|[[File:Nuvola Red.png|16px]] [[Elitech RC-3]] (1xtemp, RS232)
File:Escort 19.png|link=Escort 19|[[File:Nuvola Red.png|16px]] [[Escort 19]] (1x temp, RS232)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (1xtemp, RS232)
File:Rding temper front.png|link=RDing TEMPer|[[File:Nuvola Red.png|16px]] [[RDing TEMPer]] (1xtemp, USB)
File:Rding temper gold device front.png|link=RDing TEMPer Gold|[[File:Nuvola Red.png|16px]] [[RDing TEMPer Gold]] (1xtemp, USB)
File:Rding temper1 device front.png|link=RDing TEMPer1|[[File:Nuvola Red.png|16px]] [[RDing TEMPer1]] (1xtemp, USB)
File:Pcsensor_temper1k2.png|link=RDing TEMPer1K2|[[File:Nuvola Red.png|16px]] [[RDing TEMPer1K2]] (1xtemp, USB)
File:Voltcraft dl-120th.png|link=Voltcraft DL-120TH|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-120TH]] (1xtemp, USB)
File:Voltcraft dl-140th.png|link=Voltcraft DL-140TH|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-140TH]] (1xtemp, USB)
</gallery>

== Hygrometers ==

<gallery widths="100px" heights="100px">
File:EL-USB-2.png|link=Lascar Electronics EL-USB-2|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-2]] (temp/humidity, USB)
File:Mic 98583.png|link=MIC 98583|[[File:Nuvola OK.png|16px]] [[MIC 98583]] (temp/humidity, USB)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (also: light-/soundlevelmeter; RS232)
File:Silabs si7005usb dgl eb top.jpg|link=SiLabs Si7005USB-Dongle|[[File:Nuvola Red.png|16px]] [[SiLabs Si7005USB-Dongle]] (USB)
</gallery>

== Anemometers ==

<gallery widths="100px" heights="100px">
File:Mastech ms6252b.png|link=MASTECH MS6252B|[[File:Nuvola Red.png|16px]] [[MASTECH MS6252B]] (USB)
</gallery>

== Light meters ==

<gallery widths="100px" heights="100px">
File:Lutron YK-2005LX.png|link=Lutron YK-2005LX|[[File:Nuvola Red.png|16px]] [[Lutron YK-2005LX]] (RS232)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (RS232)
</gallery>

== Energy meters ==

<gallery widths="100px" heights="100px">
File:Actaris_a14c5_teleinfo.png|link=EDF Teleinfo|[[File:Nuvola OK.png|16px]] [[EDF Teleinfo]] (RS232)
File:Acme.png|link=BayLibre ACME|[[File:Nuvola OK.png|16px]] [[BayLibre ACME]] (I2C)
</gallery>

== DAQs ==

<gallery widths="100px" heights="100px">
File:Ni usb 6008.png|link=NI USB-6008|[[File:Nuvola Red.png|16px]] [[NI USB-6008]] (8/2 analog inputs/outputs, 12 digital I/Os)
</gallery>

== Dataloggers ==

<gallery widths="100px" heights="100px">
File:EL-USB-CO.png|link=Lascar Electronics EL-USB-CO|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-CO]] (carbon monoxide (CO) logger, USB)
File:Testo_435-4.png|link=Testo 435-4|[[File:Nuvola OK.png|16px]] [[Testo 435-4]] (USB)
File:Gsg_indoor_air_monitor.png|link=GSG Indoor Air Monitor|[[File:Nuvola Red.png|16px]] [[GSG Indoor Air Monitor]] (air quality monitor, USB)
File:Maul_studio_i.png|link=MAUL studio i|[[File:Nuvola Red.png|16px]] [[MAUL studio i]] (weighing scale, RS232)
File:Voltcraft co-20.png|link=Voltcraft CO-20|[[File:Nuvola Red.png|16px]] [[Voltcraft CO-20]] (air quality monitor, USB)
</gallery>

== Tachometers ==

<gallery widths="100px" heights="100px">
File:Uni-t ut372 mugshot.png|link=UNI-T UT372|[[File:Nuvola OK.png|16px]] [[UNI-T UT372]] (USB)
</gallery>

== Scales ==

<gallery widths="100px" heights="100px">
File:Kern ew-6200-2nm mugshot.png|link=KERN scale series|[[File:Nuvola OK.png|16px]] [[KERN scale series]] (RS232)
</gallery>

== Digital loads ==

<gallery widths="100px" heights="100px">
File:Maynuo m9812 mugshot.png|link=Maynuo M9812|[[File:Nuvola OK.png|16px]] [[Maynuo M9812]]
File:Atten ATZ9711.png|link=ATTEN ATZ9711|[[File:Nuvola Red.png|16px]] [[ATTEN ATZ9711]]
</gallery>

== Function generators ==

<gallery widths="100px" heights="100px">
File:Hantek DDS-3X25 top.png|link=Hantek DDS-3X25|[[File:Nuvola Red.png|16px]] [[Hantek DDS-3X25]] (25MHz, PC-based, USB)
File:Siglent sdg1010 device front 8116.png|link=Siglent SDG1010|[[File:Nuvola Red.png|16px]] [[Siglent SDG1010]] (10MHz, USB)

File:BG7TBL small.png|link=BG7TBL|[[File:Nuvola Red.png|16px]] [[BG7TBL]] (138MHz-4.4GHz, PC-based, USB)

File:MHINSTEK UDB1305S persp.jpg|link=MHINSTEK UDB1xxxS|[[File:Nuvola Red.png|16px]] [[MHINSTEK UDB1xxxS]] (2/5/8MHz, Serial)
</gallery>

== RF receivers ==

<gallery widths="100px" heights="100px">
File:Per vices noctar.png|link=Per Vices Noctar|[[File:Nuvola Red.png|16px]] [[Per Vices Noctar]] (100kHz-4GHz, IQ modulator/demodulator, PCIe)
</gallery>

== Spectrum analyzers ==

TODO.

== Power supplies ==

<gallery widths="100px" heights="100px">
File:Atten PPS3203T-3S.png|link=Atten PPS3203T-3S|[[File:Nuvola OK.png|16px]] [[Atten PPS3203T-3S]] (3ch, 2x 0-32V, 1x 0-6V at 0-3A, USB&RS232)
File:Chroma_61604_front.png|link=Chroma 61604|[[File:Nuvola OK.png|16px]] [[Chroma 61604]] (1ch, 0-300V, 0-16A, 2kVA)
File:Conrad_digi_35_cpu_logo.png|link=Conrad DIGI 35 CPU|[[File:Nuvola OK.png|16px]] [[Conrad DIGI 35 CPU]] (1ch, 0-35V/0-2.55A, RS232)
File:HP-6632B_mugshot.png|link=HP 6632B|[[File:Nuvola OK.png|16px]] [[HP 6632B]] (1ch, 0-20V/0-5A, GPIB&RS232)
File:Velleman ps3005d mugshot.png|link=Korad KDxxxxP series|[[File:Nuvola OK.png|16px]] [[Korad KDxxxxP series]] (1ch, 0-30V/0-5A, USB&RS232)
File:Manson hcs3202.png|link=Manson HCS-3202|[[File:Nuvola OK.png|16px]] [[Manson HCS-3202]] (1ch, 1-36V/0-10A, USB)
File:Motech_LPS-301_logo.png|link=Motech LPS-301|[[File:Nuvola OK.png|16px]] [[Motech LPS-301]] (1ch, 1-32V/0-2A, RS232)
File:Philips PM2813.png|link=Philips PM2800 series|[[File:Nuvola OK.png|16px]] Fluke/Philips PM2800 series
File:Rigol DP832.png|link=Rigol DP800 series|[[File:Nuvola OK.png|16px]] [[Rigol DP800 series]]
File:Voltcraft pps-11815 logo.png|link=Voltcraft PPS-11815|[[File:Nuvola OK.png|16px]] [[Voltcraft PPS-11815]] (1ch, 0-60V/0-5A, USB)

File:Sigrok logo no text transparent 512.png|link=Voltcraft 18220|[[File:Nuvola Red.png|16px]] [[Voltcraft 18220]] (1ch, 0-40V/0-5A, RS232)
</gallery>

== GPIB interfaces ==

<gallery widths="100px" heights="100px">
File:Beiming_s82357.png|link=Beiming S82357|[[File:Nuvola Red.png|16px]] [[Beiming S82357]] (hardware-based, USB)
File:ICS 488-USB.png|link=ICS 488-USB|[[File:Nuvola Red.png|16px]] [[ICS 488-USB]] (hardware-based, USB)
File:GPIB-USB 82357B clone.png|link=GPIB-USB 82357B clone|[[File:Nuvola Red.png|16px]] [[GPIB-USB 82357B clone]] (hardware-based, USB)
File:NI GPIB-ENET.png|link=National Instruments GPIB-ENET|[[File:Nuvola Red.png|16px]] [[National Instruments GPIB-ENET]] (hardware-based, Ethernet)
File:NI GPIB-USB-HS.png|link=National Instruments GPIB-USB-HS|[[File:Nuvola Red.png|16px]] [[National Instruments GPIB-USB-HS]] (hardware-based, USB)
File:Prologix-usb.png|link=Prologix GPIB-USB|[[File:Nuvola Red.png|16px]] [[Prologix GPIB-USB]] (firmware-based, USB)
File:GalvantGPIBUSBrev4.JPG|link=Galvant GPIBUSB|[[File:Nuvola Red.png|16px]] [[Galvant GPIBUSB]] (firmware-based, USB, OSHW)
</gallery>

== Potential other candidates ==

If you own any other logic analyzers, oscilloscopes, multimeters, dataloggers, ... and want to add support for them in sigrok (or donate/lend devices to developers), please let us know. We're always happy to add more hardware support! Join the [https://lists.sourceforge.net/lists/listinfo/sigrok-devel mailing list] or ask on [irc://chat.freenode.net/sigrok IRC #sigrok] if you want to help out.

__FORCETOC__

Sysclk LWLA1016

2015-11-28T14:40:38Z

Danielk: Device is now supported

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1016.png|180px]]
| name = Sysclk LWLA1016
| status = supported
| source_code_dir = sysclk-lwla
| channels = 16/8
| samplerate = 100/200/250 MHz
| samplerate_state = ?
| triggers = only in 100MHz mode
| voltages = ?
| threshold = ?
| memory = 512Kbit/channel, or 256Kbit/channel with RLE
| compression = optional RLE
| website = [http://item.taobao.com/item.htm?id=12821371102 taobao.com]
}}

The '''Sysclk LWLA1016''' is a USB-based, 16-channel logic analyzer with up to 100MHz sampling rate, or up to 250MHz with 8 channels.

Note that sigrok supports only the 100 MHz mode with 16 channels. Supporting the 200/250 MHz 8 channel modes is not worth the effort, since the device does not support triggers in these modes. A non-streaming device without triggers is pretty much useless for any real world application.

See [[Sysclk LWLA1016/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

TODO.

== Photos ==

<gallery>
File:Sysclk lwla1016 front.jpg|Device, front
File:Sysclk lwla1016 device back.jpg|Device, back
File:Sysclk lwla1016 device open.jpg|Device, open
File:Sysclk lwla1016 pcb top.jpg|PCB, top
File:Sysclk lwla1016 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1016 pcb cypress fx2.jpg|Cypress FX2
File:Sysclk lwla1016 pcb issi 1.jpg|ISSI 1
File:Sysclk lwla1016 pcb issi2.jpg|ISSI 2
File:Sysclk lwla1016 pcb atmlh105.jpg|ATMLH105
File:Sysclk lwla1016 stc 15f104e.jpg|STC
File:Sysclk lwla1016 pcb ldo.jpg|LDOs
File:Sysclk lwla1016 pcb input.jpg|Input stage
File:Sysclk lwla1016 pcb crystal.jpg|Crystal
</gallery>

== Protocol ==

Reverse engineering of the vendor's custom protocol is complete. See [[Sysclk LWLA1016/Protocol]] for the findings gathered.

== Resources ==

TODO.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Sysclk LWLA1034/Protocol

2015-10-31T01:00:28Z

Danielk: Document capture control bits

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

=== Command 0005: Copy Protection Check ===

This command writes 16 32-bit words which are then verified by the device for copy protection purposes. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures.

The values are apparently obtained by scrambling and/or hashing the captured data. The device functions correctly even without ever sending this command. For this reason, the LWLA1034 firmware distributed with sigrok implements the copy protection in the FPGA instead.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is the usual 2-1-4-3 mixed endianess. It appears that the three high bytes of each word are always zero.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Write Long Registers ===

This command writes several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. See the table of long registers for a description of the configuration and status fields.

=== Command 0008: Read Long Registers ===

This command reads several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The software uses this command mainly to read the block of capture status registers. During idle periods, the original vendor software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

Each returned 64-bit word is in very much mixed up (6-5-8-7-2-1-4-3) byte order. See the table of long registers for the meaning of the values at each address.

== Control Registers ==

The device exposes a number of 32-bit wide registers accessed via commands 1 and 2. Some of the register addresses appearing in the protocol also occur in the LWLA1016 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1034.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Name
!Description
|-
| 1074
| MEM_CTRL
| Control register for capture memory access.
|-
| 1078
| MEM_FILL
| Compressed size of captured data (number of 36-bit words).
|-
| 107C
| MEM_ADDR?
| Not clear if this is an address or another control register, or even if it is needed at all.
|-
| 1090
| TEST?
| Writing 1 to this register apparently enables some sort of test mode.
|-
| 1094
| DIV_BYPASS
| This is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.
|-
| 10B0
| LONG_STROBE
| Long register read/write strobe.
|-
| 10B4
| LONG_ADDR
| Long register address.
|-
| 10B8
| LONG_LOW
| Long register low word.
|-
| 10BC
| LONG_HIGH
| Long register high word.
|-
| 10C0
| FREQ_CH1
|rowspan="4"|
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.
|-
| 10C4
| FREQ_CH2
|-
| 10C8
| FREQ_CH3
|-
| 10CC
| FREQ_CH4
|}

=== Long Registers ===

These are separate 64-bit wide registers mainly used for capture control and status reporting. Single values can be read or written indirectly via special control registers. Commands 7 and 8 can be used to read or write multiple 64-bit values in a single command.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Purpose
!Description
|-
| 0
| Channel enable mask
| Bit mask of enabled channels. Bit 0 (LSB) corresponds to channel 1.
|-
| 1
| Clock divider count
| Max value of the counter which divides the internal clock to yield the sampling clock, for sampling rates of 100 MS/s or less. The value is calculated as 1 / (samplefreq * 10ns) - 1.
|-
| 2
| Trigger level mask
| Each bit corresponds to a channel, selecting whether to trigger on low/falling (0) or high/rising (1).
|-
| 3
| Trigger edge mask
| Each bit corresponds to a channel, selecting whether to trigger on level (0) or edge (1).
|-
| 4
| Trigger enable mask
| Each bit corresponds to a channel, selecting whether the trigger is enabled (1) or disabled (0).
|-
| 5
| Capture memory fill level
| On write, the value limits the (compressed) size of the captured data. On read, the current memory fill level is returned.
|-
| 6
| Not used?
| Apparently unused.
|-
| 7
| Running capture duration
| Time passed since the first sample. For samplerates up to 100 MS/s, the value is a duration in milliseconds. At 125 MS/s, the value needs to be adjusted by 100/125 = 4/5.
|-
| 8
| Channel input state
| Each bit corresponds to a channel, showing whether the input signal is currently low (0) or high (1).
|-
| 9
| Capture status flags
| A bit vector of status flags, as described in the next section. Only the lowest 6 bits appear to be valid, the remaining ones may contain garbage.
|-
| 10
| Capture control
| This appears to be a control register for starting and stopping data capture.
|-
| 100
| Test ID
| When read, the fixed value 0x1234567887654321 is returned. This is used for a sanity check during initialization.
|}

The original vendor software uses the bulk read/write commands exclusively with the long registers 0 to 9. The long registers 10 and 100 are only ever accessed indirectly via the control registers 0x10B0 to 0x10BC.

=== Capture Status Flags ===

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}

=== Capture Control Bits ===

The capture control bits of long register 10 are assigned as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
!Bit 6
|-
| trg_en
|
| do_clr_timebase
|
| flush_fifo
| clr_fifo32_ful
| clr_cntr0
|}

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 2 and 3 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue command 5 with scrambled data to be verified by the device for copy protection

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The original software does the copy protection check only for the first three captures. It is in fact possible to not send command 5 at all, which is exactly what the sigrok driver does.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T16:51:49Z

Danielk: Clear up the command 5 mystery

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

=== Command 0005: Copy Protection Check ===

This command writes 16 32-bit words which are then verified by the device for copy protection purposes. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures.

The values are apparently obtained by scrambling and/or hashing the captured data. The device functions correctly even without ever sending this command. For this reason, the LWLA1034 firmware distributed with sigrok implements the copy protection in the FPGA instead.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is the usual 2-1-4-3 mixed endianess. It appears that the three high bytes of each word are always zero.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Write Long Registers ===

This command writes several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. See the table of long registers for a description of the configuration and status fields.

=== Command 0008: Read Long Registers ===

This command reads several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The software uses this command mainly to read the block of capture status registers. During idle periods, the original vendor software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

Each returned 64-bit word is in very much mixed up (6-5-8-7-2-1-4-3) byte order. See the table of long registers for the meaning of the values at each address.

== Control Registers ==

The device exposes a number of 32-bit wide registers accessed via commands 1 and 2. Some of the register addresses appearing in the protocol also occur in the LWLA1016 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1034.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Name
!Description
|-
| 1074
| MEM_CTRL
| Control register for capture memory access.
|-
| 1078
| MEM_FILL
| Compressed size of captured data (number of 36-bit words).
|-
| 107C
| MEM_ADDR?
| Not clear if this is an address or another control register, or even if it is needed at all.
|-
| 1090
| TEST?
| Writing 1 to this register apparently enables some sort of test mode.
|-
| 1094
| DIV_BYPASS
| This is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.
|-
| 10B0
| LONG_STROBE
| Long register read/write strobe.
|-
| 10B4
| LONG_ADDR
| Long register address.
|-
| 10B8
| LONG_LOW
| Long register low word.
|-
| 10BC
| LONG_HIGH
| Long register high word.
|-
| 10C0
| FREQ_CH1
|rowspan="4"|
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.
|-
| 10C4
| FREQ_CH2
|-
| 10C8
| FREQ_CH3
|-
| 10CC
| FREQ_CH4
|}

=== Long Registers ===

These are separate 64-bit wide registers mainly used for capture control and status reporting. Single values can be read or written indirectly via special control registers. Commands 7 and 8 can be used to read or write multiple 64-bit values in a single command.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Purpose
!Description
|-
| 0
| Channel enable mask
| Bit mask of enabled channels. Bit 0 (LSB) corresponds to channel 1.
|-
| 1
| Clock divider count
| Max value of the counter which divides the internal clock to yield the sampling clock, for sampling rates of 100 MS/s or less. The value is calculated as 1 / (samplefreq * 10ns) - 1.
|-
| 2
| Trigger level mask
| Each bit corresponds to a channel, selecting whether to trigger on low/falling (0) or high/rising (1).
|-
| 3
| Trigger edge mask
| Each bit corresponds to a channel, selecting whether to trigger on level (0) or edge (1).
|-
| 4
| Trigger enable mask
| Each bit corresponds to a channel, selecting whether the trigger is enabled (1) or disabled (0).
|-
| 5
| Capture memory fill level
| On write, the value limits the (compressed) size of the captured data. On read, the current memory fill level is returned.
|-
| 6
| Not used?
| Apparently unused.
|-
| 7
| Running capture duration
| Time passed since the first sample. For samplerates up to 100 MS/s, the value is a duration in milliseconds. At 125 MS/s, the value needs to be adjusted by 100/125 = 4/5.
|-
| 8
| Channel input state
| Each bit corresponds to a channel, showing whether the input signal is currently low (0) or high (1).
|-
| 9
| Capture status flags
| A bit vector of status flags, as described in the next section. Only the lowest 6 bits appear to be valid, the remaining ones may contain garbage.
|-
| 10
| Capture control
| This appears to be a control register for starting and stopping data capture.
|-
| 100
| Test ID
| When read, the fixed value 0x1234567887654321 is returned. This is used for a sanity check during initialization.
|}

The original vendor software uses the bulk read/write commands exclusively with the long registers 0 to 9. The long registers 10 and 100 are only ever accessed indirectly via the control registers 0x10B0 to 0x10BC.

=== Capture Status Flags ===

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 2 and 3 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue command 5 with scrambled data to be verified by the device for copy protection

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The original software does the copy protection check only for the first three captures. It is in fact possible to not send command 5 at all, which is exactly what the sigrok driver does.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T16:26:01Z

Danielk: Create table of long registers and move capture status/control documentation there

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Write Long Registers ===

This command writes several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. See the table of long registers for a description of the configuration and status fields.

=== Command 0008: Read Long Registers ===

This command reads several long registers in bulk. The long registers are 64 bit wide and use their own address space separate from the 32-bit control registers.

The software uses this command mainly to read the block of capture status registers. During idle periods, the original vendor software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

Each returned 64-bit word is in very much mixed up (6-5-8-7-2-1-4-3) byte order. See the table of long registers for the meaning of the values at each address.

== Control Registers ==

The device exposes a number of 32-bit wide registers accessed via commands 1 and 2. Some of the register addresses appearing in the protocol also occur in the LWLA1016 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1034.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Name
!Description
|-
| 1074
| MEM_CTRL
| Control register for capture memory access.
|-
| 1078
| MEM_FILL
| Compressed size of captured data (number of 36-bit words).
|-
| 107C
| MEM_ADDR?
| Not clear if this is an address or another control register, or even if it is needed at all.
|-
| 1090
| TEST?
| Writing 1 to this register apparently enables some sort of test mode.
|-
| 1094
| DIV_BYPASS
| This is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.
|-
| 10B0
| LONG_STROBE
| Long register read/write strobe.
|-
| 10B4
| LONG_ADDR
| Long register address.
|-
| 10B8
| LONG_LOW
| Long register low word.
|-
| 10BC
| LONG_HIGH
| Long register high word.
|-
| 10C0
| FREQ_CH1
|rowspan="4"|
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.
|-
| 10C4
| FREQ_CH2
|-
| 10C8
| FREQ_CH3
|-
| 10CC
| FREQ_CH4
|}

=== Long Registers ===

These are separate 64-bit wide registers mainly used for capture control and status reporting. Single values can be read or written indirectly via special control registers. Commands 7 and 8 can be used to read or write multiple 64-bit values in a single command.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Purpose
!Description
|-
| 0
| Channel enable mask
| Bit mask of enabled channels. Bit 0 (LSB) corresponds to channel 1.
|-
| 1
| Clock divider count
| Max value of the counter which divides the internal clock to yield the sampling clock, for sampling rates of 100 MS/s or less. The value is calculated as 1 / (samplefreq * 10ns) - 1.
|-
| 2
| Trigger level mask
| Each bit corresponds to a channel, selecting whether to trigger on low/falling (0) or high/rising (1).
|-
| 3
| Trigger edge mask
| Each bit corresponds to a channel, selecting whether to trigger on level (0) or edge (1).
|-
| 4
| Trigger enable mask
| Each bit corresponds to a channel, selecting whether the trigger is enabled (1) or disabled (0).
|-
| 5
| Capture memory fill level
| On write, the value limits the (compressed) size of the captured data. On read, the current memory fill level is returned.
|-
| 6
| Not used?
| Apparently unused.
|-
| 7
| Running capture duration
| Time passed since the first sample. For samplerates up to 100 MS/s, the value is a duration in milliseconds. At 125 MS/s, the value needs to be adjusted by 100/125 = 4/5.
|-
| 8
| Channel input state
| Each bit corresponds to a channel, showing whether the input signal is currently low (0) or high (1).
|-
| 9
| Capture status flags
| A bit vector of status flags, as described in the next section. Only the lowest 6 bits appear to be valid, the remaining ones may contain garbage.
|-
| 10
| Capture control
| This appears to be a control register for starting and stopping data capture.
|-
| 100
| Test ID
| When read, the fixed value 0x1234567887654321 is returned. This is used for a sanity check during initialization.
|}

The original vendor software uses the bulk read/write commands exclusively with the long registers 0 to 9. The long registers 10 and 100 are only ever accessed indirectly via the control registers 0x10B0 to 0x10BC.

=== Capture Status Flags ===

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 2 and 3 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T14:29:47Z

Danielk: Move register documentation to separate section

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Capture Setup ===

This command prepares a capture operation. Essentially, this command appears to write to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. The layout of the configuration and status memory is outlined in the description of command 0008.

=== Command 0008: Capture Status ===

This command reads the current capture configuration and status. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity -- the same memory space command 7 writes to. During idle periods, the software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order. Roughly, the first half is used to set up a capture operation, whereas the second half contains status information. Field 5 is an exception, as it is used for both setup and status.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Byte offset
!Value
|-
| 0
| 00
| Channel enable mask
|-
| 1
| 08
| Clock divider count
|-
| 2
| 10
| Trigger level mask
|-
| 3
| 18
| Trigger edge mask
|-
| 4
| 20
| Trigger enable mask
|-
| 5
| 28
| Capture memory fill level
|-
| 6
| 30
| Not used?
|-
| 7
| 38
| Running capture duration
|-
| 8
| 40
| Channel input state
|-
| 9
| 48
| Capture status flags
|}

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

During setup, field 5 is used to limit the (compressed) size of the captured data. During a running capture operation, field 5 indicates the current memory fill level.

Field 7 is the time passed since the first sample. For samplerates up to 100 MHz, the value is a duration in milliseconds. The 125 MHz setting is again special and uses the same timebase as the 100 MHz setting, i.e. field 7 can then be interpreted as the sample count × 10−5.

Field 8 records a snapshot of the signal level of all 34 channels at the time the status is being read.

Field 6 appears to be unused.

===== Capture Status Flags =====

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}
The higher bits of field 9 appear to contain garbage (apparently copies of the bits from field 8).

== Control Registers ==

The device exposes a number of 32-bit wide registers accessed via commands 1 and 2. Some of the register addresses appearing in the protocol also occur in the LWLA1016 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1034.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Name
!Description
|-
| 1074
| MEM_CTRL
| Control register for capture memory access.
|-
| 1078
| MEM_FILL
| Compressed size of captured data (number of 36-bit words).
|-
| 107C
| MEM_ADDR?
| Not clear if this is an address or another control register, or even if it is needed at all.
|-
| 1090
| TEST?
| Writing 1 to this register apparently enables some sort of test mode.
|-
| 1094
| DIV_BYPASS
| This is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.
|-
| 10B0
| LONG_STROBE
| Long register read/write strobe.
|-
| 10B4
| LONG_ADDR
| Long register address.
|-
| 10B8
| LONG_LOW
| Long register low word.
|-
| 10BC
| LONG_HIGH
| Long register high word.
|-
| 10C0
| FREQ_CH1
|rowspan="4"|
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.
|-
| 10C4
| FREQ_CH2
|-
| 10C8
| FREQ_CH3
|-
| 10CC
| FREQ_CH4
|}

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 2 and 3 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1016/Protocol

2015-10-25T13:26:46Z

Danielk: Move register documentation to separate section

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register. It appears to be identical to [[Sysclk_LWLA1034/Protocol#Command_0001:_Read_Register|command 1 in the LWLA1034 protocol]].

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register. It appears to be identical to [[Sysclk_LWLA1034/Protocol#Command_0002:_Write_Register|command 2 in the LWLA1034 protocol]].

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

=== Command 0003: Read Memory at Address ===

This command reads the captured samples from the device. It works very much like command 6 in the LWLA1034 protocol.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0003
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 32 bit wide, and thus the size of the response in bits is 32 times the value in the length field. The original vendor software reads chunks of 250 words @ 32 bit at a time, i.e. 1000 bytes. Note that the software always starts reading at address 2 rather than 0.

===== Compression Scheme =====

In timing-state mode a very simple form of run-length encoding is used. Each 32-bit unit of memory holds 2 Little Endian values. The 16-bit word at the lower address is the repeat count for the channel state encoded in the subsequent 16-bit word.

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Control Registers ==

The device exposes a number of 32-bit wide registers accessed via commands 1 and 2. Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Name
!Description
|-
| 1000
| SAMPLE_MASK
| Bit mask of enabled channels.
|-
| 1010
| MS
| Elapsed time in milliseconds.
|-
| 1070
| ASRAM_WR_PTR
|
|-
| 1074
| ASRAM_RD_PTR
|
|-
| 1078
| ASRAM_DATA
|
|-
| 107C
| ASRAM_CTR
|
|-
| 10B0
| ST_CNTR
|
|-
| 10B4
| ST_TOTAL_CNTR1 ST_TRG_SEL
|
|-
| 10B8
| ST_CTL
|
|-
| 10BC
| ST_TOTAL_CNTR0 ST_DIV_CNTR ST_PORT_VAL
|
|}

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034

=== Device State Polling ===

# Read register 0x10B8, reply is 0x10 in timing-state mode, or 0 in normal mode
# Read register 0x10B0, reply is 0
# Read register 0x1070, reply is 0
# Read register 0x10BC, reply is 0x1234xxxx, where "xxxx" is the channel state
# Read register 0x1010, reply is 0

Sysclk LWLA1034/Protocol

2015-10-25T11:58:47Z

Danielk: Long write: Correct interchangeable step numbers

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 10C0
| Channel 1 frequency counter
|-
| 10C4
| Channel 2 frequency counter
|-
| 10C8
| Channel 3 frequency counter
|-
| 10CC
| Channel 4 frequency counter
|}
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Selftest value
|-
| 10B0
| 12345678
|-
| 10BC
| 12345678
|-
| 10B8
| 87654321
|}
These three registers assume the values listed here after writing 100 (decimal) to register 10B4. This is apparently an identification and self-test sequence, which is performed twice in a row during initialization. After initialization, these registers are part of command sequences which initiate device operations, like capture start/stop.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1078
| Capture size (number of 36-bit words)
|}
This register holds the (compressed) size of the captured data. The vendor software retrieves this just before fetching the SRAM content.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 10B4
| 00000064
|}
The vendor software writes the value 100 (decimal) to this register during initialization into order to start the self test sequence. After that, the magic register values listed in the table for command 0001 become available. So, this is kind of a command-triggering register, and there are other command codes, too.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Purpose
|-
| 1094
| Bypass clock divider
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}
These are written to when a capture operation is initiated or cancelled. Register 1094 is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 1074
| 00000002
|-
| 107C
| 00000000
|}
The vendor software writes these two registers during initialization, and also when initiating a capture.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Capture Setup ===

This command prepares a capture operation. Essentially, this command appears to write to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. The layout of the configuration and status memory is outlined in the description of command 0008.

=== Command 0008: Capture Status ===

This command reads the current capture configuration and status. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity -- the same memory space command 7 writes to. During idle periods, the software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order. Roughly, the first half is used to set up a capture operation, whereas the second half contains status information. Field 5 is an exception, as it is used for both setup and status.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Byte offset
!Value
|-
| 0
| 00
| Channel enable mask
|-
| 1
| 08
| Clock divider count
|-
| 2
| 10
| Trigger level mask
|-
| 3
| 18
| Trigger edge mask
|-
| 4
| 20
| Trigger enable mask
|-
| 5
| 28
| Capture memory fill level
|-
| 6
| 30
| Not used?
|-
| 7
| 38
| Running capture duration
|-
| 8
| 40
| Channel input state
|-
| 9
| 48
| Capture status flags
|}

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

During setup, field 5 is used to limit the (compressed) size of the captured data. During a running capture operation, field 5 indicates the current memory fill level.

Field 7 is the time passed since the first sample. For samplerates up to 100 MHz, the value is a duration in milliseconds. The 125 MHz setting is again special and uses the same timebase as the 100 MHz setting, i.e. field 7 can then be interpreted as the sample count × 10−5.

Field 8 records a snapshot of the signal level of all 34 channels at the time the status is being read.

Field 6 appears to be unused.

===== Capture Status Flags =====

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}
The higher bits of field 9 appear to contain garbage (apparently copies of the bits from field 8).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 2 and 3 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T11:42:59Z

Danielk: Reference long read/write in task recipes

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 10C0
| Channel 1 frequency counter
|-
| 10C4
| Channel 2 frequency counter
|-
| 10C8
| Channel 3 frequency counter
|-
| 10CC
| Channel 4 frequency counter
|}
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Selftest value
|-
| 10B0
| 12345678
|-
| 10BC
| 12345678
|-
| 10B8
| 87654321
|}
These three registers assume the values listed here after writing 100 (decimal) to register 10B4. This is apparently an identification and self-test sequence, which is performed twice in a row during initialization. After initialization, these registers are part of command sequences which initiate device operations, like capture start/stop.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1078
| Capture size (number of 36-bit words)
|}
This register holds the (compressed) size of the captured data. The vendor software retrieves this just before fetching the SRAM content.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 10B4
| 00000064
|}
The vendor software writes the value 100 (decimal) to this register during initialization into order to start the self test sequence. After that, the magic register values listed in the table for command 0001 become available. So, this is kind of a command-triggering register, and there are other command codes, too.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Purpose
|-
| 1094
| Bypass clock divider
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}
These are written to when a capture operation is initiated or cancelled. Register 1094 is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 1074
| 00000002
|-
| 107C
| 00000000
|}
The vendor software writes these two registers during initialization, and also when initiating a capture.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Capture Setup ===

This command prepares a capture operation. Essentially, this command appears to write to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. The layout of the configuration and status memory is outlined in the description of command 0008.

=== Command 0008: Capture Status ===

This command reads the current capture configuration and status. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity -- the same memory space command 7 writes to. During idle periods, the software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order. Roughly, the first half is used to set up a capture operation, whereas the second half contains status information. Field 5 is an exception, as it is used for both setup and status.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Byte offset
!Value
|-
| 0
| 00
| Channel enable mask
|-
| 1
| 08
| Clock divider count
|-
| 2
| 10
| Trigger level mask
|-
| 3
| 18
| Trigger edge mask
|-
| 4
| 20
| Trigger enable mask
|-
| 5
| 28
| Capture memory fill level
|-
| 6
| 30
| Not used?
|-
| 7
| 38
| Running capture duration
|-
| 8
| 40
| Channel input state
|-
| 9
| 48
| Capture status flags
|}

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

During setup, field 5 is used to limit the (compressed) size of the captured data. During a running capture operation, field 5 indicates the current memory fill level.

Field 7 is the time passed since the first sample. For samplerates up to 100 MHz, the value is a duration in milliseconds. The 125 MHz setting is again special and uses the same timebase as the 100 MHz setting, i.e. field 7 can then be interpreted as the sample count × 10−5.

Field 8 records a snapshot of the signal level of all 34 channels at the time the status is being read.

Field 6 appears to be unused.

===== Capture Status Flags =====

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}
The higher bits of field 9 appear to contain garbage (apparently copies of the bits from field 8).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 3 and 4 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence:
## Read long register 100; ignore result
## Read long register 100; result should be 0x1234567887654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074
# Write 0x74 to long register 10
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 1 to long register 10
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 0 to long register 10
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T11:34:56Z

Danielk: Document long register read/write

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 10C0
| Channel 1 frequency counter
|-
| 10C4
| Channel 2 frequency counter
|-
| 10C8
| Channel 3 frequency counter
|-
| 10CC
| Channel 4 frequency counter
|}
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Selftest value
|-
| 10B0
| 12345678
|-
| 10BC
| 12345678
|-
| 10B8
| 87654321
|}
These three registers assume the values listed here after writing 100 (decimal) to register 10B4. This is apparently an identification and self-test sequence, which is performed twice in a row during initialization. After initialization, these registers are part of command sequences which initiate device operations, like capture start/stop.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1078
| Capture size (number of 36-bit words)
|}
This register holds the (compressed) size of the captured data. The vendor software retrieves this just before fetching the SRAM content.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 10B4
| 00000064
|}
The vendor software writes the value 100 (decimal) to this register during initialization into order to start the self test sequence. After that, the magic register values listed in the table for command 0001 become available. So, this is kind of a command-triggering register, and there are other command codes, too.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Purpose
|-
| 1094
| Bypass clock divider
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}
These are written to when a capture operation is initiated or cancelled. Register 1094 is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 1074
| 00000002
|-
| 107C
| 00000000
|}
The vendor software writes these two registers during initialization, and also when initiating a capture.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Capture Setup ===

This command prepares a capture operation. Essentially, this command appears to write to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. The layout of the configuration and status memory is outlined in the description of command 0008.

=== Command 0008: Capture Status ===

This command reads the current capture configuration and status. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity -- the same memory space command 7 writes to. During idle periods, the software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order. Roughly, the first half is used to set up a capture operation, whereas the second half contains status information. Field 5 is an exception, as it is used for both setup and status.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Byte offset
!Value
|-
| 0
| 00
| Channel enable mask
|-
| 1
| 08
| Clock divider count
|-
| 2
| 10
| Trigger level mask
|-
| 3
| 18
| Trigger edge mask
|-
| 4
| 20
| Trigger enable mask
|-
| 5
| 28
| Capture memory fill level
|-
| 6
| 30
| Not used?
|-
| 7
| 38
| Running capture duration
|-
| 8
| 40
| Channel input state
|-
| 9
| 48
| Capture status flags
|}

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

During setup, field 5 is used to limit the (compressed) size of the captured data. During a running capture operation, field 5 indicates the current memory fill level.

Field 7 is the time passed since the first sample. For samplerates up to 100 MHz, the value is a duration in milliseconds. The 125 MHz setting is again special and uses the same timebase as the 100 MHz setting, i.e. field 7 can then be interpreted as the sample count × 10−5.

Field 8 records a snapshot of the signal level of all 34 channels at the time the status is being read.

Field 6 appears to be unused.

===== Capture Status Flags =====

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}
The higher bits of field 9 appear to contain garbage (apparently copies of the bits from field 8).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Long Register Read ===

This sequence reads from a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Read dummy value from strobe register 0x10B0
# Read high word from register 0x10BC
# Read low word from register 0x10B8

Steps 3 and 4 appear to be interchangeable.

=== Long Register Write ===

This sequence writes to a 64-bit wide internal memory, probably the same as that accessed by commands 7 and 8.

# Write index to address register 0x10B4
# Write low word to register 0x10B8
# Write high word to register 0x10BC
# Write 0 (dummy value) to strobe register 0x10B0

Steps 3 and 4 appear to be interchangeable.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence (performed twice by vendor software, only the results of the second run should be checked):
## Write 100 to register 0x10B4
## Read register 0x10B0: value should be ignored
## Read register 0x10BC: value should be 0x12345678
## Read register 0x10B8: value should be 0x87654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074 (previous write may be redundant, needs testing)
# Write 10 to register 0x10B4
# Write 0x74 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 10 to register 0x10B4
# Write 1 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 10 to register 0x10B4
# Write 0 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1034/Protocol

2015-10-25T00:37:30Z

Danielk: Correct assumptions about init sequence

== FPGA Configuration ==

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Length
!Payload...
|-
| nnnn-nnnn
| dd...
|}

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# when switching clocking mode between internal, external/rising or external/falling,
# on application exit.

The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.
=== Firmware Extraction ===

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file <tt>lwla1034_EN_setup.exe</tt> on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Offset
!Length
!Mode
|-
| 34110338
| 78398
| Internal clock
|-
| 34266237
| 78247
| External clock (rising edge)
|-
| 34344484
| 79145
| External clock (falling edge)
|-
| 34578631
| 48525
| Shutdown
|}

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

== Control Commands ==

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages are sent to the device as a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

=== Command 0001: Read Register ===

This command reads a 32-bit wide control register.

==== Command ====

Fixed length of 2 words (4 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
|-
| 0001
| aaaa
|}

==== Response ====

The response has a fixed length of 2 words (4 bytes). It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 10C0
| Channel 1 frequency counter
|-
| 10C4
| Channel 2 frequency counter
|-
| 10C8
| Channel 3 frequency counter
|-
| 10CC
| Channel 4 frequency counter
|}
These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is unclear what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency, which would imply that the software resets the counters. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all. However, that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Selftest value
|-
| 10B0
| 12345678
|-
| 10BC
| 12345678
|-
| 10B8
| 87654321
|}
These three registers assume the values listed here after writing 100 (decimal) to register 10B4. This is apparently an identification and self-test sequence, which is performed twice in a row during initialization. After initialization, these registers are part of command sequences which initiate device operations, like capture start/stop.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1078
| Capture size (number of 36-bit words)
|}
This register holds the (compressed) size of the captured data. The vendor software retrieves this just before fetching the SRAM content.

=== Command 0002: Write Register ===

This command writes a 32-bit value to a control register.

==== Command ====

Fixed length of 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Data
|-
| 0002
| aaaa
| dddd-dddd
|}

The value is encoded in mixed endian (2-1-4-3) byte order.

==== Registers ====

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 10B4
| 00000064
|}
The vendor software writes the value 100 (decimal) to this register during initialization into order to start the self test sequence. After that, the magic register values listed in the table for command 0001 become available. So, this is kind of a command-triggering register, and there are other command codes, too.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Purpose
|-
| 1094
| Bypass clock divider
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}
These are written to when a capture operation is initiated or cancelled. Register 1094 is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125 MHz internal clock or the external clock modes, it is set to 1.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Init value
|-
| 1074
| 00000002
|-
| 107C
| 00000000
|}
The vendor software writes these two registers during initialization, and also when initiating a capture.

=== Command 0005: Write ??? ===

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that. Luckily, the sigrok driver works without ever sending this command at all.

==== Command ====

Fixed length of 33 words (66 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Data 1
!Data 2
!...
!Data 16
|-
| 0005
| dddd-dddd
| dddd-dddd
| ...
| dddd-dddd
|}
The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

==== Sample capture ====

A sample of three such commands from an actual protocol analysis session:

10185 56.455640 Cmd 5: write ??? data C3 9A 4B 91 30 D2 98 C1 CA F2 D7 4F 82 74 C0 8B
14155 95.788766 Cmd 5: write ??? data E5 7B 2C F3 6B 06 76 4B 60 94 F3 EC C9 AA E9 35
17823 131.101569 Cmd 5: write ??? data 16 66 EA 7B 35 F6 71 A8 0A E0 D7 E7 45 E0 4F 23

Only the least significant byte is shown for each 32-bit data word, as the other bytes are always 0. The message content changes with each run of the vendor software. It's hard to make head or tail of this. However, as this command is issued after all captured data has been retrieved, it cannot possibly affect the preceding capture and read-out operations.

=== Command 0006: Read Memory at Address ===

This command reads a chunk of data from the device memory (SRAM). It allows for random access using a 32-bit start address, and for variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0006
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 36 bit wide, and thus the size of the response in bits is 36 times the value in the length field. The original vendor software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 32 (i.e. 4320 bits = 135 32-bit words or 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to nine 32-bit words or 36 bytes. The overall amount of memory being read when fetching captured samples from a full buffer is just below the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably, the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason (perhaps testing), the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Note that reading more than 1024 bytes at a time seems to be unreliable. Due to the constraints outlined in the following section, the maximum read length should therefore be restricted to 224 device words, which works out to 1008 bytes.

===== 36-to-32 Bit Mapping =====

The data returned by the read command consists of 32-bit words in 2-1-4-3 mixed endian byte order. Eight consecutive 36-bit words from the SRAM are mapped at a time to nine consecutive 32-bit words in the received stream. The first of these slices aligns to the beginning of the read-out stream, apparently irrespective of the absolute start address of the read operation.

The first eight 32-bit words in a slice contain the lower 32 bit of the eight encoded 36-bit words. The ninth 32-bit word contains the four remaining high bits of all eight 36-bit words combined. The high nibbles are shifted into the ninth word from right to left, resulting in a 1-2-3-4-5-6-7-8 order of nibbles. (This is after conversion from mixed endian byte order!)

As it is necessary to access the ninth 32-bit word in each slice even to fully extract the first 36-bit word, it follows that memory reads should always request a multiple of the slice length, i.e. eight 36-bit words. The length of the response will thus always be a multiple of nine 32-bit words (36 bytes). However, it does not appear to be necessary to restrict read operations to only the two lengths 120 and 8 used by the vendor software.

===== Compression Scheme =====

The compression scheme is a form of run-length encoding. Very short run lengths of only one or two cycles are handled as special cases, which helps to keep the worst-case overhead of compression pretty low. In particular, the scheme ensures that it is never necessary to write more than one 36-bit word per sampling cycle to the SRAM buffer.

Each 36-bit word in the stream is either a data word or a repeat half-count word. The first word in the stream is a data word, with the following layout:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit
!35
!34
!33
!32
!31
!...
!2
!1
!0
|-
!Meaning
| Repeat count follows
| LSB of repeat count
| CH34
| CH33
| CH32
| ...
| CH3
| CH2
| CH1
|}

If bit 35 is set, then the next 36-bit word in the stream encodes the number of cycles the previous data word is repeated, divided by two. The actual number of repeat cycles is twice that number plus the LSB of repeat count, i.e. bit 34 from the data word. If bit 35 is not set the next word is again a data word and the repeat half-count is assumed as zero. However, the LSB of repeat count bit still applies; i.e. if it is set then the repeat count would be 1.

So, to recap, repeat counts 0 to 1 are encoded as part of the channel data word, larger repeat counts use up a full extra 36-bit word. The combined repeat count is then 37 bit wide. At 125 MHz, this scheme would allow for encoding run lengths of more than 18 minutes. However, note that the vendor software does not actually make use of the full range: Apparently, it stops as soon as the count rolls over into bit 36, thereby cutting the maximum possible run length in half (i.e. about 9 minutes at 125 MHz). However, this detail does not make any difference for the decompression algorithm.

The next word following a repeat half-count is again a data word. Note that it is possible for a sample/run-length pair to be split across a slice boundary, or even across successive read chunks. The decoder therefore needs to keep track of RLE state across slices as well as read operations.

=== Command 0007: Capture Setup ===

This command prepares a capture operation. Essentially, this command appears to write to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

==== Command ====

Variable length of 3 words (6 bytes) plus length × 4 words (8 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
!Data
!...
|-
| 0007
| aaaa
| nnnn
| dddd-dddd-dddd-dddd
| ...
|}

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the payload should consist of 40 words or 80 bytes.

The vendor software always writes a slice of length 10 beginning at address 0, thus completely resetting both the capture configuration as well as the capture status. The layout of the configuration and status memory is outlined in the description of command 0008.

=== Command 0008: Capture Status ===

This command reads the current capture configuration and status. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity -- the same memory space command 7 writes to. During idle periods, the software polls the channel state about 34 times per second for its live port status display. During a capture operation, it is necessary to poll the status in order to find out whether the capture buffer has been filled completely and samples can be retrieved.

==== Command ====

Fixed length of 3 words (6 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0008
| aaaa
| nnnn
|}

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (4 words or 8 bytes). Thus, if length is 10 the reply will consist of 40 words or 80 bytes.

Although the vendor software always reads the full 10 fields of configuration and status information, it does not seem to be an actual requirement. Restricting reads to fields 5 to 9 in the sigrok driver works fine so far without any problems.

==== Response ====

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order. Roughly, the first half is used to set up a capture operation, whereas the second half contains status information. Field 5 is an exception, as it is used for both setup and status.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Index
!Byte offset
!Value
|-
| 0
| 00
| Channel enable mask
|-
| 1
| 08
| Clock divider count
|-
| 2
| 10
| Trigger level mask
|-
| 3
| 18
| Trigger edge mask
|-
| 4
| 20
| Trigger enable mask
|-
| 5
| 28
| Capture memory fill level
|-
| 6
| 30
| Not used?
|-
| 7
| 38
| Running capture duration
|-
| 8
| 40
| Channel input state
|-
| 9
| 48
| Capture status flags
|}

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

During setup, field 5 is used to limit the (compressed) size of the captured data. During a running capture operation, field 5 indicates the current memory fill level.

Field 7 is the time passed since the first sample. For samplerates up to 100 MHz, the value is a duration in milliseconds. The 125 MHz setting is again special and uses the same timebase as the 100 MHz setting, i.e. field 7 can then be interpreted as the sample count × 10−5.

Field 8 records a snapshot of the signal level of all 34 channels at the time the status is being read.

Field 6 appears to be unused.

===== Capture Status Flags =====

The status flag bits are used as follows:
{| border="0" style="font-size: smaller;" class="sigroktable"
!Bit 0
!Bit 1
!Bit 2
!Bit 3
!Bit 4
!Bit 5
|-
| ???
| Capturing
| ???
| ???
| Triggered
| Memory available
|}
The higher bits of field 9 appear to contain garbage (apparently copies of the bits from field 8).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream (default: internal clock) to EP 4 via bulk transfer
# Device test sequence (performed twice by vendor software, only the results of the second run should be checked):
## Write 100 to register 0x10B4
## Read register 0x10B0: value should be ignored
## Read register 0x10BC: value should be 0x12345678
## Read register 0x10B8: value should be 0x87654321
# Capture setup/state test (vendor software does this, not mandatory):
## Write sequence 0..9 to capture setup fields (via command 7)
## Read back capture state (via command 8): 0..4 should be read back as is, 5..9 are trashed anyway
# Memory test (vendor software does this, not mandatory):
## Write 2 to register 0x1074
## Write 0 to register 0x107C
## Read memory beginning at address 0 in chunks of 120 36-bit words, up to but not including 0x013FB0
## Read memory beginning at address 0x013FB0 in chunks of 8 36-bit words, up to but not including 0x014000

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

=== Poll channel state ===

The vendor software continuously polls the channel state even when idle. However, it is not mandatory to do so.

# Poll frequency of signal at CH1 to CH4:
## Read register 0x10C0: value is frequency of CH1 signal
## Read register 0x10C4: value is frequency of CH2 signal
## Read register 0x10C8: value is frequency of CH3 signal
## Read register 0x10CC: value is frequency of CH4 signal
# Poll signal level of all channels:
## Read capture state (via command 8): the signal level of all channels is recorded in field 8

=== Clocking Mode Switch ===

# Transfer one of three FPGA bitstreams to EP 4:
## Configuration for internal clock
## Configuration for external clock, rising edge
## Configuration for external clock, falling edge

=== Signal Capture ===

# Write 2 to register 0x1074
# Write 1 to register 0x1074 (previous write may be redundant, needs testing)
# Write 10 to register 0x10B4
# Write 0x74 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Write divider bypass flag to register 0x1094 (see description of register)
# Write capture setup (command 7, address 0, length 10: see description of command)
# Write 10 to register 0x10B4
# Write 1 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Wait for capture to finish:
## Poll capture state (command 8, address 0, length 10: see description of command)
## Report progress information (got trigger, cycles elapsed, memory fill percentage) to user
## Capture has finished once the memory available flag is reset

=== Cancel Signal Capture ===

# Write 10 to register 0x10B4
# Write 0 to register 0x10B8
# Write 0 to register 0x10BC
# Write 0 to register 0x10B0
# Write 0 to register 0x1094 (divider bypass flag)

After that, the memory available flag in the capture state should have been cleared. Continue in the same manner as for a regularly finished capture.

=== Read Captured Data ===

# Read register 0x1078: value is the number of 36-bit words in the capture buffer
# Write 1 to register 0x1094 (divider bypass flag)
# Write 2 to register 0x1074
# Write 4 to register 0x107C
# Read capture buffer:
## Read memory beginning at address 4 in chunks of 120 36-bit words, up to but not including 0x03FFC4
## Read memory beginning at address 0x03FFC4 in chunks of 8 36-bit words, up to but not including 0x03FFF4
# Write 0 to register 0x1094 (divider bypass flag)
# Issue mystery command 5 with mystery data, but for some mystical reason only for the first three captures after application start

It does not seem to be necessary to use exactly the same read chunk length as the original vendor software. See the description of command 6 for constraints.

The sigrok driver works fine without ever issuing mystery command 5.

=== Shutdown ===

1. Transfer FPGA configuration for device shutdown to EP 4

Sysclk LWLA1016/Protocol

2015-07-06T12:29:35Z

Danielk: Correct description of command 3

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read Memory at Address ===

This command reads the captured samples from the device. It works very much like command 6 in the LWLA1034 protocol.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0003
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 32 bit wide, and thus the size of the response in bits is 32 times the value in the length field. The original vendor software reads chunks of 250 words @ 32 bit at a time, i.e. 1000 bytes. Note that the software always starts reading at address 2 rather than 0.

===== Compression Scheme =====

In timing-state mode a very simple form of run-length encoding is used. Each 32-bit unit of memory holds 2 Little Endian values. The 16-bit word at the lower address is the repeat count for the channel state encoded in the subsequent 16-bit word.

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034

=== Device State Polling ===

# Read register 0x10B8, reply is 0x10 in timing-state mode, or 0 in normal mode
# Read register 0x10B0, reply is 0
# Read register 0x1070, reply is 0
# Read register 0x10BC, reply is 0x1234xxxx, where "xxxx" is the channel state
# Read register 0x1010, reply is 0

Sysclk LWLA1016

2015-07-06T09:22:21Z

Danielk: Add more detail

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1016.png|180px]]
| name = Sysclk LWLA1016
| status = in progress
| source_code_dir =
| channels = 16/8
| samplerate = 100/200/250 MHz
| samplerate_state = ?
| triggers = only in 100MHz mode
| voltages = ?
| threshold = ?
| memory = 256Kbit/channel
| compression = optional
| website = [http://item.taobao.com/item.htm?id=12821371102 taobao.com]
}}

The '''Sysclk LWLA1016''' is a USB-based, 16-channel logic analyzer with up to 100MHz sampling rate, or up to 250MHz with 8 channels.

See [[Sysclk LWLA1016/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

TODO.

== Photos ==

<gallery>
File:Sysclk lwla1016 front.jpg|Device, front
File:Sysclk lwla1016 device back.jpg|Device, back
File:Sysclk lwla1016 device open.jpg|Device, open
File:Sysclk lwla1016 pcb top.jpg|PCB, top
File:Sysclk lwla1016 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1016 pcb cypress fx2.jpg|Cypress FX2
File:Sysclk lwla1016 pcb issi 1.jpg|ISSI 1
File:Sysclk lwla1016 pcb issi2.jpg|ISSI 2
File:Sysclk lwla1016 pcb atmlh105.jpg|ATMLH105
File:Sysclk lwla1016 stc 15f104e.jpg|STC
File:Sysclk lwla1016 pcb ldo.jpg|LDOs
File:Sysclk lwla1016 pcb input.jpg|Input stage
File:Sysclk lwla1016 pcb crystal.jpg|Crystal
</gallery>

== Protocol ==

Reverse engineering of the vendor's custom protocol has begun. See [[Sysclk LWLA1016/Protocol]] for the findings gathered so far.

== Resources ==

TODO.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:In progress]]

Sysclk LWLA1016

2015-07-05T22:55:47Z

Danielk: Also change category

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1016.png|180px]]
| name = Sysclk LWLA1016
| status = in progress
| source_code_dir =
| channels = 16
| samplerate = 100MHz
| samplerate_state = ?
| triggers = ?
| voltages = ?
| threshold = ?
| memory = 256Kbit/channel
| compression = ?
| website = [http://item.taobao.com/item.htm?id=12821371102 taobao.com]
}}

The '''Sysclk LWLA1016''' is a USB-based, 16-channel logic analyzer with up to 100MHz sampling rate, or up to 250MHz with 8 channels.

See [[Sysclk LWLA1016/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

TODO.

== Photos ==

<gallery>
File:Sysclk lwla1016 front.jpg|Device, front
File:Sysclk lwla1016 device back.jpg|Device, back
File:Sysclk lwla1016 device open.jpg|Device, open
File:Sysclk lwla1016 pcb top.jpg|PCB, top
File:Sysclk lwla1016 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1016 pcb cypress fx2.jpg|Cypress FX2
File:Sysclk lwla1016 pcb issi 1.jpg|ISSI 1
File:Sysclk lwla1016 pcb issi2.jpg|ISSI 2
File:Sysclk lwla1016 pcb atmlh105.jpg|ATMLH105
File:Sysclk lwla1016 stc 15f104e.jpg|STC
File:Sysclk lwla1016 pcb ldo.jpg|LDOs
File:Sysclk lwla1016 pcb input.jpg|Input stage
File:Sysclk lwla1016 pcb crystal.jpg|Crystal
</gallery>

== Protocol ==

Reverse engineering of the vendor's custom protocol has begun. See [[Sysclk LWLA1016/Protocol]] for the findings gathered so far.

== Resources ==

TODO.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:In progress]]

Sysclk LWLA1016

2015-07-05T22:54:00Z

Danielk: Elevate state to "in progress"

Supported hardware

2015-07-05T22:51:56Z

Danielk: LWLA1016 support is now in progress

sigrok is intended as a flexible, cross-platform, and '''hardware-independent''' software suite, i.e., it supports various devices from many different vendors.

Here is a list of currently supported devices (various stages of completeness) and devices we plan to support in the near future.

The lists are sorted by category ([[File:Nuvola OK.png|16px]] supported: [[:Category:Supported|{{PAGESINCATEGORY:Supported|pages}}]], [[File:Nuvola Orange.png|16px]] in progress: [[:Category:In progress|{{PAGESINCATEGORY:In progress|pages}}]], [[File:Nuvola Red.png|16px]] planned: [[:Category:Planned|{{PAGESINCATEGORY:Planned|pages}}]]), and alphabetically within those categories.

== Logic analyzers ==

<gallery widths="100px" heights="100px">
File:ARMFLY MINI LOGIC.png|link=ARMFLY Mini-Logic|[[File:Nuvola OK.png|16px]] [[ARMFLY Mini-Logic]] (8ch, 24MHz)
File:ASIX SIGMA 2.png|link=ASIX SIGMA|[[File:Nuvola OK.png|16px]] [[ASIX SIGMA]] (16ch, 200MHz)
File:Braintechnology_usb_interface_v26.png|link=Braintechnology USB Interface V2.x|[[File:Nuvola OK.png|16px]] [[Braintechnology USB Interface V2.x]] (8/16ch, 24/12MHz)
File:Braintechnology_usb_lps.png|link=Braintechnology USB-LPS|[[File:Nuvola OK.png|16px]] [[Braintechnology USB-LPS]] (8/16ch, 24/12MHz)
File:Chronovu la8 front.png|link=ChronoVu LA8|[[File:Nuvola OK.png|16px]] [[ChronoVu LA8]] (8ch, 100MHz)
File:Chronovu la16.png|link=ChronoVu LA16|[[File:Nuvola OK.png|16px]] [[ChronoVu LA16]] (16ch, 200MHz)
File:Cwav_usbee_sx.png|link=CWAV USBee SX|[[File:Nuvola OK.png|16px]] [[CWAV USBee SX]] (8ch, 100MHz)
File:Buspirate_v3.png|link=Dangerous Prototypes Buspirate|[[File:Nuvola OK.png|16px]] [[Dangerous Prototypes Buspirate]] (5ch, 1MHz)
File:Dangerous prototypes irtoy mugshot.png|link=Dangerous Prototypes USB IR Toy|[[File:Nuvola OK.png|16px]] [[Dangerous Prototypes USB IR Toy]] (1ch, 10kHz)
File:Eeelec xla esla100.png|link=EE Electronics ESLA100|[[File:Nuvola OK.png|16px]] [[EE Electronics ESLA100]] (8ch, 24MHz)
File:Ikalogic_scanalogic2.png|link=IKALOGIC Scanalogic-2|[[File:Nuvola OK.png|16px]] [[IKALOGIC Scanalogic-2]] (4ch, 20MHz)
File:Ikalogic scanaplus mugshot.png|link=IKALOGIC ScanaPLUS|[[File:Nuvola OK.png|16px]] [[IKALOGIC ScanaPLUS]] (9ch, 100MHz)
File:Kingst kqs3506 la16100.png|link=KingST KQS3506-LA16100|[[File:Nuvola OK.png|16px]] [[KingST KQS3506-LA16100]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Lcsoft-miniboard-front.png|link=Lcsoft Mini Board|[[File:Nuvola OK.png|16px]] [[Lcsoft Mini Board]] (8/16ch, 24/12MHz)
File:logic-shrimp-front.png|link=Logic Shrimp|[[File:Nuvola OK.png|16px]] [[Logic Shrimp]] (4ch, 20MHz)
File:Mcu123 saleae logic clone.png|link=MCU123 Saleae Logic clone|[[File:Nuvola OK.png|16px]] [[MCU123 Saleae Logic clone]] (8ch, 24MHz)
File:Usbee_ax_clone_front.png|link=MCU123 USBee AX Pro clone|[[File:Nuvola OK.png|16px]] [[MCU123 USBee AX Pro clone]] (8ch, 24MHz)
File:Mcupro_Logic16_overview.png|link=mcupro Logic16 clone|[[File:Nuvola OK.png|16px]] [[mcupro Logic16 clone]] (16ch, 100MHz)
File:Openbench logic sniffer front.png|link=Openbench Logic Sniffer|[[File:Nuvola OK.png|16px]] [[Openbench Logic Sniffer]] (32ch, 100MHz)
File:Prist akip 9101 mugshot.png|link=Prist AKIP-9101|[[File:Nuvola OK.png|16px]] [[Prist AKIP-9101]] (16ch, 200MHz)
File:Robomotic buglogic3.png|link=Robomotic BugLogic 3|[[File:Nuvola OK.png|16px]] [[Robomotic BugLogic 3]] (8ch, 24MHz)
File:Robomotic_minilogic.png|link=Robomotic MiniLogic|[[File:Nuvola OK.png|16px]] [[Robomotic MiniLogic]] (8ch, 24MHz)
File:Saleae Logic.png|link=Saleae Logic|[[File:Nuvola OK.png|16px]] [[Saleae Logic]] (8ch, 24MHz)
File:Saleae_Logic16_bottom.png|link=Saleae Logic16|[[File:Nuvola OK.png|16px]] [[Saleae Logic16]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Saanlima Pipistrello-OLS.png|link=Saanlima Pipistrello OLS|[[File:Nuvola OK.png|16px]] [[Saanlima Pipistrello OLS]] (32ch, 100MHz)
File:Sysclk lwla1034 mugshot.png|link=Sysclk LWLA1034|[[File:Nuvola OK.png|16px]] [[Sysclk LWLA1034]] (34ch, 125MHz)
File:Wayengineer saleae16.png|link=WayEngineer Saleae16|[[File:Nuvola OK.png|16px]] [[WayEngineer Saleae16]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Zeroplus Logic Cube.png|link=ZEROPLUS Logic Cube LAP-C(16032)|[[File:Nuvola OK.png|16px]] [[ZEROPLUS Logic Cube LAP-C(16032)]] (16ch, 100MHz)
File:Zeroplus Logic Cube.png|link=ZEROPLUS Logic Cube LAP-C(322000)|[[File:Nuvola OK.png|16px]] [[ZEROPLUS Logic Cube LAP-C(322000)]] (32ch, 200MHz)
File:Zeroplus_lap-16128u.png|link=ZEROPLUS LAP-16128U|[[File:Nuvola OK.png|16px]] [[ZEROPLUS LAP-16128U]] (16ch, 200MHz)

File:DSLogic.png|link=DreamSourceLab DSLogic|[[File:Nuvola Orange.png|16px]] [[DreamSourceLab DSLogic]] (16ch, 400MHz)
File:Hsa-logic.png|link=HSA Logic|[[File:Nuvola Orange.png|16px]] [[HSA Logic]] (8ch, 6.25MHz)
File:RockyLogic Ant18e.png|link=RockyLogic Ant18e|[[File:Nuvola Orange.png|16px]] [[RockyLogic Ant18e]] (8ch, 1GHz)
File:Sysclk lwla1016.png|link=Sysclk LWLA1016|[[File:Nuvola Orange.png|16px]] [[Sysclk LWLA1016]] (16ch, 100MHz)

File:Acute_pkla1216.png|link=Acute PKLA-1216|[[File:Nuvola Red.png|16px]] [[Acute PKLA-1216]] (16ch, 200MHz)
File:Hantek 4032l mugshot.png|link=Hantek 4032L|[[File:Nuvola Red.png|16px]] [[Hantek 4032L]] (32ch, 400MHz)
File:Ideofy_la_08.png|link=Ideofy LA-08|[[File:Nuvola Red.png|16px]] [[Ideofy LA-08]] (8ch, 96/60/30MHz @ 2/4/8ch)
File:Intronix Logicport.png|link=Intronix Logicport LA1034|[[File:Nuvola Red.png|16px]] [[Intronix Logicport LA1034]] (34ch, 500MHz)
File:Sigrok_logo_no_text_transparent_512.png|link=Link Instruments LA-5580|[[File:Nuvola Red.png|16px]] [[Link Instruments LA-5580]] (80ch, 500MHz)
File:Microchip_pickit2.png|link=Microchip PICkit2|[[File:Nuvola Red.png|16px]] [[Microchip PICkit2]] (3ch, 1MHz)
File:Minila parport.png|link=MiniLA|[[File:Nuvola Red.png|16px]] [[MiniLA]] (32ch, 100MHz)
File:Minila_mockup.png|link=MiniLA Mockup|[[File:Nuvola Red.png|16px]] [[MiniLA Mockup]] (32ch, 100MHz)
File:Noname_la16_mugshot.png|link=Noname LA16|[[File:Nuvola Red.png|16px]] [[Noname LA16]] (16ch, 100MHz)
File:Noname xl logic16 100m mugshot.png|link=Noname XL-LOGIC16-100M|[[File:Nuvola Red.png|16px]] [[Noname XL-LOGIC16-100M]] (16ch, 100/50/32/16MHz @ 3/6/9/16ch)
File:Rockylogic_ant8.png|link=RockyLogic Ant8|[[File:Nuvola Red.png|16px]] [[RockyLogic Ant8]] (8ch, 500MHz)
File:Sysclk lwla2034 mugshot.png|link=Sysclk LWLA2034|[[File:Nuvola Red.png|16px]] [[Sysclk LWLA2034]] (34ch, 200MHz)
File:Techtools_digiview_dv1-100.png|link=TechTools DigiView DV1-100|[[File:Nuvola Red.png|16px]] [[TechTools DigiView DV1-100]] (18ch, 100MHz)
File:Xmos xtag2.png|link=XMOS XTAG-2|[[File:Nuvola Red.png|16px]] [[XMOS XTAG-2]] (?ch, 50MHz)
File:Zlg_la1032.png|link=ZLG LA1032|[[File:Nuvola Red.png|16px]] [[ZLG LA1032]] (32ch, 100MHz)
</gallery>

== Mixed-signal devices ==

<gallery widths=105px heights=105px>
File:Armfly_ax_pro.png|link=ARMFLY AX-Pro|[[File:Nuvola OK.png|16px]] [[ARMFLY AX-Pro]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:Sysclk ax pro mugshot.png|link=Sysclk AX-Pro|[[File:Nuvola OK.png|16px]] [[Sysclk AX-Pro]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 3MHz BW)
File:Esla201a.png|link=EE Electronics ESLA201A|[[File:Nuvola OK.png|16px]] [[EE Electronics ESLA201A]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:Rigol DS1052E.png|link=Rigol DS1000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS1000 series|Rigol DS1000D series]] (16ch, 2ch analog, 50-150MHz BW)
File:Rigol_VS5202D.png|link=Rigol VS5000 series|[[File:Nuvola OK.png|16px]] [[Rigol VS5000 series|Rigol VS5000D series]] (16ch, 2ch analog, 20-200MHz BW
File:Yokogawa DLM2000 front.png|link=Yokogawa DLM2000 series|[[File:Nuvola OK.png|16px]] [[Yokogawa DLM2000 series]] (8ch, 2/4ch analog, 2.5GSa/s, 200/350/500MHz BW)
File:Xzl studio ax mugshot.png|link=XZL_Studio AX|[[File:Nuvola OK.png|16px]] [[XZL_Studio AX]]1 (8ch, 24MHz; 2ch analog, 24MSa/s, 40MHz BW)
File:BitScope BS10.png|link=BitScope BS10|[[File:Nuvola Orange.png|16px]] [[BitScope BS10]] (8ch, 40MHz; 2ch analog, 20MSa/s, ? BW)
File:Link Instruments MSO-19 front.png|link=Link Instruments MSO-19|[[File:Nuvola Orange.png|16px]] [[Link Instruments MSO-19]] (8ch, 200MHz; 1ch analog, 200MSa/s, 60MHz BW)

File:Agilent_MSO7104A.png|link=Agilent MSO7104A|[[File:Nuvola Red.png|16px]] [[Agilent MSO7104A]] (16ch, ?; 4ch analog, 2GSa/s, 1GHz BW)
File:Digilent_analog_discovery.png|link=Digilent Analog Discovery|[[File:Nuvola Red.png|16px]] [[Digilent Analog Discovery]] (16ch, 100MHz; 2ch analog, 100MSa/s, 5MHz BW)
File:Hantek_1008C.png|link=Hantek 1008C|[[File:Nuvola Red.png|16px]] [[Hantek 1008C]] (8ch)
File:Lab nation smartscope mugshot.png|link=LabNation SmartScope|[[File:Nuvola Red.png|16px]] [[LabNation SmartScope]] (8ch, 100MHz; 2ch analog, 100MSa/s, 45MHz BW)
File:Meilhaus_mephisto_scope1.png|link=Meilhaus MEphisto Scope1|[[File:Nuvola Red.png|16px]] [[Meilhaus MEphisto Scope1]] (16ch, 100kHz; 2ch analog, 1MSa/s, 500kHz BW)
File:Polabs_poscope_basic2.png|link=PoLabs PoScope Basic2|[[File:Nuvola Red.png|16px]] [[PoLabs PoScope Basic2]] (16ch, 8MHz; 2ch analog, 200kSa/s, ? BW)
File:QuantAsylum QA100.png|link=QuantAsylum QA100|[[File:Nuvola Red.png|16px]] [[QuantAsylum QA100]] (12ch; 2ch analog)
File:Saleae Logic Pro 16 bottom.jpg|link=Saleae Logic Pro 16|[[File:Nuvola Red.png|16px]] [[Saleae Logic Pro 16]] (4/16ch, 500/100MHz; 16ch analog, 50MSa/s, 5MHz BW)
File:Sigrok_logo_no_text_transparent_512.png|link=XZL_Studio DX|[[File:Nuvola Red.png|16px]] [[XZL_Studio DX]] (16ch, 24MHz; 2ch analog)
</gallery>


1 Only the logic analyzer functionality is supported so far, analog support is work in progress. 


== Oscilloscopes ==

<gallery widths=100px heights=100px>
File:Agilent DSO1014A.png|link=Agilent DSO1000 series|[[File:Nuvola OK.png|16px]] [[Agilent DSO1000 series]] (2-4ch, 2GS/s, 60-200MHz BW)
File:Fluke_Scopemeter_199B.png|link=Fluke ScopeMeter 199B|[[File:Nuvola OK.png|16px]] [[Fluke ScopeMeter 199B]] (2ch, 2.5GS/s, 200MHz BW)
File:Hameg HMO2024.png|link=Hameg HMO compact series|[[File:Nuvola OK.png|16px]] [[Hameg HMO compact series]] (2-4ch, 2GS/s, 70-200MHz BW)
File:Hantek DSO-2090.png|link=Hantek DSO-2090|[[File:Nuvola OK.png|16px]] [[Hantek DSO-2090]] (2ch, 100MS/s, 40MHz)
File:Rigol DS1052E.png|link=Rigol DS1000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS1000 series|Rigol DS1000E series]] (2ch, 1GS/s, 50-150MHz BW)
File:Rigol-ds2072 mugshot.png|link=Rigol DS2000 series|[[File:Nuvola OK.png|16px]] [[Rigol DS2000 series]] (2ch, 2GS/s, 70-200MHz BW)
File:Rigol_VS5202D.png|link=Rigol VS5000 series|[[File:Nuvola OK.png|16px]] [[Rigol VS5000 series]] (2ch, 20-200MHz BW)

File:Hantek dso2250 mugshot.png|link=Hantek DSO-2250|[[File:Nuvola Orange.png|16px]] [[Hantek DSO-2250]] (2ch, 250MS/s, 100MHz BW)
File:Hantek dso-5200a device front.png|link=Hantek DSO-5200A|[[File:Nuvola Orange.png|16px]] [[Hantek DSO-5200A]] (2ch, 250MS/s, 200MHz BW)
File:OsciPrime.png|link=Nexus-Computing OsciPrime|[[File:Nuvola Orange.png|16px]] [[Nexus-Computing OsciPrime]] (2ch, ?MS/s, 3.3MHz-8MHz BW)
File:Velleman PCSU1000.png|link=Velleman PCSU1000|[[File:Nuvola Orange.png|16px]] [[Velleman PCSU1000]] (2ch, 1GS/s, 50MHz BW)

File:Fluke scopemeter123.png|link=Fluke ScopeMeter 123|[[File:Nuvola Red.png|16px]] [[Fluke ScopeMeter 123]] (2ch, 25MS/s, 20MHz BW)
File:Focussz_fosc21_mugshot.png|link=Focussz Fosc21|[[File:Nuvola Red.png|16px]] [[Focussz Fosc21]] (2ch, 8kS/s, 3kHz BW)
File:Hantek 6022be.jpg|link=Hantek 6022BE|[[File:Nuvola Red.png|16px]] [[Hantek 6022BE]] (2ch, 48MS/s, 20MHz BW)
File:Hantek front.jpg|link=Hantek 6052BE|[[File:Nuvola Red.png|16px]] [[Hantek 6052BE]] (2ch, 150MS/s, 50MHz BW)
File:Sigrok_logo_no_text_transparent_512.png|link=Hantek DSO-1200|[[File:Nuvola Red.png|16px]] [[Hantek DSO-1200]] (2ch, 500MS/s, 200MHz BW)
File:Usbduxfast.png|link=Incite Technology USB-DUXfast|[[File:Nuvola Red.png|16px]] [[Incite Technology USB-DUXfast]] (16ch, 3MHz, ? BW)
File:Sigrok_logo_no_text_transparent_512.png|link=Owon SDS series|[[File:Nuvola Red.png|16px]] [[Owon SDS series]] (2ch, 0.5-3.2GS/s, 60-300MHz BW)
File:Picoscope 2203.png|link=Pico Technology PicoScope 2203|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 2203]] (40/20MS/s, 5MHz BW)
File:PicoScope_2205.png|link=Pico Technology PicoScope 2205|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 2205]] (200/100MS/s, 25MHz BW)
File:Picoscope 3206.png|link=Pico Technology PicoScope 3206|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 3206]] (200/100MS/s, 200MHz BW)
File:Picoscope 5203.png|link=Pico Technology PicoScope 5203|[[File:Nuvola Red.png|16px]] [[Pico Technology PicoScope 5203]] (1/0.5GS/s, 250MHz BW)
File:Tektronix tds2024b mugshot.png|link=Tektronix TDS2000B series|[[File:Nuvola Red.png|16px]] [[Tektronix TDS2000B series]] (2-4ch, 1-2GS/s, 60-200MHz BW)
File:UNI-T UTD2042C.png|link=UNI-T UTD2042C|[[File:Nuvola Red.png|16px]] [[UNI-T UTD2042C]] (2ch, 500MS/s, 40MHz BW)
File:VellemanWFS210.png|link=Velleman WFS210|[[File:Nuvola Red.png|16px]] [[Velleman WFS210]] (2ch, 10MS/s, ?? MHz BW)
File:Voltcraft dso-220 usb.png|link=Voltcraft DSO-220|[[File:Nuvola Red.png|16px]] [[Voltcraft DSO-220]] (2ch, 60MS/s, 20MHz BW)
File:Voltcraft DSO-3062C.png|link=Voltcraft DSO-3062C|[[File:Nuvola Red.png|16px]] [[Voltcraft DSO-3062C]] (2ch, 1GS/s, 60MHz BW)
</gallery>

== Multimeters ==

<gallery widths="100px" heights="100px">
File:Agilent U1232A.png|link=Agilent U12xxx series|[[File:Nuvola OK.png|16px]] [[Agilent U12xxx series]] (USB/Bluetooth)
File:Bbc gm m2110 mugshot.png|link=BBC Goertz Metrawatt M2110|[[File:Nuvola OK.png|16px]] [[BBC Goertz Metrawatt M2110]] (30000 counts, RS232)
File:Brymen BM257.png|link=Brymen BM257|[[File:Nuvola OK.png|16px]] [[Brymen BM257]] (6000 counts, RS232/USB)
File:Brymen bm257s mugshot.png|link=Brymen BM257s|[[File:Nuvola OK.png|16px]] [[Brymen BM257s]] (6000 counts, RS232/USB)
File:Bm_857_mugshot_500000.png|link=Brymen BM857|[[File:Nuvola OK.png|16px]] [[Brymen BM857]] (50000 counts, RS232)
File:Bm869_mugshot.png|link=Brymen BM869|[[File:Nuvola OK.png|16px]] [[Brymen BM869]] (50000 counts, USB)
File:Digitek_dt4000zc_device_front.png|link=Digitek DT4000ZC|[[File:Nuvola OK.png|16px]] [[Digitek DT4000ZC]] (4000 counts, RS232)
File:Fluke 187.png|link=Fluke 187/189|[[File:Nuvola OK.png|16px]] [[Fluke 187/189]] (50000 counts, RS232)
File:Fluke 287.png|link=Fluke 287/289|[[File:Nuvola OK.png|16px]] [[Fluke 287/289]] (50000 counts, RS232)
File:Gmc metrahit 14a logo.png|link=Gossen Metrawatt Metrahit 14A|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 14A]] (3100 counts, RS232)
File:Gossen Metrawatt Metrahit 16I small.png|link=Gossen Metrawatt Metrahit 16I|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 16I]] (3100 counts, RS232)
File:Gossen Metrawatt Metrahit 18S small.png|link=Gossen Metrawatt Metrahit 18S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 18S]] (31000 counts, RS232)
File:Gossen Metrawatt Metrahit 25S Logo.png|link=Gossen Metrawatt Metrahit 25S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 25S]] (31000 counts, RS232/USB)
File:Gmc kmm2002 logo.png|link=Gossen Metrawatt T-Com KMM2002|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt T-Com KMM2002]] (3100 counts, RS232)
File:Gmc metrahit 29s logo.png|link=Gossen Metrawatt Metrahit 29S|[[File:Nuvola OK.png|16px]] [[Gossen Metrawatt Metrahit 29S]] (310000 counts, RS232/USB)
File:HT410 logo.png|link=HT Instruments HT410|[[File:Nuvola OK.png|16px]] [[HT Instruments HT410]] (3100 counts, RS232)
File:100px_Idm103n.png|link=ISO-TECH IDM103N|[[File:Nuvola OK.png|16px]] [[ISO-TECH IDM103N]] (4000 counts, RS232)
File:Mastech mas345 device front.png|link=MASTECH MAS345|[[File:Nuvola OK.png|16px]] [[MASTECH MAS345]] (4000 counts, RS232)
File:Mastech ms8250b mugshot.png|link=MASTECH MS8250B|[[File:Nuvola OK.png|16px]] [[MASTECH MS8250B]] (4000 counts, USB)
File:Metex m4650cr mugshot.png|link=Metex M-4650CR|[[File:Nuvola OK.png|16px]] [[Metex M-4650CR]] (20000 counts, RS232)
File:Metex_me-31.png|link=Metex ME-31|[[File:Nuvola OK.png|16px]] [[Metex ME-31]] (4000 counts, RS232)
File:Norma dm950.png|link=Norma DM950|[[File:Nuvola OK.png|16px]] [[Norma DM950]] (21000 counts, RS232)
File:Pce-pce-dm32.png|link=PCE PCE-DM32|[[File:Nuvola OK.png|16px]] [[PCE PCE-DM32]] (4000 counts, RS232)
File:Metex_me-31.png|link=PeakTech 3410|[[File:Nuvola OK.png|16px]] [[PeakTech 3410]] (4000 counts, RS232)
File:Peaktech 4370 device front.png|link=PeakTech 4370|[[File:Nuvola OK.png|16px]] [[PeakTech 4370]] (2000 counts, RS232)
File:Rs_22_168_mugshot.png|link=RadioShack 22-168|[[File:Nuvola OK.png|16px]] [[RadioShack 22-168]] (2000 counts, RS232)
File:Rs_22-805_front.png|link=RadioShack 22-805|[[File:Nuvola OK.png|16px]] [[RadioShack 22-805]] (4000 counts, RS232)
File:radioshack_22_812_front.png|link=RadioShack 22-812|[[File:Nuvola OK.png|16px]] [[RadioShack 22-812]] (4000 counts, RS232)
File:siemens_b1026_logo.png|link=Siemens B1026|[[File:Nuvola OK.png|16px]] [[Siemens B1026]] (21000 counts, RS232)
File:Siemens B1105 small.png|link=Siemens B1105|[[File:Nuvola OK.png|16px]] [[Siemens B1105]] (310000 counts, RS232/USB)
File:Tecpel dmm8061.png|link=Tecpel DMM-8061|[[File:Nuvola OK.png|16px]] [[Tecpel DMM-8061]] (4000 counts, RS232/USB)
File:Tp4000zc_front.png|link=TekPower TP4000ZC|[[File:Nuvola OK.png|16px]] [[TekPower TP4000ZC]] (4000 counts, RS232)
File:Tenma 72-7745.png|link=Tenma 72-7745|[[File:Nuvola OK.png|16px]] [[Tenma 72-7745]] (4000 counts, RS232/USB)
File:Ut60e_-_front_-_alpha.png|link=UNI-T UT60E|[[File:Nuvola OK.png|16px]] [[UNI-T UT60E]] (4000 counts, RS232/USB)
File:Uni-t ut61b mugshot.png|link=UNI-T UT61B|[[File:Nuvola OK.png|16px]] [[UNI-T UT61B]] (4000 counts, RS232/USB)
File:Uni-t ut61c mugshot.png|link=UNI-T UT61C|[[File:Nuvola OK.png|16px]] [[UNI-T UT61C]] (6000 counts, RS232/USB)
File:Uni t ut61d device.png|link=UNI-T UT61D|[[File:Nuvola OK.png|16px]] [[UNI-T UT61D]] (6000 counts, RS232/USB)
File:Old ver front.png|link=UNI-T UT61E|[[File:Nuvola OK.png|16px]] [[UNI-T UT61E]] (22000 counts, RS232/USB)
File:Ut71c mugshot.png|link=UNI-T UT71C|[[File:Nuvola OK.png|16px]] [[UNI-T UT71C]] (40000 counts, RS232/USB)
File:Va_va18b.png|link=V&A VA18B|[[File:Nuvola OK.png|16px]] [[V&A VA18B]] (6000 counts, USB)
File:Va va40b mugshot.png|link=V&A VA40B|link=V&A VA40B|[[File:Nuvola OK.png|16px]] [[V&A VA40B]] (6000 counts, USB)
File:Victor 70C.png|link=Victor 70C|[[File:Nuvola OK.png|16px]] [[Victor 70C]] (4000 counts, USB)
File:Victor 86c device front.png|link=Victor 86C|[[File:Nuvola OK.png|16px]] [[Victor 86C]] (4000 counts, USB)
File:Voltcraft m-3650cr.png|link=Voltcraft M-3650CR|[[File:Nuvola OK.png|16px]] [[Voltcraft M-3650CR]] (2000 counts, RS232)
File:Voltcraft_M-3650D_transparent.png|link=Voltcraft M-3650D|[[File:Nuvola OK.png|16px]] [[Voltcraft M-3650D]] (2000 counts, RS232)
File:Voltcraft m4650cr.png|link=Voltcraft M-4650CR|[[File:Nuvola OK.png|16px]] [[Voltcraft M-4650CR]] (20000 counts, RS232)
File:Voltcraft ME-42 logo.png|link=Voltcraft ME-42|[[File:Nuvola OK.png|16px]] [[Voltcraft ME-42]] (4000 counts, RS232)
File:Voltcraft vc820 device.png|link=Voltcraft VC-820|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-820]] (4000 counts, RS232/USB)
File:Voltcraft vc830.png|link=Voltcraft VC-830|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-830]] (6000 counts, RS232/USB)
File:Voltcraft vc840 device front.png|link=Voltcraft VC-840|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-840]] (4000 counts, RS232/USB)
File:Voltcraft vc920.png|link=Voltcraft VC-920|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-920]] (40000/4000 counts, RS232/USB)
File:Voltcraft vc940.png|link=Voltcraft VC-940|[[File:Nuvola OK.png|16px]] [[Voltcraft VC-940]] (40000/4000 counts, RS232/USB)

File:Tenma 72-1016.png|link=Tenma 72-1016|[[File:Nuvola Orange.png|16px]] [[Tenma 72-1016]] (6000 counts, RS232/USB)
File:Tenma 72-7730.png|link=Tenma 72-7730|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7730]] (20000 counts, RS232/USB)
File:Tenma 72-7732.png|link=Tenma 72-7732|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7732]] (40000 counts, RS232/USB)
File:Tenma 72-7750.png|link=Tenma 72-7750|[[File:Nuvola Orange.png|16px]] [[Tenma 72-7750]] (6000 counts, RS232/USB)
File:Tenma 72-9380A.png|link=Tenma 72-9380A|[[File:Nuvola Orange.png|16px]] [[Tenma 72-9380A]] (40000 counts, RS232/USB)

File:Appa 107.png|link=APPA 107|[[File:Nuvola Red.png|16px]] [[APPA 107]] (4000 / 20000 counts, RS232)
File:Digitek dt8000.png|link=Digitek DT8000|[[File:Nuvola Red.png|16px]] [[Digitek DT8000]] (8000 counts, RS232)
File:Digitek dt80000.png|link=Digitek DT80000|[[File:Nuvola Red.png|16px]] [[Digitek DT80000]] (80000 counts, RS232)
File:Escort 179 device front.png|link=Escort 179|[[File:Nuvola Red.png|16px]] [[Escort 179]] (10000 counts, RS232)
File:Gossen metrahit 30m.png|link=Gossen-Metrawatt METRAHIT 30M|[[File:Nuvola Red.png|16px]] [[Gossen-Metrawatt METRAHIT 30M]] (1200000 counts, RS232/USB)
File:800px-Mastech m9803r device front.png|link=MASTECH M9803R|[[File:Nuvola Red.png|16px]] [[MASTECH M9803R]] (4000 counts, RS232)
File:Metrix mx53.png|link=Metrix MX53|[[File:Nuvola Red.png|16px]] [[Metrix MX53]] (50000 counts, RS232)
File:Metrix mx56c.png|link=Metrix MX56C|[[File:Nuvola Red.png|16px]] [[Metrix MX56C]] (50000 counts, RS232)
File:Peaktech 4380 mugshot.png|link=PeakTech 4380|[[File:Nuvola Red.png|16px]] [[PeakTech 4380]] (4000 counts, RS232)
File:Sigrok_logo_no_text_transparent_512.png|link=Protek 6500|[[File:Nuvola Red.png|16px]] [[Protek 6500]] (50000 counts, RS232)
File:Voltcraft m3890dt usb.png|link=Voltcraft M-3890DT|[[File:Nuvola Red.png|16px]] [[Voltcraft M-3890DT]] (4000 counts, USB)
File:Voltcraft m4660a device front.png|link=Voltcraft M-4660A|[[File:Nuvola Red.png|16px]] [[Voltcraft M-4660A]] (20000 counts, RS232)
File:Sigrok_logo_no_text_transparent_512.png|link=Voltcraft VC-870|[[File:Nuvola Red.png|16px]] [[Voltcraft VC-870]] (40000 counts, RS232/USB)
</gallery>

== LCR meters ==

<gallery widths="100px" heights="100px">
File:Voltcraft4080_2.png|link=Voltcraft 4080|[[File:Nuvola Orange.png|16px]] [[Voltcraft 4080]] (serial)
</gallery>

== Sound level meters ==

<gallery widths="100px" heights="100px">
File:CEM DT-8852.png|link=CEM DT-8852|[[File:Nuvola OK.png|16px]] [[CEM DT-8852]] (USB)
File:Colead SL-5868P.png|link=Colead SL-5868P|[[File:Nuvola OK.png|16px]] [[Colead SL-5868P]] (RS232)
File:Kecheng KC-330B.png|link=Kecheng KC-330B|[[File:Nuvola OK.png|16px]] [[Kecheng KC-330B]] (RS232)
File:Tondaj sl-814.png|link=Tondaj SL-814|[[File:Nuvola OK.png|16px]] [[Tondaj SL-814]] (USB)
File:Voltcraft_DL-161S.png|link=Voltcraft DL-161S|[[File:Nuvola Orange.png|16px]] [[Voltcraft DL-161S]] (USB)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (also: light-/thermo-/hygrometer; RS232)
File:Voltcraft_dl_160s.png|link=Voltcraft DL-160S|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-160S]] (USB)
</gallery>

== Thermometers ==

<gallery widths="100px" heights="100px">
File:rs55ii.png|link=APPA 55II|[[File:Nuvola OK.png|16px]] [[APPA 55II]] (2xtemp, RS232)
File:EL-USB-2.png|link=Lascar Electronics EL-USB-2|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-2]] (1xtemp, 1xhum, USB)
File:Mic 98581.png|link=MIC 98581|[[File:Nuvola OK.png|16px]] [[MIC 98581]] (1xtemp, USB)
File:Mic 98583.png|link=MIC 98583|[[File:Nuvola OK.png|16px]] [[MIC 98583]] (1xtemp, 1xhum, USB)
File:Uni-t ut325 front.png|link=UNI-T UT325|[[File:Nuvola OK.png|16px]] [[UNI-T UT325]] (2xtemp, USB)
File:Voltcraft k204.png|link=Voltcraft K204|[[File:Nuvola OK.png|16px]] [[Voltcraft K204]] (4xtemp, RS232)
File:Elitech rc3.png|link=Elitech RC-3|[[File:Nuvola Red.png|16px]] [[Elitech RC-3]] (1xtemp, RS232)
File:Escort 19.png|link=Escort 19|[[File:Nuvola Red.png|16px]] [[Escort 19]] (1x temp, RS232)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (1xtemp, RS232)
File:Rding temper front.png|link=RDing TEMPer|[[File:Nuvola Red.png|16px]] [[RDing TEMPer]] (1xtemp, USB)
File:Rding temper gold device front.png|link=RDing TEMPer Gold|[[File:Nuvola Red.png|16px]] [[RDing TEMPer Gold]] (1xtemp, USB)
File:Rding temper1 device front.png|link=RDing TEMPer1|[[File:Nuvola Red.png|16px]] [[RDing TEMPer1]] (1xtemp, USB)
File:Pcsensor_temper1k2.png|link=RDing TEMPer1K2|[[File:Nuvola Red.png|16px]] [[RDing TEMPer1K2]] (1xtemp, USB)
File:Voltcraft dl-120th.png|link=Voltcraft DL-120TH|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-120TH]] (1xtemp, USB)
File:Voltcraft dl-140th.png|link=Voltcraft DL-140TH|[[File:Nuvola Red.png|16px]] [[Voltcraft DL-140TH]] (1xtemp, USB)
</gallery>

== Hygrometers ==

<gallery widths="100px" heights="100px">
File:EL-USB-2.png|link=Lascar Electronics EL-USB-2|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-2]] (temp/humidity, USB)
File:Mic 98583.png|link=MIC 98583|[[File:Nuvola OK.png|16px]] [[MIC 98583]] (temp/humidity, USB)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (also: light-/soundlevelmeter; RS232)
File:Silabs si7005usb dgl eb top.jpg|link=SiLabs Si7005USB-Dongle|[[File:Nuvola Red.png|16px]] [[SiLabs Si7005USB-Dongle]] (USB)
</gallery>

== Anemometers ==

<gallery widths="100px" heights="100px">
File:Mastech ms6252b.png|link=MASTECH MS6252B|[[File:Nuvola Red.png|16px]] [[MASTECH MS6252B]] (USB)
</gallery>

== Light meters ==

<gallery widths="100px" heights="100px">
File:Lutron YK-2005LX.png|link=Lutron YK-2005LX|[[File:Nuvola Red.png|16px]] [[Lutron YK-2005LX]] (RS232)
File:Pce_pce-222_front.png|link=PCE PCE-222|[[File:Nuvola Red.png|16px]] [[PCE PCE-222]] (RS232)
</gallery>

== Energy meters ==

<gallery widths="100px" heights="100px">
File:Actaris_a14c5_teleinfo.png|link=EDF Teleinfo|[[File:Nuvola OK.png|16px]] [[EDF Teleinfo]] (RS232)
File:Acme.png|link=BayLibre ACME|[[File:Nuvola OK.png|16px]] [[BayLibre ACME]] (I2C)
</gallery>

== DAQs ==

<gallery widths="100px" heights="100px">
File:Ni usb 6008.png|link=NI USB-6008|[[File:Nuvola Red.png|16px]] [[NI USB-6008]] (8/2 analog inputs/outputs, 12 digital I/Os)
</gallery>

== Dataloggers ==

<gallery widths="100px" heights="100px">
File:EL-USB-CO.png|link=Lascar Electronics EL-USB-CO|[[File:Nuvola OK.png|16px]] [[Lascar Electronics EL-USB-CO]] (carbon monoxide (CO) logger, USB)
File:Testo_435-4.png|link=Testo 435-4|[[File:Nuvola OK.png|16px]] [[Testo 435-4]] (USB)
File:Gsg_indoor_air_monitor.png|link=GSG Indoor Air Monitor|[[File:Nuvola Red.png|16px]] [[GSG Indoor Air Monitor]] (air quality monitor, USB)
File:Maul_studio_i.png|link=MAUL studio i|[[File:Nuvola Red.png|16px]] [[MAUL studio i]] (weighing scale, RS232)
File:Voltcraft co-20.png|link=Voltcraft CO-20|[[File:Nuvola Red.png|16px]] [[Voltcraft CO-20]] (air quality monitor, USB)
</gallery>

== Tachometers ==

<gallery widths="100px" heights="100px">
File:Uni-t ut372 mugshot.png|link=UNI-T UT372|[[File:Nuvola OK.png|16px]] [[UNI-T UT372]] (USB)
</gallery>

== Digital loads ==

<gallery widths="100px" heights="100px">
File:Maynuo m9812 mugshot.png|link=Maynuo M9812|[[File:Nuvola OK.png|16px]] [[Maynuo M9812]]
File:Atten ATZ9711.png|link=ATTEN ATZ9711|[[File:Nuvola Red.png|16px]] [[ATTEN ATZ9711]]
</gallery>

== Function generators ==

<gallery widths="100px" heights="100px">
File:Hantek DDS-3X25 top.png|link=Hantek DDS-3X25|[[File:Nuvola Red.png|16px]] [[Hantek DDS-3X25]] (25MHz, PC-based, USB)
File:Siglent sdg1010 device front 8116.png|link=Siglent SDG1010|[[File:Nuvola Red.png|16px]] [[Siglent SDG1010]] (10MHz, USB)
</gallery>

== RF receivers ==

<gallery widths="100px" heights="100px">
File:Per vices noctar.png|link=Per Vices Noctar|[[File:Nuvola Red.png|16px]] [[Per Vices Noctar]] (100kHz-4GHz, IQ modulator/demodulator, PCIe)
</gallery>

== Spectrum analyzers ==

TODO.

== Power supplies ==

<gallery widths="100px" heights="100px">
File:Atten PPS3203T-3S.png|link=Atten PPS3203T-3S|[[File:Nuvola OK.png|16px]] [[Atten PPS3203T-3S]] (3ch, 2x 0-32V, 1x 0-6V at 0-3A, USB&RS232)
File:Chroma_61604_front.png|link=Chroma 61604|[[File:Nuvola OK.png|16px]] [[Chroma 61604]] (1ch, 0-300V, 0-16A, 2kVA)
File:Conrad_digi_35_cpu_logo.png|link=Conrad DIGI 35 CPU|[[File:Nuvola OK.png|16px]] [[Conrad DIGI 35 CPU]] (1ch, 0-35V/0-2.55A, RS232)
File:Manson hcs3202.png|link=Manson HCS-3202|[[File:Nuvola OK.png|16px]] [[Manson HCS-3202]] (1ch, 1-36V/0-10A, USB)
File:Motech_LPS-301_logo.png|link=Motech LPS-301|[[File:Nuvola OK.png|16px]] [[Motech LPS-301]] (1ch, 1-32V/0-2A, RS232)
File:Philips PM2813.png|link=Philips PM2800 series|[[File:Nuvola OK.png|16px]] Fluke/Philips PM2800 series
File:Rigol DP832.png|link=Rigol DP800 series|[[File:Nuvola OK.png|16px]] [[Rigol DP800 series]]
File:Voltcraft pps-11815 logo.png|link=Voltcraft PPS-11815|[[File:Nuvola OK.png|16px]] [[Voltcraft PPS-11815]] (1ch, 0-60V/0-5A, USB)

File:PS3005D front on.JPG|link=Velleman PS3005D|[[File:Nuvola Red.png|16px]] [[Velleman PS3005D]] (1ch, 0-30V/0-5A, USB&RS232)
File:Sigrok logo no text transparent 512.png|link=Voltcraft 18220|[[File:Nuvola Red.png|16px]] [[Voltcraft 18220]] (1ch, 0-40V/0-5A, RS232)
</gallery>

== GPIB interfaces ==

<gallery widths="100px" heights="100px">
File:Beiming_s82357.png|link=Beiming S82357|[[File:Nuvola Red.png|16px]] [[Beiming S82357]] (hardware-based, USB)
File:ICS 488-USB.png|link=ICS 488-USB|[[File:Nuvola Red.png|16px]] [[ICS 488-USB]] (hardware-based, USB)
File:GPIB-USB 82357B clone.png|link=GPIB-USB 82357B clone|[[File:Nuvola Red.png|16px]] [[GPIB-USB 82357B clone]] (hardware-based, USB)
File:NI GPIB-ENET.png|link=National Instruments GPIB-ENET|[[File:Nuvola Red.png|16px]] [[National Instruments GPIB-ENET]] (hardware-based, Ethernet)
File:NI GPIB-USB-HS.png|link=National Instruments GPIB-USB-HS|[[File:Nuvola Red.png|16px]] [[National Instruments GPIB-USB-HS]] (hardware-based, USB)
File:Prologix-usb.png|link=Prologix GPIB-USB|[[File:Nuvola Red.png|16px]] [[Prologix GPIB-USB]] (firmware-based, USB)
File:GalvantGPIBUSBrev4.JPG|link=Galvant GPIBUSB|[[File:Nuvola Red.png|16px]] [[Galvant GPIBUSB]] (firmware-based, USB, OSHW)
</gallery>

== Potential other candidates ==

If you own any other logic analyzers, oscilloscopes, multimeters, dataloggers, ... and want to add support for them in sigrok (or donate/lend devices to developers), please let us know. We're always happy to add more hardware support! Join the [https://lists.sourceforge.net/lists/listinfo/sigrok-devel mailing list] or ask on [irc://chat.freenode.net/sigrok IRC #sigrok] if you want to help out.

__FORCETOC__

User:Danielk/Simple Internal Compression Proposal

2015-07-05T14:50:40Z

Danielk: Grammar fix

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a 32-bit integer while allowing some room for arithmetic without overflow. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

Instead of requiring tight packing of the channel state and repeat count bits, one could also have a ''repeat count offset'' property which specifies the bit index at which the repeat count starts. This would allow an efficient arrangement for e.g. a 28 channels device with a 31-bit repeat count stored in bytes 4 to 7, while satisfying the 4-byte span restriction and guaranteeing 32-bit alignment. The separate property should make no difference to the extraction speed.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

An alternative implementation would be to have a fast path if ''unit size'' is divisible by 4 and a generic fallback path doing byte-wise extraction. This variant would never generate unaligned reads (assuming the data feed starts on an aligned address) and needs fewer conditionals.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any. However, in the same vein as above, it would make sense to introduce inline helper functions to simplify indexed access to single channels.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T14:48:55Z

Danielk: Propose additional repeat count index

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a 32-bit integer while allowing some room for arithmetic without overflow. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

Instead of requiring tight packing of the channel state and repeat count bits, one could also have a ''repeat count offset'' property which specifies the bit index at which the repeat count starts. This would allow an efficient arrangement for e.g. an 28 channels device with an 31-bit repeat count stored in bytes 4 to 7, while satisfying the 4-byte span restriction and guaranteeing 32-bit alignment. The separate property should make no difference to the extraction speed.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

An alternative implementation would be to have a fast path if ''unit size'' is divisible by 4 and a generic fallback path doing byte-wise extraction. This variant would never generate unaligned reads (assuming the data feed starts on an aligned address) and needs fewer conditionals.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any. However, in the same vein as above, it would make sense to introduce inline helper functions to simplify indexed access to single channels.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T14:22:14Z

Danielk: Reword justification for 31-bit limit

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a 32-bit integer while allowing some room for arithmetic without overflow. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

An alternative implementation would be to have a fast path if ''unit size'' is divisible by 4 and a generic fallback path doing byte-wise extraction. This variant would never generate unaligned reads (assuming the data feed starts on an aligned address) and needs fewer conditionals.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any. However, in the same vein as above, it would make sense to introduce inline helper functions to simplify indexed access to single channels.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T12:41:18Z

Danielk: Note that channel indexing could also use helper functions

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

An alternative implementation would be to have a fast path if ''unit size'' is divisible by 4 and a generic fallback path doing byte-wise extraction. This variant would never generate unaligned reads (assuming the data feed starts on an aligned address) and needs fewer conditionals.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any. However, in the same vein as above, it would make sense to introduce inline helper functions to simplify indexed access to single channels.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T12:34:10Z

Danielk: Describe alternative repeat count extraction

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

An alternative implementation would be to have a fast path if ''unit size'' is divisible by 4 and a generic fallback path doing byte-wise extraction. This variant would never generate unaligned reads (assuming the data feed starts on an aligned address) and needs fewer conditionals.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T12:25:02Z

Danielk: Mention unit size caveat for 32-bit read

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads (and assuming the ''unit size'' is at least 4), this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T11:50:21Z

Danielk: Note that the repeat count extractor needs a byte swap on BE machines

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads, this function could just do a single memory read (and a byte swap on BE machines) followed by a right shift.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T10:45:50Z

Danielk: Missing word

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to produce consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads, this function could just do a single memory read followed by a right shift.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk/Simple Internal Compression Proposal

2015-07-05T10:41:50Z

Danielk: Create compression proposal

== Goal ==

Many logic analyzers and file formats support simple stream compression; usually employing some variation of RLE. However, within sigrok logic streams are currently always uncompressed, and a driver for a device with compression has to expand the compressed stream coming from the device before passing it on.

This is not a problem for disk storage, since many of the output modules re-compress the logic stream (e.g. ZIP for the srzip format, or RLE for the VCD format). It is also not a problem if the run lengths for each sample are very short.

However, the worst case behavior is incredibly awful. For instance, with many LAs it is very easy to fill Gigabytes of RAM within seconds, simply by forgetting to turn on the signal source before starting acquisition. It makes for a very bad user experience if a simple mistake like that instantly puts your machine into swap death.

Apart from mistakes that can be made, there are also legitimate reasons to over-sample logic signals -- for instance, if accurate timing information is required.

Even if the RAM is not exhausted, processing will be very slow if streams contain Kilobytes or even Megabytes of consecutive identical samples. This applies to all stages in the processing pipeline, including decoders and display in PulseView.

Therefore, sigrok should support some means of internal stream compression. The compression scheme does not need to be particularly efficient. It should be some form of RLE, to allow easy transcoding from one format to another without having to expand the data. It is not intended to replace srzip compression. However, it would make sense to apply ZIP on top of RLE, in order to avoid having to expand the data at any point.

== Proposed Format ==

Currently, logic data feed packets have a channel count and a unit size in bytes. For the LWLA1034, the channel count is 34 and the unit size is 5. Each sample looks like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Ch. 33..32
|}
The 6 high bits of byte 4 are unused.

This could be extended by introducing another parameter ''repeat count width'', specifying the number of bits to use for the repeat count. The choice of a good width would be at the discretion of the driver and may vary from one acquisition to another. However, ''channel count'' plus ''repeat count width'' must be not be greater than 8 times the ''unit size''.

As an example, the LWLA1034 driver could specify a ''repeat count width'' of 30, which makes for a nice ''unit size'' of 8 bytes. Each sample would then look like this:

{| border="0" style="font-size: smaller;" class="sigroktable"
!Byte 0
!Byte 1
!Byte 2
!Byte 3
!Byte 4
!Byte 5
!Byte 6
!Byte 7
|-
| Ch. 7..0
| Ch. 15..8
| Ch. 23..16
| Ch. 31..24
| Rep. 5..0, Ch. 33..32
| Rep 13..6
| Rep 21..14
| Rep 29..22
|}

For ease of processing, the repeat count width should be restricted to at most 31 bits, so that it fits into a signed 32-bit integer. For devices that generate larger repeat counts, it is easy enough to split up longer runs on the fly. Also, the repeat count should not be allowed to span more than 4 bytes.

There should be no guarantee that the RLE-encoded stream is minimal. That is, it is legitimate for a driver to consecutive identical samples with run lengths less than the maximum. This avoids the need for the driver to carry state from one chunk of data to the next.

The input/output modules should do what is sensible for the format. E.g. the VCD output can just re-use the incoming run lengths without intermediate expansion. The VCD input module should generate RLE-compressed data feeds. The srzip writer should apply ZIP on top on the RLE-compressed data feed.

== API Thoughts ==

In order to make life easy for processing modules and client code, libsigrok should provide helper macros and/or inline functions to deal with RLE data feeds. In particular, there should be a function to extract the repeat count of a sample as an integer. On machines which permit unaligned 32-bit reads, this function could just do a single memory read followed by a right shift.

The channel state extraction does not change from how it works now, except that care has to be taken to mask unused bits in the last channel state byte, if any.

Optionally, an extension to the protocol decoder Python API may allow decoders to process unexpanded RLE data. This could speed up decoding quite significantly in some situations.

User:Danielk

2015-07-05T09:40:49Z

Danielk: Fix link

== Hardware TODO list ==

* [[Sysclk LWLA1016]]

== Proposals ==

* [[/Simple Internal Compression Proposal/]]

User:Danielk

2015-07-05T09:35:56Z

Danielk: Link to compression proposal

== Hardware TODO list ==

* [[Sysclk LWLA1016]]

== Proposals ==

* [[Simple Internal Compression Proposal]]

Sysclk LWLA1016/Protocol

2015-07-04T19:34:27Z

Danielk: Describe memory read command and compression scheme

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read Memory at Address ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed length of 5 words (10 bytes).

{| border="0" style="font-size: smaller;" class="sigroktable"
!ID
!Address
!Length
|-
| 0003
| aaaa-aaaa
| nnnn-nnnn
|}

Both the address and the length are encoded in mixed endian (2-1-4-3) byte order.

==== Response ====

The memory is 32 bit wide, and thus the size of the response in bits is 32 times the value in the length field. The original vendor software reads chunks of 250 words @ 32 bit at a time, i.e. 1000 bytes. Note that the software always starts reading at address 2 rather than 0.

===== Compression Scheme =====

In timing-state mode a very simple form of run-length encoding is used. Each 32-bit unit of memory holds 2 Little Endian values. The 16-bit word at the lower address is the repeat count for the channel state encoded in the subsequent 16-bit word.

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034

=== Device State Polling ===

# Read register 0x10B8, reply is 0x10 in timing-state mode, or 0 in normal mode
# Read register 0x10B0, reply is 0
# Read register 0x1070, reply is 0
# Read register 0x10BC, reply is 0x1234xxxx, where "xxxx" is the channel state
# Read register 0x1010, reply is 0

Sysclk LWLA1016/Protocol

2015-07-04T18:49:11Z

Danielk: Add detail on 0x10B8 polling

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read ??? ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed (?) length of 4 words (8 bytes).

==== Response ====

The response to the command as sent by the vendor software consists of 8 words (16 bytes).

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034

=== Device State Polling ===

# Read register 0x10B8, reply is 0x10 in timing-state mode, or 0 in normal mode
# Read register 0x10B0, reply is 0
# Read register 0x1070, reply is 0
# Read register 0x10BC, reply is 0x1234xxxx, where "xxxx" is the channel state
# Read register 0x1010, reply is 0

Sysclk LWLA1016/Protocol

2015-07-04T18:23:41Z

Danielk: Add info on device state polling

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read ??? ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed (?) length of 4 words (8 bytes).

==== Response ====

The response to the command as sent by the vendor software consists of 8 words (16 bytes).

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034

=== Device State Polling ===

# Read register 0x10B8, reply is 0x10
# Read register 0x10B0, reply is 0
# Read register 0x1070, reply is 0
# Read register 0x10BC, reply is 0x1234xxxx, where "xxxx" is the channel state
# Read register 0x1010, reply is 0

Sysclk LWLA1016/Protocol

2015-07-04T18:17:11Z

Danielk: Elaborate on the 6 bitstreams

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

There are six different FPGA bitstreams for the various LA modes: 3 frequency modes times 2 compression modes. In the vendor's terminology, "Timing-State" is the mode with compression enabled and "Normal" is the mode without compression.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read ??? ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed (?) length of 4 words (8 bytes).

==== Response ====

The response to the command as sent by the vendor software consists of 8 words (16 bytes).

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034
## Read register 0x10B8, reply is 0x10
## Read register 0x10B0, reply is 0
## Read register 0x1070, reply is 0
## Read register 0x10BC, reply is 0x12340000
## Read register 0x1010, reply is 0
## Read register 0x10B8, reply is 0x10
## ...

Sysclk LWLA1016/Protocol

2015-07-04T16:44:21Z

Danielk: Expand on reg 10BC

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
!Description
|-
| 1010
| ???
|
|-
| 1070
| ???
|
|-
| 107C
| ???
|
|-
| 10B0
| ???
|
|-
| 10B4
| ???
|
|-
| 10B8
| ???
|
|-
| 10BC
| 0x1234xxxx
| The lower 16 bit appear to be the live channel state
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read ??? ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed (?) length of 4 words (8 bytes).

==== Response ====

The response to the command as sent by the vendor software consists of 8 words (16 bytes).

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034
## Read register 0x10B8, reply is 0x10
## Read register 0x10B0, reply is 0
## Read register 0x1070, reply is 0
## Read register 0x10BC, reply is 0x12340000
## Read register 0x1010, reply is 0
## Read register 0x10B8, reply is 0x10
## ...

Sysclk LWLA1016/Protocol

2015-07-02T17:59:28Z

Danielk: Mention command 5

The basic structure of the SysClk LWLA1016 protocol is similar to the [[Sysclk LWLA1034/Protocol]]. As one would expect, it looks very much like an earlier iteration of the LWLA1034 protocol. It appears to lack the specialized commands the LWLA1034 has for reading memory and capture setup/status. Most of the functionality seems to be implemented on top of basic register reads and writes, using the same commands as the LWLA1034 for those.

== FPGA Configuration ==

As with the LWLA1034, the FPGA bitstream is loaded via bulk transfer to USB end point 4. The format seems to be exactly the same, too.

The Windows software ships four separate executables: One for running with 16 channels at up to 100 MSps, one for 8 channels at up to 200 MSps, and one for 8 channels at 250 MSps. A fourth executable runs the LWLA1016 in frequency counter mode. Each of the executables downloads its own bitstream to the FPGA.

=== Application Behavior ===

The vendor software transfers a new bitstream to the FPGA
# on application start,
# ... (TODO).

Selecting specific device configurations may require downloading other bitstream variants to the device. TODO: Make sure all modes are covered.

=== Firmware Extraction ===

The FPGA bitstreams are stored in RBF (Raw Binary File) format, as with the LWLA1034. The bitstreams can be extracted from various DLLs installed with the Windows software (an extraction tool will be provided until we get permission to distribute the firmware). Unfortunately, unlike with the LWLA1034, the LWLA1016 firmware cannot be easily extracted from the installer executable without installing the software first.

== Control Commands ==

As with the LWLA1034, control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

For the most part, the LWLA1016 protocol seems to consist of basic register read and write commands. Unlike with the LWLA1034, it looks like capture setup, capture status polling and reading from memory are implemented on top of simple register reads and writes.

=== Command 0001: Read Register ===

Apparently identical to command 1 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1010
| ???
|-
| 1070
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0002: Write Register ===

Apparently identical to command 2 in the LWLA1034 protocol.

==== Registers ====

Some of the register addresses appearing in the protocol also occur in the LWLA1034 protocol, although it seems that their purpose may not be the same. Other registers appear to be specific to the LWLA1016.

{| border="0" style="font-size: smaller;" class="sigroktable"
!Address
!Value
|-
| 1000
| ???
|-
| 1010
| ???
|-
| 107C
| ???
|-
| 10B0
| ???
|-
| 10B4
| ???
|-
| 10B8
| ???
|-
| 10BC
| ???
|}

=== Command 0003: Read ??? ===

This command reads something from the device. It does not occur in the LWLA1034 protocol.

==== Command ====

Fixed (?) length of 4 words (8 bytes).

==== Response ====

The response to the command as sent by the vendor software consists of 8 words (16 bytes).

=== Command 0005: Write ??? ===

This command appears to have the same format and function as command 5 sent by the original LWLA1034 firmware. That means we can probably ignore it, just as with the LWLA1034.

==== Command ====

Fixed length of 33 words (66 bytes).

== Task Recipes ==

This section lists the commands issued by the software to perform a particular task.

=== Initialization ===

# Acquire control of USB device and select configuration 1
# Send FPGA bitstream to EP 4 via bulk transfer
# Initial register activity:
## Read register 0x10B4, expected reply is 0x12345678
## Read register 0x10B4 (again), expected reply is 0x12345678
## Send command 5, which seems to have the same format and payload as with the LWLA1034
## Read register 0x10B8, reply is 0x10
## Read register 0x10B0, reply is 0
## Read register 0x1070, reply is 0
## Read register 0x10BC, reply is 0x12340000
## Read register 0x1010, reply is 0
## Read register 0x10B8, reply is 0x10
## ...

Sysclk LWLA1016/Protocol

2015-07-02T17:45:27Z

Danielk: Begin task recipes section

Protocol decoder HOWTO

2015-06-29T20:37:42Z

Danielk: Hint on enums in Python

This page serves as a quick-start guide for people who want to write their own [[libsigrokdecode]] protocol decoders ([[Protocol decoders|PDs]]).

It is '''not''' intended to replace the [[Protocol decoder API]] page, but rather to give a short overview/tutorial and some tips.

== Introduction ==

Protocol decoders are written entirely in Python (>= 3.0).

== Files ==

Every protocol decoder is a Python module and has its own subdirectory in libsigrokdecode's '''[http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders decoders]''' directory.

This is a minimalistic example of how a protocol decoder looks like, in this case the '''[[Protocol_decoder:I2c|i2c]]''' decoder (license header, comments, and some other parts omitted).

'''Note''': Do not start new protocol decoders by copying code from here. Instead, it's recommended to select an already existing decoder in the source code which is similar to the one you plan to write, and copy that as a starting point.

=== __init__.py ===


<source lang="python">
'''
I²C (Inter-Integrated Circuit) is a bidirectional, multi-master
bus using two signals (SCL = serial clock line, SDA = serial data line).

<Insert notes and hints for the user here>
'''

from .pd import Decoder
</source>


This is a standard Python file, required in every Python module. It contains a module-level docstring, which is accessible by frontends via the [http://sigrok.org/api/libsigrokdecode/unstable/index.html libsigrokdecode API]. It should contain a (very) short description of what the protocol (in this case [[Protocol_decoder:I2c|I²C]]) is about, and some notes and hints for the user of this protocol decoder (which can be shown in GUIs when the user selects/browses different PDs).

This docstring should '''not''' contain the full, extensive protocol description. Instead, the per-PD wiki page should be used for protocol description, photos of devices or photos of example acquisition setups, and so on. Each decoder has one unique wiki page at the URL '''<nowiki>http://sigrok.org/wiki/Protocol_decoder:<pd></nowiki>''', where '''<pd>''' is the Python module name of the decoder ('''i2c''' in this case). Some examples for such per-PD wiki pages: [[Protocol_decoder:Uart|UART]], [[Protocol_decoder:Pan1321|PAN1321]], [[Protocol_decoder:Mx25lxx05d|MX25Lxx05D]], [[Protocol_decoder:Dcf77|DCF77]].

The "'''from .pd import Decoder'''" line will make sure the code from '''pd.py''' gets properly imported when this module is used.

=== pd.py ===


<source lang="python">
import sigrokdecode as srd

class Decoder(srd.Decoder):
api_version = 2
id = 'i2c'
name = 'I²C'
longname = 'Inter-Integrated Circuit'
desc = 'Two-wire, multi-master, serial bus.'
license = 'gplv2+'
inputs = ['logic']
outputs = ['i2c']
channels = (
{'id': 'scl', 'name': 'SCL', 'desc': 'Serial clock line'},
{'id': 'sda', 'name': 'SDA', 'desc': 'Serial data line'},
)
optional_channels = ()
options = (
{'id': 'address_format', 'desc': 'Displayed slave address format',
'default': 'shifted', 'values': ('shifted', 'unshifted')},
)
annotations = (
('start', 'Start condition'),
('repeat-start', 'Repeat start condition'),
('stop', 'Stop condition'),
('ack', 'ACK'),
('nack', 'NACK'),
('bit', 'Data/address bit'),
('address-read', 'Address read'),
('address-write', 'Address write'),
('data-read', 'Data read'),
('data-write', 'Data write'),
('warnings', 'Human-readable warnings'),
)
annotation_rows = (
('bits', 'Bits', (5,)),
('addr-data', 'Address/Data', (0, 1, 2, 3, 4, 6, 7, 8, 9)),
('warnings', 'Warnings', (10,)),
)

def __init__(self, **kwargs):
self.state = 'FIND START'
# And various other variable initializations...

def metadata(self, key, value):
if key == srd.SRD_CONF_SAMPLERATE:
self.samplerate = value

def start(self):
self.out_ann = self.register(srd.OUTPUT_ANN)

def decode(self, ss, es, data):
for self.samplenum, (scl, sda) in data:
# Decode the samples.
</source>


The recommended name for the actual decoder file is '''pd.py'''. This file contains some meta information about the decoder, and the actual code itself, mostly in the '''decode()''' method.

If needed, large unwieldy lists or similar things can also be factored out into another *.py file (examples: [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/midi midi], [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/z80 z80]).

== Copyright and license ==

Every protocol decoder '''must''' come with source code in the form of '''*.py''' files. No pre-compiled code should be present, Python or otherwise. The PD must not use any helpers that are not provided as source code under the same license as the PD itself.

The '''<tt>Decoder</tt>''' class must have a license declaration (see above), stating the license under which all the contents in the decoder's directory are provided. This is usually <tt>'gplv2+'</tt> or <tt>'gplv3+'</tt>, whichever you prefer. In either case, the decoder license must be compatible with the [[libsigrokdecode]] license (which is "GPL, version 3 or later").

== <tt>channels</tt> & <tt>optional_channels</tt> ==

The following excerpt from the [[Protocol_decoder:spi|SPI]] PD shows how to use '''<tt>channels</tt>''' and '''<tt>optional_channels</tt>'''. To decode SPI, the clock signal is always needed, the chip-select signal is optional and only used when provided. To give the user the flexibility to provide only one of the MOSI/MISO signals, they are both also defined as optional:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'spi'
...
channels = (
{'id': 'clk', 'name': 'CLK', 'desc': 'Clock'},
)
optional_channels = (
{'id': 'miso', 'name': 'MISO', 'desc': 'Master in, slave out'},
{'id': 'mosi', 'name': 'MOSI', 'desc': 'Master out, slave in'},
{'id': 'cs', 'name': 'CS#', 'desc': 'Chip-select'},
)
</source>


'''<tt>data</tt>''', the argument of the decoder's [[Protocol decoder API#decode-function|'''<tt>decode()</tt>''']] function that contains the data to decode, is a list of tuples. These tuples contain the (absolute) number of the sample and the data at that sample. To process all samples, the SPI decoder loops over '''<tt>data</tt>''' like this:


<source lang="python">
def decode(self, ss, es, data):
...
for (self.samplenum, pins) in data:
</source>


'''<tt>channels</tt>''' and '''<tt>optional_channels</tt>''' contain in total four channels, therefore the second member of the tuple is an object of Python's [https://docs.python.org/3/library/stdtypes.html#typebytes '''<tt>bytes</tt>'''] class containing 4 bytes, one for each channel. The decoder unpacks the bytes into the variables '''<tt>clk</tt>''', '''<tt>miso</tt>''', '''<tt>mosi</tt>''', and '''<tt>cs</tt>''' as shown below.

Then, it checks for the optional channels, if their value is either 0 or 1. If it is not, that optional channel is not provided to the decoder. In the case that neither of them is supplied, an exception is raised:


<source lang="python">
(clk, miso, mosi, cs) = pins
self.have_miso = (miso in (0, 1))
self.have_mosi = (mosi in (0, 1))
self.have_cs = (cs in (0, 1))

# Either MISO or MOSI (but not both) can be omitted.
if not (self.have_miso or self.have_mosi):
raise ChannelError('Either MISO or MOSI (or both) pins required.')
</source>


== <tt>annotations</tt> & <tt>annotation_rows</tt> ==

To make the relation between the '''<tt>annotations</tt>''' and the '''<tt>annotation_rows</tt>''' members of a decoder object more clear, take a look at how the [[Protocol_decoder:Ir_nec|ir_nec]] PD uses them:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'ir_nec'
...
annotations = (
('bit', 'Bit'),
('agc-pulse', 'AGC pulse'),
('longpause', 'Long pause'),
('shortpause', 'Short pause'),
('stop-bit', 'Stop bit'),
('leader-code', 'Leader code'),
('addr', 'Address'),
('addr-inv', 'Address#'),
('cmd', 'Command'),
('cmd-inv', 'Command#'),
('repeat-code', 'Repeat code'),
('remote', 'Remote'),
('warnings', 'Warnings'),
)
annotation_rows = (
('bits', 'Bits', (0, 1, 2, 3, 4)),
('fields', 'Fields', (5, 6, 7, 8, 9, 10)),
('remote', 'Remote', (11,)),
('warnings', 'Warnings', (12,)),
)
</source>


It groups the first five annotation types together into the '''<tt>bits</tt>''' row and the next six into the '''<tt>fields</tt>''' row. The rows '''<tt>remote</tt>''' and '''<tt>warnings</tt>''' both only contain one annotation type.

Without '''<tt>annotation_rows</tt>''', [[PulseView]] would have to put each annotation type in its own row (which is unhandy if the decoder has many annotations) or it would have to put them all on the same row (which would result in unreadable output due to overlaps). But because of the '''<tt>annotation_rows</tt>''', the output of the [[Protocol_decoder:Ir_nec|ir_nec]] decoder is grouped together as shown in the following picture (note how different annotation types, distinguishable by their different colors, share the same row):

[[File:Pv example ir nec cropped.png]]

== Random notes, tips and tricks ==

* You should usually only use '''raise''' in a protocol decoder to raise exceptions in cases which are a clear bug in how the protocol decoder is invoked (e.g. if no samplerate was provided for a PD which needs the samplerate, or if some of the required channels were not provided by the user, and so on).
* A simple way to check whether an optional PD channel was supplied (by the frontend/user) in this run is:
<source lang="python">
if pin in (0, 1):
do_stuff()
</source>
* A simple and fast way to calculate a parity (i.e., count the number of 1 bits) over a number (0x55 in this example) is:
<source lang="python">
ones = bin(0x55).count('1')
</source>
* A simple function to convert a BCD number (max. 8 bits) to an integer is:
<source lang="python">
def bcd2int(b):
return (b & 0x0f) + ((b >> 4) * 10)
</source>
* An elegant way to convert a sequence of bus pins to a numeric value:
<source lang="python">
from functools import reduce

def reduce_bus(bus):
if 0xFF in bus:
return None # unassigned bus channels
else:
return reduce(lambda a, b: (a << 1) | b, reversed(bus))
</source>
* A nice way to construct method names according to e.g. protocol commands is (assuming '''cmd''' is 8, this would call the function '''self.handle_cmd_0x08'''):
<source lang="python">
fn = getattr(self, 'handle_cmd_0x%02x' % cmd);
fn(arg1, arg2, ...)
</source>
* A cheap way to deal with Python's lack of enumerations (useful for states, pin indices, annotation indices, etc.):
<source lang="python">
class Cycle:
NONE, MEMRD, MEMWR, IORD, IOWR, FETCH, INTACK = range(7)
</source>
* <div id="SIGROKDECODE_DIR"></div>You don't need to reinstall the whole libsigrokdecode project every time you make a change on your decoder, instead you can use the environment variable '''<tt>SIGROKDECODE_DIR</tt>''' to point the software to your development directory:
<source lang="bash">
$ SIGROKDECODE_DIR=/path/to/libsigrokdecode/decoders/ sigrok-cli … -P <your decoder's name>
</source>
Because this environment variable is evaluated by the libsigrokdecode code itself, it can be used for any program that uses the library, for example when calling [[PulseView]] or the '''<tt>pdtest</tt>''' unit test utility from the [[sigrok-test]] repository.

== Submitting your decoder ==

When you've finished your decoder and everything is working nicely, please contribute the decoder to the sigrok project so that other people can benefit from it (and test it, improve upon it, and so on).

* Send the decoder (preferrably as a patch against the current git HEAD of [[libsigrokdecode]]) to the [https://lists.sourceforge.net/lists/listinfo/sigrok-devel sigrok-devel] mailing list, and/or tell us the location of your git repository containing the decoder (on the '''#sigrok''' IRC channel on FreeNode).
* Please also send us a few example data files (*.sr) and a small README to go with your decoder. We'll need these in order to properly review and test your decoder. Preferrably these files should also come as patches against the latest git HEAD of the [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree sigrok-dumps] repository. See [[Example dumps]] for details.
* Finally, please also consider adding a few "unit tests" for your decoder in the [http://sigrok.org/gitweb/?p=sigrok-test.git;a=tree sigrok-test] repository. These test will automatically run the decoder against various input files specified in '''test.conf''' and check whether the expected output is produced (examples: [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/rfm12/test.conf rfm12], [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/nrf24l01/test.conf nrf24l01]). This allows us to notice and fix any regressions in the decoder and/or the [[libsigrokdecode]] backend that may arise over time.

Thanks a lot!

[[Category:APIs]]

Protocol decoder HOWTO

2015-06-29T20:33:16Z

Danielk: Add hint on obtaining bus values

This page serves as a quick-start guide for people who want to write their own [[libsigrokdecode]] protocol decoders ([[Protocol decoders|PDs]]).

It is '''not''' intended to replace the [[Protocol decoder API]] page, but rather to give a short overview/tutorial and some tips.

== Introduction ==

Protocol decoders are written entirely in Python (>= 3.0).

== Files ==

Every protocol decoder is a Python module and has its own subdirectory in libsigrokdecode's '''[http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders decoders]''' directory.

This is a minimalistic example of how a protocol decoder looks like, in this case the '''[[Protocol_decoder:I2c|i2c]]''' decoder (license header, comments, and some other parts omitted).

'''Note''': Do not start new protocol decoders by copying code from here. Instead, it's recommended to select an already existing decoder in the source code which is similar to the one you plan to write, and copy that as a starting point.

=== __init__.py ===


<source lang="python">
'''
I²C (Inter-Integrated Circuit) is a bidirectional, multi-master
bus using two signals (SCL = serial clock line, SDA = serial data line).

<Insert notes and hints for the user here>
'''

from .pd import Decoder
</source>


This is a standard Python file, required in every Python module. It contains a module-level docstring, which is accessible by frontends via the [http://sigrok.org/api/libsigrokdecode/unstable/index.html libsigrokdecode API]. It should contain a (very) short description of what the protocol (in this case [[Protocol_decoder:I2c|I²C]]) is about, and some notes and hints for the user of this protocol decoder (which can be shown in GUIs when the user selects/browses different PDs).

This docstring should '''not''' contain the full, extensive protocol description. Instead, the per-PD wiki page should be used for protocol description, photos of devices or photos of example acquisition setups, and so on. Each decoder has one unique wiki page at the URL '''<nowiki>http://sigrok.org/wiki/Protocol_decoder:<pd></nowiki>''', where '''<pd>''' is the Python module name of the decoder ('''i2c''' in this case). Some examples for such per-PD wiki pages: [[Protocol_decoder:Uart|UART]], [[Protocol_decoder:Pan1321|PAN1321]], [[Protocol_decoder:Mx25lxx05d|MX25Lxx05D]], [[Protocol_decoder:Dcf77|DCF77]].

The "'''from .pd import Decoder'''" line will make sure the code from '''pd.py''' gets properly imported when this module is used.

=== pd.py ===


<source lang="python">
import sigrokdecode as srd

class Decoder(srd.Decoder):
api_version = 2
id = 'i2c'
name = 'I²C'
longname = 'Inter-Integrated Circuit'
desc = 'Two-wire, multi-master, serial bus.'
license = 'gplv2+'
inputs = ['logic']
outputs = ['i2c']
channels = (
{'id': 'scl', 'name': 'SCL', 'desc': 'Serial clock line'},
{'id': 'sda', 'name': 'SDA', 'desc': 'Serial data line'},
)
optional_channels = ()
options = (
{'id': 'address_format', 'desc': 'Displayed slave address format',
'default': 'shifted', 'values': ('shifted', 'unshifted')},
)
annotations = (
('start', 'Start condition'),
('repeat-start', 'Repeat start condition'),
('stop', 'Stop condition'),
('ack', 'ACK'),
('nack', 'NACK'),
('bit', 'Data/address bit'),
('address-read', 'Address read'),
('address-write', 'Address write'),
('data-read', 'Data read'),
('data-write', 'Data write'),
('warnings', 'Human-readable warnings'),
)
annotation_rows = (
('bits', 'Bits', (5,)),
('addr-data', 'Address/Data', (0, 1, 2, 3, 4, 6, 7, 8, 9)),
('warnings', 'Warnings', (10,)),
)

def __init__(self, **kwargs):
self.state = 'FIND START'
# And various other variable initializations...

def metadata(self, key, value):
if key == srd.SRD_CONF_SAMPLERATE:
self.samplerate = value

def start(self):
self.out_ann = self.register(srd.OUTPUT_ANN)

def decode(self, ss, es, data):
for self.samplenum, (scl, sda) in data:
# Decode the samples.
</source>


The recommended name for the actual decoder file is '''pd.py'''. This file contains some meta information about the decoder, and the actual code itself, mostly in the '''decode()''' method.

If needed, large unwieldy lists or similar things can also be factored out into another *.py file (examples: [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/midi midi], [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=tree;f=decoders/z80 z80]).

== Copyright and license ==

Every protocol decoder '''must''' come with source code in the form of '''*.py''' files. No pre-compiled code should be present, Python or otherwise. The PD must not use any helpers that are not provided as source code under the same license as the PD itself.

The '''<tt>Decoder</tt>''' class must have a license declaration (see above), stating the license under which all the contents in the decoder's directory are provided. This is usually <tt>'gplv2+'</tt> or <tt>'gplv3+'</tt>, whichever you prefer. In either case, the decoder license must be compatible with the [[libsigrokdecode]] license (which is "GPL, version 3 or later").

== <tt>channels</tt> & <tt>optional_channels</tt> ==

The following excerpt from the [[Protocol_decoder:spi|SPI]] PD shows how to use '''<tt>channels</tt>''' and '''<tt>optional_channels</tt>'''. To decode SPI, the clock signal is always needed, the chip-select signal is optional and only used when provided. To give the user the flexibility to provide only one of the MOSI/MISO signals, they are both also defined as optional:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'spi'
...
channels = (
{'id': 'clk', 'name': 'CLK', 'desc': 'Clock'},
)
optional_channels = (
{'id': 'miso', 'name': 'MISO', 'desc': 'Master in, slave out'},
{'id': 'mosi', 'name': 'MOSI', 'desc': 'Master out, slave in'},
{'id': 'cs', 'name': 'CS#', 'desc': 'Chip-select'},
)
</source>


'''<tt>data</tt>''', the argument of the decoder's [[Protocol decoder API#decode-function|'''<tt>decode()</tt>''']] function that contains the data to decode, is a list of tuples. These tuples contain the (absolute) number of the sample and the data at that sample. To process all samples, the SPI decoder loops over '''<tt>data</tt>''' like this:


<source lang="python">
def decode(self, ss, es, data):
...
for (self.samplenum, pins) in data:
</source>


'''<tt>channels</tt>''' and '''<tt>optional_channels</tt>''' contain in total four channels, therefore the second member of the tuple is an object of Python's [https://docs.python.org/3/library/stdtypes.html#typebytes '''<tt>bytes</tt>'''] class containing 4 bytes, one for each channel. The decoder unpacks the bytes into the variables '''<tt>clk</tt>''', '''<tt>miso</tt>''', '''<tt>mosi</tt>''', and '''<tt>cs</tt>''' as shown below.

Then, it checks for the optional channels, if their value is either 0 or 1. If it is not, that optional channel is not provided to the decoder. In the case that neither of them is supplied, an exception is raised:


<source lang="python">
(clk, miso, mosi, cs) = pins
self.have_miso = (miso in (0, 1))
self.have_mosi = (mosi in (0, 1))
self.have_cs = (cs in (0, 1))

# Either MISO or MOSI (but not both) can be omitted.
if not (self.have_miso or self.have_mosi):
raise ChannelError('Either MISO or MOSI (or both) pins required.')
</source>


== <tt>annotations</tt> & <tt>annotation_rows</tt> ==

To make the relation between the '''<tt>annotations</tt>''' and the '''<tt>annotation_rows</tt>''' members of a decoder object more clear, take a look at how the [[Protocol_decoder:Ir_nec|ir_nec]] PD uses them:


<source lang="python">
class Decoder(srd.Decoder):
...
id = 'ir_nec'
...
annotations = (
('bit', 'Bit'),
('agc-pulse', 'AGC pulse'),
('longpause', 'Long pause'),
('shortpause', 'Short pause'),
('stop-bit', 'Stop bit'),
('leader-code', 'Leader code'),
('addr', 'Address'),
('addr-inv', 'Address#'),
('cmd', 'Command'),
('cmd-inv', 'Command#'),
('repeat-code', 'Repeat code'),
('remote', 'Remote'),
('warnings', 'Warnings'),
)
annotation_rows = (
('bits', 'Bits', (0, 1, 2, 3, 4)),
('fields', 'Fields', (5, 6, 7, 8, 9, 10)),
('remote', 'Remote', (11,)),
('warnings', 'Warnings', (12,)),
)
</source>


It groups the first five annotation types together into the '''<tt>bits</tt>''' row and the next six into the '''<tt>fields</tt>''' row. The rows '''<tt>remote</tt>''' and '''<tt>warnings</tt>''' both only contain one annotation type.

Without '''<tt>annotation_rows</tt>''', [[PulseView]] would have to put each annotation type in its own row (which is unhandy if the decoder has many annotations) or it would have to put them all on the same row (which would result in unreadable output due to overlaps). But because of the '''<tt>annotation_rows</tt>''', the output of the [[Protocol_decoder:Ir_nec|ir_nec]] decoder is grouped together as shown in the following picture (note how different annotation types, distinguishable by their different colors, share the same row):

[[File:Pv example ir nec cropped.png]]

== Random notes, tips and tricks ==

* You should usually only use '''raise''' in a protocol decoder to raise exceptions in cases which are a clear bug in how the protocol decoder is invoked (e.g. if no samplerate was provided for a PD which needs the samplerate, or if some of the required channels were not provided by the user, and so on).
* A simple way to check whether an optional PD channel was supplied (by the frontend/user) in this run is:
<source lang="python">
if pin in (0, 1):
do_stuff()
</source>
* A simple and fast way to calculate a parity (i.e., count the number of 1 bits) over a number (0x55 in this example) is:
<source lang="python">
ones = bin(0x55).count('1')
</source>
* A simple function to convert a BCD number (max. 8 bits) to an integer is:
<source lang="python">
def bcd2int(b):
return (b & 0x0f) + ((b >> 4) * 10)
</source>
* An elegant way to convert a sequence of bus pins to a numeric value:
<source lang="python">
from functools import reduce

def reduce_bus(bus):
if 0xFF in bus:
return None # unassigned bus channels
else:
return reduce(lambda a, b: (a << 1) | b, reversed(bus))
</source>
* A nice way to construct method names according to e.g. protocol commands is (assuming '''cmd''' is 8, this would call the function '''self.handle_cmd_0x08'''):
<source lang="python">
fn = getattr(self, 'handle_cmd_0x%02x' % cmd);
fn(arg1, arg2, ...)
</source>
* <div id="SIGROKDECODE_DIR"></div>You don't need to reinstall the whole libsigrokdecode project every time you make a change on your decoder, instead you can use the environment variable '''<tt>SIGROKDECODE_DIR</tt>''' to point the software to your development directory:
<source lang="bash">
$ SIGROKDECODE_DIR=/path/to/libsigrokdecode/decoders/ sigrok-cli … -P <your decoder's name>
</source>
Because this environment variable is evaluated by the libsigrokdecode code itself, it can be used for any program that uses the library, for example when calling [[PulseView]] or the '''<tt>pdtest</tt>''' unit test utility from the [[sigrok-test]] repository.

== Submitting your decoder ==

When you've finished your decoder and everything is working nicely, please contribute the decoder to the sigrok project so that other people can benefit from it (and test it, improve upon it, and so on).

* Send the decoder (preferrably as a patch against the current git HEAD of [[libsigrokdecode]]) to the [https://lists.sourceforge.net/lists/listinfo/sigrok-devel sigrok-devel] mailing list, and/or tell us the location of your git repository containing the decoder (on the '''#sigrok''' IRC channel on FreeNode).
* Please also send us a few example data files (*.sr) and a small README to go with your decoder. We'll need these in order to properly review and test your decoder. Preferrably these files should also come as patches against the latest git HEAD of the [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree sigrok-dumps] repository. See [[Example dumps]] for details.
* Finally, please also consider adding a few "unit tests" for your decoder in the [http://sigrok.org/gitweb/?p=sigrok-test.git;a=tree sigrok-test] repository. These test will automatically run the decoder against various input files specified in '''test.conf''' and check whether the expected output is produced (examples: [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/rfm12/test.conf rfm12], [http://sigrok.org/gitweb/?p=sigrok-test.git;a=blob;f=decoder/test/nrf24l01/test.conf nrf24l01]). This allows us to notice and fix any regressions in the decoder and/or the [[libsigrokdecode]] backend that may arise over time.

Thanks a lot!

[[Category:APIs]]

Sysclk LWLA1016/Protocol

2015-06-29T20:14:54Z

Danielk: Add detail on FPGA bitstreams

Protocol decoder:Z80

2014-03-02T12:23:38Z

Danielk: License is GPL 3 or later

{{Infobox protocol decoder
| id = z80
| name = Z80
| description = Zilog Z80 microprocessor disassembly
| status = supported
| license = GPLv3+
| source_code_dir = z80
| image = [[File:Z80 decoder example.png|250px]]
| input = logic
| output = z80
| probes = D0–D7, /M1, /RD, /WR
| optional_probes = /MREQ, /IORQ, A0–A15
}}

The '''z80''' protocol decoder disassembles the instruction stream of a Zilog Z80 microprocessor.

== Hardware ==

=== KC 85/4 ===

The [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=z80/kc85 z80/kc85] directory in sigrok-dumps contains a set of example bus captures of the Z80-based [http://www.mpm-kc85.com/ KC 85/4] computer.

The logic analyzer used was a [[Sysclk LWLA1034]].

== Protocol ==

The data bus lines plus the control signals /M1, /RD and /WR are sufficient to display full disassembly. Optionally, the address bus lines and the control signals /MREQ and /IORQ may also be provided.

== Resources ==

[[Category:Protocol decoder]]

User:Danielk

2014-03-02T11:48:01Z

Danielk: LWLA1034 is done, switch TODO to LWLA1016

== Hardware TODO list ==

* [[Sysclk LWLA1016]]

Protocol decoder:Z80

2014-02-28T23:01:40Z

Danielk: Limit image width to 250px

{{Infobox protocol decoder
| id = z80
| name = Z80
| description = Zilog Z80 microprocessor disassembly
| status = supported
| license = GPLv2+
| source_code_dir = z80
| image = [[File:Z80 decoder example.png|250px]]
| input = logic
| output = z80
| probes = D0–D7, /M1, /RD, /WR
| optional_probes = /MREQ, /IORQ, A0–A15
}}

The '''z80''' protocol decoder disassembles the instruction stream of a Zilog Z80 microprocessor.

== Hardware ==

=== KC 85/4 ===

The [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=z80/kc85 z80/kc85] directory in sigrok-dumps contains a set of example bus captures of the Z80-based [http://www.mpm-kc85.com/ KC 85/4] computer.

The logic analyzer used was a [[Sysclk LWLA1034]].

== Protocol ==

The data bus lines plus the control signals /M1, /RD and /WR are sufficient to display full disassembly. Optionally, the address bus lines and the control signals /MREQ and /IORQ may also be provided.

== Resources ==

[[Category:Protocol decoder]]

File:Z80 decoder example.png

2014-02-28T22:59:33Z

Danielk: Sample disassembly by the Z80 decoder in PulseView

== Summary ==
Sample disassembly by the Z80 decoder in PulseView
== Licensing ==
{{CC-BY-SA-3.0}}

Protocol decoder:Z80

2014-02-28T22:37:55Z

Danielk: Create initial Z80 decoder page

{{Infobox protocol decoder
| id = z80
| name = Z80
| description = Zilog Z80 microprocessor disassembly
| status = supported
| license = GPLv2+
| source_code_dir = z80
| image = [[File:Z80 decoder example.png]]
| input = logic
| output = z80
| probes = D0–D7, /M1, /RD, /WR
| optional_probes = /MREQ, /IORQ, A0–A15
}}

The '''z80''' protocol decoder disassembles the instruction stream of a Zilog Z80 microprocessor.

== Hardware ==

=== KC 85/4 ===

The [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=z80/kc85 z80/kc85] directory in sigrok-dumps contains a set of example bus captures of the Z80-based [http://www.mpm-kc85.com/ KC 85/4] computer.

The logic analyzer used was a [[Sysclk LWLA1034]].

== Protocol ==

The data bus lines plus the control signals /M1, /RD and /WR are sufficient to display full disassembly. Optionally, the address bus lines and the control signals /MREQ and /IORQ may also be provided.

== Resources ==

[[Category:Protocol decoder]]

Sysclk LWLA1034

2014-02-28T22:27:36Z

Danielk: Link to correct item on AliExpress

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1034 mugshot.png|180px]]
| name = Sysclk LWLA1034
| status = supported
| source_code_dir = sysclk-lwla
| channels = 34
| samplerate = 125MHz (max)
| samplerate_state = ?
| triggers = 34 + extern
| voltages = 0-5V
| threshold = ?
| memory = 256Kbit/channel
| compression = RLE
| website = [http://www.aliexpress.com/item/free-shipping-New-arrival-Powerful-100MHz-34-channels-LA1034-Logic-Analyzer-Timing-State-Logic-Analyzer/1227957767.html aliexpress.com]
}}

The '''Sysclk LWLA1034''' is a USB-based, 34-channel logic analyzer with up to 125MHz sampling rate.

See [[Sysclk LWLA1034/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

* Altera EP2C5Q208C8N (Cyclone II) FPGA
* Cypress CY7C68013A-56 (FX2) USB interface chip
* Cypress 256k×36 SRAM (likely a [http://www.cypress.com/?mpn=CY7C1361C-133AXC CY7C1361C-133AXC] or similar)
* STC15F104E 8051-based microcontroller

The not-installed 10-pin connector between the USB socket and the large capacitor seems to connect to the JTAG pins of the FPGA.

== Photos ==

<gallery>
File:Sysclk lwla1034 device top.jpg
File:Sysclk lwla1034 device bottom.jpg
File:Sysclk lwla1034 device connector.jpg
File:Sysclk lwla1034 device usb.jpg
File:Sysclk lwla1034 device open.jpg
File:Sysclk lwla1034 pcb top2.jpg
File:Sysclk lwla1034 pcb bottom2.jpg
File:Sysclk lwla1034 altera cyclone2.jpg
File:Sysclk lwla1034 cypress sram.jpg
File:Sysclk lwla1034 cypress fx2.jpg
File:Sysclk lwla1034 24c64n otherso8 crystal.jpg
File:Sysclk lwla1034 crystal 50mhz.jpg
File:Sysclk lwla1034 crystal 40mhz.jpg
File:Sysclk lwla1034 ams1117 33.jpg
File:Sysclk lwla1034 ams1117 12.jpg
</gallery>

(Note: The yellow/greenish markings weren't there, they're added by the photographer)

''' PCB for another device''':
<gallery>
File:Sysclk lwla1034 pcb top.jpg|PCB, top
File:Sysclk lwla1034 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1034 pcb closeup.jpg|PCB, close-up
File:Sysclk lwla1034 chip2.jpg|Cypress FX2
File:Sysclk lwla1034 chip3 removed marking.jpg|SRAM (marking removed)
</gallery>

== Software ==

[[File:Sysclk lwla1034 software.png]]

== Firmware ==

We have received permission from the vendor to distribute the FPGA bitstreams with sigrok. Thus, the bitstreams are now included in the sigrok-firmware module.

* The FX2 firmware is loaded from an EEPROM on the board, so that the final USB device descriptor is immediately available on power-up.
* Endpoint 4 is used exclusively for loading a new bitstream into the FPGA.
* Endpoint 2 is used for sending commands to the FPGA firmware, with responses (if any) coming in from endpoint 6.

Reverse engineering of the vendor's custom protocol has been completed. See [[Sysclk LWLA1034/Protocol]] for the documentation.

== Resources ==

* [http://blog.csdn.net/mcupro Mcupro blog on CSDN]

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Protocol decoders

2014-02-18T22:49:55Z

Danielk: Bump Z80 decoder progress to 80%

This is a list of '''supported protocol decoders (PDs)''' and '''decoders which we might want to write in the future''' (or users might want to contribute).

See [[Protocol decoder API]] for details on how the decoders work in sigrok, and [[Protocol decoder HOWTO]] for a quick introduction about how to write your own decoders.

== Supported protocol decoders ==

Number of currently supported protocol decoders: '''31'''.


Please do '''not''' edit this table in the wiki directly, it is automatically generated.


{| border="0" style="font-size: smaller" class="alternategrey sortable sigroktable"
|-
!Protocol
!Category
!Input IDs
!Output IDs
!Status
!Full name
!Description

{{pd|avr_isp|AVR ISP|AVR in-system programming|Protocol for in-system programming Atmel AVR MCUs.|Flash/debug|spi, logic|avr_isp|supported}}
{{pd|can|CAN|Controller Area Network|Field bus protocol for distributed realtime control.|Automotive|—|can|supported}}
{{pd|dcf77|DCF77|DCF77 time protocol|European longwave time signal (77.5kHz carrier signal).|Time signal|—|dcf77|supported}}
{{pd|ds1307|DS1307|Dallas DS1307|Realtime clock module protocol.|RTC|i2c|ds1307|supported}}
{{pd|edid|EDID|Extended Display Identification Data|Data structure describing display device capabilities.|PC|i2c|edid|supported}}
{{pd|i2cdemux|I2C demux|I2C demultiplexer|Demux I2C packets into per-slave-address streams.|Embedded|i2c|''runtime decision''|supported}}
{{pd|i2cfilter|I2C filter|I2C filter|Filter out addresses/directions in an I2C stream.|Embedded|i2c|i2c|supported}}
{{pd|i2c|I2C|Inter-Integrated Circuit|Two-wire, multi-master, serial bus.|Embedded|—|i2c|supported}}
{{pd|i2s|I2S|Integrated Interchip Sound|Serial bus for connecting digital audio devices.|Audio|—|i2s|supported}}
{{pd|jtag|JTAG|Joint Test Action Group (IEEE 1149.1)|Protocol for testing, debugging, and flashing ICs.|Flash/debug|—|jtag|supported}}
{{pd|jtag_stm32|JTAG / STM32|Joint Test Action Group / ST STM32|ST STM32-specific JTAG protocol.|Flash/debug|jtag|jtag_stm32|supported}}
{{pd|lm75|LM75|National LM75|National LM75 (and compatibles) temperature sensor protocol.|Sensors|i2c|lm75|supported}}
{{pd|lpc|LPC|Low-Pin-Count|Protocol for low-bandwidth devices on PC mainboards.|PC|—|lpc|supported}}
{{pd|maxim_ds28ea00|DS28EA00|Maxim DS28EA00 1-Wire digital thermometer|1-Wire digital thermometer with Sequence Detect and PIO.|Sensors|onewire_network|maxim_ds28ea00|supported}}
{{pd|midi|MIDI|Musical Instrument Digital Interface|Musical Instrument Digital Interface (MIDI) protocol.|Music|uart|midi|supported}}
{{pd|mlx90614|MLX90614|Melexis MLX90614|Infrared Thermometer protocol.|Sensors|i2c|mlx90614|supported}}
{{pd|mx25lxx05d|MX25Lxx05D|Macronix MX25Lxx05D|SPI (NOR) flash chip protocol.|SPI flash|spi, logic|mx25lxx05d|supported}}
{{pd|mxc6225xu|MXC6225XU|MEMSIC MXC6225XU|Digital Thermal Orientation Sensor (DTOS) protocol.|Sensors|i2c|mxc6225xu|supported}}
{{pd|nunchuk|Nunchuk|Nintendo Wii Nunchuk|Nintendo Wii Nunchuk controller protocol.|Other|i2c|nunchuk|supported}}
{{pd|onewire_link|1-Wire link layer|1-Wire serial communication bus (link layer)|Bidirectional, half-duplex, asynchronous serial bus.|Embedded|—|onewire_link|supported}}
{{pd|onewire_network|1-Wire network layer|1-Wire serial communication bus (network layer)|Bidirectional, half-duplex, asynchronous serial bus.|Embedded|onewire_link|onewire_network|supported}}
{{pd|pan1321|PAN1321|Panasonic PAN1321|Bluetooth RF module with Serial Port Profile (SPP).|Bluetooth|uart|pan1321|supported}}
{{pd|parallel|Parallel|Parallel sync bus|Generic parallel synchronous bus.|Misc|—|parallel|supported}}
{{pd|rtc8564|RTC-8564|Epson RTC-8564 JE/NB|Realtime clock module protocol.|RTC|i2c|rtc8564|supported}}
{{pd|sdcard_spi|SD card (SPI mode)|Secure Digital card (SPI mode)|Secure Digital card (SPI mode) low-level protocol.|Memory|spi|sdcard_spi|supported}}
{{pd|spi|SPI|Serial Peripheral Interface|Full-duplex, synchronous, serial bus.|Embedded|—|spi|supported}}
{{pd|tlc5620|TI TLC5620|Texas Instruments TLC5620|Texas Instruments TLC5620 8-bit quad DAC.|DAC|—|tlc5620|supported}}
{{pd|uart|UART|Universal Asynchronous Receiver/Transmitter|Asynchronous, serial bus.|Embedded|—|uart|supported}}
{{pd|usb_packet|USB packet|Universal Serial Bus (LS/FS) packet|USB (low-speed and full-speed) packet protocol.|USB|usb_signalling|usb_packet|supported}}
{{pd|usb_signalling|USB signalling|Universal Serial Bus (LS/FS) signalling|USB (low-speed and full-speed) signalling protocol.|USB|—|usb_signalling|supported}}
{{pd|xfp|XFP|10 Gigabit Small Form Factor Pluggable Module (XFP)|Data structure describing device capabilities.|Networking|i2c|xfp|supported}}

|}

== Possible candidates for future protocol decoders ==

{| border="0" style="font-size: smaller" class="alternategrey sortable sigroktable"
|-
!Protocol
!Category
!Input ID(s)
!Output ID(s)
!Status
!Description
!Comments

|-
| SA8807A
| Displays
| spi
|
| bgcolor="red" | 0%
| SPI-attached LCD. Datasheet: [http://pdf1.alldatasheet.com/datasheet-pdf/view/36922/SAMES/SA8807A.html Sames SA8807A].
|

|-
| EA eDIPTFT43-A
| Displays
| i2c
|
| bgcolor="red" | 0%
| I2C-attached LCD. Datasheet: [http://www.lcd-module.de/pdf/grafik/ediptft43-a.pdf EA eDIPTFT43-A].
|

|-
| Analog Devices AD7291
| ADC
| i2c
|
| bgcolor="red" | 0%
| I2C-attached ADC. Datasheet: [http://pdf1.alldatasheet.com/datasheet-pdf/view/318172/AD/AD7291.html Analog Devices AD7291].
|

|-
| Analog Devices ADS1258
| ADC
| spi
| ads1258
| bgcolor="orange" | 0%
| SPI-attached ADC.
| Planned (Uwe Hermann).

|-
| Microchip MCP3901
| ADC
| spi
| mcp3901
| bgcolor="orange" | 0%
| Can be controlled via a parallel protocol, or SPI, or I2C.
| Planned (Uwe Hermann).

|-
| JTAG / TMPA9xx
| Flash/debug
| jtag
| jtag_tmpa9xx
| bgcolor="red" | 0%
| Toshiba TMPA9xx specific JTAG protocol details.
|

|-
| USB transaction
| USB
| usb_packet
| usb_transaction
| bgcolor="yellow" | 30%
|
| Work in progress (Uwe Hermann).

|-
| USB transfer
| USB
| usb_transaction
| usb_transfer
| bgcolor="yellow" | 10%
|
| Work in progress (Uwe Hermann).

|-
| USB / HID
| USB
| usb_transfer
| usb_hid
| bgcolor="red" | 0%
|
|

|-
| USB / CDC
| USB
| usb_transfer
| usb_cdc
| bgcolor="red" | 0%
|
|

|-
| USB / USBTMC
| USB
| usb_transfer
| usb_usbtmc
| bgcolor="red" | 0%
|
|

|-
| Dallas DS1985
| Other
| onewire_network
|
| bgcolor="orange" | 0%
| Dallas DS1985 iButton (1-Wire) device.
| Planned (Uwe Hermann).

|-
| Microwire
| Embedded
| —
|
| bgcolor="red" | 0%
|
|

|-
| UNI/O
| Embedded
| —
|
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Synchronous_Serial_Interface SSI]
| Embedded
| —
|
| bgcolor="red" | 0%
| Synchronous Serial Interface
|

|-
| CompactFlash
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| MMC
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| Memory Stick
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| SmartMedia
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| xD-Picture Card
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| SD card (SD mode)
| Memory
| —
| sdcard_sd
| bgcolor="yellow" | 40%
|
| Work in progress (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/ISO/IEC_7816 ISO 7816]
| Smartcards
| —
|
| bgcolor="red" | 0%
|
|

|-
| FlexRay
| Automotive
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/Flexray FlexRay] is an automotive network communications protocol.
|

|-
| LIN
| Automotive
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/Local_Interconnect_Network LIN] (Local Interconnect Network) is an automotive bus standard.
|

|-
| SWD
| Flash/debug
| —
|
| bgcolor="red" | 0%
| [https://en.wikipedia.org/wiki/Joint_Test_Action_Group#Serial_Wire_Debug Serial Wire Debug]
|

|-
| AVR PDI
| Flash/debug
| —
|
| bgcolor="red" | 0%
| Atmel Program and Debug Interface (PDI) protocol.
|

|-
| AVR TPI
| Flash/debug
| —
|
| bgcolor="red" | 0%
| Atmel Tiny Programming Interface (TPI) protocol.
|

|-
| FWH
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| ISA
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| PCI
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| SMBus
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| IDE
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| SCSI
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| PS/2
| PC
| —
|
| bgcolor="orange" | 0%
|
| Planned (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/Platform_Environment_Control_Interface PECI]
| PC
| —
|
| bgcolor="red" | 0%
| Platform Environment Control Interface
|

|-
| [https://en.wikipedia.org/wiki/SVID SVID]
| PC
| —
|
| bgcolor="red" | 0%
| Serial Voltage Identification
|

|-
| AC'97
| Audio
| —
|
| bgcolor="orange" | 0%
|
| Planned (Uwe Hermann).

|-
| HD Audio
| Audio
| —
|
| bgcolor="red" | 0%
|
|

|-
| Nokia NRC17
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Sony SIRC
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-5
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-6
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-MM
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RECS80
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| [http://en.wikipedia.org/wiki/Infrared_Data_Association IrDA]
| Misc
| —
|
| bgcolor="red" | 0%
|
|

|-
| PWM
| Misc
| —
|
| bgcolor="red" | 0%
|
|

|-
| AT93C46
| EEPROM
| —
|
| bgcolor="red" | 0%
| Atmel AT93C46 serial EEPROM protocol
|

|-
| HD44780
| Displays
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/HD44780_Character_LCD HD44780 character LCD] protocol
|

|-
| 7-segment display
| Displays
| —
|
| bgcolor="red" | 0%
|
|

|-
| [[Protocol_decoder:Pcf8814|PCF8814]]
| Displays
| —
| pcf8814
| bgcolor="yellow" | 50%
| Philips PCF8814 65 x 96 pixels matrix LCD driver
| Work in progress (Uwe Hermann).

|-
| [[Protocol_decoder:Pcf8814_lcd|PCF8814 LCD]]
| Displays
| pcf8814
| pcf8814_lcd
| bgcolor="yellow" | 50%
| Philips PCF8814 65 x 96 pixels matrix LCD driver
| Work in progress (Uwe Hermann).

|-
| GPIB
| Other
| —
| gpib
| bgcolor="orange" | 0%
| [https://en.wikipedia.org/wiki/IEEE-488 General purpose interface bus] (GPIB), a.k.a. IEEE-488.1.
| Planned (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/DMX512 DMX512]
| Industrial Lighting
| —
| dmx512
| bgcolor="yellow" | 20%
| Digital MultipleX 512
| Work in progress (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/Digital_Signal_Interface DSI]
| Industrial Lighting
| —
| dsi
| bgcolor="red" | 0%
| Digital Serial Interface
|

|-
| [http://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface DALI]
| Industrial Lighting
| —
| dali
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/RDM_%28lighting%29 RDM]
| Industrial Lighting
| —
| rdm
| bgcolor="red" | 0%
|
|

|-
| PWM
| Backlight Brightness Control
| —
|
| bgcolor="orange" | 0%
|
| Planned (Matt Ranostay).

|-
| [https://en.wikipedia.org/wiki/NMEA_0183 NMEA 0183]
| GPS
| uart
| nmea0183
| bgcolor="red" | 0%
|
|

|-
| [[Protocol_decoder:Nmea2000|NMEA2000]]
| Marine
| can
| nmea2000
| bgcolor="red" | 0%
| [https://en.wikipedia.org/wiki/NMEA_2000 NMEA 2000 Wikipedia page]
|

|-
| [https://en.wikipedia.org/wiki/Digital_Command_Control DCC]
| Trains
| —
| dcc
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Train_Communication_Network MVB]
| Trains
| —
| mvb
| bgcolor="red" | 0%
| Multifunction Vehicle Bus
|

|-
| [https://en.wikipedia.org/wiki/Train_Communication_Network WTB]
| Trains
| —
| wtb
| bgcolor="red" | 0%
| Wire Train Bus
|

|-
| [https://en.wikipedia.org/wiki/C-Bus_%28protocol%29 C-Bus]
| Home automation
| —
| cbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/X10_%28industry_standard%29 X10]
| Home automation
| —
| x10
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/LonWorks LonWorks]
| Home automation
| —
| lonworks
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/S-Bus S-Bus]
| Home automation
| —
| sbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Meter-Bus M-Bus]
| Automation
| —
| mbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus RTU]
| Automation
| uart
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus ASCII]
| Automation
| uart
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus TCP]
| Automation
| ip
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Highway_Addressable_Remote_Transducer_Protocol HART protocol]
| Automation
| —
| hart
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/INTERBUS INTERBUS]
| Automation
| —
| interbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/DirectNET_Protocol DirectNET]
| Automation
| uart
| directnet
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/KNX_%28standard%29 KNX]
| Automation
| various
| knx
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Bacnet BACnet]
| Automation
|
| bacnet
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/OpenTherm OpenTherm]
| Automation
| —
| opentherm
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/EBUS_%28serial_buses%29 EBUS]
| Automation
| uart
| ebus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Attachment_Unit_Interface AUI]
| Networking
| —
| aui
| bgcolor="red" | 0%
| Attachment Unit Interface
|

|-
| [https://en.wikipedia.org/wiki/Medium_Dependent_Interface MDI]
| Networking
| —
| mdi
| bgcolor="red" | 0%
| Medium Dependent Interface
|

|-
| [https://en.wikipedia.org/wiki/Media_Independent_Interface MII]
| Networking
| —
| mii
| bgcolor="red" | 0%
| Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/Gigabit_Media_Independent_Interface#Gigabit_Media_Independent_Interface GMII]
| Networking
| —
| gmii
| bgcolor="red" | 0%
| Gigabit Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/10_Gigabit_Media_Independent_Interface#10_Gigabit_Media_Independent_Interface XGMII]
| Networking
| —
| xgmii
| bgcolor="red" | 0%
| 10 Gigabit Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/Management_Data_Input/Output MDIO]
| Networking
| —
| mdio
| bgcolor="red" | 0%
| Management Data Input/Output
|

|-
| [https://en.wikipedia.org/wiki/Wiegand_interface Wiegand]
| RFID
| —
| wiegand
| bgcolor="red" | 0%
| Wiegand interface
|

|-
| [https://en.wikipedia.org/wiki/Zilog_Z80 Z80]
| Other
| —
| z80
| bgcolor="yellow" | 80%
| Zilog Z80 CPU
| Work in progress ([[User:Danielk]])

|}

__FORCETOC__

Protocol decoders

2014-02-14T23:52:57Z

Danielk: List Z80 CPU as future decoder

This is a list of '''supported protocol decoders (PDs)''' and '''decoders which we might want to write in the future''' (or users might want to contribute).

See [[Protocol decoder API]] for details on how the decoders work in sigrok, and [[Protocol decoder HOWTO]] for a quick introduction about how to write your own decoders.

== Supported protocol decoders ==

Number of currently supported protocol decoders: '''31'''.


Please do '''not''' edit this table in the wiki directly, it is automatically generated.


{| border="0" style="font-size: smaller" class="alternategrey sortable sigroktable"
|-
!Protocol
!Category
!Input IDs
!Output IDs
!Status
!Full name
!Description

{{pd|avr_isp|AVR ISP|AVR in-system programming|Protocol for in-system programming Atmel AVR MCUs.|Flash/debug|spi, logic|avr_isp|supported}}
{{pd|can|CAN|Controller Area Network|Field bus protocol for distributed realtime control.|Automotive|—|can|supported}}
{{pd|dcf77|DCF77|DCF77 time protocol|European longwave time signal (77.5kHz carrier signal).|Time signal|—|dcf77|supported}}
{{pd|ds1307|DS1307|Dallas DS1307|Realtime clock module protocol.|RTC|i2c|ds1307|supported}}
{{pd|edid|EDID|Extended Display Identification Data|Data structure describing display device capabilities.|PC|i2c|edid|supported}}
{{pd|i2cdemux|I2C demux|I2C demultiplexer|Demux I2C packets into per-slave-address streams.|Embedded|i2c|''runtime decision''|supported}}
{{pd|i2cfilter|I2C filter|I2C filter|Filter out addresses/directions in an I2C stream.|Embedded|i2c|i2c|supported}}
{{pd|i2c|I2C|Inter-Integrated Circuit|Two-wire, multi-master, serial bus.|Embedded|—|i2c|supported}}
{{pd|i2s|I2S|Integrated Interchip Sound|Serial bus for connecting digital audio devices.|Audio|—|i2s|supported}}
{{pd|jtag|JTAG|Joint Test Action Group (IEEE 1149.1)|Protocol for testing, debugging, and flashing ICs.|Flash/debug|—|jtag|supported}}
{{pd|jtag_stm32|JTAG / STM32|Joint Test Action Group / ST STM32|ST STM32-specific JTAG protocol.|Flash/debug|jtag|jtag_stm32|supported}}
{{pd|lm75|LM75|National LM75|National LM75 (and compatibles) temperature sensor protocol.|Sensors|i2c|lm75|supported}}
{{pd|lpc|LPC|Low-Pin-Count|Protocol for low-bandwidth devices on PC mainboards.|PC|—|lpc|supported}}
{{pd|maxim_ds28ea00|DS28EA00|Maxim DS28EA00 1-Wire digital thermometer|1-Wire digital thermometer with Sequence Detect and PIO.|Sensors|onewire_network|maxim_ds28ea00|supported}}
{{pd|midi|MIDI|Musical Instrument Digital Interface|Musical Instrument Digital Interface (MIDI) protocol.|Music|uart|midi|supported}}
{{pd|mlx90614|MLX90614|Melexis MLX90614|Infrared Thermometer protocol.|Sensors|i2c|mlx90614|supported}}
{{pd|mx25lxx05d|MX25Lxx05D|Macronix MX25Lxx05D|SPI (NOR) flash chip protocol.|SPI flash|spi, logic|mx25lxx05d|supported}}
{{pd|mxc6225xu|MXC6225XU|MEMSIC MXC6225XU|Digital Thermal Orientation Sensor (DTOS) protocol.|Sensors|i2c|mxc6225xu|supported}}
{{pd|nunchuk|Nunchuk|Nintendo Wii Nunchuk|Nintendo Wii Nunchuk controller protocol.|Other|i2c|nunchuk|supported}}
{{pd|onewire_link|1-Wire link layer|1-Wire serial communication bus (link layer)|Bidirectional, half-duplex, asynchronous serial bus.|Embedded|—|onewire_link|supported}}
{{pd|onewire_network|1-Wire network layer|1-Wire serial communication bus (network layer)|Bidirectional, half-duplex, asynchronous serial bus.|Embedded|onewire_link|onewire_network|supported}}
{{pd|pan1321|PAN1321|Panasonic PAN1321|Bluetooth RF module with Serial Port Profile (SPP).|Bluetooth|uart|pan1321|supported}}
{{pd|parallel|Parallel|Parallel sync bus|Generic parallel synchronous bus.|Misc|—|parallel|supported}}
{{pd|rtc8564|RTC-8564|Epson RTC-8564 JE/NB|Realtime clock module protocol.|RTC|i2c|rtc8564|supported}}
{{pd|sdcard_spi|SD card (SPI mode)|Secure Digital card (SPI mode)|Secure Digital card (SPI mode) low-level protocol.|Memory|spi|sdcard_spi|supported}}
{{pd|spi|SPI|Serial Peripheral Interface|Full-duplex, synchronous, serial bus.|Embedded|—|spi|supported}}
{{pd|tlc5620|TI TLC5620|Texas Instruments TLC5620|Texas Instruments TLC5620 8-bit quad DAC.|DAC|—|tlc5620|supported}}
{{pd|uart|UART|Universal Asynchronous Receiver/Transmitter|Asynchronous, serial bus.|Embedded|—|uart|supported}}
{{pd|usb_packet|USB packet|Universal Serial Bus (LS/FS) packet|USB (low-speed and full-speed) packet protocol.|USB|usb_signalling|usb_packet|supported}}
{{pd|usb_signalling|USB signalling|Universal Serial Bus (LS/FS) signalling|USB (low-speed and full-speed) signalling protocol.|USB|—|usb_signalling|supported}}
{{pd|xfp|XFP|10 Gigabit Small Form Factor Pluggable Module (XFP)|Data structure describing device capabilities.|Networking|i2c|xfp|supported}}

|}

== Possible candidates for future protocol decoders ==

{| border="0" style="font-size: smaller" class="alternategrey sortable sigroktable"
|-
!Protocol
!Category
!Input ID(s)
!Output ID(s)
!Status
!Description
!Comments

|-
| SA8807A
| Displays
| spi
|
| bgcolor="red" | 0%
| SPI-attached LCD. Datasheet: [http://pdf1.alldatasheet.com/datasheet-pdf/view/36922/SAMES/SA8807A.html Sames SA8807A].
|

|-
| EA eDIPTFT43-A
| Displays
| i2c
|
| bgcolor="red" | 0%
| I2C-attached LCD. Datasheet: [http://www.lcd-module.de/pdf/grafik/ediptft43-a.pdf EA eDIPTFT43-A].
|

|-
| Analog Devices AD7291
| ADC
| i2c
|
| bgcolor="red" | 0%
| I2C-attached ADC. Datasheet: [http://pdf1.alldatasheet.com/datasheet-pdf/view/318172/AD/AD7291.html Analog Devices AD7291].
|

|-
| Analog Devices ADS1258
| ADC
| spi
| ads1258
| bgcolor="orange" | 0%
| SPI-attached ADC.
| Planned (Uwe Hermann).

|-
| Microchip MCP3901
| ADC
| spi
| mcp3901
| bgcolor="orange" | 0%
| Can be controlled via a parallel protocol, or SPI, or I2C.
| Planned (Uwe Hermann).

|-
| JTAG / TMPA9xx
| Flash/debug
| jtag
| jtag_tmpa9xx
| bgcolor="red" | 0%
| Toshiba TMPA9xx specific JTAG protocol details.
|

|-
| USB transaction
| USB
| usb_packet
| usb_transaction
| bgcolor="yellow" | 30%
|
| Work in progress (Uwe Hermann).

|-
| USB transfer
| USB
| usb_transaction
| usb_transfer
| bgcolor="yellow" | 10%
|
| Work in progress (Uwe Hermann).

|-
| USB / HID
| USB
| usb_transfer
| usb_hid
| bgcolor="red" | 0%
|
|

|-
| USB / CDC
| USB
| usb_transfer
| usb_cdc
| bgcolor="red" | 0%
|
|

|-
| USB / USBTMC
| USB
| usb_transfer
| usb_usbtmc
| bgcolor="red" | 0%
|
|

|-
| Dallas DS1985
| Other
| onewire_network
|
| bgcolor="orange" | 0%
| Dallas DS1985 iButton (1-Wire) device.
| Planned (Uwe Hermann).

|-
| Microwire
| Embedded
| —
|
| bgcolor="red" | 0%
|
|

|-
| UNI/O
| Embedded
| —
|
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Synchronous_Serial_Interface SSI]
| Embedded
| —
|
| bgcolor="red" | 0%
| Synchronous Serial Interface
|

|-
| CompactFlash
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| MMC
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| Memory Stick
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| SmartMedia
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| xD-Picture Card
| Memory
| —
|
| bgcolor="red" | 0%
|
|

|-
| SD card (SD mode)
| Memory
| —
| sdcard_sd
| bgcolor="yellow" | 40%
|
| Work in progress (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/ISO/IEC_7816 ISO 7816]
| Smartcards
| —
|
| bgcolor="red" | 0%
|
|

|-
| FlexRay
| Automotive
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/Flexray FlexRay] is an automotive network communications protocol.
|

|-
| LIN
| Automotive
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/Local_Interconnect_Network LIN] (Local Interconnect Network) is an automotive bus standard.
|

|-
| SWD
| Flash/debug
| —
|
| bgcolor="red" | 0%
| [https://en.wikipedia.org/wiki/Joint_Test_Action_Group#Serial_Wire_Debug Serial Wire Debug]
|

|-
| AVR PDI
| Flash/debug
| —
|
| bgcolor="red" | 0%
| Atmel Program and Debug Interface (PDI) protocol.
|

|-
| AVR TPI
| Flash/debug
| —
|
| bgcolor="red" | 0%
| Atmel Tiny Programming Interface (TPI) protocol.
|

|-
| FWH
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| ISA
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| PCI
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| SMBus
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| IDE
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| SCSI
| PC
| —
|
| bgcolor="red" | 0%
|
|

|-
| PS/2
| PC
| —
|
| bgcolor="orange" | 0%
|
| Planned (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/Platform_Environment_Control_Interface PECI]
| PC
| —
|
| bgcolor="red" | 0%
| Platform Environment Control Interface
|

|-
| [https://en.wikipedia.org/wiki/SVID SVID]
| PC
| —
|
| bgcolor="red" | 0%
| Serial Voltage Identification
|

|-
| AC'97
| Audio
| —
|
| bgcolor="orange" | 0%
|
| Planned (Uwe Hermann).

|-
| HD Audio
| Audio
| —
|
| bgcolor="red" | 0%
|
|

|-
| Nokia NRC17
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Sony SIRC
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-5
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-6
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RC-MM
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| Philips RECS80
| IR
| —
|
| bgcolor="red" | 0%
|
|

|-
| [http://en.wikipedia.org/wiki/Infrared_Data_Association IrDA]
| Misc
| —
|
| bgcolor="red" | 0%
|
|

|-
| PWM
| Misc
| —
|
| bgcolor="red" | 0%
|
|

|-
| AT93C46
| EEPROM
| —
|
| bgcolor="red" | 0%
| Atmel AT93C46 serial EEPROM protocol
|

|-
| HD44780
| Displays
| —
|
| bgcolor="red" | 0%
| [http://en.wikipedia.org/wiki/HD44780_Character_LCD HD44780 character LCD] protocol
|

|-
| 7-segment display
| Displays
| —
|
| bgcolor="red" | 0%
|
|

|-
| [[Protocol_decoder:Pcf8814|PCF8814]]
| Displays
| —
| pcf8814
| bgcolor="yellow" | 50%
| Philips PCF8814 65 x 96 pixels matrix LCD driver
| Work in progress (Uwe Hermann).

|-
| [[Protocol_decoder:Pcf8814_lcd|PCF8814 LCD]]
| Displays
| pcf8814
| pcf8814_lcd
| bgcolor="yellow" | 50%
| Philips PCF8814 65 x 96 pixels matrix LCD driver
| Work in progress (Uwe Hermann).

|-
| GPIB
| Other
| —
| gpib
| bgcolor="orange" | 0%
| [https://en.wikipedia.org/wiki/IEEE-488 General purpose interface bus] (GPIB), a.k.a. IEEE-488.1.
| Planned (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/DMX512 DMX512]
| Industrial Lighting
| —
| dmx512
| bgcolor="yellow" | 20%
| Digital MultipleX 512
| Work in progress (Uwe Hermann).

|-
| [https://en.wikipedia.org/wiki/Digital_Signal_Interface DSI]
| Industrial Lighting
| —
| dsi
| bgcolor="red" | 0%
| Digital Serial Interface
|

|-
| [http://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface DALI]
| Industrial Lighting
| —
| dali
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/RDM_%28lighting%29 RDM]
| Industrial Lighting
| —
| rdm
| bgcolor="red" | 0%
|
|

|-
| PWM
| Backlight Brightness Control
| —
|
| bgcolor="orange" | 0%
|
| Planned (Matt Ranostay).

|-
| [https://en.wikipedia.org/wiki/NMEA_0183 NMEA 0183]
| GPS
| uart
| nmea0183
| bgcolor="red" | 0%
|
|

|-
| [[Protocol_decoder:Nmea2000|NMEA2000]]
| Marine
| can
| nmea2000
| bgcolor="red" | 0%
| [https://en.wikipedia.org/wiki/NMEA_2000 NMEA 2000 Wikipedia page]
|

|-
| [https://en.wikipedia.org/wiki/Digital_Command_Control DCC]
| Trains
| —
| dcc
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Train_Communication_Network MVB]
| Trains
| —
| mvb
| bgcolor="red" | 0%
| Multifunction Vehicle Bus
|

|-
| [https://en.wikipedia.org/wiki/Train_Communication_Network WTB]
| Trains
| —
| wtb
| bgcolor="red" | 0%
| Wire Train Bus
|

|-
| [https://en.wikipedia.org/wiki/C-Bus_%28protocol%29 C-Bus]
| Home automation
| —
| cbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/X10_%28industry_standard%29 X10]
| Home automation
| —
| x10
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/LonWorks LonWorks]
| Home automation
| —
| lonworks
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/S-Bus S-Bus]
| Home automation
| —
| sbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Meter-Bus M-Bus]
| Automation
| —
| mbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus RTU]
| Automation
| uart
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus ASCII]
| Automation
| uart
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Modbus Modbus TCP]
| Automation
| ip
| modbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Highway_Addressable_Remote_Transducer_Protocol HART protocol]
| Automation
| —
| hart
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/INTERBUS INTERBUS]
| Automation
| —
| interbus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/DirectNET_Protocol DirectNET]
| Automation
| uart
| directnet
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/KNX_%28standard%29 KNX]
| Automation
| various
| knx
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Bacnet BACnet]
| Automation
|
| bacnet
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/OpenTherm OpenTherm]
| Automation
| —
| opentherm
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/EBUS_%28serial_buses%29 EBUS]
| Automation
| uart
| ebus
| bgcolor="red" | 0%
|
|

|-
| [https://en.wikipedia.org/wiki/Attachment_Unit_Interface AUI]
| Networking
| —
| aui
| bgcolor="red" | 0%
| Attachment Unit Interface
|

|-
| [https://en.wikipedia.org/wiki/Medium_Dependent_Interface MDI]
| Networking
| —
| mdi
| bgcolor="red" | 0%
| Medium Dependent Interface
|

|-
| [https://en.wikipedia.org/wiki/Media_Independent_Interface MII]
| Networking
| —
| mii
| bgcolor="red" | 0%
| Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/Gigabit_Media_Independent_Interface#Gigabit_Media_Independent_Interface GMII]
| Networking
| —
| gmii
| bgcolor="red" | 0%
| Gigabit Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/10_Gigabit_Media_Independent_Interface#10_Gigabit_Media_Independent_Interface XGMII]
| Networking
| —
| xgmii
| bgcolor="red" | 0%
| 10 Gigabit Media Independent Interface
|

|-
| [https://en.wikipedia.org/wiki/Management_Data_Input/Output MDIO]
| Networking
| —
| mdio
| bgcolor="red" | 0%
| Management Data Input/Output
|

|-
| [https://en.wikipedia.org/wiki/Wiegand_interface Wiegand]
| RFID
| —
| wiegand
| bgcolor="red" | 0%
| Wiegand interface
|

|-
| [https://en.wikipedia.org/wiki/Zilog_Z80 Z80]
| Other
| —
| z80
| bgcolor="yellow" | 20%
| Zilog Z80 CPU
| Work in progress ([[User:Danielk]])

|}

__FORCETOC__

Sysclk LWLA1034

2014-02-01T20:33:42Z

Danielk: Mention that the firmware is now included in sigrok

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1034 mugshot.png|180px]]
| name = Sysclk LWLA1034
| status = supported
| source_code_dir = sysclk-lwla
| channels = 34
| samplerate = 125MHz (max)
| samplerate_state = ?
| triggers = 34 + extern
| voltages = 0-5V
| threshold = ?
| memory = 256Kbit/channel
| compression = RLE
| website = [http://item.taobao.com/item.htm?id=19834430293 taobao.com]
}}

The '''Sysclk LWLA1034''' is a USB-based, 34-channel logic analyzer with up to 125MHz sampling rate.

See [[Sysclk LWLA1034/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

* Altera EP2C5Q208C8N (Cyclone II) FPGA
* Cypress CY7C68013A-56 (FX2) USB interface chip
* Cypress 256k×36 SRAM (likely a [http://www.cypress.com/?mpn=CY7C1361C-133AXC CY7C1361C-133AXC] or similar)
* STC15F104E 8051-based microcontroller

The not-installed 10-pin connector between the USB socket and the large capacitor seems to connect to the JTAG pins of the FPGA.

== Photos ==

<gallery>
File:Sysclk lwla1034 device top.jpg
File:Sysclk lwla1034 device bottom.jpg
File:Sysclk lwla1034 device connector.jpg
File:Sysclk lwla1034 device usb.jpg
File:Sysclk lwla1034 device open.jpg
File:Sysclk lwla1034 pcb top2.jpg
File:Sysclk lwla1034 pcb bottom2.jpg
File:Sysclk lwla1034 altera cyclone2.jpg
File:Sysclk lwla1034 cypress sram.jpg
File:Sysclk lwla1034 cypress fx2.jpg
File:Sysclk lwla1034 24c64n otherso8 crystal.jpg
File:Sysclk lwla1034 crystal 50mhz.jpg
File:Sysclk lwla1034 crystal 40mhz.jpg
File:Sysclk lwla1034 ams1117 33.jpg
File:Sysclk lwla1034 ams1117 12.jpg
</gallery>

(Note: The yellow/greenish markings weren't there, they're added by the photographer)

''' PCB for another device''':
<gallery>
File:Sysclk lwla1034 pcb top.jpg|PCB, top
File:Sysclk lwla1034 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1034 pcb closeup.jpg|PCB, close-up
File:Sysclk lwla1034 chip2.jpg|Cypress FX2
File:Sysclk lwla1034 chip3 removed marking.jpg|SRAM (marking removed)
</gallery>

== Software ==

[[File:Sysclk lwla1034 software.png]]

== Firmware ==

We have received permission from the vendor to distribute the FPGA bitstreams with sigrok. Thus, the bitstreams are now included in the sigrok-firmware module.

* The FX2 firmware is loaded from an EEPROM on the board, so that the final USB device descriptor is immediately available on power-up.
* Endpoint 4 is used exclusively for loading a new bitstream into the FPGA.
* Endpoint 2 is used for sending commands to the FPGA firmware, with responses (if any) coming in from endpoint 6.

Reverse engineering of the vendor's custom protocol has been completed. See [[Sysclk LWLA1034/Protocol]] for the documentation.

== Resources ==

* [http://blog.csdn.net/mcupro Mcupro blog on CSDN]

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Sysclk LWLA1034

2014-01-20T21:11:57Z

Danielk: Add STC15F104E to chip list

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1034 mugshot.png|180px]]
| name = Sysclk LWLA1034
| status = supported
| source_code_dir = sysclk-lwla
| channels = 34
| samplerate = 125MHz (max)
| samplerate_state = ?
| triggers = 34 + extern
| voltages = 0-5V
| threshold = ?
| memory = 256Kbit/channel
| compression = RLE
| website = [http://item.taobao.com/item.htm?id=19834430293 taobao.com]
}}

The '''Sysclk LWLA1034''' is a USB-based, 34-channel logic analyzer with up to 125MHz sampling rate.

See [[Sysclk LWLA1034/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

* Altera EP2C5Q208C8N (Cyclone II) FPGA
* Cypress CY7C68013A-56 (FX2) USB interface chip
* Cypress 256k×36 SRAM (likely a [http://www.cypress.com/?mpn=CY7C1361C-133AXC CY7C1361C-133AXC] or similar)
* STC15F104E 8051-based microcontroller

The not-installed 10-pin connector between the USB socket and the large capacitor seems to connect to the JTAG pins of the FPGA.

== Photos ==

<gallery>
File:Sysclk lwla1034 device top.jpg
File:Sysclk lwla1034 device bottom.jpg
File:Sysclk lwla1034 device connector.jpg
File:Sysclk lwla1034 device usb.jpg
File:Sysclk lwla1034 device open.jpg
File:Sysclk lwla1034 pcb top2.jpg
File:Sysclk lwla1034 pcb bottom2.jpg
File:Sysclk lwla1034 altera cyclone2.jpg
File:Sysclk lwla1034 cypress sram.jpg
File:Sysclk lwla1034 cypress fx2.jpg
File:Sysclk lwla1034 24c64n otherso8 crystal.jpg
File:Sysclk lwla1034 crystal 50mhz.jpg
File:Sysclk lwla1034 crystal 40mhz.jpg
File:Sysclk lwla1034 ams1117 33.jpg
File:Sysclk lwla1034 ams1117 12.jpg
</gallery>

(Note: The yellow/greenish markings weren't there, they're added by the photographer)

''' PCB for another device''':
<gallery>
File:Sysclk lwla1034 pcb top.jpg|PCB, top
File:Sysclk lwla1034 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1034 pcb closeup.jpg|PCB, close-up
File:Sysclk lwla1034 chip2.jpg|Cypress FX2
File:Sysclk lwla1034 chip3 removed marking.jpg|SRAM (marking removed)
</gallery>

== Software ==

[[File:Sysclk lwla1034 software.png]]

== Firmware ==

* The FX2 firmware is loaded from an EEPROM on the board, so that the final USB device descriptor is immediately available on power-up.
* Endpoint 4 is used exclusively for loading a new bitstream into the FPGA.
* Endpoint 2 is used for sending commands to the FPGA firmware, with responses (if any) coming in from endpoint 6.

Reverse engineering of the vendor's custom protocol has been completed. See [[Sysclk LWLA1034/Protocol]] for the documentation.

== Resources ==

* [http://blog.csdn.net/mcupro Mcupro blog on CSDN]

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Sysclk LWLA1034

2014-01-17T01:28:13Z

Danielk: Link to source code

{{Infobox logic analyzer
| image = [[File:Sysclk lwla1034 mugshot.png|180px]]
| name = Sysclk LWLA1034
| status = supported
| source_code_dir = sysclk-lwla
| channels = 34
| samplerate = 125MHz (max)
| samplerate_state = ?
| triggers = 34 + extern
| voltages = 0-5V
| threshold = ?
| memory = 256Kbit/channel
| compression = RLE
| website = [http://item.taobao.com/item.htm?id=19834430293 taobao.com]
}}

The '''Sysclk LWLA1034''' is a USB-based, 34-channel logic analyzer with up to 125MHz sampling rate.

See [[Sysclk LWLA1034/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware ==

* Altera EP2C5Q208C8N (Cyclone II) FPGA
* Cypress CY7C68013A-56 (FX2) USB interface chip
* Cypress 256k×36 SRAM (likely a [http://www.cypress.com/?mpn=CY7C1361C-133AXC CY7C1361C-133AXC] or similar)

The not-installed 10-pin connector between the USB socket and the large capacitor seems to connect to the JTAG pins of the FPGA.

== Photos ==

<gallery>
File:Sysclk lwla1034 device top.jpg
File:Sysclk lwla1034 device bottom.jpg
File:Sysclk lwla1034 device connector.jpg
File:Sysclk lwla1034 device usb.jpg
File:Sysclk lwla1034 device open.jpg
File:Sysclk lwla1034 pcb top2.jpg
File:Sysclk lwla1034 pcb bottom2.jpg
File:Sysclk lwla1034 altera cyclone2.jpg
File:Sysclk lwla1034 cypress sram.jpg
File:Sysclk lwla1034 cypress fx2.jpg
File:Sysclk lwla1034 24c64n otherso8 crystal.jpg
File:Sysclk lwla1034 crystal 50mhz.jpg
File:Sysclk lwla1034 crystal 40mhz.jpg
File:Sysclk lwla1034 ams1117 33.jpg
File:Sysclk lwla1034 ams1117 12.jpg
</gallery>

(Note: The yellow/greenish markings weren't there, they're added by the photographer)

''' PCB for another device''':
<gallery>
File:Sysclk lwla1034 pcb top.jpg|PCB, top
File:Sysclk lwla1034 pcb bottom.jpg|PCB, bottom
File:Sysclk lwla1034 pcb closeup.jpg|PCB, close-up
File:Sysclk lwla1034 chip2.jpg|Cypress FX2
File:Sysclk lwla1034 chip3 removed marking.jpg|SRAM (marking removed)
</gallery>

== Software ==

[[File:Sysclk lwla1034 software.png]]

== Firmware ==

* The FX2 firmware is loaded from an EEPROM on the board, so that the final USB device descriptor is immediately available on power-up.
* Endpoint 4 is used exclusively for loading a new bitstream into the FPGA.
* Endpoint 2 is used for sending commands to the FPGA firmware, with responses (if any) coming in from endpoint 6.

Reverse engineering of the vendor's custom protocol has been completed. See [[Sysclk LWLA1034/Protocol]] for the documentation.

== Resources ==

* [http://blog.csdn.net/mcupro Mcupro blog on CSDN]

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Sysclk LWLA1016/Protocol

2014-01-17T00:00:48Z

Danielk: Start documenting the LWLA1016 protocol