FNIRSI-1013D "100MHz" tablet oscilloscope

[Russell2024UK]

Wow, Atlan, you're so clever! It works perfectly for me. 😊 A switch to toggle the feature on and off, like you suggested, would be really useful. It's ideal—I can now measure accurate distances across the entire area! If it's not too much trouble, would it be possible to add voltage measurements in the future? I’d really appreciate it. Thank you again for all your help! 

[Atlan]

In the diagnostics menu, there is a cursor locking switch. The default is to lock cursors. I doubt that anyone will turn it off...
v0.025s needs to be tested, but I don't expect any problems.

[Russell2024UK]

Hi Atlan,Thanks  for the new firmware update (V0.025s to lock cursors ) – I’ve downloaded it and noticed that you’ve now included voltage Cursor as per Time measurement, which is great! The addition of the cursor locking switch is ideal as well. I’ve tested it, and everything is working superbly as expected. Very happy with the update and its features.Thanks again! 

[Russell2024UK]

Hi Atlan, Could you help investigate something for me ?  I've noticed a very slight issue with two FNIRSI 1013D oscilloscopes, as shown in the pictures provided. Both have a vertical line kink halfway up the image when using certain firmware versions, but the original firmware doesn't display this kink on the image when using the built-in 1kHz square signal.
Picture 1: Shows both oscilloscopes with different firmware versions—V0.025q and V0.025s.
Picture 2: A zoomed-in image of firmware V0.025s showing the vertical kink.
Picture 3: A zoomed-in image of firmware V0.025q showing the same vertical kink.
Picture 4: The original firmware showing no vertical kink at all. Additionally, I've included the calibration screen pictures for both oscilloscopes. For accuracy, I used x10 oscilloscope probes during this test. Thanks again for looking into this! Thanks again 

[pcprogrammer]

That is not a bug nor wrong. If any, the original firmware is wrong.

A signal has rise time and even if it is very fast, the scope itself is not due to its filters. The new firmware plots the signal in a standard x, x+1 way, so the last pixel of the square low period is on x, and the first pixel of the square high period is on x+1, hence the need for the vertical line to have what you call a kink in it.

To make this smooth dithering could be applied, but that makes the code more complex and slower. To make it straight the code needs to scan the samples to see if there is an almost instant change in the signal and then make it a straight vertical line. And this would be falsifying what you see, which is what the original firmware does a lot.

In the new firmware what you see is much closer to the real world signal. Sampling is based on making discrete steps in time, which leads to what you see. Sample A is behind in time on sample B, so no line can be straight in the vertical direction. Due to noise it ain't always straight in the horizontal direction either.

Even using a sinc filter would not improve on this issue.

My advice is to study the theory of signal behavior and sampling and use a proper scope for comparisons instead of making comparisons between the original firmware and the new firmware.

The FNIRSI 1013D is and stays a cheap scope and will never become as good as even the cheapest Rigol or Siglent scopes. Even the Hantek DSO2000 series is better than this FNIRSI will ever be, no matter what amount of software or FPGA configuration development you throw at it. The hardware is seriously limiting.

[ECJ]

The big disadvantage of this is that, even in large proportions of time per division, this happens leaving a very ugly appearance in the signal. Maybe include something like math.floor to ignore variations that are irrelevant to the display. Forgive me if I'm talking nonsense.

[pcprogrammer]

The big disadvantage of this is that, even in large proportions of time per division, this happens leaving a very ugly appearance in the signal. Maybe include something like math.floor to ignore variations that are irrelevant to the display. Forgive me if I'm talking nonsense.

A possible improvement, as mentioned before, is using a sinc filter on the sample data. This would improve on higher frequency signal appearance by filling in the missing points with sine based curves instead of the linear approximation used now.

I have no idea how much processing time this would take, but since it is being used on lots of scopes with not much more processing power it should be ok. Maybe Atlan is willing to look into this, but for me it is not on my project list for the foreseen future.

[dougduck]

"Even the Hantek DSO2000 series is better than this FNIRSI will ever be..."

Here you exaggerated! 

Hantek is a Linux oscilloscope software.
And they don't have enough hardware to run the Linux kernel well, for this reason it is slow and constantly crashes, overloads the memory which easily damages it.
It may even have better specifications, but it is too much hassle that it is not worth it. 

[Aldo22]

And they don't have enough hardware to run the Linux kernel well, for this reason it is slow and constantly crashes, overloads the memory which easily damages it.
It may even have better specifications, but it is too much hassle that it is not worth it. 

I have a DSO2000 and mine doesn't crash.
Of course it runs a bit on the limit, but that's to be expected for the price.
I get on well with it and think it's in a higher class than these Fnirsis (from what I've seen), despite some issues it admittedly has.
Just 50mV/div vs 2mV/div is a different world.

[bffargo]

Version S looks great, including the locked cursors.

One tiny thing I noticed if you're ever back in the code area - The battery % is one pixel line too low from center within the battery icon:

[Atlan]

I thought there was an odd number of pixels.  Ok, I'll move it.

[pcprogrammer]

"Even the Hantek DSO2000 series is better than this FNIRSI will ever be..."

Here you exaggerated! 

Hantek is a Linux oscilloscope software.
And they don't have enough hardware to run the Linux kernel well, for this reason it is slow and constantly crashes, overloads the memory which easily damages it.
It may even have better specifications, but it is too much hassle that it is not worth it. 

No I did not. I own a DSO2D10 and it works fine, as long as you don't tweak the knobs to fast according to what I read about it here on the forum. I have not have it crash on me once, but to be fair, I don't use it that much.

The one benefit of the FNIRSI with the new open source firmware is that it starts up really fast. Of all the scopes I own it starts up the fastest. Hantek is second, Yokogawa third and Rigol last.

But the Hantek could become just as fast as the FNIRSI if someone reverse engineers it and writes a bare metal version of the scope software for it. But that will be a time consuming project. It uses the same MCU as the FNIRSI, so some of the work done for the FNIRSI can be re used to get something running, but finding all the FPGA control commands will take its time.

[Atlan]

v0.025t move battery value one pixel up,scope_prepare_setup_for_file fix lock cursors, reset comp value

[Atlan]

To know what adc comp compensates for.  In the rhythm of the sampling frequency, ad converters record something like in the picture.  And that is a compensation of 2 and - 2 (some here have 4 and - 3)

[Atlan]

Small problem, this fpga does not have flash... Will the content be blocked against reading?  I'm afraid that the pin assignment is also different.