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.

[pcprogrammer]

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.

So the one in the picture uses another Anlogic FPGA. I believe this one has more block memory than the AL3-10, but less logic cells (LUT's). They also switched to this one in different products of them, like new releases of the 1014D. Most likely a newer family and maybe the AL3 is becoming obsolete.

Finding Anlogic documentation is a bit problematic. For some documents you need a login, but I did find a document about the EF2S45 https://www.anlogic.com/En/Skippower/downloadFile/id/48/mid/98.html. It mentions internal FLASH for the configuration and PSRAM for memory storage. The latter is probably not in the version used in your device, since it is an EF2L45.

Don't know how much difference there is in pinout between the two.

If the configuration data is blocked from reading can only be found out if more information about the FPGA is known. Maybe someone who has a login on the Anlogic site can download them and post them here. Might need translation to English though.

[Atlan]

i find this https://github.com/nviennot/reversing-mono4k/tree/main/firmware

[pcprogrammer]

I looked into it a bit further and found that:

• L version is FPGA with FLASH
• M version is FPGA plus FLASH plus Cortex-M3 core
• S version is FPGA plus FLASH plus PSRAM

There is more information about some projects with a development board here: https://github.com/AnlogicInfo/EF2M45-SOC

[Atlan]

If a 60Mhz crystal is used for the FPGA, would it be necessary to modify the firmware in uP so that it displays the correct values?

FPGA But you need some program and hardware for reading, and some software to create a program for fpga.

[pcprogrammer]

If a 60Mhz crystal is used for the FPGA, would it be necessary to modify the firmware in uP so that it displays the correct values?

If the design is based on a 50MHz crystal then changing it to 60MHz would cause the FPGA to run faster and may cause problems with the timing in the routing, and yes it would need modification in the firmware to change all the values related to the FPGA sampling speed. Instead of 100MSa/s it becomes 120MSa/s per ADC channel. This is also stretching what the ADC's can handle.

While reverse engineering the FPGA configuration back into HDL, I ran into timing problems while trying to synthesize and route the new design. It needs careful designed timing constraints to get it right, so pushing the limits by raising the clock is not a very good idea.

IFPGA But you need some program and hardware for reading, and some software to create a program for fpga.

To work with the Anlogic FPGA's you need the Tang Dynasty suite. It can be found here: https://dl.sipeed.com/shareURL/TANG/Premier/IDE

The only issue is the license file is not up to date and I'm not sure if it will be updated. Also there seems to be a newer version of the suite, but that is also not easily available. See: https://www.eevblog.com/forum/fpga/latest-version-of-anlogic-ide/

Getting one from Anlogic requires a special login on their website and that was and may still be problematic from outside of China. See: https://www.anlogic.com/en/product/software/1.html I can login, but I can't download certain things like the new software.

The somewhere on this forum described programming interface for the Anlogic JTAG based devices can be used with this software and will allow reading and writing of the internally or externally connected FLASH.

See the attached datasheet for the EF2 family.

Edit: For the JTAG programmer check out my github repository here: https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Anlogic_JTAG_Programmer

[humidbeing]

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

I just wanted to drop in and say thank you to you and everyone involved with creating this great firmware.

I almost returned my 1013D because of some issues with the firmware, but after loading this "t" version I am happy with it enough to keep it.

Great work everyone!

[mm87]

Hi all, new user here!

I just bought one of these FNIRSI 1013D tablet scopes, with the primary goal of working on audio circuits. I was a bit on the fence but then I saw that someone (Atlan and pcprogrammer, I think?) was working on upgrading the firmware, so I just pulled the trigger

Just a few questions for you folks:
- What is the most recent firmware version? I lurked on some github pages, but I am not sure.
- What are the plans for future development?
- Any other things I should know about this scope? I know the performance isn't quite what is advertised, but it should be enough for my purposes.

Since I also code in C, I was also wondering if I could contribute to the development. Not sure I have the time to commit to it, though and I don't really know how complex it would be. Ideally, I'd like to have FFT with scales and simple measurements like THD, as well as a math channel (again, simple things: V1 + V2, V1-V2, V1*V2, ...).

In any case I hugely appreciate the effort you guys put in, so thank you!

[pcprogrammer]

- What is the most recent firmware version? I lurked on some github pages, but I am not sure.

The latest version of the binary is what you can find here in Atlan his posts. The source is in his github repository, but that might be lacking behind.

- What are the plans for future development?

I don't have any plans for now. Can't speak for Atlan.

- Any other things I should know about this scope? I know the performance isn't quite what is advertised, but it should be enough for my purposes.

Everything to know about it is written in this thread. Sure, it is a bit of a long read, but tells the whole story. 

Since I also code in C, I was also wondering if I could contribute to the development. Not sure I have the time to commit to it, though and I don't really know how complex it would be. Ideally, I'd like to have FFT with scales and simple measurements like THD, as well as a math channel (again, simple things: V1 + V2, V1-V2, V1*V2, ...).

The code is not super complex and has lots of comments on how things work. For the FFT there is already a spot where it could be hooked into the code. A math channel should not be to hard, but requires menu manipulation which is a bit more work.

I used Netbeans 8.2 for the development, but it is makefile driven, so any IDE or simple text editor can be used to develop new functionality.

The only thing for the final run-able firmware on the scope is that the scope binary has to be combined with the boot loader and splash screen. I wrote a simple program for this that is used in the makefile, but it is written for Linux. The source code is available here, so porting to Windows can be done.

A request for you, can you post some pictures of the PCB, so we can see which FPGA and MCU is used.

Have fun with your scope. 

[Atlan]

In theory, it could work.  You just have to write it in the oscilloscope.


If you want to do on fft, create a new file h and c.  It will be much easier to move it if necessary.  In scopefuncions you will find a link to the location of the fft.c program

[Atlan]

I would be interested in switching the brightness (maximum brightness - set brightness)