User:PeterMortensen

From sigrok
Revision as of 18:58, 2 December 2022 by PeterMortensen (talk | contribs) (→‎Meta: Created a stub for a subsection of a subsection)
Jump to navigation Jump to search

Recent activity

2020-01

Getting insight into what happens with PC keyboards on the signal level and on higher levels (related to repurposing an old PS/2 keyboard (BTC 5349) as a macro keyboard, with the help of an Arduino Leonardo):

  1. For the keyboards listed below: Verify that all keys work (by capturing in PulseView and observe there is actually a signal. Note that the accent and umlaut key requires pressing a letter after).
  2. For the keyboards listed below: Capturing and submitting information for PS/2 PC keyboards (CLK and DATA), including during pressing and releasing and bidirectional traffic (PC initialising the keyboard, e.g. at connect and/or PC startup). Submit to Git repository "sigrok-dumps": Keyboards (all European layout):
    1. BTC 5349 (102 keys IBM/AT type, corresponding to IBM Model M (Enhanced)). 100 mA (measured). Mechanical keyboard?
    2. Fujitsu/Siemens (105 keys + 10 media keys (sleep, mail, play, stop, speaker controls, etc.). IBM/AT type. ?? mA.
    3. Microsoft "Natural Keyboard Elite". 105 keys. 500 mA (nominal).
    4. Apple Extended Keyboard II. 105 keys + one power key. ??? mA. Mechanical keyboard. Uses ADB, not PS/2 (physically similar, but 4-pin mini-DIN connector). A single pin for data and 'PSW' connected directly to the power switch. All communication is host initiated (polling).
  3. Consider adding regression tests for the PS/2 decoder. It will include if it handles the 2-3% clock frequency offset for the BTC 5349 (probably, as there is CLK, but that is not the case if decoding as the UART protocol decoder).
  4. Some higher-level protocol decoder work for PC keyboards (not decided on yet), e.g. identifying scan code sequences as the corresponding keys.
  5. Some hardware to allow an Arduino Leonardo to pose as a PC (open collector outputs). To explore what commands various keyboards responds to and what modes they might enter (for example, Linux allegedly tries put keyboards into "Set 3" (the powerup default is usually "Set 2")). The three LEDs on the keyboard can also be used for user feedback for the macro keyboard.
  6. Existing content on the wiki, etc. regarding PC keyboards, etc.:
    1. Keyboards (none found, but are probably not supposed to exist, only actual capturing hardware(?)).
    2. PS/2 decoder page. Does not exist??
    3. "The decode of some PS/2 (or USB) keyboard/mouse traffic could yield an ASCII text file of all the keys that were pressed on the keyboard." (on a planning page)
    4. Look in bug tracker for PS/2, keyboards, etc.
      1. Bug #1460 - ps2: end data byte at rising clock edge of the stop bit
    5. Look in Git log
      1. PS/2 keyboard data submitted on 2019-12-21 (discovered on projects / sigrok-dumps.git / commit )
    6. Look in IRC log
    7. Look in blog posts for info on PS/2, etc.
  7. Updating the wiki
    1. Add PS/2 low-level reference (details about the CLK signal) to the PS/2 protocol decoder page. IRC ref. [2020-01-07 01:49:07] and [2020-01-07 18:09:02] (UTC+1)). Add to the resources section. Is: http://www.nerdkits.com/videos/interrupts_and_ps2_keyboard/
    2. Add keyboard documentation, pictures (not decided on yet).
  8. Ideas:
    1. Deliberately send data to the keyboard with a parity error.
    2. Deliberately add noise to the signals (say, wide-band white noise by electronics means), forcing parity errors. This should force the receiver (keyboard or host PC) to respond.
    3. Send unknown commands to the keyboard. It should respond with 0xFE (in contrast to the normal 0xFA).
    4. Try all the keyboard commands in Keyboard commands.
    5. For a keyboard that is both capable of USB and PS/2: Record the startup sequence when connected via PS/2 to a PC host. To see if there is any indication on the signal level of such capability.

Other:

  1. Updating broken links here. For example, for the CAN protocol decoder.

2019-04

  1. Building a Docker container for compiling sigrok-cli and PulseView. It is supposed to both run under Linux and Windows (x64).
  2. Testing a new driver by user droghio that should work for the TDS2024C Tektronix oscilloscope. Some placeholding:

2018-04

Submitting comprehensive sample data for CAN bus, both 11-bit and 29-bit messages, and corresponding test cases (mostly for regression test - especially regression for the 2018-04-12 fix to the decoding at the end of the CRC part).

Notes to self:

  1. Original acquired analog data: C:\temp2\2017-12-23\CAN decoder, new stuff bit handling at the end of the CRC segment\Data67\In\ACQ000009_Tektronix.txt

2017-12

Recording 22483 traces for the purpose of evaluating a proposed fix to the CAN protocol decoder (actually only changing a single number from 16 to 17), stuff bit at the very end of the CRC segment, with a modified trigger scheme:

  • Change the position of the trigger point to the end (right) so there is always a CAN message in the trace (for the previous), but still 26 µs recessive.

The time division was 100 µs / division (about 225 bit times max) to always record whole CAN messages - at 10 samples per bit time.

2017-07

Using the sigrok command-line ("sigrok-cli") to bulk process data derived from Tektronix oscilloscope data of 250 kbit/s CAN traffic on a real-world system (mobile cranes). The first sample data set is 5335 oscilloscope traces obtained with the trigger set to a negative pulse on CAN-H (to start off at the end of a CAN message) - corresponding to 6.5 recessive bits, 26 µsec (detecting the space in-between CAN messages). Sometimes there is a CAN message right after this, sometimes it is a bit delayed, and sometimes it is completely empty.

A sample command line (on Windows) is: 

sigrok-cli -P can:bitrate=250000:can_rx="CAN RX" -P timing:data="CAN RX" -I csv:header=true:samplerate=5000000 -i "T:\stdHMF\UserData\scripts\Tektronix2PulseView\_PulseView_AllChannels_ACQ000001_Tektronix_f5000000.txt"

2017-04

Using PulseView to decode data from a Tektronix oscilloscope of SPI communication to a CAN controller, MCP2515.

Task list

Currently not in priority order.

  • Allow import of analog data through CSV files. (Related: fixed bug 1064 - locale issue, decimal point, "," vs. ".".).
  • Add detection of error frames to the CAN protocol decoder
  • Add support for the gigga watt EEVBlog multimeter (Bluetooth, etc.)
  • Add a snap feature to the "cursor" (blue) in PulveView
  • Change number of significant digits for the time display in the "cursor" (blue) in PulveView
  • Submit selected sample traces for CAN decoder change (for CRC segment) validation. With and without stuff bits in various places. With and without timing deviations. (Related: bug 1085, celeron55's fix, if len(self.bits) > self.last_databit + 16 → if len(self.bits) > self.last_databit + 17 (16 → 17)).
  • Add support for the TDS2000 series in libsigrok, and thus, by extension, use by the new shiny stuff in PulveView.

On wiki

  • Change recommended procedure for submitting sample Sigrok files (traces), on Example dumps.

Glossary

  • BBB BeagleBone Black
  • GH GitHub
  • ISTR ????
  • LA Logic analyser
  • ML Mailing list
  • OLS ????
  • PR Pull request (a Git term). Not "problem report".
  • SR Sigrok
  • srd ????
  • WIP Work in progress. Mostly related to particular Git commits.
  • PD protocol decoder. Non-standard spellings are Pd and pd.
  • PV PulseView. Non-standard spellings are Pv and pv.

Some bug reports

Interests

I am mostly interested in:

Protocol decoders

Non-empty wiki pages

Currently (2017-07-08), 28 of 77 protocol decoders (36%) have non-empty pages here on the wiki:

Meta

Creating sub pages for proposals

Profile

Profile: see my Wikipedia user page.

Credentials: more than 5000 edits on the English Wikipedia.

Shortcuts

Protocol decoders

Building sigrok

Retrieved from "https://sigrok.org/w/index.php?title=User:PeterMortensen&oldid=16364"