Difference between revisions of "PoLabs PoScope Mega50"

From sigrok
Jump to navigation Jump to search
(link to vendor's device page)
 
(5 intermediate revisions by the same user not shown)
Line 11: Line 11:
* ''NXP'' LPC1111F: Cortex-M0 based microcontroller (For the output probably)
* ''NXP'' LPC1111F: Cortex-M0 based microcontroller (For the output probably)
* ''NXP'' PCA9555: 16 I/O CMOS device
* ''NXP'' PCA9555: 16 I/O CMOS device
* 4x ''Nexpia'': 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel)
* 4x ''Nexpia'' 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel)
* ''Microchip'' 24lc128i: I2C EEPROM
* 2x ''Nexpia'' 74HC245: Octal bus transceiver
* ''TI'' LM358: opamp


== Photos ==
== Photos ==


[[Media:PoScopeMx50 PCB.JPG]]
 
[[File:PoScopeMx50 PCB.JPG|200px]]
[[File:PoscopeMx50 inside.JPG|200px]]
[[File:Poscope_inside_2.JPG|200px]]


== Protocol ==
== Protocol ==

Latest revision as of 12:28, 6 January 2020

The PoLabs PoScope Mega50 is a mixed signal oscilloscope with 2 analog channels (8 bits each) and 2 digital ports (16 digital lines in summary).

...

See PoLabs PoScope Mega50/Info for some more details (such as lsusb -v output) on the device.

Hardware

  • Cypress CY7C68013A-56: USB Microcontroller
  • Analog Devices AD9288: 8-Bit Dual A/D Converter
  • NXP LPC1111F: Cortex-M0 based microcontroller (For the output probably)
  • NXP PCA9555: 16 I/O CMOS device
  • 4x Nexpia 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel)
  • Microchip 24lc128i: I2C EEPROM
  • 2x Nexpia 74HC245: Octal bus transceiver
  • TI LM358: opamp

Photos

PoScopeMx50 PCB.JPG PoscopeMx50 inside.JPG Poscope inside 2.JPG

Protocol

The main communication when setting it up/changing configuration always goes like this:


The host sends a "URB_BULK out" command where there are 64 bytes of data.

The device sends a packet with 4 times 0x00 as data

The host returns the same data but with an 0x00 instead of an 0x01 at byte 16

The device returns a "URB_BULK in" command with a lot of data in the 64 bytes of data.



The setup:

// In the following examples, I'm only talking about the 64 bytes of data, because (I think) everything else gets handled by the driver itself

//I'm making assumptions about what the commands do

Booting:

the host sends 0xa2 followed by 63 0x00

the host sends 0xa8 followed by 63 0x00


the host sends 0xa4 + 0x30 + 0x00 + 0x20 + 60 * 0x00

now, the host counts bytes 1 and 2 up in 0x20 steps, always 0xa4 at byte 0 like that:

this is probably to clean out old values


byte 0 1 2 3 4-64
0xa4 + 0x30 + 0x20 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0x40 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0x60 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0x80 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0xa0 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0xc0 + 0x20 + 60 * 0x00
0xa4 + 0x30 + 0xe0 + 0x20 + 60 * 0x00
0xa4 + 0x31 + 0x00 + 0x20 + 60 * 0x00
0xa4 + 0x31 + 0x20 + 0x20 + 60 * 0x00

until byte 1 is 0x3f and byte 2 is 0xe0

then the host sends: 0xa4 + 0x40 + 0x00 + 0x00 + 60 * 0x00


Starting (setting modes and other stuff probably):

0xa5 + 0x28 + 0x01 + 0x01 + 0x00 + 0x00 + 58 * 0x00
0xa6 + 0x28 + 0x07 + 0x00 + 0x00 + 0x00 + 58 * 0x00
0xa5 + 0x28 + 0x01 + 0x06 + 0x00 + 0x00 + 58 * 0x00
0xa5 + 0x28 + 0x01 + 0x01 + 0x00 + 0x00 + 58 * 0x00
0xa6 + 0x28 + 0x07 + 0x00 + 0x00 + 0x00 + 58 * 0x00
0x06 + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 58 * 0x00 maybe initializes mode change. always comes before b2
0xb2 + 0x00 + 0x00 + 0x01 + 0xe0 + 0x14 + 58 * 0x00 b2 could set the mode. it repeats with other data when switching modes
0x05 + 0xc7 + 0x00 + 0x00 + 0x00 + 0x00 + 58 * 0x00


after that you can ask for data with:

  0ad5ffff000000000900000100ff00860300000000

Resources