Link Instruments MSO-19

File:MSO-19.JPG

Link Instruments MSO-19

File:MSO-19-naked.jpg

PCB Front

The Link Instruments MSO-19 is a 2GSa/s oscilloscope, 200MSa/s logic analyzer, 100MSa/s pattern generator and a TDR. It is also extremely portable and is only $249 (including probe, clips, wires and software).

See Link Instruments MSO-19/Info for more details (such as lsusb -vvv output) about the device.

Hardware

• Lattice MachXO LCMXO2280 PLD
• Kenet KAD2710C-10 10bit, 105MSPS ADC
• Silabs CP2103 USB to UART Bridge

Original software

Link Instruments ships the product with its FrontPanelTM Oscilloscope software. Software is for Windows only. Written in .NET (C#), without any kind of obfuscation, which makes it a real breeze to reverse engineer.

USB protocol

It's just serial-over-USB, supported by the Linux kernel through the cp210x driver, though as of Kernel 2.6.37 it needs to be patched to recognize the Link Instruments Vendor/Product ID (3195:f190).

iSerial was exploited by Link Instruments to store hardware type, hardware revision, calibration quirks and the actual serial number.

• for an iSerial of 4294333650260000000 we have:
  • 42943 336 502 6 0 000000
    • vbit = 42943 / 10000
    • dacoffset = 336
    • offsetrange = 502
    • hwmodel = 6
    • hwrev = 0
    • serial number = 000000

Serial protocol

• Control message
  • Fixed header: 0x40, 0x4c, 0x44, 0x53, 0x7e
  • Variable size payload, 16bit aligned
    • Looks like each 16bits of payload are a register write operation
    • register writes are 4bits for addr, 8 bits for value, 2 unused bits and 2 bits im not sure what they are for :)
      • The simplest explanation for the unused bits is that the device bus width is 7 bits (being a CPLD that is very acceptable).
      • The 2 special bits seem to be synchronization bits. 0x7e violates the conversion (high byte), and that may be used to reset the CPLD parser at the end of the packet.
    • .?12 AAAA .?34 5678
    • Conversion is: ((v & 0x3f) | ((v & 0xc0) << 6) | ((a & 0xf) << 8) | (((v ^ 0x20) & 0x20) << 1) | (((v ^ 0x80) & 0x80) << 7))
    • Byte order is big endian
  • Fixed footer: 0x7e

Registers description

There is no way to read from registers, only write is possible.

The purpose of registers 0 to 8 seems to depend on the value of register 15.

Registers for R15 == 0

• Read Sample buffer (1): Write 0 to this register to read the samples buffer.
• Read Trigger status (2): Write 0 to this register to read the trigger status.
• TRIGGER_CONFIG_L (3):
  • lsbyte of the threshold value.
• TRIGGER_CONFIG_H (4):
  • bits [1:0] hold the msbits of the threshold value
  • (1 << 2): Trigger on falling edge
• LA_TRIGGER(5):
• LA_TRIGGER_MASK(6):
• SCOPE_TRIGGER_THRESHOLD(7-8):

Registers for R15 == 2

• TRIG_I2C_WORD0 (0): Holds the first i2c word to be matched.
  • If matching less than 4 words, this register is set to 0 (match bus idle) and the mask is set to 0xff. See below.
• TRIG_I2C_WORD1 (1): Holds the second i2c word to be matched. Same as above.
• TRIG_I2C_WORD2 (2): Holds the third i2c word to be matched. Same as above.
• TRIG_I2C_WORD2 (3): Holds the fourth i2c word to be matched. Same as above.
• TRIG_I2C_MASK0 (4): Holds the mask for the first i2c word.
  • If matching less than 4 words, this register is set to 0xff. This forces a match on a "bus idle" state.
  • Could forcing the match to bus idle cause trouble whith packets too close together??
• TRIG_I2C_MASK1 (5): Holds the mask for the 2nd i2c word.
• TRIG_I2C_MASK2 (6): Holds the mask for the 3d i2c word.
• TRIG_I2C_MASK3 (7): Holds the mask for the 4th i2c word.
• UNKWNOWN_8 (8): This seems to be always set to zero... WHY?

Registers which don't seem to change purpose (so far)

• CLKRATE(9-10):
• TRIGGER_WIDTH(11): The trigger width in sample units (mso19 app forces the value to be greater than 3)
• DAC(12-13):
• CONTROL (14):
  • (1 << 0): Reset SFM
  • (1 << 4): Reset ADC (?)
  • (1 << 6): Reset ADC (?)
  • (1 << 7): Led on/off
• SLOWMODE(15): This should be renamed BANK perhaps!