FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Can a LM2577 or LM2596 be used instead of the MIC2903

No, because it is a linear regulator and not a buck converter.

Edit: I guess you yourself deduced that because you removed the above not literal quoted from your post

[pcprogrammer]

TNX it helped a lot. BAT is ok on MIC29302 3.3V pin i have 1,92V. I have injected 3.3v on that pin and it has turned on. I have measured on the same chip input and it is BAT input but output is 1,92. So i assume that the MIC29302 is defect. Will order replacement chips.

Did you measure the current when injecting the 3.3V? Should be about 1Amp.

[illiac4]

I have used variable power supply  to inject voltage (DPS5020) and it showed 0,8A at the beginning when the relays triggered, after that it has dropped to around 0,55A.

[pcprogrammer]

I have used variable power supply  to inject voltage (DPS5020) and it showed 0,8A at the beginning when the relays triggered, after that it has dropped to around 0,55A.

Sounds good. The ~1Amp I measured was when supplied with 4.5V on the battery terminals. Question is where the remainder of the current is drawn then? Guess it also depends on the selected sample rate. The ADC's might draw more current when clocked at 100MHz. Have to look at the specs.

Another question is why your regulator died?

[illiac4]

I do not know. The scopes were not connected when it died. I have touched the terminal with the finger and it went blank. Will report back when i will get the linear regulator replaced so it can help someone in the future. Maybe attach those photos with ref voltages into the git for easy troubleshoot. It was really helpful in my case. I hope you will continue to make it better.

TNX

[pcprogrammer]

Maybe attach those photos with ref voltages into the git for easy troubleshoot.

Uploaded them to the firmware repository

I hope you will continue to make it better.

No plans for it anytime soon. Busy with other projects

[dimorlus]

I found another bug. When connected to a sine with a DC offset, firstly, the autoset did not work, and secondly, synchronization was only when the trigger level was "under" the sine, as if a signal without a DC was being received by the trigger

[Evi]

Quote from: dimorlus on Today at 02:34:21

I found another bug. When connected to a sine with a DC offset, firstly, the autoset did not work, and secondly, synchronization was only when the trigger level was "under" the sine, as if a signal without a DC was being received by the trigger

Confirm

[Asu]

Hello! First, I want to say thank you to the community here for the informative thread and the people who tirelessly reverse engineered and developed the new firmware. With that said, I have quickly skimmed through all 60+ pages and I'm here to confirm my findings and have some questions if you don't mind answering.

Is it possible to have the new firmware on a new SD card (through SD card reader, not the scope itself) and keep the original SD card as it is and possibly switch between the two firmwares by just swapping SD card in case something goes wrong? If so, what is the definitive steps I can take as a beginner (not much experience in programming)? And overall, how foolproof the whole process should be? Thanks!

[pcprogrammer]

Hello Asu,

welcome to the forum.

Yes you can load the new firmware to a new SD card, and it can be done with a separate card reader/writer.

It depends on the operating system you use on your personal computer as to what the procedure is. There is an image of a SD card with the firmware that can be used on Windows with software for writing disk images. Since I'm not a Windows user anymore I can't help with that.

On a Linux machine the same steps described in the firmware repository apply. It does not matter if the SD card is in a dedicated card reader/writer or the scope. Linux just sees them as block devices.

The SD card image is also in the repository, just like most of the needed information to make it work. Follow the link to the repository in my signature below.

[wolferl1210]

Hello pcprogrammer, thanks for your work and providing it to the community
the FNIRSI-1013D arrived today per mail - ordered at the FNIRSI shop on Aliexpress.

On a Windows PC with Rufus 3.21 the 'NO_LABEL.vhd' that you been so kind and packed
into V0.005_Windows.7z transferred to a 16GB SD

Swapped the original SD with my new created SD ... power ON, here we go, light, easy, perfect!

Wish that all 'hacks' beeing so easy to be implemented

greetings from Vienna/Austria
wolferl1210

[pcprogrammer]

On a Windows PC with Rufus 3.21 the 'NO_LABEL.vhd' that you been so kind and packed
into V0.005_Windows.7z transferred to a 16GB SD

That honor goes to Sleo, I just added it to the repository.

But for the rest you are welcome. It was an interesting project.

[bffargo]

Thanks to both of you. I was able to use the .7Z file (even though my SD card had 1 fewer block than the original it seems to work).

Thanks for the new firmware and making it so easy to load with that file using Win32DiskImager.  And for getting rid of the slower boot screen that makes it boot much faster now.

QQ: It seems with the new firmware the trace is a bit more jittery, both in voltage and in frequency, depending on the samples per second selected. It's hard to compare by constantly flipping cards back and forth but it just something I am noticing, or at least think I am, using the new firmware. Is it just me or my scope or an intended change?

Thanks again.

[pcprogrammer]

Hi bffargo,

I know it is a long read, but it is all described in this thread. It is not your scope, it is intentional, because the original software does a lot of unnecessary processing on the data it is much slower in updating. And sure, there is room for improvement with trace averaging, something like dot mode or using a sync function to try to represent the real signal more closely, but that is again a lot of work.

Have fun with it, and when it does not suit your demands just switch back to the original.

[tv84]

Reversing the programming: only in God mode...

Ok it took way more then 7 days, but if I had a son I would have to rename him Jesus, because I did it. 

[techneut]

Ok, this is confiusing. One God worshipping another one.

[tv84]

Ok, this is confiusing. One God worshipping another one.

We're polytheists... 

[tatel]

A good friend of mine asked me for advice. He wants to buy an oscilloscope for his 18 years old son. He wouldn't want to pay more than €100. I made clear to him that in this price range, any oscilloscope would be quite bad. But he wants advice from me about the more bang-for-the-buck cheap oscilloscope anyway. The boy plays with arduinos and has already a Saleae clone. He also looks at his father's car electronics. So I think either FNIRSI-1013D or Owon VDS1022 could more or less fit the bill. Foriantbr's unofficial firmware for the Owon seems to make that oscilloscope quite a bit better. GitHub repository has a good list of improvements made.

However I wonder what this 1013D with unofficial firmware could do. I looked at the github repository and more or less parsed this thread, but I'm unable to get a feature list of shortcomings solved or new features added by this firmware. It seems that pcprogrammer's firmware more or less does for the FNIRSI the same as oriantbr's for the Owon. I would love to know what this device is capable of, after reflashing. Does that feature list exist? Could you guys give me a pointer to it? Are there any remaining problems?

Also it seem there are at least two variants of 1013D, with recessed or protruding BNC connectors. Any hints about which one would be "better"?

Many kudos for the people that makes that cheap hardware better. I too worship you...

[tunk]

If you can stretch the budget a bit, you could look at Hantek 2C42 or Owon HDS242.

[pcprogrammer]

However I wonder what this 1013D with unofficial firmware could do. I looked at the github repository and more or less parsed this thread, but I'm unable to get a feature list of shortcomings solved or new features added by this firmware. It seems that pcprogrammer's firmware more or less does for the FNIRSI the same as oriantbr's for the Owon. I would love to know what this device is capable of, after reflashing. Does that feature list exist? Could you guys give me a pointer to it? Are there any remaining problems?

I think that somewhere in this thread there is a summation and I will try to repeat it here from memory.

The original has a buggy USB mass storage interface that causes the scope to hang when disconnected from the computer.
It also has some bugs when it comes to displaying the correct time per division when zooming in on a stopped signal.
It calculates a perfect sine when the input is above 44.x MHz and displays that instead of the real measured signal.

In it self all minor bugs or features that are not to bad, but are resolved in the open source firmware.

Right out lies from FNIRSI are the 1GSa/s sample rate and the 100MHz bandwidth. Truth is 200Ma/s and ~30MHz.

The open source firmware lacks some features the original has.

The FFT is not implemented.
The ROLL mode when in the 50s -20ms time base settings is not implemented.

A bug with the auto set has been reported that when there is a DC offset in the signal it does not work properly.

Some say that the open source firmware has a bit of a volatile display and it could use some improvement there.

Also it seem there are at least two variants of 1013D, with recessed or protruding BNC connectors. Any hints about which one would be "better"?

Basically the only difference between the two is the look. Hardware is mostly the same. Some older versions with the protruding BNC connectors use an Altera FPGA where the newer ones use an Anlogic FPGA. The programming of the FPGA's is the same.

I would not advise buying either the FNIRSI 1013D or 1014D. The input sensitivity is crap. They say 50mV per division, but that is based on a software zoom. It is 100mV per division with a 1x probe.

But like tunk wrote, a bit more money spend can get your friend a better scope.

[tatel]

I would not advise buying either the FNIRSI 1013D or 1014D. The input sensitivity is crap. They say 50mV per division, but that is based on a software zoom. It is 100mV per division with a 1x probe.

But like tunk wrote, a bit more money spend can get your friend a better scope.

Good to know. I'm thinking I'm going to advise him to choose between a dirty cheap toy , the Owon VDS1022 or go all the way to an entry-level, 4-channel, benchtop oscilloscope. If it were me, I would choose the toy and next year it could be the 4-channel. The kid is quite smart and he will need the 4-channel pretty soon. But, not my bussines anyway.

Thank you very much for the information

[tunk]

If you go for the toy version, this may have the best performance/price ratio (40/18MHz model):
https://www.eevblog.com/forum/testgear/new-toy()-scope-dso154pro-1ch-claimed-40mss/

Edit: At least on paper - there's no reviews or tests yet.

[illiac4]

Just for info. Replacing this one did fix the problem. It is alive again.
Common symptom is that the red led is on but the display is not working, then there is a big chance the chip MIC29302 is dead.
Replacing it with the ne one will fix the problem.
https://www.aliexpress.com/item/1005002625862420.html

[pcprogrammer]

Michal Derkacz (github user ziutek) made an update for the firmware. He improved the RMS measurement and created a new version v0.006 for it. I merged it into the repository after looking at the code. Did not test it myself and took it on face value.

There is no new image file made like for version v0.005, so windows users who fail to use the binary in the repository have to hope on someone posting a new image file here on the forum.

[yar]

I've lurked on this thread for approximately forever.  I fiddled with the URL and bookmarked a post far into the future, so when I remember to cruise on over here, I get effectively the "last" page, even without logging in.

I don't *need* 100Mhz and as a mere software guy, my standards are pretty low for a scope. I value the small size and absence of a hundred knobs. I use it "just" for finding which wire I've missed, watching i2c (for "yep, that looks like i2c. I really did get all the output bits enabled" or seeing "the device is selected and talking back, but I can't 'hear' it, so I have problems with receiver enable" and not actual decoding) or confirming why two RS-232 devices aren't playing nice, audio issues, timing an interrupt handler or other profiling by wiggling a GPIO during entry/exit, etc. While I *wish* it had protocol decoding, it wasn't advertised with signal decoding and I can break out one of the $6 logic analyzers when I do. I'm just pretty happy to have a small, portable device for those few times I need a scope and not a LA. I wish it would do everything (plus ponies!) but I'm actually not unhappy with this device.

However, I want to give a big thank you to PCProgrammer. Watching the reverse - and then forward - engineering exercise around this thing was VERY educational. Learning more about the horrors of Allwinner (I'm team RISC-V, where they're new, and not ARM at this level) and all the terrible decisions that went into building a low cost cheap product was fascinating to watch. While I've not actually used the results (see also: low standards) the results seem impressive and it's nice to know that if I need this improved version - or want signal decoding badly enough to implement it - that we have this excellent base to build around.

I just wanted to say thank you. It may seem strange that I'm not thanking you for having actually used the end result, I'm thanking you for the insight into the process of reverse engineering, the act of tracing parts back to their mother sources, for the act of figuring out the magic chips - or at least the code that used it well enough you didn't HAVE to figure out the magic chips - was a service to engineers around the globe. It was super clever to build an emulator that first ran the original code so you could work out UI, measurement/signal handling, and related issues on a Normal Computer (with a debugger) and then take that code back to the real hardware - that's definitely a trick I'm keeping in my toolbox.

So, PCProgrammer (and other contributors), I just wanted to say it publicly: Thank You.