Difference between revisions of "User:PeterMortensen"

From sigrok
Jump to navigation Jump to search
(→‎Recent activity: Getting organised, part 1.)
m (Minior corrections, etc.)
Line 5: Line 5:
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 [https://store.arduino.cc/arduino-leonardo-with-headers Arduino Leonardo]:
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 [https://store.arduino.cc/arduino-leonardo-with-headers Arduino Leonardo]:


#Verify that all keys work on BTC 5349. The same for the other keyboard (but it is suspected to work).
#Verify that all keys work on BTC 5349. The same for the other keyboard (but it is expected to work).
#Capturing and submitting information for PS/2 PC keyboards (CLK and DATA), including during pressing and releasing all keys for an IBM/AT type (standard) keyboard and bidirectional traffic (PC initialising the keyboard, e.g. at connect and/or PC startup). Submit to Git repository "[https://sigrok.org/gitweb/ sigrok-dumps]".
#Capturing and submitting information for PS/2 PC keyboards (CLK and DATA), including during pressing and releasing all 100+ keys for an IBM/AT type (standard) keyboard and bidirectional traffic (PC initialising the keyboard, e.g. at connect and/or PC startup). Submit to Git repository "[https://sigrok.org/gitweb/ sigrok-dumps]".
#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).
#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).
#Some higher-level protocol decoder work for PC keyboard (not decided on yet), e.g. identifying scan code sequences as the corresponding keys.
#Some higher-level protocol decoder work for PC keyboard (not decided on yet), e.g. identifying scan code sequences as the corresponding keys.
#Some hardware to allow an Arduino Leonardo to pose as a PC ([https://en.wikipedia.org/wiki/Open_collector open collector] outputs). To explore what commands various keyboards responds to and what modes they might enter (for example, Linux allegedly tries put keyboard 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.
#Some hardware to allow an Arduino Leonardo to pose as a PC ([https://en.wikipedia.org/wiki/Open_collector 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.
#Existing content on the wiki, etc. regarding PC keyboards, etc.:
#Existing content on the wiki, etc. regarding PC keyboards, etc.:
## Keyboards (none found, but are probably not supposed to exist, only actual capturing hardware(?)).
## Keyboards (none found, but are probably not supposed to exist, only actual capturing hardware(?)).

Revision as of 20:05, 10 January 2020

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. Verify that all keys work on BTC 5349. The same for the other keyboard (but it is expected to work).
  2. Capturing and submitting information for PS/2 PC keyboards (CLK and DATA), including during pressing and releasing all 100+ keys for an IBM/AT type (standard) keyboard and bidirectional traffic (PC initialising the keyboard, e.g. at connect and/or PC startup). Submit to Git repository "sigrok-dumps".
  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 keyboard (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.
    5. Look in Git log.
    6. 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)

Other:

  1. Updating broken links here. E.g 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.