FNIRSI-1013D "100MHz" tablet oscilloscope

[e_Johny]

A poll:
How many of the readers of this post want me to move the hacking updates to another thread?

The current is good for me. 
But I'm just a newbie, here. :-)

[pcprogrammer]

Yes,
I'm happy to help. 

Hi e_Johny, can you make a capture where you do touch on the screen. Start with the top right button that changes the right menu bar and then touch the v+ of the first channel. After that touch the main menu button. Hopefully this will give me insight in how it works, because a setting is read after the touch and the result of it is used in the code.

Edit: also do a capture when changing the brightness.

The data you provided is also useful but it seems to repeats a certain pattern of id's. The first four seem to be initialize calls of which the 0x10 is for the brightness. The others repeat.

Code: [Select]

{ 0x00, 0x36, 0x28, 0x89, 0x69, 0x96, 0x99, 0x13 },  //Checksum ok  Crypt mangle ok  Id: 0x0A  Len: 0
{ 0x01, 0x25, 0x55, 0x39, 0x69, 0x96, 0x99, 0x27 },  //Checksum ok
{ 0x00, 0xA1, 0x50, 0xBC, 0x69, 0x96, 0x99, 0xED },  //Checksum ok  Crypt mangle ok  Id: 0x14  Len: 0
{ 0x01, 0xCA, 0x55, 0xC4, 0x69, 0x96, 0x99, 0x0D },  //Checksum ok
{ 0x00, 0x1E, 0x58, 0x06, 0x69, 0x96, 0x99, 0x00 },  //Checksum ok  Crypt mangle ok  Id: 0x16  Len: 0
{ 0x01, 0x05, 0x5A, 0x8B, 0x69, 0x96, 0x7E, 0xAF },  //Checksum ok
{ 0x00, 0xA0, 0x40, 0xE4, 0x69, 0x96, 0x99, 0x64 },  //Checksum ok  Crypt mangle ok  Id: 0x10  Len: 0
{ 0x01, 0x70, 0x5A, 0x13, 0x69, 0x96, 0xEA, 0x60 },  //Checksum ok
{ 0x00, 0x51, 0x45, 0x09, 0x69, 0x96, 0x7D, 0x97 },  //Checksum ok  Crypt mangle ok  Id: 0x11  Len: 1
{ 0x01, 0x31, 0x5A, 0x6C, 0x69, 0x96, 0x07, 0xDB },  //Checksum ok
{ 0x00, 0x61, 0x30, 0x0B, 0x69, 0x96, 0x99, 0x00 },  //Checksum ok  Crypt mangle ok  Id: 0x0C  Len: 0
{ 0x01, 0xC1, 0x55, 0xCE, 0x69, 0x96, 0x99, 0x20 },  //Checksum ok
{ 0x00, 0x34, 0x2C, 0xF8, 0x69, 0x96, 0x99, 0x00 },  //Checksum ok  Crypt mangle ok  Id: 0x0B  Len: 0
{ 0x01, 0xA7, 0x55, 0x41, 0x69, 0x96, 0x99, 0xAD },  //Checksum ok
{ 0x00, 0xAD, 0x45, 0x4A, 0x69, 0x96, 0xA5, 0xFA },  //Checksum ok  Crypt mangle ok  Id: 0x11  Len: 1
{ 0x01, 0xA7, 0x5A, 0x6B, 0x69, 0x96, 0x0A, 0x61 },  //Checksum ok
{ 0x00, 0xAD, 0x30, 0x8F, 0x69, 0x96, 0x99, 0x00 },  //Checksum ok  Crypt mangle ok  Id: 0x0C  Len: 0
{ 0x01, 0x8C, 0x55, 0x99, 0x69, 0x96, 0x99, 0x20 },  //Checksum ok
{ 0x00, 0x86, 0x2C, 0x4A, 0x69, 0x96, 0x99, 0x00 },  //Checksum ok  Crypt mangle ok  Id: 0x0B  Len: 0
{ 0x01, 0x99, 0x55, 0x33, 0x69, 0x96, 0x99, 0xAD },  //Checksum ok


[bianchifan]

Sigrok does not compile on my actual system and Ubuntu's pulseview makes nonsense
DSView 0.99 doesn't compile too, casting errors 64bit->8bit..
DSViev 1.12 did compile and found a DSLogic Basic..
I captured two sessions a' 20 seconds, first samplrate 10MHz, 2nd 4MHz.
Switch on, moving lines(signal*cursors), timbase,  trigger, vertical sensivity, switch off - CH1 only with CH2 turned off.
Data saved as DSView format, csv and gnuplot.

The zips contain tgzs, tgz didn't upload

[e_Johny]

Unfortunately, the touch panel of my scope has two bugs.

1. (Original-, "factory" fault) The mid column is blind. Therefore cannot be switched anything in  the Ch2 menu.

This was the main reason to follow this forum-thread.

2. The top row of the touch panel is blind.
(This is my fault. I measured the traces between the glass and the GT911. Maybe I made something mistake, because since then no reaction on the top row. I will continue the checking, but its very slow (for my other duties).

I ordered a new touch panel, but it is still in shipping from China.

I can switch the RUN/STOP, and the lower buttons.

So, if you want presently, I can capture something only with these...

(Sorry, if my english is sometimes a little poor.)

[pcprogrammer]

Hi e_Johny,

your English is fine

So it seems it is quite a few scopes that have issues with the touch panel. Luckily it can be solved easily with what has been discovered here. And yeah shipping form China takes it time unfortunately

Any capture with touch will help. It will give an insight in the logic behind it all.

[pcprogrammer]

I captured two sessions a' 20 seconds, first samplrate 10MHz, 2nd 4MHz.
Switch on, moving lines(signal*cursors), timbase,  trigger, vertical sensivity, switch off - CH1 only with CH2 turned off.
Data saved as DSView format, csv and gnuplot.
(Attachment Link)
The zips contain tgzs, tgz didn't upload

Hi bianchifan, thanks for the effort, but the data is incomplete. The 3rd line seems to be the clock and changes regularly, but what I assume to be the data line (no trace number) is one and stays one. The other traces (0,1) are zero and stay zer0.

[e_Johny]

Good news:

The "top-line" error  is over. 
// Fault was maybe:
// - thin short between 2 "legs" (~QFN package),
// - or the ribbon cable contact (~bending).

I captured the asked procedures.

At the brightness modifications I made a "full menu path"- and a "just the slider moving" capture.
Both was made with steps, and countinous variant. (detailed file names)

( At the first procedures - I don't remember - the "V+" how many times was pressed.
Maybe one, or maybe all steps (while relays switch)...)

Edit:
The scope was in RUN mode, at all procedures.
/In STOP mode, the V+/V- just do 2 relay-steps up/down. (In RUN mode, it is more)./

[pcprogrammer]

Hi e_Johny,

well done. This now a days hardware is all very very small and probing with a sharp tool easily damages things or makes shorts

And thanks again for making the captures.

Today I wrote a conversion program to read the saleae binary export and convert the data into the scope data. I uploaded it to the repository. (https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/i2c_bin_data_converter)

I converted the data you made yesterday and it shows that the reads of id 0x11, 0x0C and 0x0B are indeed repeated down to the end.

Added the results to the scope emulator, but it did not result in working "touch", so hopefully the captures you made today will shed some light on things.

[e_Johny]

But it did not result in working "touch"

Does it matter if our firmwares (maybe) are different?

[pcprogrammer]

Does it matter if our firmwares (maybe) are different?

Don't think it will, since others have used the "new" firmware in "old" scopes without real problems. (Apart from touch panel coordinates reversals)

I ordered a cheap 8 channel 24MHz usb logic analyzer from AliExpress (https://nl.aliexpress.com/item/1005001809356844.html) yesterday, so when it arrives, I can check what my scope does. In the mean time I can study what you supplied.

[pcprogrammer]

For the brightness it shows that the special chip translates an 8 bit value into a 16 bit value. While adjusting it repeatedly sends the brightness id 0x10.

I also noticed that in the repeated sequence of the 0x11, 0x0C and 0x0B it is once in a while extended with 0x0E. In the emulator I saw 0x0D passing by. So maybe a per channel message?

The first capture (01_CTRL_+_V+_+_MENU_+_SystemSettings) did not show extra commands.

The data below shows the actual data on the wire, the "decrypted" data, checksum status, id and length indicator (0 means a byte)

Code: [Select]

{ 0x00, 0x4C, 0xD2, 0x07, 0xFB, 0x04, 0x0B, 0xDF },{ 0x00, 0xDE, 0x40, 0x95, 0x69, 0x96, 0x99, 0x4D },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xD2, 0x77, 0x63, 0x44, 0xBB, 0x95, 0x3D },{ 0x01, 0x2D, 0x5A, 0x4E, 0x69, 0x96, 0xB8, 0x10 },  //Checksum ok
{ 0x00, 0xA3, 0x6D, 0x23, 0x44, 0xBB, 0xB4, 0x60 },{ 0x00, 0x8E, 0x40, 0x0E, 0x69, 0x96, 0x99, 0x4D },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xB0, 0x15, 0x3F, 0x26, 0xD9, 0xF7, 0x5F },{ 0x01, 0x4F, 0x5A, 0x70, 0x69, 0x96, 0xB8, 0x10 },  //Checksum ok
{ 0x00, 0xBA, 0x0F, 0xBD, 0x26, 0xD9, 0xD6, 0x1F },{ 0x00, 0xF5, 0x40, 0xF2, 0x69, 0x96, 0x99, 0x50 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x80, 0x25, 0x49, 0x16, 0xE9, 0xC1, 0xDF },{ 0x01, 0x7F, 0x5A, 0x36, 0x69, 0x96, 0xBE, 0xA0 },  //Checksum ok
{ 0x00, 0xFB, 0x3F, 0x4E, 0x16, 0xE9, 0xE6, 0x2F },{ 0x00, 0x84, 0x40, 0x31, 0x69, 0x96, 0x99, 0x50 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x79, 0xDC, 0xBB, 0xEF, 0x10, 0x38, 0x26 },{ 0x01, 0x86, 0x5A, 0x3D, 0x69, 0x96, 0xBE, 0xA0 },  //Checksum ok
{ 0x00, 0x8C, 0xC6, 0x46, 0xEF, 0x10, 0x1F, 0xD6 },{ 0x00, 0x0A, 0x40, 0xC0, 0x69, 0x96, 0x99, 0x50 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x2C, 0x89, 0x59, 0xBA, 0x45, 0x6D, 0x73 },{ 0x01, 0xD3, 0x5A, 0x8A, 0x69, 0x96, 0xBE, 0xA0 },  //Checksum ok
{ 0x00, 0x7C, 0x93, 0xE1, 0xBA, 0x45, 0x4A, 0x89 },{ 0x00, 0xAF, 0x40, 0x32, 0x69, 0x96, 0x99, 0x5A },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x63, 0xC6, 0xD5, 0xF5, 0x0A, 0x48, 0x1C },{ 0x01, 0x9C, 0x5A, 0x49, 0x69, 0x96, 0xD4, 0x80 },  //Checksum ok
{ 0x00, 0xC6, 0xDC, 0x6C, 0xF5, 0x0A, 0x05, 0xC6 },{ 0x00, 0x5A, 0x40, 0xF0, 0x69, 0x96, 0x99, 0x5A },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xAC, 0x09, 0x53, 0x3A, 0xC5, 0x87, 0xD3 },{ 0x01, 0x53, 0x5A, 0x00, 0x69, 0x96, 0xD4, 0x80 },  //Checksum ok
{ 0x00, 0x78, 0x13, 0x84, 0x3A, 0xC5, 0xCA, 0x30 },{ 0x00, 0x2B, 0x40, 0xD7, 0x69, 0x96, 0x99, 0x63 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xA7, 0x02, 0x91, 0x31, 0xCE, 0xB0, 0x68 },{ 0x01, 0x58, 0x5A, 0xC9, 0x69, 0x96, 0xE8, 0x30 },  //Checksum ok
{ 0x00, 0x52, 0x18, 0x65, 0x31, 0xCE, 0xC1, 0x3B },{ 0x00, 0x0A, 0x40, 0x3D, 0x69, 0x96, 0x99, 0x63 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xC5, 0x60, 0x91, 0x53, 0xAC, 0xD2, 0x0A },{ 0x01, 0x3A, 0x5A, 0xAB, 0x69, 0x96, 0xE8, 0x30 },  //Checksum ok
{ 0x00, 0x4B, 0x7A, 0xC0, 0x53, 0xAC, 0xA3, 0x59 },{ 0x00, 0x71, 0x40, 0xFA, 0x69, 0x96, 0x99, 0x63 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0xA1, 0x04, 0x91, 0x37, 0xC8, 0xB6, 0x6E },{ 0x01, 0x5E, 0x5A, 0xCF, 0x69, 0x96, 0xE8, 0x30 },  //Checksum ok
{ 0x00, 0xDA, 0x1E, 0xF8, 0x37, 0xC8, 0xC7, 0x3A },{ 0x00, 0x84, 0x40, 0xA6, 0x69, 0x96, 0x99, 0x64 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x9D, 0x38, 0x67, 0x0B, 0xF4, 0x88, 0x02 },{ 0x01, 0x62, 0x5A, 0x05, 0x69, 0x96, 0xEA, 0x60 },  //Checksum ok
{ 0x00, 0x19, 0x22, 0x3B, 0x0B, 0xF4, 0xFB, 0x06 },{ 0x00, 0x7B, 0x40, 0x59, 0x69, 0x96, 0x99, 0x64 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x00, 0xA5, 0x5D, 0x96, 0x69, 0x15, 0x9F },{ 0x01, 0xFF, 0x5A, 0xA2, 0x69, 0x96, 0xEA, 0x60 },  //Checksum ok
{ 0x00, 0xFF, 0xBF, 0xBE, 0x96, 0x69, 0x66, 0x9B },{ 0x00, 0x00, 0x40, 0x41, 0x69, 0x96, 0x99, 0x64 },  //Checksum ok  Id: 0x10  Len: 0
{ 0x01, 0x24, 0x81, 0xA5, 0xB2, 0x4D, 0x31, 0xBB },{ 0x01, 0xDB, 0x5A, 0x7E, 0x69, 0x96, 0xEA, 0x60 },  //Checksum ok

The rest is for another day

[bianchifan]

the data is incomplete.

I also was not happy with the data.
DSView 1.12 does not work correctly with my hacked/upgraded DSLogic.
Today I managed to turn it into a Basic one, so DSView should work ok.
But unfortunately I cannot upload my data, I always get a screen for a new topic ...

Nevertheless I noticed today a laggy screen and some quite wrong actions, the reason was...charging!

[bianchifan]

No success with upload, I fear the zip is too big..

[bianchifan]

Scenario 1: 20sec - 10MHz
running system, moving lines and cursors, switchin trigger, timebase, sensivity and so on until sudden death due to time limit

First zip contains DSView-Format, 2nd zip contains sigrok(Pulseview)-Format

TOO late, no idea how to upload my data 

[bianchifan]

Scenario 2: 20sec - 4MHz
Scope turned off, switching on, moving lines and cursors, switchin trigger, timebase, sensivity, turn off after ~17sec.

First zip contains DSView-Format, 2nd zip contains sigrok(Pulseview)-Format

[bianchifan]

scene 3: 5sec - 4MHz
System is running, doing nothing but charging

[bianchifan]

The zip is 3.1MB

[bianchifan]

... 20sec_4MHz_dsl.zip (3198.73 kB - downloaded 37 times.)

[bianchifan]

...

[pcprogrammer]

Hi bianchifan,

looking at the images the data still looks as if there is something wrong. If you look at the image e_Johny attached in post #819 you can see the clock and data zoomed in on a singe packet. There should be 8 bytes per packet with 9 clock pulses per byte (1 for the ack/nack).

You could also check things with the I2C converter I uploaded to the repository yesterday. SCL should be in the first trace file loaded and SDA in the second. It expects double time values for each transition. Take a look here: https://support.saleae.com/faq/technical-faq/binary-export-format-logic-2. If you manage to get output like what I posted yesterday, it will be much less data and very well compressible, so no problems with uploading.

Maybe your capture device will work with the saleae program as well. It can be downloaded for linux as an appimage and I tried it on ubuntu 16.04 and linux mint 20. Don't have a device yet but I'm able to open the files e_Johny made.

Your efforts are appreciated

[pcprogrammer]

Examining e_Johny's captures of the communication between the FPGA and the special chip brought some light, but it is still quite dark

It looks like the id's 0x11 and 0x0B play a special role in the control of the state of the scope. There is also some interaction with the FPGA for this process. The scope reads two bytes from the FPGA after sending command 0x14. It does some coding on the data and then uses it as input for parameter id 0x11. The data returned after reading the parameter data is used in the code to do things. Not clear what and how.

The parameter id 0x0B is being used with 6 immediate values, but also with variable data. The immediate values are 0 to 5. One variable value I saw in a capture of e_Johny. 6. The special chip sends data back and I think it is a fixed response per input. 0 seems to return 0xAD and 6 0xB8.

If the intention of this special chip was to make hacking the scope difficult they did a good job. 

The hacking keeps on going. Still have ideas and options to get to the bottom of it all. I have a cyclone iv FPGA board lying around, so can try to load the bit stream in it and peek and poke the commands.

[pcprogrammer]

It looks like that what the special chip does for id 0x11 is not that complex.

If I'm correct it just shifts the data 4 bits to the right and adds two.

The scope code takes the two bytes from the FPGA and does the following:

Code: [Select]

uint FUN_8001bec4(void)
{
  byte bVar1;
  byte bVar2;
  uint uVar3;
 
  fpga_write_cmd('\x14');
  bVar1 = fpga_read_data();
  bVar2 = fpga_read_data();
  uVar3 = get_setting(0x11, bVar1 & 0xf | (bVar1 & 0xf) << 0xc | (uint)bVar2 << 4);
  return uVar3;
}


I processed the capture e_Johny made to undo the action done to the FPGA data and show only the parameter 0x11 lines.
The last two bytes of the data in between the second set of brackets show what is received by the chip. (0x7D, 0x97 ==> 0x7D97 ==> 0x07D9)

Code: [Select]

{ 0x00, 0x51, 0x35, 0x79, 0x19, 0xE6, 0x0D, 0xE7 },{ 0x00, 0x21, 0x45, 0x09, 0x69, 0x96, 0x7D, 0x97 },  //Checksum ok  Data: 0x000007D9  Id: 0x11  Len: 1
{ 0x01, 0xCE, 0x6B, 0x5D, 0x58, 0xA7, 0x36, 0xEA },{ 0x01, 0x31, 0x5A, 0x6C, 0x69, 0x96, 0x07, 0xDB },  //Checksum ok  Data: 0x000007DB
{ 0x00, 0xAD, 0xE2, 0xED, 0xCE, 0x31, 0x02, 0x5D },{ 0x00, 0x0A, 0x45, 0x4A, 0x69, 0x96, 0xA5, 0xFA },  //Checksum ok  Data: 0x00000A5F  Id: 0x11  Len: 1
{ 0x01, 0x58, 0xFD, 0xCC, 0xCE, 0x31, 0xAD, 0xC6 },{ 0x01, 0xA7, 0x5A, 0x6B, 0x69, 0x96, 0x0A, 0x61 },  //Checksum ok  Data: 0x00000A61
{ 0x00, 0x66, 0xDC, 0xA0, 0xF0, 0x0F, 0x3C, 0x23 },{ 0x00, 0xFF, 0x45, 0x39, 0x69, 0x96, 0xA5, 0xBA },  //Checksum ok  Data: 0x00000A5B  Id: 0x11  Len: 1
{ 0x01, 0xA4, 0x01, 0x40, 0x32, 0xCD, 0x51, 0x06 },{ 0x01, 0x5B, 0x5A, 0x1B, 0x69, 0x96, 0x0A, 0x5D },  //Checksum ok  Data: 0x00000A5D
{ 0x00, 0x62, 0x5C, 0x1C, 0x70, 0x8F, 0xBC, 0xA3 },{ 0x00, 0x7B, 0x45, 0x05, 0x69, 0x96, 0xA5, 0xBA },  //Checksum ok  Data: 0x00000A5B  Id: 0x11  Len: 1
{ 0x01, 0xFA, 0x5F, 0xC0, 0x6C, 0x93, 0x0F, 0x58 },{ 0x01, 0x05, 0x5A, 0xC5, 0x69, 0x96, 0x0A, 0x5D },  //Checksum ok  Data: 0x00000A5D
{ 0x00, 0x60, 0x54, 0x42, 0x78, 0x87, 0xB4, 0xDB },{ 0x00, 0x71, 0x45, 0x53, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x1E, 0xBB, 0x43, 0x88, 0x77, 0xEB, 0xBF },{ 0x01, 0xE1, 0x5A, 0xA2, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0x68, 0x56, 0x3C, 0x7A, 0x85, 0xB6, 0xC9 },{ 0x00, 0x7B, 0x45, 0x2F, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x55, 0xF0, 0xC6, 0xC3, 0x3C, 0xA0, 0xF5 },{ 0x01, 0xAA, 0x5A, 0x6C, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0x63, 0x7C, 0x1D, 0x50, 0xAF, 0x9C, 0xA3 },{ 0x00, 0x5A, 0x45, 0x24, 0x69, 0x96, 0xA5, 0x9A },  //Checksum ok  Data: 0x00000A59  Id: 0x11  Len: 1
{ 0x01, 0x60, 0xC5, 0xC2, 0xF6, 0x09, 0x95, 0xC4 },{ 0x01, 0x9F, 0x5A, 0x5D, 0x69, 0x96, 0x0A, 0x5B },  //Checksum ok  Data: 0x00000A5B
{ 0x00, 0x9A, 0x0B, 0x13, 0x27, 0xD8, 0xEB, 0x84 },{ 0x00, 0xD4, 0x45, 0x5D, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0xD7, 0x72, 0xC1, 0x41, 0xBE, 0x22, 0x76 },{ 0x01, 0x28, 0x5A, 0xE9, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0x30, 0x04, 0xA2, 0x28, 0xD7, 0xE4, 0x8B },{ 0x00, 0x71, 0x45, 0xE3, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x38, 0x9D, 0x4F, 0xAE, 0x51, 0xCD, 0x99 },{ 0x01, 0xC7, 0x5A, 0x88, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0xA2, 0x48, 0x58, 0x64, 0x9B, 0xA8, 0xC7 },{ 0x00, 0xAF, 0x45, 0x55, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x38, 0x9D, 0x4F, 0xAE, 0x51, 0xCD, 0x99 },{ 0x01, 0xC7, 0x5A, 0x88, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0x91, 0x21, 0x20, 0x0D, 0xF2, 0xC1, 0xAE },{ 0x00, 0xF5, 0x45, 0x44, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x9A, 0x3F, 0x43, 0x0C, 0xF3, 0x6F, 0x3B },{ 0x01, 0x65, 0x5A, 0x26, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0xB6, 0x88, 0x5E, 0xA4, 0x5B, 0x00, 0x21 },{ 0x00, 0x7B, 0x45, 0x93, 0x69, 0x96, 0xCD, 0xEC },  //Checksum ok  Data: 0x00000CDE  Id: 0x11  Len: 1
{ 0x01, 0xC9, 0x6C, 0x4D, 0x5F, 0xA0, 0x3A, 0xD6 },{ 0x01, 0x36, 0x5A, 0x7B, 0x69, 0x96, 0x0C, 0xE0 },  //Checksum ok  Data: 0x00000CE0
{ 0x00, 0xB5, 0xA0, 0xD3, 0x8C, 0x73, 0x40, 0x3F },{ 0x00, 0x50, 0x45, 0x36, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x7C, 0xD9, 0xC6, 0xEA, 0x15, 0x89, 0xDC },{ 0x01, 0x83, 0x5A, 0x45, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0x91, 0x21, 0x30, 0x0D, 0xF2, 0xC1, 0xBE },{ 0x00, 0xF5, 0x45, 0x54, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x53, 0xF6, 0xC2, 0xC5, 0x3A, 0xA6, 0xF3 },{ 0x01, 0xAC, 0x5A, 0x6E, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0x51, 0x35, 0x54, 0x19, 0xE6, 0xD5, 0xFA },{ 0x00, 0x21, 0x45, 0x24, 0x69, 0x96, 0xA5, 0x8A },  //Checksum ok  Data: 0x00000A58  Id: 0x11  Len: 1
{ 0x01, 0x7E, 0xDB, 0xBF, 0xE8, 0x17, 0x8B, 0xDB },{ 0x01, 0x81, 0x5A, 0x3E, 0x69, 0x96, 0x0A, 0x5A },  //Checksum ok  Data: 0x00000A5A
{ 0x00, 0x25, 0xE4, 0x47, 0xC8, 0x37, 0x04, 0x3B },{ 0x00, 0x84, 0x45, 0xE6, 0x69, 0x96, 0xA5, 0x9A },  //Checksum ok  Data: 0x00000A59  Id: 0x11  Len: 1
{ 0x01, 0x28, 0x8D, 0x42, 0xBE, 0x41, 0xDD, 0x8C },{ 0x01, 0xD7, 0x5A, 0x95, 0x69, 0x96, 0x0A, 0x5B },  //Checksum ok  Data: 0x00000A5B
{ 0x00, 0xBF, 0xAA, 0xD7, 0x86, 0x79, 0x4A, 0x25 },{ 0x00, 0x50, 0x45, 0x38, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x9A, 0x3F, 0x43, 0x0C, 0xF3, 0x6F, 0x3B },{ 0x01, 0x65, 0x5A, 0x26, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0x5A, 0x1F, 0x37, 0x33, 0xCC, 0xFF, 0xC0 },{ 0x00, 0x00, 0x45, 0x6D, 0x69, 0x96, 0xA5, 0x9A },  //Checksum ok  Data: 0x00000A59  Id: 0x11  Len: 1
{ 0x01, 0xA1, 0x04, 0x42, 0x37, 0xC8, 0x54, 0x05 },{ 0x01, 0x5E, 0x5A, 0x1C, 0x69, 0x96, 0x0A, 0x5B },  //Checksum ok  Data: 0x00000A5B
{ 0x00, 0x61, 0x74, 0x53, 0x58, 0xA7, 0x94, 0xEB },{ 0x00, 0x50, 0x45, 0x62, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0xDB, 0x7E, 0xC2, 0x4D, 0xB2, 0x2E, 0x7B },{ 0x01, 0x24, 0x5A, 0xE6, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0x5A, 0x1F, 0x07, 0x33, 0xCC, 0xFF, 0x90 },{ 0x00, 0x00, 0x45, 0x5D, 0x69, 0x96, 0xA5, 0xCA },  //Checksum ok  Data: 0x00000A5C  Id: 0x11  Len: 1
{ 0x01, 0x12, 0xB7, 0x43, 0x84, 0x7B, 0xE7, 0xB3 },{ 0x01, 0xED, 0x5A, 0xAE, 0x69, 0x96, 0x0A, 0x5E },  //Checksum ok  Data: 0x00000A5E
{ 0x00, 0x49, 0x77, 0x2E, 0x5B, 0xA4, 0x97, 0xD8 },{ 0x00, 0x7B, 0x45, 0x1C, 0x69, 0x96, 0xA5, 0xEA },  //Checksum ok  Data: 0x00000A5E  Id: 0x11  Len: 1
{ 0x01, 0x7A, 0xDF, 0xCD, 0xEC, 0x13, 0x8F, 0xE5 },{ 0x01, 0x85, 0x5A, 0x48, 0x69, 0x96, 0x0A, 0x60 },  //Checksum ok  Data: 0x00000A60
{ 0x00, 0xE6, 0xD8, 0xFC, 0xF4, 0x0B, 0x38, 0x07 },{ 0x00, 0x7B, 0x45, 0x61, 0x69, 0x96, 0xA5, 0x9A },  //Checksum ok  Data: 0x00000A59  Id: 0x11  Len: 1
{ 0x01, 0xB7, 0x12, 0x4E, 0x21, 0xDE, 0x42, 0x13 },{ 0x01, 0x48, 0x5A, 0x06, 0x69, 0x96, 0x0A, 0x5B },  //Checksum ok  Data: 0x00000A5B
{ 0x00, 0x25, 0xE4, 0x87, 0xC8, 0x37, 0x04, 0x7B },{ 0x00, 0x84, 0x45, 0x26, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x3D, 0x98, 0x46, 0xAB, 0x54, 0xC8, 0x9D },{ 0x01, 0xC2, 0x5A, 0x84, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0xBE, 0x8A, 0xC6, 0xA6, 0x59, 0x6A, 0x15 },{ 0x00, 0x71, 0x45, 0x09, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x8E, 0x2B, 0x42, 0x18, 0xE7, 0x7B, 0x2E },{ 0x01, 0x71, 0x5A, 0x33, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0xF5, 0xB0, 0x23, 0x9C, 0x63, 0x50, 0x2F },{ 0x00, 0x00, 0x45, 0xD6, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0x79, 0xDC, 0xCE, 0xEF, 0x10, 0x8C, 0xD9 },{ 0x01, 0x86, 0x5A, 0x48, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F
{ 0x00, 0xBB, 0x2A, 0xA3, 0x06, 0xF9, 0xCA, 0xF5 },{ 0x00, 0xD4, 0x45, 0xCC, 0x69, 0x96, 0xA5, 0x9A },  //Checksum ok  Data: 0x00000A59  Id: 0x11  Len: 1
{ 0x01, 0xE9, 0x4C, 0xC2, 0x7F, 0x80, 0x1C, 0x4D },{ 0x01, 0x16, 0x5A, 0xD4, 0x69, 0x96, 0x0A, 0x5B },  //Checksum ok  Data: 0x00000A5B
{ 0x00, 0x3A, 0x0E, 0xC6, 0x22, 0xDD, 0xEE, 0x91 },{ 0x00, 0x71, 0x45, 0x8D, 0x69, 0x96, 0xA5, 0xDA },  //Checksum ok  Data: 0x00000A5D  Id: 0x11  Len: 1
{ 0x01, 0xD2, 0x77, 0xC2, 0x44, 0xBB, 0x27, 0x72 },{ 0x01, 0x2D, 0x5A, 0xEF, 0x69, 0x96, 0x0A, 0x5F },  //Checksum ok  Data: 0x00000A5F


The question now is what is going on in the FPGA that makes it return these different values when command 0x14 is read.

[bianchifan]

looking at the images the data still looks as if there is something wrong....There should be 8 bytes per packet with 9 clock pulses per byte

I beg your pardon but I didn't took a closer look at the data for I have only very little I2C skills, normally I do not use.

There should be 8 bytes per packet with 9 clock pulses per byte (1 for the ack/nack).

IIRC I2C data may vary betwenn 7 and 11 bytes and I'm quite shure that 7and 9 are used, even thouhg quite rarely.

Maybe your capture device will work with the saleae program as well.

1st.. I do not think so, 2nd, I'm using FOSS only

To get things done I passed up my bike ride this afternoon and digged instaed in my electronic cementary, at least I found my first LA, a 5in1 Combi from Banggood. I set it to USBee for it worked wih the sigrok FW a couple of years ago.

First, I set SR to 4MHZ, same procedure as before (switch on, doing some stuff, switch off).
Zoomed in to have a closer look at the bytes, not happy due to varying no of samles for same timelength.



Next capture done with 12MHz, better but still varying samples but hopefully good enough...



Zips attached, format is srzip, standard pulseview format

[pcprogrammer]

looking at the images the data still looks as if there is something wrong....There should be 8 bytes per packet with 9 clock pulses per byte

I beg your pardon but I didn't took a closer look at the data for I have only very little I2C skills, normally I do not use.

There should be 8 bytes per packet with 9 clock pulses per byte (1 for the ack/nack).

IIRC I2C data may vary betwenn 7 and 11 bytes and I'm quite shure that 7and 9 are used, even thouhg quite rarely.

A) No problem.
B) We call it I2C, but what they made here is not true I2C. It looks like it, but it won't work with actual I2C hardware. That is why I wrote a conversion program to cater for the mishaps they made.

I will take a look at your captures later to verify my findings. The pictures are promising the data is correct.

And again thanks for doing the work

[pcprogrammer]

Found some FPGA commands from the captured data. Parameter id 0x0C returns 0x20. This is used to write to the FPGA and then read 750 or 1500 bytes. Don't know when it is 750 or 1500 yet, but I added code to the emulator to return data for this command. Also implemented it for 0x21. This one turns out to be for channel 2. The parameter used to get this data is 0x0D. The FPGA command 0x20 is for channel 1.

Still need to figure out what the levels need to be and how the data needs to change for showing a sine wave on the screen. Did manage to get a single square crossing to show on channel 1.

Also found the bit that can make the arrow in the battery level indicator disappear
For the battery level the KEYADC is used. Could implement it, but for now other parts are more interesting.

Edit: Actual square wave showing now.