FNIRSI-1013D "100MHz" tablet oscilloscope

[dfw_ee]

Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.

Thanks

Here is the tool plus the steps to make it work.

!! I take no responsibility if anything goes wrong !!

Steps for making the FNIRSI-1013D firmware backup on a Linux machine:

• Connect the scope to the computer via USB.
• Turn on the scope and start the USB connection via the main menu option.
• Wait until the file manager window opens. (Only if auto mount is working properly)
• Close the file manager window.
• Open a terminal window (ctrl + alt + t) and type the "lsblk" command (!do not use the quotes!) and check which device the scope is on. (~8GB disk)
• Copy the files from the card to have a backup on your computer.
• Un-mount the partition. ("sudo umount /dev/sdc1" in my case)
• Just to be more safe make a backup with dd. ("sudo dd bs=4M if=/dev/sdc of=sd_card_backup.bin" again in my case)
• Open gparted and check if the device is properly formated. (Use right mouse and information to see the sector info)
• If not delete the partition and make a new one leaving 1M free at the start. Format is fat32.
• When the partition remounts after the previous step un-mount it again.
• Use dd to place the backup package on the SD card. ("sudo dd if=fnirsi_1013d_fwb.bin of=/dev/sdc bs=1024 seek=8")
• This will re-mount the partition. Un-mount the partition again. ("sudo umount /dev/sdc1" in my case)
• Turn of the scope and turn it back on. This will start the backup process.
• Wait until it is done and the scope is mounted again. File manager window should open after a while.
• Copy the three files to the computer. (FNIRSI_1013D_full_flash_backup.bin, FNIRSI_1013D_tp_config.bin, FWB_FSI_1013.bin)
• Turn off the scope and turn it back on. It should start normally.

When the scope showed the "!! special touch panel detected !!" message please upload the "FNIRSI_1013D_tp_config.bin" file in this thread.

If your scope uses a smaller or bigger SD card be warned that this is not tested yet. Only 8GB cards have been tested.

See the attached image for info on the sd card sectors. Screen cap from gparted.

Remove the .txt extension from the firmware backup package file.

[engineer.r152]

https://youtu.be/-eb8TvmtihE?feature=shared
Part of the beam displays the current value, and part of the false one

[tokar]

https://youtu.be/J_cZJTdngeQ?feature=shared

This also happens on my device, although to a lesser extent.
https://youtu.be/UYh5JF16DdE

[pcprogrammer]

Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.

Thanks

The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.

The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.

So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.

[Atlan]

https://youtu.be/-eb8TvmtihE?feature=shared
Part of the beam displays the current value, and part of the false one

This is after manually selecting the sampling frequency and time per div or after pressing AUTO. The display with data cannot be seen well in the video

[engineer.r152]

it was not possible to achieve a repeat effect, once it was when switching to a faster scan

[engineer.r152]

the effect was manifested at ACQ 200KSa/s 500us/div and 100KSa 1md

[Atlan]

https://youtu.be/J_cZJTdngeQ?feature=shared

This also happens on my device, although to a lesser extent.
https://youtu.be/UYh5JF16DdE

Upload v0.023u. Start the Base calibration, and upload the image from the calibration with the data here.

[engineer.r152]

v0.023u defect 100KSa 1ms and 50KSa 2ms

[Atlan]

Ok, there's something there. I will find out later.

fast test:

set 200KSa/s and 500us/div, turn the oscilloscope off and on, will the error appear? If the 200us/div option is selected in the ACQ menu, does the error disappear? if 500us/div is selected next in the ACQ menu. does the malfunction no longer appear?

[engineer.r152]

https://youtu.be/b6aEUykkB2I?feature=shared

[Atlan]

And when a sine or rectangular waveform is introduced there, what does it do?

[engineer.r152]

https://youtu.be/DDkhqrzV6Gk?feature=shared
I found out the full error algorithm. when turned on at a frequency of 100/1, everything is as in the video. When an alternating signal is applied, the beam stabilizes. when the signal is removed, the interference returns. If the frequency is lowered by 50/2, the effect is the same, if increased to 500/200, the beam stabilizes, but flickers, if the frequency is increased to 1/100, everything returns to normal. When the frequency is reduced to the early limits, everything works well.
Gaps occur only if you turn on the oscilloscope with a frequency of 200/500 or lower, if you set the frequency above this value before turning it off, then there are no problems in all modes.

[dfw_ee]

Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.

Thanks

The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.

The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.

So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.

I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.

After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.

Thanks for your reply. I hope there is some way to get this working again...

[pcprogrammer]

Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.

Thanks

The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.

The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.

So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.

I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.

After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.

Thanks for your reply. I hope there is some way to get this working again...

Of course there is. By the sound of it your version of the 1013D does not write the configuration to the touch panel and it then indeed got screwed up by using a wrong version of code I wrote.

A bit of background. I wrote lots of test code while working on the reverse engineering to get to the bottom of it all. At some point, after noticing that there are different hardware version of the scope out there, I decided to not write the touch panel configuration, like my first version of the 1013D did and use the touch panel as is to control the scope with the new firmware. To allow for touch panels with the coordinates swapped to still work I added a configuration option to tailor for the different hardware. Same as with the different displays.

So now back to your problem. The way to solve it is to write a correct configuration to the touch panel, and this can be done with any device that has an I2C interface. Keep in mind that the touch panel works on 3.3V, so when using a MCU running on 5V use some 100 Ohm serial resistors and 2K2 to 4K7 Ohm pullup resistors to 3.3V.

The programming guide for the touch panel can be found here.

In the touch panel configuration there are two ways to reverse the coordinates, but I only used the order of the scan lines to do the swap. The data in question starts on address 0x80B7 - 0x80C4 for the y direction and 0x80D5 - 0x80EE for the x direction. I might be mistaken which is for which. Doing this from memory.

When you have a bluepill lying around you can take a look at the project here.

[dfw_ee]

Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.

Thanks

The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.

The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.

So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.

I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.

After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.

Thanks for your reply. I hope there is some way to get this working again...

Of course there is. By the sound of it your version of the 1013D does not write the configuration to the touch panel and it then indeed got screwed up by using a wrong version of code I wrote.

A bit of background. I wrote lots of test code while working on the reverse engineering to get to the bottom of it all. At some point, after noticing that there are different hardware version of the scope out there, I decided to not write the touch panel configuration, like my first version of the 1013D did and use the touch panel as is to control the scope with the new firmware. To allow for touch panels with the coordinates swapped to still work I added a configuration option to tailor for the different hardware. Same as with the different displays.

So now back to your problem. The way to solve it is to write a correct configuration to the touch panel, and this can be done with any device that has an I2C interface. Keep in mind that the touch panel works on 3.3V, so when using a MCU running on 5V use some 100 Ohm serial resistors and 2K2 to 4K7 Ohm pullup resistors to 3.3V.

The programming guide for the touch panel can be found here.

In the touch panel configuration there are two ways to reverse the coordinates, but I only used the order of the scan lines to do the swap. The data in question starts on address 0x80B7 - 0x80C4 for the y direction and 0x80D5 - 0x80EE for the x direction. I might be mistaken which is for which. Doing this from memory.

When you have a bluepill lying around you can take a look at the project here.

Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!

[Atlan]

PC:
Where do these numbers come from?

1800,   //200ms/div 12
    1800,   //100ms/div
    1800,   // 50ms/div
    1800,   // 20ms/div (Was 800, but that does not yield enough samples)
    1800,   // 10ms/div
    2500,   //  5ms/div
    2500,   //  2ms/div
    2500,   //  1ms/div

[pcprogrammer]

Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!

Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.

[pcprogrammer]

PC:
Where do these numbers come from?

1800,   //200ms/div 12
    1800,   //100ms/div
    1800,   // 50ms/div
    1800,   // 20ms/div (Was 800, but that does not yield enough samples)
    1800,   // 10ms/div
    2500,   //  5ms/div
    2500,   //  2ms/div
    2500,   //  1ms/div

Probably from the original code. The number of samples read from the FPGA, but don't think this is still used in the code.

Consider the way it all came together as being chaotic, and not well structured. There will be bits and pieces that are not used anymore.

[Atlan]

Those numbers are sent to the FPGA

//short time base
void fpga_set_time_base(uint32 timebase)
{
  //Make sure setting is in range
  if(timebase < (sizeof(timebase_settings) / sizeof(uint32)))
  {
    //Write the command to set the short time base data to the FPGA
    fpga_write_cmd(0x0E);
   
    //Table settings ranges from setting 0 (200mS/div) to 23 (5nS/div)
    fpga_write_int(timebase_settings[timebase]);

const uint32 timebase_settings[35] =
{//long time base
    1800,   //50s/div
    1800,   //20s/div
    1800,   //10s/div

It worked until now, I don't understand why it broke. The numbers are always sent the same. It looks like the fpga has finished filling the magazine early. I don't know if they didn't feel the flood numbers because sometimes only 750 samples are taken. because 1500 samples are taken, the times are short and the collection is finished sooner. But again, it doesn't agree, so why does it somehow work when switching to a higher number and then back to sleep (however, some sampled data is still missing at the end.)

I increased the number, but that's a bad solution because I don't know where the problem actually is.

FIRMWARE v0.023x

[Atlan]

Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!

Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.

#ifndef USE_TP_CONFIG
#ifdef SAVE_TP_CONFIG
void save_tp_config(void)
{
  //Create a file for the touch panel configuration. Fails if it already exists
  if(f_open(&viewfp, "FNIRSI_1013D_tp_config.bin", FA_CREATE_NEW | FA_WRITE | FA_READ) == FR_OK)
  {
    //Write the touch panel configuration to the sd card
    f_write(&viewfp, tp_config_data, sizeof(tp_config_data), 0);

    //Close the file to finish the write
    f_close(&viewfp);
  }
}
#endif
#endif

//----------------------------------------------------------------------------------------------------------------------------------
//Touch panel configuration for the GT9157 set to 800x480 resolution

#ifdef USE_TP_CONFIG
#define USE_LR_CONFIG

#ifdef USE_LR_CONFIG
uint8 tp_config_data[] =
{
  0xFF, 0x20, 0x03, 0xE0, 0x01, 0x0A, 0xFD, 0x00, 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77,
  0xB2, 0x04, 0x00, 0x00, 0x00, 0x9A, 0x01, 0x11, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08, 0x00, 0x00, 0x04, 0xA1, 0x55, 0x00, 0x8F,
  0x62, 0x00, 0x7F, 0x71, 0x00, 0x73, 0x82, 0x00, 0x69, 0x95, 0x00, 0x69, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
  0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0xFF, 0xFF,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x01
};
#else
uint8 tp_config_data[] =
{
  0xFF, 0x20, 0x03, 0xE0, 0x01, 0x0A, 0xFD, 0x00, 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x1A, 0x1E, 0x14, 0x8B, 0x2A, 0x0C, 0x75, 0x77,
  0xB2, 0x04, 0x00, 0x00, 0x00, 0x9A, 0x01, 0x11, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08, 0x00, 0x00, 0x04, 0xA1, 0x55, 0x00, 0x8F,
  0x62, 0x00, 0x7F, 0x71, 0x00, 0x73, 0x82, 0x00, 0x69, 0x95, 0x00, 0x69, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x18, 0x16, 0x14, 0x12, 0x10, 0x0E, 0x0C, 0x0A, 0x08, 0x06, 0x04, 0x02, 0xFF, 0xFF, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x22,
  0x21, 0x20, 0x1F, 0x1E, 0x1D, 0x1C, 0x18, 0x16, 0x13, 0x12, 0x10, 0x0F, 0x0C, 0x0A, 0x08, 0x06,
  0x04, 0x02, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x01,
};
#endif
#endif

#ifdef USE_TP_CONFIG
  //Clear the checksum before calculating it
  checksum = 0; 
 
  //Calculate checksum over the configuration data (first 184 bytes)
  for(i=0;i<184;i++)
  {
    checksum += tp_config_data;
  }
 
  //Do the last action to make it the correct checksum
  checksum = ~checksum + 1;
 
  //Put the checksum in the buffer
  tp_config_data[184] = checksum;
 
  //Send the configuration data
  tp_i2c_send_data(TP_DEVICE_ADDR, TP_CFG_VERSION_REG, tp_config_data, sizeof(tp_config_data));
#else

[pcprogrammer]

Those numbers are sent to the FPGA

//short time base
void fpga_set_time_base(uint32 timebase)
{
  //Make sure setting is in range
  if(timebase < (sizeof(timebase_settings) / sizeof(uint32)))
  {
    //Write the command to set the short time base data to the FPGA
    fpga_write_cmd(0x0E);
   
    //Table settings ranges from setting 0 (200mS/div) to 23 (5nS/div)
    fpga_write_int(timebase_settings[timebase]);

const uint32 timebase_settings[35] =
{//long time base
    1800,   //50s/div
    1800,   //20s/div
    1800,   //10s/div

It worked until now, I don't understand why it broke. The numbers are always sent the same. It looks like the fpga has finished filling the magazine early. I don't know if they didn't feel the flood numbers because sometimes only 750 samples are taken. because 1500 samples are taken, the times are short and the collection is finished sooner. But again, it doesn't agree, so why does it somehow work when switching to a higher number and then back to sleep (however, some sampled data is still missing at the end.)

I increased the number, but that's a bad solution because I don't know where the problem actually is.

v0.023x

Ah it is coming back slightly. At first I thought the 0x0E to be for the short timebase settings, but it is something else, and I need to look at the reversal of the FPGA to see what it is actually used for. 0x0D is to set the sample clock, as discussed earlier. If I recall correctly it has something to do with the number of samples after the trigger, but I'm not sure.

Don't have time to look at it now. Maybe later today.

Does this mean that you are using the actual sampling system to do the long timebase settings? The original does not.

[Atlan]

No, I use the same system as the original.

It seemed easier to modify the constant tables to include the data needed for the long base.  But since those tables are used everywhere, even if some data for long mode are not necessary, I had to supplement them so that the dimensions of the tables fit.  It was probably not a good idea.

In addition, I have the feeling that adding another 2 values ​​would make it agree.  The situation is even worse.  So I suspect that the values ​​between the sampling frequency and the time base value do not match.  Since it is in the code, the question is whether it was ok before, but it was working before.
At the same time, the values ​​written on the LCD correspond to what should be sent to the fpga.

[pcprogrammer]

I'm looking at the setup in the FPGA. 0x0E command writes into a register named "time_base_set". When the sampling system is reset with command 0x01 and data 0x01, a counter named "time_base_cnt" is reset. This counter counts up on the sample write clock.

When this counter becomes larger then the "time_base_set" value a flag named "time_base_timeout" is set.  In auto mode this stops the sampling. In normal mode the sampling only stops when there has been a trigger and enough samples have been collected.

It is a stupid setup but you have to do with it. 

So the conclusion is that this value sets the number of samples collected in auto mode. It is less for the slower rates to diminish the wait time.

[Atlan]

I'm thinking about what it's good for... Or what it could be used for.  If the trigger was turned off, it would be possible to collect the set number of samples with this system.  The question is what time_base_cnt the clock - does it depend on the sampling frequency?

About 0.023x works, so far no one has reported a problem.  We'll see what the user does with the touchscreen, because the oscilloscope code contains things to write to the touchscreen.