FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

It is indeed caused by the calibration for the difference between the two ADC's. On the original firmware this phenomenon is also seen in the 25ns and 10ns per div settings, but only when the second ADC gives a lower reading then the first ADC and thus needs a positive compensation. When the first ADC returns 0, the second one also returns 0, but the compensation in the software is added, making it a ripple. In my test scope the compensation is 7, and after signal adjusting for the current volt per div setting it is cranked up to 12. This is quite the step on the display.

Since in my firmware both ADC's are used for all ranges it shows this all the time when the signal is near the bottom.

Fixed it with a check on only compensating when the sample is above zero, but probably needs checking on the other ADC output to only compensate when that value is high enough.

Things would have been so much simpler if the original developers did not make these weird design decisions. The whole trace offset should have been kept in the software domain.

[Alex62]

CH1 is a 5 MHz meander, CH2 is a 10 MHz sine.

[morris6]

Testing your new firmware on my box: Same thing. What makes me wonder is that this triangles on the bottom edge are only visible on the blue channel trace. And co-incide with the sampling rate, one triangle has a base of 2 x 5 ns: 10 ns. And.. while the traces are jittering left to right the triangles remain in place.

Now with slower signals, like 500 kHz and 1 MHz the traces look 'fuzzy'. And where the blue trace touches the bottom edge a nice zig-zag pattern is displayed.

At slower time base setting, like 1us/div the blue trace, nearing the bottom edge, sometimes flattens out about have a division above the bottom edge. Is this because only one adc per channel is used, no interleaving?

When the cause of the fuzzyness of the traces is 'not proper calibration / equality' of both adc in the channel, as a faint triangle pattern is visible in both traces, why is number 1 channel not giving the same pattern when the signal reaches the bottom?

In my opinion when the trace reaches the edge of the diplay area the trace should simply disappear. The trace along the edge of the display area can be interpreted wrongly as a valid signal. Maybe show an arrow near the trace indicator on the left edge to indicate over-limit?

About the FPGA: loading a new program with OpenOCD fails at 95% progress, something in the settings is not correct yet....

[pcprogrammer]

Hi Maurits,

as can be seen on  Alex62 his box it has to do with the calibration between the two ADC's used for a single channel. In his box it is channel 1 that has this problem. Only happens when the compensation value is positive. You are right that a more proper way of handling this would be limiting the signal to allow it to stay within reach of this calibration value. This means that for both ADC's the signal needs to be cutoff  below the calibration value.

This is something that needs to be incorporated in the FPGA.

To bad the programming of it is still problematic. Have you considered just making a ROM image of your bitstream and write it to the FLASH and test if it works that way?

[morris6]

Hallo Peter,

This calibration issue is difficult for me to grasp at the moment. The per channel interleaved adc's should give equal results, otherwise noise is produced. But how one channel influences the other here..?

Later last evening I got programming the FPGA working, although my prepared test was not running. OpenOCD's svf programmer reported 0 faults and my CONF-DONE indicater changed from red to green. Issue is, how I see it now, the clone usb-blaster. It always runs full speed, 25 MHz or so. When I added the -d switch on the command line for troubleshooting it worked. The process is then slowed down because OpenOCD has to spew 'everything' to the terminal.

To be continued..

[pcprogrammer]

Hi Maurits,

good to hear you were able to program the FPGA, but it not doing what you thought is a bummer. Keep trying

Due to mismatch in the ADC chip it is possible that the two conversions are slightly of. When grounded the input should be stable and the same on both inputs, so if there then is a difference between the readings of the two ADC's, there is a need to compensate for it, because otherwise that would give noise in the interleaved data. To adjust for this the reading of one of the ADC's needs to be adjusted with the measured difference. This can be either positive or negative depending on how they differ from each other. (An other option is to make it meet in the middle, so compensate both ADC's)

When it is negative the software, as it is now, just keeps it on zero when the reading is below the compensation value. This does not lead to the ripple. When it is positive the software always added the value, giving problems near the bottom. The other ADC will be zero later then the one that is compensated, and when that happens the compensation starts to make the ripple. In my case: ADC1 = 0, ADC2 = 0 + 7, ADC1 = 0, ADC2 = 0 + 7, etc.

It is not that the one scope channel is influencing the other scope channel. Each scope channel has two ADC's connected to it.

It should not be to hard to solve this in hardware, but I do have to think about a good solution.

[pcprogrammer]

Started with the reversal of the baseline calibration code to get a better understanding about the working of the FPGA. A lot of what is done is the same as for the short time base acquisition but I did notice a difference. In the normal acquisition the FPGA command 0x0F is written with a 0 before the capture process and a 1 after the command 0x0A signals there was a trigger or a full buffer. At the start of the calibration process the command 0x0F is written with a 1.

This leads me to think the 0x0F command signals the usage of the trigger logic. For the calibration there is no signal so no need to wait for a trigger.

It is a big chunk of code, so it will take some time to dig through it all.

[pcprogrammer]

I pulled the Rigol out the cupboard to do some measurements on the FNIRSI, because I kept wondering about this trace offset that is done in the FPGA. It turns out it uses PWM to shift the other inputs on the ADC's.

When reverse engineering the schematic I did notice connections from the FPGA to the analog side of the ADC's, which I named ADC_OFFSET, but figured this was for some zero offset on the channels. It uses PWM on a 25KHz square wave signal (To phrase George Clooney, what else  ) to make an offset voltage. This PWM is controlled with the movement of the trace on the display. So now I know why it needs to be set in the FPGA, and also that it offers room to do it differently.

Calibrate the signal when grounded or not connected to mid ADC range and keep it on that. Do the trace displacement on screen fully in software.

Also measured another thing I was wondering about. Is the clock of the ADC's always on 100MHz or does it change when the time base is changed. Turns out it lowers the clock on the ADC's. With my firmware, when set to 200KSA/s the clock on the ADC's is 100KHz. So no FPGA DSP implementation to prevent aliasing. (Which we already knew )

As to be expected, the calibration code is also full of crappy code. The first bit I checked is for the trace offset calibration, so I now have some insight in the values used.

Well the story continues

[1audio]

However if you move the trace at the input of the ADC you can use All of the ADC for the active signal. If you move on screen you need to have 2X screen height info to not run out of screen. With an 8 bit ADC you have 256 levels to work with. I think the screen probably has 256 vertical pixels if not 480 vertical pixels. If you use software to move the display you quickly need some good software to interpolate or at least hide the reduced resolution. Maybe this is why the DSO's I've used do not have a vertical zoom, nothing to show there.

[pcprogrammer]

Sure, shifting the input signal this way allows for the full ADC range to be on the display. As it is now it already does a fractional multiplication to match the volt per division setting. But that being said, I have noticed that, when switching between sensitivity settings, the center alignment is often of, with the line either above or below the indicator. This can, to my opinion, be avoided with proper zero adjustment per volt per div setting.

Something to experiment with.

[x86guru]

They need a better name. "FNIRSI" how does one pronounce that?

I think it might be an acronym?

F - Fictional
N - Non-triggering
I - Imaginary
R - Real-time
S - Sampling
I - Instrument

[pcprogrammer]

They need a better name. "FNIRSI" how does one pronounce that?

I think it might be an acronym?

F - Fictional
N - Non-triggering
I - Imaginary
R - Real-time
S - Sampling
I - Instrument

Good one 

[pcprogrammer]

Worked through the calibration code. Was not to complex and basically does two tasks.

• Find the calibration values for the trace offset
• Get the ADC1, ADC2 adjustment value

The code can be reduced, but may need changes based upon how I'm going to do the trace offset on the screen. Also need some experimenting with the system since it is using a call to the special ic. Command 0x12, which does some magic on two values found for the trace offset calibration.

Uploaded my work files and the updated Ghidra archive to the repository: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Software%20reverse%20engineering

[voltsandjolts]

I don't know what the circuit for this FNIRSI is like, but normally having the ability to apply a dc offset in the analog domain is an important characteristic of any scope. It's not just to move the trace up and down on the screen. It's main purpose is to allow the input amplifiers to function over a wider input range when in dc coupling mode and when the input signal has substantial dc offset, that would otherwise cause input amplifier saturation. Without that feature, the only option for the user would be ac coupling mode, which would be inadequate where there is low frequency signal of interest with large dc offset. I would advise to keep the pwm offset adjustment in the analog domain.

[pcprogrammer]

Hi voltsandjolts,

thanks for this info. The problem with this hardware is that the DC offset is not on the front end circuitry and therefore does not help in amplifier saturation. It is on the "negative" input of the ADC, so the signal is already through the amplifier before any shifting is done.

So in this case it only allows for the whole 256 bits of the ADC to still be on the screen when the trace is moved to either the top or the bottom. If this is useful on this scope, I don't know. One thing is for sure, it needs improvement to keep the center of the trace on the center pointer, because that is not always the case.

At the moment looking into the auto setup code, so more digging through the original code.

[voltsandjolts]

The problem with this hardware is that the DC offset is not on the front end circuitry and therefore does not help in amplifier saturation. It is on the "negative" input of the ADC, so the signal is already through the amplifier before any shifting is done.

 

Ahh, just found your schematic. Oh well, it is what it is.

[pcprogrammer]

While going through the auto setup and 50% trigger code I stumbled upon a possible option for improvement in the lower sample frequency ranges.

For the original long time base settings (50s/div - 100ms/div) the scope uses FPGA commands 0x24 and 0x26 for the two channels and reads 10 samples per time element and averages these. It turns out these 10 samples are not mandatory, because in the auto setup function it only reads 1 sample per channel in a variable timed loop. It reads 1000 samples and the interval between each sample increases.

I have to experiment with this, but it might provide a way to do timer based sampling and triggering in the software. It is hopefully possible to do 100KSa/s or maybe 500KSa/s this way with a large enough buffer to hold ~3s worth of samples. It then becomes a possibility to do a better FFT for audio signals.

Also a better implementation of a roll mode belongs to the possibilities.

So back to the drawing board and see what time brings

Edit:  Just hooked the Rigol to the ADC clock to see what it does.  Unfortunately the clock frequency for the long time base settings seems to be fixed to 50KSa/s. Still an option to improve on the 2ms/div to 200ms/div with trigger and longer sample buffers, but for audio not good enough.

[pcprogrammer]

Coded and tested the trace offset calibration and ran into the problem that channel 2 came out OK, but channel 1 failed. Since it uses the special IC with parameter 0x12 to get some data I could not get it right on my simulator, so I wrote a bit of test code to write the results of the calls to the special IC to a file. It turns out it uses signed integers for the calculations, which was not clear from the Ghidra output.

Modified my code to also use signed integers and now it works like a charm, except for the same problem as the original. It is not consistent throughout the sensitivity settings.

I'm going to write a bit more test code to get a better insight into the special IC. With FatFS running it is now very simple to accomplish this.

I'm also updating both the scope projects (the original and the new code) with this, so it is still an option to finish the original reversal.

Still need to do the interleaving ADC compensation calibration and when that is done I will update the repository.

Attached the file with the output of the special IC data returned for parameter 0x12. Below is the code used to make it.

Code: [Select]

  //Data read out special IC
  if(f_open(&viewfp, "special_ic_data.txt", FA_CREATE_NEW | FA_WRITE) == FR_OK)
  {
    uint32 offset;
    uint32 offset1;
    uint32 offset2;
    int8   valuestring[100];
    int8  *ptr;
    
    int8 headerstring[] = "low,high,result\n";

    f_write(&viewfp, headerstring, sizeof(headerstring) - 1, 0);

    for(offset1=200;offset1<=1500;offset1+=50)
    {
      for(offset2=1500;offset2>=200;offset2-=50)
      {
        offset = fpga_read_parameter_ic(0x12, (offset1 & 0x0000FFFF) | (offset2 << 16));

        ptr = scope_print_decimal(valuestring, offset1, 0);
        *ptr++ = ',';
        
        ptr = scope_print_decimal(ptr, offset2, 0);
        *ptr++ = ',';
        
        ptr = scope_print_decimal(ptr, offset, 0);
        *ptr++ = '\n';

        f_write(&viewfp, valuestring, ptr - valuestring, 0);
      }
    }

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

    //Show the saved successful message
    scope_display_file_status_message(MESSAGE_SAVE_SUCCESSFUL, 1);
  }

[pcprogrammer]

Discovered I made an error in my version of the code to communicate with the special IC. When input bytes are not used the original code set them to dedicated values. This is also in my code, but instead of doing it based on the actual input value it also changed in between zero bytes.

Corrected it and the output of the special IC for parameter 0x12 now makes more sense

It was this

Code: [Select]

  //Load the data bytes with the value
  parameter_buffer[3] = (uint8)(value >> 24);
  parameter_buffer[4] = (uint8)(value >> 16);
  parameter_buffer[5] = (uint8)(value >> 8);
  parameter_buffer[6] = (uint8)(value);

  //Check if MSB is actually used
  if(parameter_buffer[3] == 0x00)
  {
    //Set the MSB to a fixed value if not used
    parameter_buffer[3] = 0x69;
    
    //Take one of the length
    length--;
  }

  //Check if MLSB is actually used
  if(parameter_buffer[4] == 0x00)
  {
    //Set the MLSB to a fixed value if not used
    parameter_buffer[4] = 0x96;

    //Take one of the length
    length--;
  }

  //Check if LMSB is actually used
  if(parameter_buffer[5] == 0x00)
  {
    //Set the LMSB to a fixed value if not used
    parameter_buffer[5] = 0x99;

    //Take one of the length
    length--;
  }

And changed it to this

Code: [Select]

  //Load the data bytes with the value
  parameter_buffer[3] = (uint8)(value >> 24);
  parameter_buffer[4] = (uint8)(value >> 16);
  parameter_buffer[5] = (uint8)(value >> 8);
  parameter_buffer[6] = (uint8)(value);

  //Check if MSB is actually used
  if(parameter_buffer[3] == 0x00)
  {
    //Set the MSB to a fixed value if not used
    parameter_buffer[3] = 0x69;
    
    //Take one of the length
    length--;

    //When MSB is not used check if MLSB is actually used
    if(parameter_buffer[4] == 0x00)
    {
      //Set the MLSB to a fixed value if not used
      parameter_buffer[4] = 0x96;

      //Take one of the length
      length--;

      //When MSB and MLSB are not used check if LMSB is actually used
      if(parameter_buffer[5] == 0x00)
      {
        //Set the LMSB to a fixed value if not used
        parameter_buffer[5] = 0x99;

        //Take one of the length
        length--;
      }
    }
  }

It looks like the IC subtracts the two input values and multiplies the result with 100. It is still prone to error though. Some values are zero in one readout, but the correct value in the next.

If possible I would like to avoid using this special IC, but earlier tests showed it to be needed. Will do more tests on it.

[morris6]

Some findings and thoughts about the FPGA:

The earlier 1013D scopes contain an Altera EP4CE6E22. Later ones have an unidentified type that was considered a clone of the Altera one. First findings after connecting with JTAG: the IDCODE doesn't match. OK, tried some configuration with a simple program with OpenOCD. Didn't work. As a last resort I considered uploading the simple program to the flash rom of the FPGA. Before doing this I checked the contents of this flash once more: The contents is too short for a real Altera EP4CE6. Only 282866 bytes, 2.262.928 bits, where EP4CE6 expects 368011 bytes, 2.944.088 bits.

The conclusion is: the unknown FPGA is not a clone but some other FPGA chip..? For now my re-programming experiments end here.

Maybe someone has an idea about what actual FPGA chip the later model scope contains?

[pcprogrammer]

Hi Maurits,

that is a disappointment. Maybe it is possible to find some information based on the jtag id you got from the device.

When it is some proprietary FPGA the chance of getting the programming software for it is very slim.

Well then we just have to do with what it is. My experiments are giving me some new insights. Before reading the sample data the command 0x1F needs to be written with some 16 bit data. This can't be random or fixed. When not sending the command the readout becomes very unstable and weird. When set to a fixed number the signal won't trigger. So it looks like some trigger point select in the buffer. Needs further investigation.

I uploaded the new calibration code to the repository. Also incorporated it in the simulator.

[pcprogrammer]

I looked back in the thread to find the postings of tv84 about e FPGA. These are on page 25 and 27. It looks like he did not check the header of the uncompressed version, but only made an image showing the bit patterns.

The compressed version has the cyclone iv device id.

I don't know how the header is arranged, but looking at the bytes I do see the jtag id morris6 found.

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
CC 55 AA 33 F0 00 00 06 18 00 6C 31 0B B7 C2 00 00 06 D1 00 05 00 E9 93 C3 00 00 06 D7 B0 4B B0
AF F0 C7 00 00 06 04 33 01 01 A6 53 C8 00 00 06 00 00 04 80 98 88 C1 00 00 06 00 1C 00 00 92 0D
C4 00 00 06 02 00 00 20 6B 60 F1 00 00 04 00 00 78 AF EC F0 04 33 00 00 B0 00 00 00 00 00 02 C0


Does this indeed mean they changed the design and selected another FPGA?

[pcprogrammer]

Turns out the root of a lot of the scopes problems are caused by that special IC connected to the FPGA.

I don't know why earlier testing failed, when I used the FPGA commands for reading the samples directly, without the translation via the special IC, but I changed the code to do it without them and now it works. Also removed the translation of the volt/div setting via this IC, and that solves the occasional zeroing of the traces.

On earlier tests I could see the traces flash as a straight line on the bottom of the scope once in a while.

The tests I ran today showed that at random the readings form the special IC fail. The software then returns a zero, and when multiplying with this value the result is zero

Also found that the brightness translation is based on a simple formula: (brightness * 560) + 4000.

Another finding is that the FPGA command 0x0D is used for setting the sample clock. For the long time base settings in the original code this is always set with 2000, which seems to be equal to 50KSa/s. For the other time base settings the values go from 99999999, 39999999, 19999999, ..... 99, 39, 19, 9, 3, 1, 0, ... 0.
The zero value is for 200MSa/s.

This means it should be possible to select a higher clock for software/timer based sampling. But this needs to be tested.

The last thing I have to look into regarding this special IC is parameter 0x11. This is used for reading the sample data and has to do with the trigger point. Failure at this point will result in the trigger point not being on the correct spot, so I would like to get rid of this translation too, but it is a bit harder to determine the range of the input values, since it is read from the FPGA after a trigger has been detected.

So a bit more testing and researching to do.

[pcprogrammer]

Investigation done. Had already noticed what it did in earlier investigations, but had forgotten about it Testing verified the earlier observation is indeed correct.

The special IC just shifts the input data 4 bits to the right and adds 2.

So here are two new test versions. One for the standard display and one for the shifted display. It still is a bit wobbly, but much better then before. Disconnecting the USB cable also helps

The baseline calibration is working, but the values are not saved to the FLASH.

[pcprogrammer]

Trying to figure which FPGA FNIRSI could have used. The jtag IDCODE (18006C31) morris6 found does not help a bit. I wonder how many new players there are on the FPGA field. Found Anlogic and their Eagle series might fit the bill. But as per usual with the Chinese stuff not a lot of documentation can be found.

The Eagle-4 and Eagle-10 seem to be available in 144 TQFP package, but can't find the pin out for it 

Someone an idea on this?