New bench scope - Fnirsi 1014D, 7", 1GSa/s

[donwulff]

On the other hand, there's a large body of research on FPGA reverse-engineering (Obviously, I'd say, just the synthesis software will usually visualize the net-lists to level where you *could* reverse-engineer it (due to gates usually being mapped to LUT's), but automated tools better) like https://github.com/emsec/hal - while that doesn't suffice for fully open source firmware (Does it matter if the hardware is "proprietary"?) it would help to get to speed, and perhaps lift some limitations. Reading gate level logic without comments or proper naming is bound to be annoying though, but some large scale architecture should be recognizable enough and perhaps extendable.

Oh and look if there could be self-update mechanism. Another thought is there are actually quite a few published oscilloscope FPGA designs, so perhaps this could be using one with some modifications? Obviously, if the firmware is fully re-written, it could also be adopted to some open source hardware scopes. Although the 1013/1014D price is hard to beat, and have any of the open source hardware oscilloscope projects actually got off the ground?

So now I'll just have to wade through all the threads looking for actual instructions on backing up & replacing the firmware (for the non-complete firmwares), and reading the FPGA etc. Not saying I can find the time to work on this....

[pcprogrammer]

The link to the emsec/hal repository is interesting, but will also take some time to get familiar with, and you still need a way to convert the bit stream of your target FPGA into a net list. And there in lies a lot of work, I can attest to. Did it for the 1013D FPGA. (https://www.eevblog.com/forum/fpga/reverse-engineering-anlogic-al3_10-fpga/)

And even though I succeeded in reverting it back into readable verilog it failed to synthesize back into a working bit stream due to timing issues and different versions of the used IDE. The crude verilog did produce a somewhat working bit stream, but still not like the original. It did give insight in the inner working by using simulation. A huge advantage was the already present knowledge about the command set found while reverse engineering the firmware.

So fully reverse engineering a FPGA bit stream is not that simple, and even with a tool like that emsec/hal it will take a lot of knowledge to get things done.

Both tasks were new territory for me and took a lot of time, but even now with the gained knowledge, reverse engineering another bit of similar complex firmware or FPGA configuration would still take a lot of time.

Based on the result of the FPGA reverse engineering, I can state that there is no secret way to update the flash that holds the FPGA configuration bit stream, but I already knew that from reverse engineering the firmware of the 1013D. It does not have any provision in it to write to that flash. Since the 1014D firmware is not that different, and the update process uses the same code it will neither have that functionality.

That is why I won't bother with making something new for it. The new firmware is easy to install, without even writing over the original firmware, so one can easily revert back to it. Some even modified their scope with a switch to be able to go back and forth.

About the price of the scopes, I have not looked at them recently, but I paid about 30 euro more for my DSO2D10, so yes a bit more expensive, but you get a much better scope.

When I decide to do another scope project it will be for the Hantek and not the FNIRSI. 

[donwulff]

FPGA update might not be done with the stock MCU firmware (software?), but it's odd to me to have upgradeable firmware without ability to upgrade the FPGA, especially as it's usually a standard block in the FPGA design software. Maybe they ran out of LUT space to put it in, I'll take your word for it, but yeah I'm not sure how many people buying 150 EUR scope or so have hardware & desire to flash it manually. Of course, the first FPGA design could probably put the flash-upgrade block in (Bearing in mind I don't really know the exact limitations here, although I've done some FPGA work in the past).

I can only imagine how much work it's taken to reverse-engineer the whole thing. It'll be lot easier for me to start with reading everything that's already been written about it on the threads, but don't know if I can put the time into it. Maybe I can get something working first though, also the idea that the same designs should be partially applicable to other/designed from scratch hardware is interesting, even if people don't get playing with that specific hardware.

Speaking of that, DSO2D10 doesn't seem to currently be available on AliExpress. From what I can see, DSO2C10 without the function-generator sells for around 300 EUR, so it seems also about double the price? Kinda nevermind as this thread is about the 1014D, but still it certainly makes lot more sense to buy better scope than try to one-off improve one! Then again, I personally wouldn't start to tear down even 300 EUR scope for the fun of it, so about 150 EUR is a sweet spot for me, with code & logic that should be applicable for higher performance ones. Still, I ALSO like to have it around for hobby projects & basic indicator. But we'll see, at least it's still available for purchase, which means a lot of people could get it. A shame the F1C200 versions aren't more common, and other hardware upgrades don't really look like an option.

[pcprogrammer]

FPGA update might not be done with the stock MCU firmware (software?), but it's odd to me to have upgradeable firmware without ability to upgrade the FPGA, especially as it's usually a standard block in the FPGA design software.

The FNIRSI hardware and firmware is full of stupidity, so to me not such a big surprise that the FPGA configuration is not up gradable.

Have not seen something for it in the Anlogic IDE, but have not looked for it either.

Maybe they ran out of LUT space to put it in,

There is plenty of room left in the FPGA.

The way I could tell it not being in there is that the pins connected to the FPGA flash are not used in the bit stream.

Programming a serial peripheral interface into the FPGA between the flash and the MCU is not that big of a deal, but they might have had problems with getting their design to work in the first place that adding it made it fail.

They could also have used the MCU to configure the FPGA and have the bit stream sit in the flash the firmware resides in. It would then have been very easy to update it with a better design.

[Fungus]

FPGA update might not be done with the stock MCU firmware (software?), but it's odd to me to have upgradeable firmware without ability to upgrade the FPGA, especially as it's usually a standard block in the FPGA design software.

The FNIRSI hardware and firmware is full of stupidity, so to me not such a big surprise that the FPGA configuration is not up gradable.

I don't think their intention is ever to sell user upgradable devices.

The flash card is probably just a convenience for them.

(Maybe it's so they don't have to dump a load of hardware if they find a fatal bug?)

[donwulff]

You'd be surprised, FNIRSI in particular have firmware updates for a lot of their products on http://www.fnirsi.cn/support, including the 1014D. Whether it was a fatal bug is a matter of debate, it's not like it's still working perfect. And they're not principally opposed to having it updateable, due to the flash chips having programming ports. Reason I'm surprised is it's just generally more effort to leave it out, no need for the second programming port on the PCB etc. I suppose one possibility is the final_final_really_final FPGA version just disabled it after programming... Half kidding, it's not hard to believe they'd just leave it out and do everything the hard way.

I meant to ask though, according to @pcprogrammer's great circuit diagram it's Altera Cyclone IV EP4CE6 but I did notice the discussion thread is about Anlogic? Is it a clone or no relation to the Altera Cyclone? I'll try to get around skimming through all those threads though.

Noticed the hacking repository also has source code for the MCU running flash programmer via USB, which is interesting. Since basically all of the case is empty air, the idea of putting in USB hub with some extra devices like WiFi, flasher etc. is one possibility. Unfortunately can't do anything about the overall capabilities, or getting to the unused pins...

[donwulff]

So looking around I found out @pcprogrammer already did the hard work of decoding the original FPGA in https://www.eevblog.com/forum/fpga/reverse-engineering-anlogic-al3_10-fpga/50/#lastPost - in addition https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4010977/#msg4010977 suggests @morris6 was working on re-write of the FPGA. Is that still ongoing?

Also on https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4027378/#msg4027378 it was mentioned some boards actually do have Altera FPGA. According to https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4051087/#msg4051087 Anlogic one has markings removed, so the Altera FPGA would have Altera logo? Might I assume all 1014D have Anlogic FPGA?

It seems my time might be better spent on trying to add support for the physical controls ARM core into the existing software for now.

[pcprogrammer]

I meant to ask though, according to @pcprogrammer's great circuit diagram it's Altera Cyclone IV EP4CE6 but I did notice the discussion thread is about Anlogic? Is it a clone or no relation to the Altera Cyclone? I'll try to get around skimming through all those threads though.

I drew the schematics with the Altera Cyclone IV because the original 1013D uses that one. It has been replaced with a pin compatible Anlogic FPGA. The two configuration bit streams are different, and since the scopes I have use the Anlogic one, it is this one that I reverse engineered. The Altera one would have been a tougher quest involving reverse engineering Altera software to get to the meaning of the individual configuration bits. That work was already done for the Anlogic one.

Read the thread about the reverse engineering of the FPGA. You might find it very interesting.

Noticed the hacking repository also has source code for the MCU running flash programmer via USB, which is interesting. Since basically all of the case is empty air, the idea of putting in USB hub with some extra devices like WiFi, flasher etc. is one possibility. Unfortunately can't do anything about the overall capabilities, or getting to the unused pins...

Due to the fact that everything I did is bare metal programming, adding more USB gadgets is not that simple. I wrote a CH340 emulator that allows communicating with the FPGA and a lot of other test stuff. But these are device implementations and not host implementations.

The USB flash programming you refer to is probably the sunxi FEL software for the F1C100s build in software to do these actions.

In the end I switch to using the SD card to load and start the firmware making it much easier to do the updates. The MCU firmware flash is left as is and unused when running my firmware. The same can be done for the 1014D.

It is not running linux like the Hantek scope. There is a version of linux that runs on the 1013D, but I did not use it, nor does the original firmware.

Edit:  I noticed that I did not change the 1014D schematic to reflect the usage of the Anlogic FPGA.

[pcprogrammer]

So looking around I found out @pcprogrammer already did the hard work of decoding the original FPGA in https://www.eevblog.com/forum/fpga/reverse-engineering-anlogic-al3_10-fpga/50/#lastPost - in addition https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4010977/#msg4010977 suggests @morris6 was working on re-write of the FPGA. Is that still ongoing?

Should have read both your posts before writing my first one 

And that is what I have been writing about here, that I did all the work for the 1013D and also partially tackled the 1014D.

I have some insight in the 1014D FPGA, but fully doing that one would still be a lot of work figuring out the clock routing and memory block usage.

The work morris6 started was never finished. There is a design that works to some extend, but we both decided it was not worth continuing with it. You can search github to find morris6 his repository about it.

Also on https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4027378/#msg4027378 it was mentioned some boards actually do have Altera FPGA. According to https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4051087/#msg4051087 Anlogic one has markings removed, so the Altera FPGA would have Altera logo? Might I assume all 1014D have Anlogic FPGA?

Since the 1014D is introduced after the 1013D I suspect they only use the Anlogic FPGA.

It seems my time might be better spent on trying to add support for the physical controls ARM core into the existing software for now.

Yep that would be a good starting point. There is also a Ghidra project for the firmware of the control MCU. The program is not that big and might be the easiest way to get an insight in what it sends to the main MCU.

[Rasz]

If you are really dead set on hacking it up ~$60 “ZEEWEII DSO1511G” is a lot cheaper/better target. ~90MHz BW, dual 100MHz AD9288 ADC. LATTICE LCMXO2, Allwinner F1C100s), more on https://www.eevblog.com/forum/testgear/dso1511e-review/ or ~$80 2 channel SigPeak DSO2512G version https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/

[donwulff]

Honestly, I'm talking about FNIRSI 1014D not because it's the absolute best (it obviously isn't), but because this is the thread for it and I already own it. The argument for price falls flat with that, although I'm considering 1013D because it already has working open source firmware. I can probably get it working on 1014D if I'm going to have the time to play with the software at all.

I'm taking notes for "unbreakable" hobbyist scope though, but I can't help but think there has to be a thread for that. DSO1511G has same AD9288 ADC as FNIRSI, LCMXO2 is 1280 LUT CPLD that should support 8k sample depth and has lot less power and potential. More importantly, it's single channel, which already disqualifies it for most uses, and more expensive per channel, and the review says it struggles at 21.5MHz. I paid 172 EUR for the FNIRSI (I keep forgetting AliExpress cheats and always lists price of cheaper option, you can get it cheaper but maybe not down to 150 EUR unlike the 1013D if you don't need signal generator, tactile sensation and look professional instead of causing a security alarm for unauthorized tablet;)


Also speaking of ADC, in https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4425640/#msg4425640 @marauder reported exchanging ADC buffer opamp. I'm assuming those are under the shield boxes on the PCB, so wondering how hard they'd be to replace, especially since my scope seems to have slightly different amplitudes on the channels too. Indeed was just looking at available components and thinking TI OPA355/OPA356 could be a better performing replacement, except the datasheet says "with sampling speeds up to 1 MSPS", but I'm sure it depends on other components. It sounds like @marauder used these without problems though. It's not going to get around any limitations of the AD9288 ADC, but on paper does seem to have lot better specs (360V/uS, 5.8 nV/Hz, 200 MHz G10@R1k vs 180V/uS, 8 nV/Hz, 10 MHz G10@R1k! - shouldn't that mess with the response?). So that would be interesting experiment to reduce noise and maybe recover most of the ADC resolution. I'm also wondering whether it would make sense to adjust the gain to be more sensitive with lower noise floor, if you can change the software to match the gain (At true 50mV resolution you should have 12V range which seems fine for most purposes, even 25mV would work for digital logic but probably more issues). If you're going to change that many components, you run risk of introducing more noise... And the AD9288 datasheet shows it could be pushed at least to 110MSPS per channel, for increase in noise if the FPGA can be pushed that high. Of course I'm not sure anybody has tested how far the silicon goes, especially if it's not genuine. Just playing with some ideas to get the most out of existing hardware.

Edit: The 10MHz is probably wrong, the specs for both of them have some differences in assumptions/units and it's hard to compare, especially as I'm not really analog circuits guy either. The figures in "Small-Signal Bandwidth" for AD9288 do look bad though. I'm not thrilled to be making component substitutions, but swapping the OpAmp wouldn't be out of question (before looking under the tin cans), especially due to the gain(?) difference between the channels.

[pcprogrammer]

Ah yes, the defective opamp in marauder his scope.

The analog circuit is indeed underneath the tin cans, and could do with more improvements then just swapping the opamp. At the least the change evi made to get rid of the ground lift problem. https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4536116/#msg4536116

It would be better to make a dedicated dual supply for the front end and another option could be to bypass the front end altogether and make a new one, but then it grows and grows into what one thinks up next. 

The one thing I like about these two scopes is the "simplicity" with which new firmware can be wiped up, but that is only now after many and many months of work to get to the root of the system. Even for the 1014D it could be done relatively quick. All that needs to be figured out first is the FPGA command to load the function generator with its waveform, the controlling of the frequency, which most likely is done with the clock ic and the commands send from the user interface processor to make the settings.

Basing it on the new 1013D firmware can be done, but needs tweaking of the screen layout and if it needs to have the same look and feel as the original 1014D the graphics engine needs some polishing.

There are some differences in the FPGA commands. The screen brightness works with only a byte of data, so the range needs to be determined. Also saw some difference in the sampling control, but not that big of a deal.

About raising the sample rate, probably not worth the trouble cranking it up with 10%, with the risk of damaging the ADC's. I guess the FPGA can handle it, but needs a proper design to get it done.

[Rasz]

Honestly, I'm talking about FNIRSI 1014D not because it's the absolute best (it obviously isn't), but because this is the thread for it and I already own it.

Im sorry for your loss. Being in this thread should make you realize you got scammed. Best course of action is selling this piece of crap and moving on with your life.

[donwulff]

I'm skimming through the old threads, just a lot to read lol. Nothing compared to actually reverse-engineering the stuff though! Anyway I edited the earlier post slightly, I'm not really sure on the specs of the Gain-Bandwidth Product/Small-Signal Bandwidth of those opamps, as the datasheet make different assumptions and not all written out etc.

I'm not too thrilled to be replacing components, either, but it's worth noting you probably can't build a lot better scope without quite different and more expensive architecture (I'm curious how the low-price 200MHz scopes do and if they're anywhere real that performance in reality), which suggests to me small improvements for DYI and learning could be worth it. Software, if it gets re-used, will at least see better return on the time used. On the other hand, if you're anyway learning & doing hobbyist projects, can't put a price on everything. Still do need to find time, though.

[pcprogrammer]

Honestly, I'm talking about FNIRSI 1014D not because it's the absolute best (it obviously isn't), but because this is the thread for it and I already own it.

Im sorry for your loss. Being in this thread should make you realize you got scammed. Best course of action is selling this piece of crap and moving on with your life.

That is bullshit. It is a nice piece of kit to play with from a development perspective. It has a 7 inch display, a reasonable fast processor and a nice FPGA. The second processor to handle the user input gives another bit for learning. Inter processor communication and scanning of rotary dials and buttons. With the schematics available it is a nice entry point to gain knowledge on programming both hardware and firmware.

The other scopes you mentioned have smaller screens and one would need to start from zero and reverse engineer the firmware to be able to make new firmware for it. Most of that work has been done for the 1014D.

I would say if you have nothing positive to add, just stay away from posting in this thread.

[Rasz]

Honestly, I'm talking about FNIRSI 1014D not because it's the absolute best (it obviously isn't), but because this is the thread for it and I already own it.

Im sorry for your loss. Being in this thread should make you realize you got scammed. Best course of action is selling this piece of crap and moving on with your life.

That is bullshit. It is a nice piece of kit to play with from a development perspective. It has a 7 inch display, a reasonable fast processor and a nice FPGA. The second processor to handle the user input gives another bit for learning. Inter processor communication and scanning of rotary dials and buttons. With the schematics available it is a nice entry point to gain knowledge on programming both hardware and firmware.

The other scopes you mentioned have smaller screens and one would need to start from zero and reverse engineer the firmware to be able to make new firmware for it. Most of that work has been done for the 1014D.

I would say if you have nothing positive to add, just stay away from posting in this thread.

Did you just say this ~$200 "100Mhz BW 1GSa/s" 20MHz BW 400MSa/s scope is a good dev board? People usually buy scopes to use them as scopes. Something tells me donwulff doesnt want a dev board, he wants a functioning scope and his interest in RE is purely in hopes of FIXING it to actually get what was advertized.

[pcprogrammer]

I never said good. It is a nice and simple platform to play with.

And if someone wants something that is what is advertised and any good then they should be prepared to shell out more cash than a couple of hundred dollars.

All one has to do is search on google and one can find that most of these cheap Chinese scopes are a bit of rubbish, but for a starting hobbyist they can be a helpful tool. Would have been very pleased if something like this was available for similar money when I was young.

donwulff has one and arrived here at this thread to find himself interested in playing with it on another level then using it as a scope. Nothing wrong with that.

[donwulff]

Acshually, I did buy the 1014D specifically because I was aware there was reverse-engineering project/some software for it on this site (Not yet ready when I purchased it, and didn't realize it would be 1013D only, but I'm not unwilling to get my hands dirty, that's kind of the point of tweaking and learning) which should be obvious from my posts. You'd be a fool not to Google what you're purchasing, especially off Chinese web-stores, and nobody should expect to get 100MHz 2-channel DSO for under 200 (euros or dollars or whatever). It's enough for hobby projects & learning, especially with the benefit of tweaking the oscilloscope itself (Not that I've done that yet, but protocol decode, phase align etc. are things you can't often do even with more expensive gear).

If I need better performance, I'll just use the Siglent SDS2204X HD, but at about 4000 EUR few people would consider taking it apart for tweaks or throw it in the back of trunk for field trip etc. To be clear, I think the 1014D is close to, if not the best around it's price class, all the other alternatives are 2X or more and/or similarly inflated specs. But the prospect of existing open firmware for experimenting and trying tweaks is what cinches it. I'll refrain from saying "makes it truly powerful" because I don't really know if any of that works yet

[donwulff]

Started writing my notes out to https://github.com/Donwulff/FNIRSI-1013D-1014D-Hack/blob/main/notes.md - there are literally multiple thousands posts on these scopes on EEVblog alone, and I've barely started wading through all of them. So this is basically still at the "figuring out the problem" (Of turning 1014D into an über programmable scope, not of just using it for it's intended hobbyist use) stage for me, starting from basically no knowledge. I'm sure it has many errors and omissions, but have to start somewhere. Just from few of the sources it appears that these scopes have been built with many different, similar components however.

Everybody, even in 2020 thread keeps saying it has terrible specs even for it's price. This doesn't really matter to me as long as it's relatively programmable. However, I've not seen anybody suggests <200 EUR/dollar scope with better specs. They're all either 2X+ the price and/or same 200MSa/s ADC, sometimes overclocked to 250MSa/s.

If anybody can suggest better than 2 independently 250MSa/s+ channels Digital Storage Oscilloscope under 200 dollars/euros, I'll definitely at least list them Programmability without having to reverse-engineer everything myself is important to me, though the choice of acceptable scope seems something of a religious issue to many, lol. Maybe I'll switch to something like the Hantek DSO2D15 IF there ready-made open firmware I can use with no risk of breaking it, and confirmation the specs actually hold. But it'll still be an overkill for scoping serial buses, or fixing the timing on most CPLD/FPGA buses where you need to adjust the output delay. And any possible source code should hopefully fairly easily port to new scope.


Now if I'll find the reference, there was also a mention some of the similar scopes have heatsinks on the ADC. Looking at the temperatures is certainly one thing to do on the hardware side.

[pcprogrammer]

It might be that the Hantek DSO2C10 can be bought for under 200 dollar/euro.  I paid 195 euro for the DSO2D10 to just be sure of the AWG components being installed. Many reported the C models to have the same fully populated PCB installed and with a simple hack enabled the full bandwidth and AWG.

The specifications of it are true. 1GSa/s max with one channel enabled and 500MSa/s max with 2 channels enabled. The FPGA used in it has 8MB of memory but there is a speed issue that causes it to not being able to use it at full sample speed. The front end is much better then the one of the FNIRSI.

But the down side is that it has not been reverse engineered. For the linux part the sources have been released, and they seems to bring some insight into the system. Not sure if it makes it possible to write your own scope code for it though.

I read your notes on github and do have some remarks. First of all you did your legwork, so hats of for that.

You mention a 400MSa/s versus advertised 1GSa/s for the two FNIRSI scopes. It is not possible with the FPGA as is, to do 400MSa/s on a single merged channel. The two ADC's in a single AD9288 chip are clocked with 180 degree phase shift to allow for the 200MSa/s sampling rate. The two AD9288 chips in the scope are clocked on these same clocks. To do 400MSa/s the clocks would need to be on phase 0, 90, 180 and 270 degrees to make it work.

So they are just 200MSa/s scopes and when 5 samples per period are assumed as ok for signal representation it could work with 40MHz signals. Limiting factor here is the front end with a ~30MHz -3db point.

About the protocol decoding. This is not trivial with the current setup. There is no way to do fast enough continuous sampling of the signal into the F1C100s memory to do analyses on it.  You mention sigrok and turning the scope into a data logger for that. Even with a dedicated FPGA implementation the limiting factor is the low memory amount in the FPGA and the speed of the interconnect between the FPGA and the F1C100s. Even though it is a parallel bus it can't even reach 100MB/s due to the way it is implemented. (Have not done actual speed tests on it)

The amount of memory in the Anlogic FPGA is enough to do 24KB per channel, but it needs careful FPGA design to get it working on 200MSa/s. It might even be possible to push it up a bit more, but that would mean mixing two types of memory available. The AL3-10 has 9K and 32K bit memory blocks scattered throughout the fabric. You need a very good synchronous design to use it all at the high speed.

There is more, but I will take a break first.

[Rasz]

If anybody can suggest better than 2 independently 250MSa/s+ channels Digital Storage Oscilloscope under 200 dollars/euros

already did - ~$80 2 channel SigPeak DSO2512G, it actually has ~90MHz of frontend BW unlike Fnirsi garbage

You mention a 400MSa/s versus advertised 1GSa/s for the two FNIRSI scopes.

thats probably my fault, I wrote that few post above erroneously giving Fnirsi scammers some benefit of a doubt

It is not possible with the FPGA as is, to do 400MSa/s on a single merged channel. The two ADC's in a single AD9288 chip are clocked with 180 degree phase shift to allow for the 200MSa/s sampling rate. The two AD9288 chips in the scope are clocked on these same clocks. To do 400MSa/s the clocks would need to be on phase 0, 90, 180 and 270 degrees to make it work.

fantastic, so the fraud is selling 1/3 to 1/5 of advertised specs

About the protocol decoding. This is not trivial with the current setup. There is no way to do fast enough continuous sampling of the signal into the F1C100s memory to do analyses on it.  You mention sigrok and turning the scope into a data logger for that. Even with a dedicated FPGA implementation the limiting factor is the low memory amount in the FPGA and the speed of the interconnect between the FPGA and the F1C100s. Even though it is a parallel bus it can't even reach 100MB/s due to the way it is implemented. (Have not done actual speed tests on it)

you could do it with DSO1511G/DSO2512G and custom CYUSB3014 (~370MB/s usb3 transfer) board replacing F1C100s

[pcprogrammer]

It is interesting to see that FNIRSI used yet another FPGA in a bunch of 1013D's. The tear down https://www.cnx-software.com/2022/11/16/fnirsi-1013d-teardown-and-mini-review-a-portable-oscilloscope-based-on-allwinner-cpu-anlogic-fgpa/ shows a clear picture of the PCB and that they did not remove the marking on the chip in this one.

The question is if this is a newer revision then the one with the AL3-10. Don't think the firmware will be any different going by the screenshots.

But this is about the 1014D and your intentions to play with it. 

About the JTAG for the FPGA. In the 1014D there is provisions for a 2.54mm double row header as shown in the schematic, so easy enough to do direct uploads to test new designs. I modified my 1013D with some wires soldered to the components to get access to the JTAG. Morris6 went a bit further and did an impressive job in adding a header and some additional LED's to his scope.

There is also a design based on a bluepill and unfortunately closed firmware for a JTAG programmer for the Anlogic IDE. https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Anlogic_JTAG_Programmer

You mention the different FPGA's as complicating things, and that is true when the road of designing a new setup for it, is taken. You would need access to all types to make it work for every scope out there. Not really optimal to say the least, but not a lot of people might be interested in upgrading the FPGA flash, which could mean the stock firmware won't work anymore. (You would need to adapt your design to be backward compatible)

In a similar way there is the usage of the different LCD modules with shifted screens as a result. I solved that with a separate configuration file, where as the manufacturer choose to supply different versions of the firmware. Also had to do this for the touch panel on the 1013D, which also has different configurations out there leading to swapped x and or y coordinates.

You mention not having success in reading the FPGA FLASH ic. The trick here is to do it with the scope up and running. Only connect the SPI signals and the ground, not the 3V3 power. The FPGA screws with the signals when not powered up. So even though there is the diode in the FLASH supply chain it did not work for me until I powered up the scope.

There is indeed some development environment I created for the 1013D, and the repository you found modified it to use the QEMU instead of my own ARM emulator I wrote just for this reverse engineering task. I have not tried it. You can try to adapt it to make a 1014D version. But don't forget that all this code is unfinished and wrote up just to aid me during development.

About the 1014D firmware backup I wrote. It is a copy of the one I wrote for the 1013D, but lacks the touch panel configuration backup. For the rest it is practically the same. It writes a full backup of the FLASH for the F1C100s to the SD card and also a separate backup of the firmware part with the needed check bytes to be able to reload the firmware based on the update procedure the manufacturer uses.

After I f...ed up my second 1013D with that procedure, I decided to pursue the SD card firmware route.

And finally, yes, like I wrote before, a good starting point for you to make something for the 1014D would be to further reverse engineer the firmware of the user interface controller. Knowing the commands send to the F1C100s is the first step in to being able to mod the 1013D firmware.

And now the fun starts 

[donwulff]

A scope with two 500MSa/s (What unit do we even use) is called 1GSa/s scope, I guess I need to make it clearer it's specifically 200MSa/s per channel. Note that definitions do give some "scamming" leeway, as some manufacturers quote the equivalent-time sampling Sa/s for example (Of course, I don't know if FNIRSI does even that, so yes, it's just completely made up), likewise with the bandwidth which in general is just saying amplitude drops to around 70% at that bandwidth (Though I'm sure the standard didn't intend imagined signal, and I haven't checked if the scope does even that).

We may (hopefully!) see about the protocol decode. It may be misleading to call this protocol decode, if I just need to read serial protocol I can use Bus Pirate or program another microcontroller to dump it. However for example I recently (or currently..) ran into a case where the serial bus will occasionally glitch, but not all the time, and no matter the price of the scope it's hard to get a scope to trigger to that. Do we call that protocol trigger or something? And for protocol decode we only need 2X the bit speed at most. But yeah, remains to be seen about the full capabilities.

I was figuring I'll have to access the SPI flash with the board powered on (In fact, I did with the Segger J-Link, but turns out it doesn't even support WinBond chips, read the chip ID though??). I was leaving trying it with Bus Pirate as last resort or until I get to the part on the threads, because the Bus Pirate documentation is pretty skimpy on what you're supposed to do with the 3v3 in that case. Plus I don't actually do anything with the FPGA flash right at this point. I can even leave the knob-controller firmware as is and just figure out how to interface to it from the Allwinner.

Hantek DSO2C10 is interesting, I couldn't find confirmation of the sample rate anywhere, most indications were it's another 200MSa/s (Looking at the specs, I think that's actually people misreading the specs which seem to indicate FFT bandwith limit is 20MHz? Or the Arbitrary Waveform Generator). If the cheaper model doesn't have BNC connector for AWG etc. it's also bit of work. By full bandwidth, do you mean 150MHz or 100MHz? Annd... of course we're somewhat more interested in full MSa/s per channel with both channels in use. AliExpress doesn't presently appear to have DSO2C10, and I'm seeing prices starting at 240 EUR's. Not to haggle over prices, <200 is pretty arbitrary choice, but if the specs and features aren't certain it's a meh at the start. Interestingly I note it has EXT trigger but only on the AWG model. The existing protocol support is quite nice indeed, so need to wait for someone to make open firmware for this

SigPeak DSO2512g "Bandwidth 120M(ch1 only),dual channel mode is 60M" like what does that even mean? https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/msg4282615/#msg4282615 says it's with ONE of the 8bit ADC's like FNIRSI 1013D/1014D, so it's actually half the sampling rate, and hence practical bandwidth, and ~50MHz (-3dB) cutoff on frequency with just one channel.

[pcprogrammer]

I'm no expert in scope semantics, but guess that the specified sample rate in the specification for a single channel might be what is used on the label. The Hantek DSO2 series uses the exact same hardware for the four available models. For some earlier versions it has been reported that the AWG components were not placed, but lately it seems they are.

About the price it varies. The link given in this post https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4611130/#msg4611130 showed ~218 euro when I looked just now.

I reverse engineered the schematics for the DSO2D10 I have, but know almost nothing about the software.

Another point, the equivalent time sampling you keep mentioning, unless you know more about it then I do, is not something that is possible on modern sampling scopes like the ones at hand. What I know about it is that to reconstruct a repetitive signal with a higher frequency (bandwidth) then your sampling rate you have to take samples at varying intervals to be able to do so. This means you have to shift your sample moment in time for every sample you take, and not at the same regular interval like done in the 1014D. For this shifting you still need some high resolution delay or fast clock signal. The Anlogic AL3-10 can work up to ~400MHz, but it takes a very careful planned design to make it work, and then still won't bring you GSa/s rates.

Looking at the Hantek in that respect, the ADC used in it is a ADC08D500 you also mentioned in your notes. To reach the 1GSa/s on a single channel the inputs of the two internal ADC's are fed from the same signal and they are clocked with a 180 degree phase difference. The connection with the FPGA uses four 8 bit buses, so every 4ns 32 bits are clocked into the FPGA and that is quite fast.

The 1013D and 1014D clock 32 bits in every 10ns. Still fast, but easier to get it right. I wrote a design for loading 125Msa/s DAC's using the AL3-10 and managed with the help of BrianHG from this forum to get it working. It was not easy and yet an interesting journey for sure.

About your use case with glitches in a serial data stream the way to catch these is to have a lot of sample memory and then zoom in to see if it is there. More expensive scopes like from Rigol and Siglent come into play here. Not something with at best 28KB. Sure you can create a new FPGA design and write software to continuous sample into the F1C100s memory. At least 16MB is free for this, but the sample rate will drop a lot. Sure all interesting experiments to do, but I have moved on to other projects for now.

[donwulff]

On the heatsinks for the (unmarked) ADC, the ADC's don't heat very much here on my table keeping the scope running. I'm not sure if there's anything I cold do to really press them, I assume 10nS timescale will keep them running at max speed. I suppose heat-sinks might still not hurt. Nice thing with two channels is you can make changes to one and try to observe difference between them. Something to test out later, for sure. https://www.analog.com/media/en/technical-documentation/data-sheets/AD9288.pdf page 10 shows SINAD/SNR dropping quite precariously over room temperature, and I'm sure the Chinese clone likewise.

If DSO2D10 has ADC08D500 (Really? The list price is about 100 dollars apiece even at bulk) that's quite a steal, and if it's running Linux, who knows how easy it is to re-program. But that's another adventure as they say, though to be honest I didn't catch that it has protocol decoders (well, for standard protocols anyway...) already, so it might already do some of what I'm hoping. So I'll definitely keep an eye out for a good price. How's it I'm not finding any of this information on Google though, lol.

For now though, the FNIRSI is almost fully reverse-engineered (Minus the 1014D bits I guess?), sounds like a small community of knowledgeable people, some possible avenues of experimentation and improvement, and not too expensive to break. What could possibly go wrong, haha.

* EEVblog review at calls FNIRSI 1013D 1 gigasample/s equivalent-time sampling, however I'm thinking that must be in error, especially as you listen further to the video they say "but they're trying to do real-time sampling here because otherwise you need extremely good trigger ability" or so. Anyway as I say on the notes-file, I don't think you necessarily need nanosecond delays, because the sample-rate won't be exact multiple of the input "frequency", you'll just need to fold it over. But it's surely better to (attempt to) do than discuss it. I don't think you may even need the FPGA to do anything extra, since it's for repetitive signals. What can you fit on the MCU?