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

[tunk]

New scope, Fnirsi 1014D:
- 7" screen
- 100MHz bandwith
- 1GSa/s sampling rate
- 240Kbit storage depth
http://fnirsi.cn/productinfo/575891.html

Edit: The hardware specs looks identical to
the 1013D, so the real bandwith could be
20-30Mhz.

[Algoma]

"Even if the encoder is completely broken, it will not affect the normal use of the oscilloscope at all"
"ads1014d still runs perfectly and operates correctly, getting rid of the limitation of the encoder's short life"

Are they actually admitting in writing that they're using very low quality encoders, and trying to overcome it with software... cheap way to save on such a basic interface feature. Basic encoders are not that expensive of a part.

[nctnico]

"Even if the encoder is completely broken, it will not affect the normal use of the oscilloscope at all"
"ads1014d still runs perfectly and operates correctly, getting rid of the limitation of the encoder's short life"

Are they actually admitting in writing that they're using very low quality encoders, and trying to overcome it with software... cheap way to save a few pennies on such a basic interface feature. Basic encoders are not that expensive of a part.

At least they are honest. Encoders also fail on $30k scopes so nothing new here.

[coppice]

"Even if the encoder is completely broken, it will not affect the normal use of the oscilloscope at all"
"ads1014d still runs perfectly and operates correctly, getting rid of the limitation of the encoder's short life"

Are they actually admitting in writing that they're using very low quality encoders, and trying to overcome it with software... cheap way to save on such a basic interface feature. Basic encoders are not that expensive of a part.

I think they are claiming to have taken debounce really seriously, which is something a lot of people should be doing and don't. YES LOGITECH, YOU ARE ONE OF THE PEOPLE I'M TALKING ABOUT. YOUR BLOODY MICE ARE A DISGRACE.

[Fungus]

Are they actually admitting in writing that they're using very low quality encoders, and trying to overcome it with software... cheap way to save a few pennies on such a basic interface feature. Basic encoders are not that expensive of a part.

At least they are honest. Encoders also fail on $30k scopes so nothing new here.

Encoders and other switches can be debounced in software much more easily than in hardware.

[nctnico]

But you'd still need a good signal from the encoder. If that isn't there then no amount of software can fix that.

Does this scope have a touch screen? Maybe they are just hinting that failing encoders don't matter because you don't need them. 

[Jan Audio]

Havent seen that brand in any store.

[tunk]

It's starting to show up at aliexpress for 170-190us$.
Fnirsi have also put a video on youtube:

[dmitrkov]

It's starting to show up at aliexpress for 170-190us$.

US $463.50   

[nctnico]

This one says 134 euro + 7 euro shipping:
https://nl.aliexpress.com/item/1005002387946152.html

BTW: I can't shake the feeling the styling has been inspired by Rigol

[Fungus]

It's starting to show up at aliexpress for 170-190us$.

$150

https://www.aliexpress.com/item/1005002340647364.html

Fnirsi have also put a video on youtube:

Certainly looks responsive.

Doesn't appear to have any serial decoders but could it be there's finally a 'scope worth owning for under $200?

[rf-loop]

Under 100 (97.50)  Euro in Taobao 

[Algoma]

I'm curious if they've used another Allwinner chip again as the applications processor. Certainly looks more responsive on the interface than previous efforts.

[robert.rozee]

i have a sneaking suspicion the video may have been sped up in post-production. i could be wrong, but some of the hand movements and multiple presses of buttons seems unnaturally quick.

on the plus side, elements of the UI seem refreshingly new, other manufacturers could possibly uplift some of the design cues. and even if the scope only had a 'true' bandwidth of 20MHz, at the right price-point (sub-$100us) it could be a real winner. notice the use of an external plug-pack for power.


cheers,
rob   :-)

[Fungus]

The label on the back says:



So that's where the corners have been cut.

For $100 though? Much better than fumbling in the dark.

[Fungus]

i have a sneaking suspicion the video may have been sped up in post-production. i could be wrong

Yep. It looks to be double speed for most of the video, probably just to keep it short.

Youtube lets you play back at half speed if you want to see it for real. 

(still looks responsive)

[tautech]

The label on the back says:



So that's where the corners have been cut.

For $100 though? Much better than fumbling in the dark.

And you don't think the 40V inputs isn't a significant design limitation ?
It's plain garbage and no wonder rf-loop was having a good laugh about these.

[nctnico]

And you don't think the 40V inputs isn't a significant design limitation ?
It's plain garbage Siglent doesn't sell them and no wonder rf-loop was having a good laugh about these.

Fixed that for you!
Ofcourse these devices don't hold a candle against what you can buy in the $500 bracket. But for $100 you hardly can't go wrong and that is the price bracket Fnirsi seems to aim for. The cost is low enough that their devices aren't a waste of money. When I was a youngster a very simplistic analog hobbyist scope costed nearly 10 times this price.

[Fungus]

And you don't think the 40V inputs isn't a significant design limitation ?

Not really, no.

A 10x probe means you can measure 400V - more than enough for most hobbyists.

(I'm really starting to believe that all tautech ever does is measure ripple on power supplies...)

[tunk]

Here's a short look, including a photo of the PCB (using Google translate):
https://nyed4fwvpph67kpf77dsqfbzwy-ac4c6men2g7xr2a-mysku-ru.translate.goog/blog/misc/85585.html

[Lukas]

Specifying memory depth in bits is very odd and a good way to make numbers look bigger than they actually are. Assuming 8 bit and 2 channels, this equals about 15kSa/channel. Not very much. Judging from the linked PCB photos, they're probably only using the block RAM of whatever FPGA that is.

[Algoma]

Looks like the Allwinner F1C200s F1C100s and the FPGA looks like perhaps a rebranded GoWin FPGA. Just like the Hantek DSO2C10, but built even cheaper in so many ways.

Curious they put the firmware on the SD Card.. That makes it a bit too easy to modify.. not sure about the input jacks so far away from the frontend inputs.

[tunk]

First video review:

[joseph nicholas]

I think this scope is perfect for tech schools, and the high school lab.  It can be secured so as not to be stolen its cheap in case the students want to try to burn it and easily replaced.  For most hobbyist, the touch screen portable version would be much better.  You could take that out to the car or put it in a back pack.  Now do this with a spectrum analyser.

[UniSoft]

SoC Allwinner F1C100s
this is the same as 1013D... so, maximum 200Msps per channel.

there is a review in Russian:
https://mysku.ru/blog/misc/85585.html

[techcornertv]

Hey Guys,

This review was made by me, I tried to give the idea that this is a very limited oscilloscope in the video,
Bare in mind that im hobbyist, not a profissional, my degree  in system computing, not electronics, but I'll try to sum the pros and cons:

Pros:
- Extremely easy to use
- Small size and big screen (for the size)
- Already includes a function generator (14 functions)
- Very cheap, mine with delivery costed 155€ (~ $185)
- It seemed fairly accurate and fast analysing signals
- The function generator BNC connector is on the front
- Very nice display, very sharp and the information  (vpp, vavg, etc) is very visible, not like in my Rigol MSO2102A where it is shown in very small letters (it has other funcionalities)
- The cursors respond very fast and a very intuitive to use
- It has FFT function included


Cons:
- It hasn't have an ground/earth connector
- it's powered by USB (5V 2A)
- There is a some problem when using the probes related with the ground that has to be the same... you might burn the motherboard if its not the same (warning on first page of the manual)
- The function generator has very low frequencies maximum, you can get max 10Mhz in sine wave
- It is very limited on the function available, an example is no math function of any kind
- I forgot to say this in the video but, you don't have the normal square wave connector for callibrating, you have to connect the aligator to bnc cable to the function generator an then somehow use in the probe to be able to calibrate the probe

My conclusion:
As always, if you're making an informed purchase, aware of the cons and pros, I believe this is a very good purchase for people starting in electronics, hobbyist like me or even work tasks do not that require advanced function in a oscilloscope. To be honest, I would't exchange my rigol for this, not in a million years, but I enjoyed VERY MUCH working with it.

You just need to know what you're buying.... it is a awesome buy if you know what you're getting, it will do the work, but forget fancy features.

I didn't open the oscilloscope in the review, because I don't want to pass the ideia that I know more than I really know, and to be honest I'm not qualified to analyse a motherboard and say if it is good or not. And also, since Im giving this unit to a channel subscriber, I didn't want to compromise the warranty.

Cheers,
Hugo Ferreira

[techcornertv]

It say it can up to 400V with 10x probe mode... didn't tested.

[techcornertv]

i have a sneaking suspicion the video may have been sped up in post-production. i could be wrong, but some of the hand movements and multiple presses of buttons seems unnaturally quick.

on the plus side, elements of the UI seem refreshingly new, other manufacturers could possibly uplift some of the design cues. and even if the scope only had a 'true' bandwidth of 20MHz, at the right price-point (sub-$100us) it could be a real winner. notice the use of an external plug-pack for power.


cheers,
rob   :-)

Hello!

I made the review and I would gladdy send the original recording mp4 for your analysis or anyone else for that matter, just private me your e-mail address and will send by WeTransfer all the raw footage.
Nothing was speed up, it is really fast moving the cursor... it blew my mind away.... to move the cursors in my rigol is a nightmare (well a little over dramatic here) but in that small oscilloscope it is fast
and intuitive. Those direction keys really help. Anyway, this is just my feedback...

Cheers,
Hugo Ferreira

[firepower]

Hugo, it was regards marketing video not your review video being 2x speed.
https://youtu.be/LuBntXGnRZ0

[firepower]

Without serial / I2C decoders, I rather pay extra and get the Hantek models.

[techcornertv]

Hugo, it was regards marketing video not your review video being 2x speed.

Ooopss... sorry! My bad...

[techcornertv]

If someone is interested in a unit of this scope, here it is the video for the giveaway/sweepstake:



An the page for enter in the giveaway and with the rules:

https://techcorner.tv/giveaways/fnirsi-1014d-digital-oscilloscope-giveaway/

Best of luck! 🤞
Hugo

[tunk]

Manual and firmware are now on Fnirsi's homepage: http://www.fnirsi.cn/support

[dmitrkov]

After updating to this firmware, the image was shifted to the left
" alt="" class="bbc_img" />

Rolled back to the old version...

[pcprogrammer]

I agree with others here, it looks very much like the 1013D. The ground problem lies in how they did the analog in the 1013D and probably the same for this one. For the 1013D no problem since it works from the battery, but one should pay attention when connected to a usb port or power supply.

The only interesting extra is the signal generator. I wonder how they implemented that. Did they use the fpga that scans the inputs for it or is there another chip. The same goes for the knobs and the buttons. By looking at the pcb picture near the top left there is an other chip with lots of pins. Do not see a separate cable for a touch panel so probably no touch. (Did not look at the specs or the full review video's so could be wrong)

The sd socket is most likely for storage of the signal and image storage, just like in the 1013D. On the pcb it looks like the same three memory chips. One flash for the f1c100s, one flash for the fpga and one special chip for the settings. By the looks of it they did improve on shielding by putting a can over, what I assume is, the power supply section.

Checking out the firmware could be a fun project, but for now still struggling with the one of the 1013D

[tunk]

Another review:

[Crjbroker]

Hello every body,

I have bought a unit of the 1014D and it has come up with a problem that channel 1 does not measure DC voltage. It's funny because if it's a waveform signal it works fine.
When measuring a DC signal it makes a voltage spike and then returns to zero.
If you then touch the dough with the tip, it makes a negative peak and returns to zero again. It is as if it has a condenser effect.

Does anyone think of what the problem could be?
This only happens on channel 1. Channel 2 works perfectly.

[Fungus]

Does anyone think of what the problem could be?

You have AC coupling mode selected on that channel, it should be DC.

[tunk]

Second part of learnelectronics video above, including a teardown: https://youtu.be/T_W1ozehOpg
And a Q&A session from TechCornerTV: https://youtu.be/6ACe_F2poLw

[tunk]

A repair video, including close up of the front end (at 3:28)(use autogenerated English subtitles if you don't understand Portuguese):

[tunk]

I have bought a unit of the 1014D and it has come up with a problem that channel 1 does not measure DC voltage.

Could look like the same problem that was fixed in the video above.

[rpa]

I bought recently the FNIRSI 1014D and I am fairly pleased with it for the price I paid, around 140€ with shipping. Quite cheap for such a device. It's easy to use and one of its attractions to me is the fact you can power it from a common 5V smartphone powerbank, making it ungrounded. It has its flaws and limitations though, most already stated here but to me the most restricting is the 50mV limit.

Updated the firmware with the latest one available on FNIRSI's site and have been doing some tests with it with various sources, including the internal signal generator. Bear in mind I'm a begginer enthusiast in electronics, still learning. I learnt how to use a CRT oscilloscope in University Electronics classes 25 years ago so I do understand the basics of electricity and electronics, been picking the subject again lately (I work in IT). I also have a Hantek DSO5202D, it's a fairly decent oscilloscope and it has a 16ch logic analyzer I was interested on.

I think I found a couple bugs in the latest firmware, already sent an email to FNIRSI detailing them and how to reproduce them.

Both bugs happen in both channels and are caused when you press the trigger MODE button to change the trigger type, each bug depends on some conditions. The bugs are:

- This is independent of having just one or both channels active. If the vertical sensitivity (V/div) is different from 1V in 1x mode or 10V on 10x mode and you press MODE, the DIV parameter shown on the channel settings on top of the screen always goes back to 1V or 10V respectively and the voltage measurements start showing wrong values; the wave display usually stays the same size, but might disappear if the set V/div is higher than 1V or 10V respectively.

- If you only have 1 channel active and the coupling of the channel was set to AC and you press MODE, it always changes to DC on the channel settings on top of the screen and it seems it always changes to DC coupling even if you press MODE twice to go back to Auto triggering (it starts to show the DC component of the signal instead of only the AC component). It does not happen if both channels are active!

Other than that, it seems a somewhat capable device for the price for a hobbyist or a begginer.

[rpa]

Just a heads up, FNIRSI did respond to my email about a week after I posted my last message, and sent me an updated firmware in the form of 2 slightly different firmware files. Sorry for not reporting this earlier but I just didn't have the time and mind, due to other stuff going on in my life, and I also didn't know if they wanted the firmwares made available generally. The files are now available in their suport page at their site.

The reason for 2 files is that the 1st batch of the 1014D use a different LCD and that's why some have experienced displaced images. I tried the 1st firmware and it displaced the image down and to the right, so it's probably the right one for those which had the displacement up and left. The other one worked fine with my unit. The 2 bugs I mentioned here were fixed and it works just fine now.

So, a good and fast response from them, kudos.

[pcprogrammer]

Received this scope yesterday as a gift from a forum member who likes my work on the FNIRSI-1013D

I can say that they improved on some of the flaws found in the FNIRSI-1013D, but is uses basically the same hardware.

Could not resist and had to open it up. Made a disappointing discovery. There is no integrated DAC for the function generator. It is 8 digital outputs from the FPGA into a resistor network, most likely R-2R. See the attached photos.

For the knobs and push buttons they use a GD32E230, so most likely no hacking of that part of the system.

The PCB is nice though. Gold plated on parts of it.

[dmitrkov]

The support site has a new firmware from 08/08/2021

[pcprogrammer]

Was wondering if the 1014D has the same issue as the 1013D with the images from the SD card. It does. See the attached images. Not sure if it is my linux mint or the actual images but my guess is the latter.

And bugs, of course not

When connected via USB with an image from the SD card open on the computer all one has to do is press the menu button and the change is very big you get what you see in the second and third image.

Have not tried to load the new firmware dmitrkov pointed to.

[dmitrkov]

Yes, the firmware has a lot of bugs.    I wrote about some mistakes to the seller and after a long  time they fixed them. It may be worth writing about this error to the seller.

P.S. on the official support site, the firmware for this oscilloscope was completely removed ...

[pcprogrammer]

P.S. on the official support site, the firmware for this oscilloscope was completely removed ...

I noticed that too. Wanted to download them today, but nothing there

For the 1013D I found out that it can be updated with the same procedure. It needs one of these files on the SD card: "UTX-1013.bin", "FSI-1013.bin", "DAN-1013.bin" or "YPK-1013.bin".
These names are in the function I wrote about in the 1013 thread, were at the end of the function, if anything goes wrong it zero's the first 1000 bytes of the program location in the flash. As it makes use of the SD card code it will become clearer once I reversed that.

[dmitrkov]

For the 1013D I found out that it can be updated with the same procedure. It needs one of these files on the SD card: "UTX-1013.bin", "FSI-1013.bin", "DAN-1013.bin" or "YPK-1013.bin".

I also thought to try with the file name "FSI-1013.bin", but there was not enough time. You have confirmed my assumptions.

Here are collected all the firmware that I have at the moment, for 1014D https://1drv.ms/u/s!Av-Riptwsak2ivB9XUOHBWbRCGIOzA?e=VU2MfD
I hope FNIRSI will not mind, since these firmware were already freely available

[thirteeneast]

Too summarize, for anyone reading this "ITS GARBAGE, I WOULD BUY IT WITH YOUR MONEY!!!"

KEEP CLEAR OF IT.

[SlowLogicBoy]

For the knobs and push buttons they use a GD32E230, so most likely no hacking of that part of the system.

Isn't GD32 just a clone of STM32 (same like CKS32), I think firmwares are compatible, meaning you can flash STM32 firmware to GD32, we just need to figure out which STM32 this is clone of exactly.

[pcprogrammer]

They are very similar, but not sure if they are exact clones. The datasheet of the GD32E230 is available and the peripherals will most likely have the same functionality as the ones of the STM32 ranges.

It is more a question if they used protection of what is in the flash, to be able to reverse it. Otherwise it means making a schematic of the connections of the rotary's and the buttons to the mcu and write your own program for it. They most likely connected it to the F1C100s via an UART. (The one in PORT A, since there is no touch panel)

The code for the F1C100s of the 1014D is smaller then what is in the 1013D, but it will have a lot of common code.

Have not yet looked at it since I'm still busy with the 1013D reversal.

[mkstevo]

Too summarize, for anyone reading this "ITS GARBAGE, I WOULD BUY IT WITH YOUR MONEY!!!"

KEEP CLEAR OF IT.

It's much, much better than one I bought from a UK educational supplier for close to three times the price (Owon), or the 50+ Gw Instek ones the College bought. I can't believe how good it is. Not everyone has the need for ultra high precision, nor the funds to spend a fortune on something that might be classed as "better". At a price of just over £125, shipped (including VAT) it's fabulous - unmatched. As long as you accept that it probably will only resolve signals of up to 25-30MHz you won't be disappointed. The measurements being shown on the right hand side of the waveform display is a vast improvement on the Owon, they are lovely and clear in a reasonable 'at a glance' font. The trigger point can be shifted to the left side of the display without it shifting when the time/div is changed (as it does on the Owon) making the display much more friendly for non-repetitive signals. An Owon 30MHz dual channel 'scope is currently £332. It is also a vast improvement on any single PicoScope I have ever used - and I used a lot when I was working in a Further Education College. My favourite 'scope at the College was a Hameg Analogue/Digital one, it had enough analogue circuitry to make it work like a traditional 'scope, but enough digital circuitry to offer waveform measurements and storage. The Fnirsi 1014D is the first 'scope I've used that hasn't made me hate fully digital 'scopes. I absolutely love it and my £125 was money well spent.

[tunk]

The minimum sensitivity is 50mV/div - isn't that a bit limiting?
And where did you find it for £125?

[pcprogrammer]

Yeah, 125 pound is about 146 euro and that is, with the new VAT rule in Europe, very cheap. I paid ~163 euro for mine. (Aliexpress)

[tautech]

The minimum sensitivity is 50mV/div - isn't that a bit limiting?

Fatally so.
Connect a 10x probe and it becomes 500mV that makes it unusable for many tasks.

[pcprogrammer]

The minimum sensitivity is 50mV/div - isn't that a bit limiting?

Fatally so.
Connect a 10x probe and it becomes 500mV that makes it unusable for many tasks.

Since the lowest setting actually is 100mV/div because to get the 50mV/div the software does a times two and makes it just a digital zoom. So it is even worse

But that being said it is very responsive on the user interface. This is a drawback of the hantek DSO2XXX series, at least the one I have (did not check or upgrade the firmware yet). It responds quite slow to changes of the settings.

For doing measurements on MCU projects it is usable though.

[tunk]

Out of curiosity, is this only done for the 50mV range, or
have they "optimised" the design by using hardware for
every second range (0.1V, 0.5, 2, 10 etc.) and software
for the rest (0.05V, 0.2, 1, 5, etc.)?

[pcprogrammer]

The scope has 7 ranges (0-6) that can be selected. 6 of them make actual changes in the hardware. You can hear the relays click. So it is only for the change from the one but lowest to the lowest that they use the digital zoom.

Code: [Select]

const int8 *volt_div_texts[3][7] =
{
  { "5V/div", "2.5V/div", "1V/div", "500mV/div", "200mV/div", "100mV/div", "50mV/div" },
  { "50V/div", "25V/div", "10V/div", "5V/div", "2V/div", "1V/div", "500mV/div" },
  { "500V/div", "250V/div", "100V/div", "50V/div", "20V/div", "10V/div", "5V/div" }
};

This is the settings lookup table I implemented in my version of the 1013D code, which uses the same hardware as the 1014D, to display the settings for the different probe magnification factors. The original code works with switch statements to get this done.

[tunk]

A hypotetical question: Would it be possible to design a scope where
every second range is hardware (e.g. 5V, 1, 0.2, 0.05, 0.01 and 0.002)
and the rest is software? I.e. trading some resolution for gaining lower
ranges?

And great thanks for your work on the 1013D.

[pcprogrammer]

And great thanks for your work on the 1013D.

Your welcome

About the hypothetical question, I guess it should be possible. In the hardware it is either dividing to a lower voltage or amplifying to a higher voltage. Have each step bring the required input range to full scale ADC range. In software the rest is easy.

[Hydrawerk]

 

[nctnico]

The scope has 7 ranges (0-6) that can be selected. 6 of them make actual changes in the hardware. You can hear the relays click. So it is only for the change from the one but lowest to the lowest that they use the digital zoom.

Code: [Select]

const int8 *volt_div_texts[3][7] =
{
  { "5V/div", "2.5V/div", "1V/div", "500mV/div", "200mV/div", "100mV/div", "50mV/div" },
  { "50V/div", "25V/div", "10V/div", "5V/div", "2V/div", "1V/div", "500mV/div" },
  { "500V/div", "250V/div", "100V/div", "50V/div", "20V/div", "10V/div", "5V/div" }
};

This is the settings lookup table I implemented in my version of the 1013D code, which uses the same hardware as the 1014D, to display the settings for the different probe magnification factors. The original code works with switch statements to get this done.

Late reply... My guess would be that this table is for a 1:10 probe. It wouldn't make sense to have a 500V/div setting because that would mean the scope could deal with several kV at the input (which it very likely can't). An upper limit of 50V/div is already high for a DSO.

[pcprogrammer]

Also late Been away on a short vacation to visit family.

I thought the descriptive text would make it clear, but the table is for the three possible probe magnifications. The first row is for the x1 setting giving 5V/div to 50mV/div, the second row is for x10 setting giving 50V/div to 500mV/div and the last row is for x100 setting giving 500V/div to 5V/div.

If it is wise to use it with such a probe and apply 4000V for max screen usage is an other question

With the probe on 1x it is max 40V that can be displayed.

[Dejan J]

Hi !
I am new on this forum. Today I received link from FNIRSI ( I joined their WhatsUp group) with
new firmware V3.0.
 File and description from it are attached.

[Dejan J]

YEAPOOK ADS1014D Digital Oscilloscope

New name for the same thing!!!

Link:
https://www.aliexpress.com/item/1005003136406423.html?dp=wwwadepibe&aff_fcid=781875729c2649abbd42f71365aa07d4-1634466828400-02777-_A3gt8c&tt=CPS_NORMAL&aff_fsk=_A3gt8c&aff_platform=portals-promotion&sk=_A3gt8c&aff_trace_key=781875729c2649abbd42f71365aa07d4-1634466828400-02777-_A3gt8c&terminal_id=cf3f1ef4ded845cd99ccc908044f93fe

YouTube:

[radiolistener]

YEAPOOK ADS1014D Digital Oscilloscope

I suspect this is remarked FNIRSI 

[pcprogrammer]

Judging by the 1013D firmware there are at least 4 versions of it, so might also be the case for this one.

The firmware file can be named:

• FSI-1013.bin
• YPK-1013.bin
• UTX-1013.bin
• DAN-1013.bin

Guess the first one is from FNIRSI and the second one YEAPOOK. The others I don't know

[Dejan J]

 I think that fourth one is for DANIU.

[tunk]

Looks like firmware v3.0 was uploaded 2021-11-01: http://fnirsi.cn/support

[Doctorandus_P]

I've seen a few reviews of these "fnisi" things and I find it appalling. (The fnirsi, not the reviews).

They've made a nice box, power supply, display, buttons, etc, but they've cut too many corners in the front end and hardware to call this a decent scope.

Every scope has some "pro's" and "cons", but this one has "it does not work properly" in it's list of cons. Even though it is sometimes capable of making a picture that resembles your signal, that should not matter. It's flaws are so big that you can not rely on the picture of the waveform it shows you. And this is especially troublesome for beginners for they do not recognize when this thing that only looks like a scope from the outside goes in the wrong.

So save up your money and buy something decent.
Decent scopes start at around EUR250.

[pcprogrammer]

In light of the developments on the 1013D, I thought lets try to make a backup of the 1014D with my firmware backup program for the 1013D.

Since it lacks the touch panel some modification was needed, and considering previous disaster with my new 1013D scope, I decided to open it up first and make a full backup with FEL.

After that I loaded my 1014D firmware backup program to the SD card and it worked, but there are a couple of issues.

• The display is definitely different from the one in the 1013D. My backup screen flickered quite a bit, so scan frequency or other settings differ.
• There is an issue with my (and the original 1013D) SPI implementation. The first byte of the full flash backup shows zero while it needs to be 6.

This last issue I also noticed on my new 1013D, but not on my old 1013D. Need to dig into the firmware of the 1014D to see if I can find out why. Also needed for the different display settings.

The layout in the flash seems to be the same as for the 1013D.
0x00000000 SPL
0x00006000 Firmware updater
0x00013000 Startup image
0x00027000 Actual scope program
0x001FD000 Settings
0x001FE000 Hardware check disable

I still have to complete the 1013D reverse engineering, but with so many similarities my efforts can form a good base for the 1014D reversal.

[pcprogrammer]

Found something interesting. They changed the FPGA programing. In the 1013D there is a FPGA command for setting the display brightness, which expects two bytes for the setting, where the 1014D seems to be using just a single byte. The command number is the same: 0x38.

I found this while going through the boot loader of the 1014D. Most of the code is the same as for the 1013D, even the display configuration seems to be the same for displaying the startup image. So it might be that the startup image is in an apparent different location on the screen between the two models.

This means I have to look into the scope program to see what the display settings they are using are. I expect them to be different.

It raises the question to what else they changed in the FPGA and if it is for the better, signal trigger wise.

Edit: Looked into the main program in Ghidra, and there they use two bytes of data for the brightness, just as in the 1013D
It shows a rather similar code structure as in the 1013D, but there are differences in the main startup functions. The "SD ERROR" is at least a handle into the initialization of FatFs.
I added the parts to my 1013D Ghidra archive, which can be found in the repository: https://github.com/pecostm32/FNIRSI-1013D-Hack

[pcprogrammer]

Worked a bit on naming the functions in the Ghidra archive. There is a lot of common code between the 1013D and 1014D. The major differences are of course the lack of the touch panel and the addition of the generator.

The touch panel is replaced by the GD32 chip that handles the buttons and the rotaries, and I think it uses UART1 to communicate.

For the generator it looks like they added some FPGA commands. Values in the 0x4X range.

The scope part of the FPGA looks to be the same. Found all the commands for setting the diverse settings like volts per div and time base. They also have the code for the parameter translation IC in there, so I guess the whole signal acquisition works the same.

Found bits of the USB code which are also the same, so again a guess that it is also the same as in the 1013D. It definitely hangs in the same way

Just a little bit a day as a thing to take my mind of the 1013D development and diversify a bit

[pcprogrammer]

Looking at the FPGA commands being used to do the acquisition on the 1014D and I see some differences to what is done on the 1013D.

There is a new command 0x29 that either takes 0 or 1 as data. No idea what it is for, but it looks like the work done on the 1013D needs adaptation to be able to be used on the 1014D. Luckily there are many similarities.

The Ghidra archive now also holds the latest version of the 1014D code. On a binary level there are many differences, but on code level it is still very similar. It looks like they moved variables to another location, because that entails the majority of the differences.

Between the two version FNIRSI distributes it is only the settings for the display that differ. Two bytes in total. This leads to the check bytes at the end being different too, but that is not code.

See my function for the display initialization. In the comments are the different settings

Code: [Select]

void sys_init_display(uint16 xsize, uint16 ysize, uint16 *address)
{
  int32   time;
 
  //Setup the used port D pins for LCD
  *PORTD_CFG0_REG = 0x22222227;   //PD00 is not used for the display
  *PORTD_CFG1_REG = 0x22222227;   //PD12 is not used for the display
  *PORTD_CFG2_REG = 0x00222222;   //Only 22 pins for port D
   
  //Clear the display memory (Set in bytes so twice the number of pixels)
  memset((uint8 *)address, 0, xsize * ysize * 2);
 
  //Clear the DEBE registers
  memset((uint8 *)DEBE_MODE_CTRL, 0, DEBE_NUMBER_OF_BYTES);
 
  //Disable the LCD timing control module
  *TCON_CTRL = 0;
 
  //Disable the LCD timing interrupts
  *TCON_INT0 = 0;
 
  //Disable the LCD clock
  *TCON_CLK_CTRL &= 0x0FFFFFFF;
 
  //Disable all the TCON0 display outputs;
  *TCON0_IO_CTRL1 = 0xFFFFFFFF;
 
  //Disable all the TCON1 display outputs;
  *TCON1_IO_CTRL1 = 0xFFFFFFFF;

  //Display engine back end section
  //Enable the display engine back end
  *CCU_BUS_CLK_GATE1 |= CCU_BCGR1_DEBE_EN;

  //De-assert the display engine back end reset
  *CCU_BUS_SOFT_RST1 |= CCU_BSRR1_DEBE_RST;

  //Enable the display engine back end
  *DEBE_MODE_CTRL |= DEBE_MODE_CTRL_EN;

  //Set layer0 size to xsize - 1 and ysize - 1
  *DEBE_LAY_SIZE  = ((xsize - 1) & 0x07FF) | (((ysize - 1) & 0x07FF) << 16);
  *DEBE_LAY0_SIZE = *DEBE_LAY_SIZE;
 
  //Set the layer0 line width in bits. (Using 16 bits per pixel)
  *DEBE_LAY0_LINEWIDTH = xsize * 16;
 
  //Set layer0 frame buffer address in bits. (8 bits per byte) With a 32 bit address the top 3 bits get lost. The manual is not clear about this.
  *DEBE_LAY0_FB_ADDR1L = (uint32)address << 3;
 
  //But in the scope there is a write to an un-described register
  *DEBE_LAY0_FB_ADDR1H = (uint32)address >> 29;
 
  //Set the layer 0 attributes to 565 RGB
  *DEBE_LAY0_ATT_CTRL1 = DEBE_LAY0_ATT_CTRL1_RGB565;
 
  //Enable layer0
  *DEBE_MODE_CTRL |= DEBE_MODE_CTRL_LAYER0_EN;
 
  //Load the module registers
  *DEBE_REGBUFF_CTRL |= DEBE_REGBUFF_CTRL_LOAD;
 
  //Start the output channel of the display engine back end
  *DEBE_MODE_CTRL |= DEBE_MODE_CTRL_START;
 
  //Video clock section
  //Set video PLL to 390 MHz ((24 * 65) / 4)
  *CCU_PLL_VIDEO_CTRL = CCU_PLL_ENABLE | CCU_PLL_VIDEO_MODE_SEL_INT | CCU_PLL_VIDEO_FACTOR_N(65) | CCU_PLL_VIDEO_PREDIV_M(4);
 
  //Max checks on PLL becoming stable
  time = 4000;
 
  //Wait for the PLL to become stable, but not endlessly
  while(time && ((*CCU_PLL_VIDEO_CTRL & CCU_PLL_LOCKED) == 0))
    time--;
 
  //Enable the lcd clock
  *CCU_BUS_CLK_GATE1 |= CCU_BCGR1_LCD_EN;

  //Turn the LCD (TCON) clock on. Assume clock source to be PLL_VIDEO * 1
  *CCU_LCD_CLK |= CCU_LCD_CLK_EN;
 
  //De-assert the lcd clock reset
  *CCU_BUS_SOFT_RST1 |= CCU_BSRR1_LCD_RST;
 
  //Use the TCON0 registers
  *TCON_CTRL &= ~TCON_CTRL_IO_MAP_SEL_TCON1;
 
  //Enable the timing generator. TCON source is DE CH1 (FIFO1 enable). TCON_STA_DLY = 23.
  *TCON0_CTRL = 0x80000170;
 
  //Enable all LCD clocks. Dot clock divider is 6.
  *TCON_CLK_CTRL = 0xF0000006;
 
  //Set timing based on the sizes. xsize - 1 and ysize - 1
  *TCON0_BASIC_TIMING0  = ((ysize - 1) & 0x07FF) | (((xsize - 1) & 0x07FF) << 16);
 
  //18--11-2021
  //Found 4 different settings through the software versions
  //1014D new version 0x041E0043, 0x041A0019
  //1014D old version 0x041E006D, 0x041A0022
  //1013D version 1   0x041E0044, 0x041A0017
  //1013D version 2   0x041E004A, 0x041A0017
 
  //Horizontal total time and horizontal back porch
  *TCON0_BASIC_TIMING1 = 0x041E0044;
 
  //Vertical front porch and vertical back porch
  *TCON0_BASIC_TIMING2 = 0x041A0017;
 
  //Horizontal sync pulse width
  *TCON0_BASIC_TIMING3 = 0x160000;
 
  //
  *TCON0_HV_TIMING = 0;
 
  //
  *TCON0_CPU_IF = 0;
 
  //DCLK1 (1/3 phase offset). IO0:2 invert IO3 not invert.
  *TCON0_IO_CTRL0 = 0x17000000;
 
  //
  *TCON0_IO_CTRL1 = 0;
 
  //Enable the LCD timing control module
  *TCON_CTRL |= TCON_CTRL_MODULE_EN;
}


The interfacing with the GD32 for the user interface starts with the F1C100s sending an 0xFF and then reading some data from the GD32. Probably not to complex.

But for this one also a long road ahead. Less then for the 1013D, since a lot of the work has already been done there, and is still being done.

[mkstevo]

I've seen a few reviews of these "fnisi" things and I find it appalling. (The fnirsi, not the reviews).

...

Decent scopes start at around EUR250.

With respect though, that is nearly double the price of the FNIRSI.

I have an OWON that I use at work which cost close to £400 five years ago and it is worse in every single way to the FNIRSI. Not only is the user interface worse, it takes in advance of 60 seconds to start, it constantly needs the self-calibration running, the display isn't as bight and any measurements are laid over part of the (much smaller) screen. Worse still is that if you move the trigger point to view more of the waveform on the OWON if you change the horizontal timebase the trigger point moves relative to the timebase making the trigger point move right off the screen and somewhere into last/next week.

I too have used some very high end oscilloscopes, I have worked in the technical department for a Technical College, for a company that manufactured measuring equipment in the aerospace and oil extraction industries and for consumer electronics companies, I'm now working for a small company where money is restricted for test equipment and so bought the OWON, I wish I'd had the chance then to buy the FNIRSI. I don't seek to claim that Hameg should be worried by FNIRSI, the two are polar opposites, but for the life of me I can't understand the snobbery towards FNIRSI.

It is a superb little oscilloscope and function generator, bought with realistic expectations I doubt you would be disappointed. Yes, I'd love a Hameg at home like I used to work with, but I can't justify the expense for something I'll use only a few times a year. I would also like to justify replacing the OWON with a FNIRSI, it would save me pulling my hair out quite as often.

[tautech]

I don't seek to claim that Hameg should be worried by FNIRSI, the two are polar opposites, but for the life of me I can't understand the snobbery towards FNIRSI.

Despite your experience you have overlooked the most basic of scope requirements, input sensitivity and input ratings !

With a max sensitivity of only 50mV/div and 40V max at 1x input attenuation severely limits this scope for even basic use. Only by adding a 10x probe is the input rating increased to 400V, a rating that is standard at 1x for most other DSO's available however with a 10x probe max sensitivity becomes 500mV/div !

Snobbery, be buggered, practical usefulness is what really matters.

[badz]

It is a superb little oscilloscope and function generator, bought with realistic expectations I doubt you would be disappointed. Yes, I'd love a Hameg at home like I used to work with, but I can't justify the expense for something I'll use only a few times a year. I would also like to justify replacing the OWON with a FNIRSI, it would save me pulling my hair out quite as often.

You can watch few teardown videos for this scope, its hardware design is worse than 1013d tablet scope. For 1014D they have to use software averaging and interpolation algorithms to deal with ringing and noisy inputs.

[JOSM]

I have bought a unit of the FNIRSI 1014D. I like the idea of having the 5V power supply. That makes it portable.
So, here is my mod.
I am using an USB power bank RealPower PB-5000C. The good thing about this powerbank is, it does not need to be switched on prior to usage. That makes it easy to hide inside the oscilloscope.

[Jackster]

Just got one of these today. Jesus, they must have gone out of their way to get the worst encoders they could get. I'm sure there are cheaper ones better than this 

For what I need, this scope works great.

I am binning ultrasonic sensors and just wanted an easy way to certify each transducer and receiver with a 100Hz step.
At 20-60Hz, this scope I think is more than accurate enough to selectively bin components?

Got it off Amazon UK for £150, https://amzn.to/33sQ1Os and it is branded "YEAPOOK ADS1014D" on the listing and box but the actual scope just has "Oscilloscope" as the brand on the top left.
Had a few free £20 coupons to use up so only cost me a few quid and got it same day.

Is the firmware worth updating? I don't know how to tell which version I am on. Right now it works fine and I sort of don't want to touch it.

[joseph4511]

Hello folks, i got my 1014D off Amazon. Scope was working fine till yesterday. Now it does turn on but thats it, freeze on fnirsi logo. I think firmware is gone, disassembled the device and connected the W25Q16 chip to pc. Compared the partial binary codes with update firmware, seems they re same. I guess scope firmware is gone, hope you guys can extract the whole bin file for me from the W25Q16. Thanks

[pcprogrammer]

Attached is the content from my flash.

I made it with the firmware backup-er I wrote, which is also attached. It runs from the SD card. Since your scope is not booting the only way to load it is to remove the SD card and use a card reader/writer.

For more info on the firmware backup program take a look here: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3807689/#msg3807689

In that thread is a lot of information about how the 1013D works, and the two scopes are very much the same software wise. A lot of info can be found here: https://github.com/pecostm32/FNIRSI-1013D-Hack

Success with the repair.

[joseph4511]

thank you so much for your effords, uploaded the whole firmware. Logo does not shift anymore but still stuck, does not boot to the scope program. Also firmware version v3.0 text disappeared. Should i upload the firmware with your backup loader ?

Also i attached my whole firmware file, your .bin file has too many blank spaces compared to my fw.

[pcprogrammer]

The fact that the firmware version v3.0 text disappeared means that the flash has been reprogrammed. This image is being displayed by the boot program. It looks like it has problems with reading from the part where the actual program sits in the flash. At address 0x27000 in the flash it expects a BROM header.

Try to replace the flash ic. It has to be at least 2MB, but does not have to be W25Q16. A W25Q32 or W25Q64 will also do.

My backup program will only make a copy of the flash onto the SD card. It does not write to the flash. It might show the problem though, because it is the scope's own CPU reading the flash.

[joseph4511]

Well i tried with genuine Macronix MX25L6405 8 MB ic flash, flashed with neo programmer which i always use for bios programming with verify option, nothing changed.

[pcprogrammer]

That makes it a problem then. The fact that the display has back-light tells us that the FPGA is doing something. Not sure if the GD32 chip in there for the knobs and buttons can block the boot up.

If you know your way around software the disassembly of the 1014D is also in the Ghidra archive in the 1013D hack repository. Maybe with the info from there you can determine why it hangs.

I gave up on reverse engineering this scope. Done the 1013D and that was educational and fun, but also frustrating.

[joseph4511]

Dont want to repair if its more then firmware issue. I ll send it back while i can, thank you so much.

[joseph4511]

they sent me a new motherboard which works perfect. Couplings work as they should. My old broken board has allwinner F1C100S and new one has f1c200s, could it be the issue ?

[YurkshireLad]

they sent me a new motherboard which works perfect. Couplings work as they should. My old broken board has allwinner F1C100S and new one has f1c200s, could it be the issue ?

Does the motherboard have a different revision number than the original?

[joseph4511]

there s no rev. number written. Only 1014D OSC, nothing is different than old board but F1C100s

[pcprogrammer]

there s no rev. number written. Only 1014D OSC, nothing is different than old board but F1C100s

The only difference between the F1C100s and the F1C200s is the size of the DRAM. 32MB for the 100 and 64MB for the 200. It might be that they ran out of the 100 and used the 200 instead. Doubt that they changed the firmware to make use of the extra memory.

Would be interesting to see what is wrong with the old board

[joseph4511]

i tried to reflash every rom from new board nothing changed. Checked all boosters and xtals. Also checked with flir nothing gets hot than usual. Afaik problem occured when its off and plugged to voltage source. If you have any idea to start somewhere, i d be grateful

[pcprogrammer]

The fact that the board is (was) able to load and display the startup image tells us that part of the system is working as it should. The fact that it hangs after displaying it tells us that it fails in either loading the real program or that the real program itself hangs before clearing the screen.

Running the firmware backup program I wrote will show if the system is capable of reading the whole flash and interact with the display. So that is one test you could do.

Other things that come to mind are:

• The DRAM in the F1C100s has a problem
• A peripheral in the F1C100s has a problem
• The GD32 chip for handling the buttons and knobs has a problem
• The FPGA has a problem

A test to perform is measure all the voltages on the board. The hardware is very similar to the 1013D so look at the schematics in the repository.

In the hack repository https://github.com/pecostm32/FNIRSI-1013D-Hack a lot of information is available to research the problem.

It could be a fun learning experience. It is possible to run linux on the F1C100s, but it needs a serial connection to one of the chips UART, so you have to figure out if it is possible to connect a USB -> serial converter to the one connected to the GD32 chip. There is a linux image in the repository that should work. (It does on the 1013D)

I myself would write my own test programs to check things, but that is me

Have fun with it

[joseph4511]

i replaced F1C100s with 200s and worked on working board, broken is still same. Swapped GD32 with working one nothing have changed. I swapped SE 98 marked component and i have 2 dead board with same issue now

[pcprogrammer]

Is also a way to get to the broken component. Requires good soldering skills and tools

I looked at my board but did not see a chip with SE 98 marking on it. Can you take pictures of the board and show which component you are talking about?

Attached is a picture of my board.

Edit: Made markings on the board picture to identify some of the parts on it.

[joseph4511]

It was special i2c ic that i changed. I have Quick 816dw Hot air station and aixun t3a soldering station with genuie jbc c245 tips. Amscope trinocular microscope, uni t ut61e+ multimeter, vision 8 bga machine and vice versa. I can solder everything without a doubt I have pretty good soldering skills and tools.

Edit: the making on the IC is SE 98, when i checked for datasheet there s only one which is ddr temperature sensor.

[pcprogrammer]

Well then I hope you still have one that is working, because this IC is unknown to what it is. Most likely some micro-controller with a forgiving I2C interface. (The I2C implementation in the FPGA is not very good timing wise)

In the original firmware it is used as some lookup device. It is also found in the 1013D but I found that it is not actually needed for reading the sample data from the FPGA.

It might well be possible to implement the needed functionality in a tiny85 or similar type of MCU. The defective board can be used without it, but needs firmware that is stripped from using this special IC. Not an easy task since it still needs the response values to have the rest of the system behaving properly.

[joseph4511]

They both dont work now i dont know why

[pcprogrammer]

They both dont work now i dont know why

Ouch  that is a bummer.

In the 1013D thread there is info about what the IC does and also some talk about measurements on the I2c data between the FPGA and the "special ic". For example a bit here https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3880016/#msg3880016

I guess there are three paths you can take:

• Do nothing and accept the device is bricked.
• Try to make code for a tiny85 MCU that mimics the "special ic". A lot of information can be found in the 1013D thread and repository.
• Try to hack the original firmware and kill of the code that interfaces with the "special ic". For this there is also a lot of information in the 1013D thread and repository.

A defective touch panel is what lured me in to reverse engineering the 1013D, so maybe the defective "special ic" is your lure for the 1014D

[joseph4511]

i do not have free time for this device Going to send it back to china, they will fix it in 10 minutes ) Im curious about the 100mhz, can this device measure 100 mhz correctly ?

[pcprogrammer]

Im curious about the 100mhz, can this device measure 100 mhz correctly ?

Nope, with 200MHz sample rate and the ~30MHz low pass bandwidth at the input it can't do 100MHz (assuming you do mean mega Hertz, upper case M and not milli Hertz, lower case m)

Did you make a copy of the FPGA FLASH? If so, can you post it here?

[free_electron]

When I was a youngster a very simplistic analog hobbyist scope costed nearly 10 times this price.

amazing what they can do for 100$ these days. My first scope was a Hameg 604. I paid over 1000$ back in 1985

[joseph4511]

Sure i can upload. Also uploaded the image of special IC with marking

[joseph4511]

Also they accepted refund without returning the goods So we can surgery every part on them, if you have any idea you can give. I do not understand software stuff, i m hardware guy

[pcprogrammer]

Hardware guy, well then it will not be easy. I did some thinking about the problem and knowing that the "I2C" implementation is not to good, there might be a problem with the pull ups being to high. 10K where 2K2 is more usual for I2C. Still a bit weird that after exchanging the "special ic" to the other board left you with two broken boards.

I have to search for the details on the communication between the FPGA and this "special ic" to devise a test you could perform. Others and I did do measurements on it with a saleae logic analyzer clone, so if you have such or a similar device it might shed more light on what is going on.

Maybe it is also possible to hook up the "special ic" to an actual I2C bus connected to a linux machine and see if it responds.

I'm more of a software guy, but with a long ago hardware background, so I know a bit about how things work. Especially not to high frequency digital stuff. 

[pcprogrammer]

Hi Joseph,

here you can find some screen captures of what the communication between the FPGA and the "special ic" looks like: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3583988/#msg3583988

To test the "special ic" with a dedicated I2C interface you could try a read of address 0. It should return multiple bytes of data.

Cheers,

Peter

[joseph4511]

I guess firmware in it is gone. No response from IC when i connect it to pc with I2C to usb adapter.

[pcprogrammer]

I wonder if there is a way to identify the chip. The fact that the "I2C" clock is ~820KHz makes it harder for bit banging, so a tiny85 (AVR based) might be to slow.

It intrigues me. I will take a look at the code and see if it is possible to remove the communication with the "special ic" from it, without it taking a lot of time.

[joseph4511]

Be careful, that crap tends to be broken. I dont want you to brick your device.

Edit: Can you compare your fpga rom file with file of mine? I did not applied heat there but im curious. Also found a Se98 datasheet, pinouts match maybe you can take a look.

[pcprogrammer]

Be careful, that crap tends to be broken. I dont want you to brick your device.

Edit: Can you compare your fpga rom file with file of mine? I did not applied heat there but im curious

I'm not touching the hardware Just looking at the firmware. It is looking back in what I did many months ago. As said the code is similar to the 1013D code, which I almost fully reverse engineered.

The code does an initialization of the "special ic" and it most likely hangs while waiting for a response. There is no timeout on that code. So removing the call to the initialization should allow the code to get a bit further. It will be a try and error game.

For comparing the fpga rom I have to extract the data from mine first. That is a bit of a pain in the bum to do, so maybe later.

[joseph4511]

Can you remove that line from firmware for that chip? I do not have knowledge for that.

[pcprogrammer]

Actually that is what I just did

The attached file is from last October 6th. Rename it to FS-1014.bin and load it on the SD card. The scope checks on startup if this file is present and will then write the flash with this data. If all goes well of course. This is the normal update procedure of FNIRSI

I have not tried it on my scope.

For those interested, what I did is change 4 bytes at location 0x04B330 from 0xFB, 0xBD, 0xFF, 0xEB to 0x00, 0x00, 0xA0, 0xE1. This changes a bl xxxx instruction to mov r0,r0.

[pcprogrammer]

Edit: Can you compare your fpga rom file with file of mine? I did not applied heat there but im curious. Also found a Se98 datasheet, pinouts match maybe you can take a look.

I looked at your fpga bitstream and at least the header looks to be correct. Don't expect any problems there, but you never know.

The se98 does not match the behavior of this "special ic" judging by the software. It is a bit strange that they left some marking on it. The three FNIRSI scopes (2x 1013D and 1x 1014D) I have don't have any markings on these ic's.

If the modified firmware I posted changes what your scope does I will make some more modifications to see if it is possible to make it work without this "special ic"

Edit: The SE98 also has a dedicated I2C address of 0x30 to 0x37 and not 0x00 which FNIRSI is using for this special ic.

[joseph4511]

everything stand still. Stucked on logo, takes 1.1 amps from supply. Can you replace the lines from whole firmware ?

[pcprogrammer]

Sure.

I expected it to show the scope screen and then hang, but there might be a call to the translate function before.

Hopefully this will have the scope continue, but it will not function as intended. I just disabled the call to the special ic without taking the needed actions on the data. When this indeed continues into the scope screen I will make a patch to make it work without the "special ic".

[joseph4511]

nothing have changed, device does not route to update screen

[pcprogrammer]

Hmm that is unfortunate.

I will have to dig a bit deeper. It might be that it needs a proper result from one of the call's to this translate function.

Later this week I have some time to play with it some more. Will use my scope with FEL mode to test things. Takes a bit of setting up but makes testing easier.

[joseph4511]

Thanks mate, i checked main firmware and i saw binary lines which match update binary. Maybe you can swap those lines like its updated.

Edit: I left a comment their YouTube channel and now they re responding very well. Let's see whats going to happen. The video link is : https://youtu.be/LuBntXGnRZ0 and my name is Yusuf Oylum

[pcprogrammer]

Thanks mate, i checked main firmware and i saw binary lines which match update binary. Maybe you can swap those lines like its updated.

Edit: I left a comment their YouTube channel and now they re responding very well. Let's see whats going to happen. The video link is : https://youtu.be/LuBntXGnRZ0 and my name is Yusuf Oylum

Hi Yusuf,

the first message beneath that video states that the October 6th firmware version is the most recent one. It is the one I have disassembled in Ghidra (a software tool for disassembling binary code) and labeled a lot of the functions in. That is how I'm able to make the needed modifications. Anyway the goal is to get something working first and worry about updates later.

I'm curious to see what reply comes from the youtube channel. When I broke the front glass panel of my first 1013D scope I emailed FNIRSI if it was possible to get a replacement part. They did reply but stated they could not send a replacement part.

You are lucky I already did the work on the 1013D, that saves a lot of time. Lets see if I can get it done in a couple of day's.

Cheers,
Peter

[joseph4511]

Hello Peter

Nice to meet you by the way. Im grateful to your researchment and yes i am curious about how they are going to solve my problem. I said them what i have tried so far, its 11 pm there so they are not working Right now. They could reply tomorrow morning. I mentioned the special IC in my comments. You can follow from YT i left the link above. Just switch to newest comments.

[pcprogrammer]

Hi Yusef

same here and you are welcome. Happy to help where I can

About FNIRSI solving your problem, don't hold your breath waiting for it

[joseph4511]

I got my money back and the 2 motherboard stay with me I dont think they re going to solve anything.

Edit : maybe you can write a comment with me to force them to help

[pcprogrammer]

Well with your money back and an additional motherboard you can't complain

Left a comment with the video telling them what rubbish it is, so check it out.

Later today I'm going to play with it to see if I can get it to work without the special ic communication.

[joseph4511]

When we get them both working, i ll stop complaining can not you extract the firmware with i2c tool?

[pcprogrammer]

Since there is no idea on which chip they used for this special ic it will not be easy to get to the bottom of it. It is also not needed because I know what the main cpu needs from it. There are a handful of commands or parameters (just semantics) in use. I know how to mimic them all, so patching the main firmware is a much simpler solution.

The new firmware I wrote for the 1013D does not use it either. The scope works even better without it. I don't know if they made improvements for the 1014D, but the code tells me that the basics are the same as in the 1013D.

[pcprogrammer]

Houston we have got a problem

I tried the firmware I patched with both the initialization and translate function disabled and it does continue into the normal scope screen. Used the wrong version needed for my scope because the screen is shifted down and to the right, but that is no biggie.

I can see that the translations are not performed because the traces are not where they supposed to be.

This means that there is either another problem messing things up or the patched firmware did not load correctly, and thinking of it, the normal firmware upgrade procedure can't work since the check bytes won't be ok anymore. Forgot all about those.

So I would like to suggest another way to go forward in testing what works on your system. It involves writing a special startup program to the SD card and then load the firmware to test via USB.

I hope you have a linux system. Attached is a file "fnirsi_1013d_startup_with_fel.bin.txt". This needs to be loaded onto a SD card with "sudo dd if=fnirsi_1013d_startup_with_fel.bin of=/dev/sdc bs=1024 seek=8". Make sure to check which block device your SD card is connected to. Use "lsblk" to list the devices. Don't forget to unmount ("sudo umount /dev/sdc1") the partition otherwise "dd" won't work properly.

Stick this card in the scope and it will start with FEL operational. Connect the scope via USB to the linux machine and check with "lsusb" if the following device is present: "ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode"

Now it is possible to load the firmware directly to DRAM. Use the following command to load and execute it: "sudo ./sunxi-fel -p write 0x7FFFFFE0 1014D_no_special_ic_no_translate.bin exe 0x80000000"

Remove the .txt extensions from the files. These are needed for uploading to the forum. Make sure the "sunxi-fel" file is executable and in the same directory as the "1014D_no_special_ic_no_translate.bin" file.

Hopefully the scope does the same as mine.

In the mean time I will continue with patching the firmware to have it do the needed translations.

[joseph4511]

going to download virtual box for Linux, which version do you suggest for me ? And i can not switch the device to usb mode because it does not respond anything. Can you backup the partition of your SD card so i can recover from that .img file to my SD card without any issue. What do you say ?

[pcprogrammer]

I'm using linux mint 20 Xfce, but any linux will do.

I assume you are running windows 10 and are going to use virtualbox on it to run linux. Might give problems with the USB link through, but might be fine.

You can just take the SD card from the scope and use a card reader/writer directly connected to the PC. Check that the FSI-1014D.bin file is no longer on the card. An option is to just re-format the card with FAT32 as type. The scope does not need any files to be on the card. It will create the needed files when they are missing.

The startup program I posted needs to be loaded to sector 16 of the card. Check the readme here: https://github.com/pecostm32/FNIRSI_1013D_Firmware. It is for the 1013D but the same applies to the 1014D.

[joseph4511]

loaded the with fel file correctly but fnirsi logo flashing and nothing happens

[pcprogrammer]

Strange.

When I start the scope with the "FEL SD card" in there I also see the startup image (logo) flashing a bit, but when I load the actual program with sunxi-fel it starts the scope software with the shifted display.

I made a video of how it works with my system: https://youtu.be/BbTE62INYpE

If you performed the same actions and it does not work then it is less easy to solve and more might be broken. The question is what.

[joseph4511]

okay i can see the usb as tablet let me flash the sunxi-fel

Edit: It says ./sunxi-fel command not found. I renamed the files.

[joseph4511]

okay i uploaded something but screen is still flashing

[pcprogrammer]

Well at least the sunxi-fel seems to be working. See that you found the version command and that it responded the same as mine.

Since it does not act the same as here it is safe to say something else is broken that stops the scope from continuing.

Lets see if this program works when loaded with sunxi-fel.

command: sudo ./sunxi-fel -p write 0x7FFFFFE0 fnirsi_1014d_firmware_backup.bin exe 0x80000000

Edit: when it works and it is done the SD card needs to be reloaded with the FEL start program.

[morgan_flint]

Since there is no idea on which chip they used for this special ic it will not be easy to get to the bottom of it. It is also not needed because I know what the main cpu needs from it...

Hello! I've been reading through this thread and came over the "mystery chip" issue, and it remembered me of a similar problem with Jyetech's scopes (DSO150 and DSO138 mini specifically).

Could that chip be an ATSHA204A or something similar?

That is like an I2C EEPROM (in fact, includes 4.5 Kb) but with some crypto authentication features. Jyetech uses it to avoid their firmware running on counterfeit copies of their products, by reading the unique serial number on the chip and checking it against an activation code specific for each serial number. Some more info here and previous posts.

Maybe FNIRSI is using a similar approach, or just including the chip in case they detect counterfeits in the future (the initial versions of DSO150 ran on counterfeits also until Jyetech started to include the activation code)

[joseph4511]

i goes black screen when i load the program

[joseph4511]

i do not think they have such a vision for this particular protection. Peter managed to run the software discarding lines which related to that chip.

[pcprogrammer]

Hmm, it should show a screen like what you see in this video:  https://youtu.be/h-tdKPDocHI

I'm beginning to think that there is a problem with the FPGA.

[joseph4511]

Maybe but how they died without any damage, dropping, heat ?


Edit: Do we have datasheet for FPGA or VCC points ? Maybe it is not getting enough voltage or something else. Because first one died for no reason, i turned off from button and tomorrow morning it died

[pcprogrammer]

Since there is no idea on which chip they used for this special ic it will not be easy to get to the bottom of it. It is also not needed because I know what the main cpu needs from it...

Hello! I've been reading through this thread and came over the "mystery chip" issue, and it remembered me of a similar problem with Jyetech's scopes (DSO150 and DSO138 mini specifically).

Could that chip be an ATSHA204A or something similar?

That is like an I2C EEPROM (in fact, includes 4.5 Kb) but with some crypto authentication features. Jyetech uses it to avoid their firmware running on counterfeit copies of their products, by reading the unique serial number on the chip and checking it against an activation code specific for each serial number. Some more info here and previous posts.

Maybe FNIRSI is using a similar approach, or just including the chip in case they detect counterfeits in the future (the initial versions of DSO150 ran on counterfeits also until Jyetech started to include the activation code)

No it is nothing of that kind. The main processor sends data to the chip and it in turns sends some altered data back. I have no idea why they choose this solution because the main processor can do this altering of the data itself without all the overhead and errors the communication causes.

[pcprogrammer]

Maybe but how they died without any damage, dropping, heat ?

The special ic is connected to the FPGA and it might caused damage to it when that first special chip died. Did you try both chips with your USB to I2C interface? I'm curious to see if both are actually dead.

Tomorrow I will take another look at the code to see if I can find a point where it might hang. The processor and the screen are working because the startup image is being displayed and the FEL mode is working.

You having the FEL mode now makes it a bit easier to have you do tests on your boards.

If the FPGA is damaged it is possible to replace it since we know it is an Anlogic AL3-10. Not sure if it is easy to get one. Aliexpress does sell boards with them. https://fr.aliexpress.com/item/1005001774923333.html

[joseph4511]

they both seem to be dead its great to buy with boards but unfortunately its expensive for me.

[pcprogrammer]

Yes I have a datasheet for the FPGA. It is to big to attach here, so I uploaded it to the githup repo: https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Dake_Elec_FA201

Also take a look here for a schematic of the board Aliexpress sels: https://github.com/pecostm32/Lichee_Nano/blob/main/Hardware/Dake_Elec_FA201/Schematic_Dake_Elec_FA201_2022-01-23.pdf

[pcprogrammer]

they both seem to be dead its great to buy with boards but unfortunately its expensive for me.

I know they are not to cheap. There are tests that can be done to see if they are the problem. But that is for later. I'm getting tired now.

[joseph4511]

Thank you for your effords and patient. It s great to have a mate like you

[pcprogrammer]

Hi Yusef,

lets see if we can probe the boards some more. Do you have a stm32f103 bluepill board lying around? If so it is possible to make a jtag programmer for the Anlogic FPGA. See: https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Anlogic_JTAG_Programmer

With such a jtag programmer it is possible to see if the FPGA is still responding by using the Tang Dynasty IDE. Read the posts on this page: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3885164/#msg3885164 They give a lot of info on the FPGA and the needed software.

I think the motherboard has a connection for the jtag programmer. It is next to the FPGA FLASH, but have to verify this by opening my scope.

If you do not have a bluepill I will see if I can whip up a simple test to check the FPGA via the CPU connection on the motherboard. I'm also going to look at the original firmware to see if I can pinpoint the spot the system hangs on.

Cheers,
Peter

EDIT: The connecter on the board is indeed the JTAG connector. See attached image with the pin names.

[pcprogrammer]

I'm looking at the hardware to see how it differs from the 1013D and noticed that they changed the FPGA clock setup. Instead of a 50MHz crystal oscillator it has a 25MHz crystal and a MS5351M clock synthesizer chip. The MS5351M is controlled via I2C which bit banged by the F1C100s. It uses pins 65 and 66 of the CPU.

They use two outputs of the synthesizer to clock the FPGA. Pins 23 and 24.

I might as well do a full reverse engineering of the schematic now I have it lying open on my desk

[pcprogrammer]

Hi Yusef,

there is another test you can run to determine if the firmware passes a certain point. Remove the SD card and turn the scope on. It should give a black screen with red text "SD ERROR"

Cheers,
Peter

[joseph4511]

Hey Peter

i tried to launch without SD card many times, never ever passed Fnirsi logo. Could not managed to pass that screen. I do not have bluepill board but i have arduino IDE and Arduino Mega and USB005 for special Infineon IR pwm controllers and gate drivers. I found TD Dynasty last night. Found the pinout of AL3-10 checked voltages and found nothing.

[pcprogrammer]

Ok that narrows it down to the first bit of the code. Tomorrow I will look at it to see if I can find why this happens.

The problem with the JTAG of the FPGA is that there is no open source project that can be converted to an Arduino Mega, At least as far as I know. So this means another approach is needed.

[joseph4511]

i ordered the stm32 dongle, it arrives 4 days later.

[pcprogrammer]

Maybe you have them lying around, but you also need a 74LVC125. This is really needed since the FPGA in the scope uses 2,5V and the STM runs on 3,3V, so the levels need to be matched.

[pcprogrammer]

They are probably not intended for actual connectors, but why oh why did they use to small a holes. I want to solder headers into these holes to be able to connect to the FLASH and FPGA more easily and only the JTAG one allowed me to stick a standard 2.54mm double row header into it. For the others I have to grind down the pins a bit. Don't want to drill out the holes to not ruin the through hole plating.

Also lifted the metal cans to be able to reverse the power and analog circuitry. Will post pictures and the schematics when I'm done.

[pcprogrammer]

Here are some pictures of the naked board and the front part of the case.

[pcprogrammer]

Sure i can upload. Also uploaded the image of special IC with marking

Hi Yusef,

I read the FLASH for the FPGA on my scope and compared it with yours. The files are the same, so no problem there.

Cheers,
Peter

[pcprogrammer]

Need some info on some SMD components.

There are two sot-23 components in the power supply part to turn the scope on. One has Y1 as marking and I found SS8050 as a possible candidate. The other one has R1 as marking. This one switches the 5V so needs to be a beefy transistor or fet.

I found this site https://www.hotenda.com/marking-code/search/list/R1.html but it lists a lot of components with this marking. Google did also gave PDTB1132T as a possible hit but it does not support more then 500mA, so might be to lightweight for the task.

[Kean]

"R1" marking could be CJ3401 P-Ch MOSFET 30V 4.2A
https://lcsc.com/product-detail/MOSFETs_Changjiang-Electronics-Tech-CJ-CJ3401_C13799.html

[dmitrkov]

https://www.s-manuals.com/smd/r1

[joseph4511]

yes its a p channel mosfet, 5v across drain to source

[pcprogrammer]

Hi Yusef,

I thought up another test to see if it is possible to load the first bit of the DRAM.

Use sunxi-fel to set the display engine to use the first part of the DRAM:

Code: [Select]

sudo ./sunxi-fel writel 0x01E60850 0x00000000
sudo ./sunxi-fel writel 0x01E60860 0x00000004

Then load the attached image data to the memory with:

Code: [Select]

sudo ./sunxi-fel -p write 0x80000000 scope_image.bin.txt

You should see the image building on the screen while it loads.

I also found the reason why the screen flickers when the boot with FEL option is used. The FPGA controls the brightness of the screen with PWM. For this to work the FPGA needs a clock, and that is what is missing. The F1C100s has to initialize the clock synthesizer for this. I'm still looking through the original code to find where this is done.

Another thing I discovered is that the GD32E230 is used to control the power. It generates a hold signal to keep the P-FET active. When the power button is pushed again it is signaled by the GD32E230 and it then releases this hold signal.

Most of the schematic is similar to the 1013D. One difference is that the MCU and FPGA use a separate 3V3 power source. Have done quite a bit already but still need to do the GD32E230 part, which is new since the 1013D just has a touch panel.

[pcprogrammer]

Schematics are done.

Did not check the capacitors and only gave them an identifier. Also not in a nice logical order since I used the 1013D schematics as a starting point.

There are some changes compared to the 1013D but nothing major. The FPGA connections changed a bit and the power supply setup is different. The analog input is mostly the same. They used 3,3V for the opamps instead of the 2,5V used in the 1013D.

The buttons on the front panel are scanned in a 6x6 matrix, but they did not use diodes so no usage of multiple buttons at once. No need for it so no problem. The rotary encoders all have separate connections on the GD32E230.

A bit of a shame that they did not add a battery and an extra diode and made use of the RTC that sits in the GD32E230. Would have given the saved files a proper time stamp. Due to the fact that the resistor networks used for rotary encoders are sourced from the GD32E230 3,3V supply it is a bit harder to make a modification. It would drain the battery at a higher rate then needed.

I'm going to rename the 1013D hack repository and upload the 1014D material there.

[pcprogrammer]

Since the PCB also has pads for a SWD connection with the GD32E230 I though lets give it a try and read the FLASH.

Did not work with the openocd version I had installed (0.10.0) but with the latest build from here: https://github.com/xpack-dev-tools/openocd-xpack/releases I was able to read the flash. Have not looked at it with Ghidra but with a hex editor it looks like vectors followed by code and then 0xFF till the end. It is a bit over 7KB of code.

So no protection by the looks of it.

Attached is the binary and a picture of the connector with pinout

[tv84]

Have not looked at it with Ghidra but with a hex editor it looks like vectors followed by code and then 0xFF till the end. It is a bit over 7KB of code.

AFAIK doesn't seem to have any visible ARM code...

[pcprogrammer]

AFAIK doesn't seem to have any visible ARM code...

Well I have looked at it and it is ARM code. I used ARM Cortex little and set the starting point on 0x08000000. This way it looses the awareness of the vectors but they are there. The first four bytes are the stack start address. The next four bytes hold the reset address. Formatting the data into a hex file where the actual code starts in the 0x08000000 region and the vectors in the 0x00000000 region can solve this.

Also found addresses of GPIO and USART0 in the code. A first glance makes me think it is not that complex a code.

Might be easier to reverse this to get to the inter MCU communication then plowing through the F1C100s code.

It is just playing around a bit. Satisfying my natural curiosity. Not planing on fully reversing the 1014D nor making new firmware for it.

[pcprogrammer]

I looked through the 1014D second program loader to see if I could find how they setup the FPGA clock synthesizer, but it turns out they don't. Instead they write 0x78 to the FPGA for the brightness command 0x38.

So I tried that in the 1014D firmware backup program I wrote and lo and behold it did the trick. The display no longer flickers. Also modified the boot with FEL code and uploaded both to the renamed hack repository: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack

The initialization of the FPGA clock synthesizer is done in the main firmware but I have not looked for it. Did notice a difference in the FPGA_Init where it sets the according GPIO pins to outputs.

Curiosity satisfied for now

[pcprogrammer]

Go figure 

I did some searching on the web to find something about a newer AD1013D II scope in response to a question asked on the 1013D firmware repository. Did not find anything about it but I did find that the Aiteme ADS1014D is the top number 1 scope around

https://www.findthisbest.com/best-lab-oscilloscopes/metric

Makes you wonder where they based there conclusions on

Had not yet heard of the Aiteme brand but the scope looks just like the FNIRSI one.

[pcprogrammer]

It was a bit of a search and gathering of resources but I now have a .svd file for the GD32E230. The addon package for the GD32E230 from the GigaDevice site https://www.gd32mcu.com/en/download/0?kw=GD32E2 has a .svd file but it misses a lot of the core peripherals like the systick timer and Ghidra stumbled on an overlap between the SYSCFG and CMP peripherals.

Used data from the ATSAML11E16A.svd file I found on the net to complement the core peripherals. Not sure if it is all correct but it is also a Cortex-M23 device. Could not find documentation on the GD32E230 that has info about the core peripherals. Just the peripherals added by GigaDevice like USART, ADC, etc.

Now the de-compiled code in Ghidra shows the name of the peripherals and the registers being used. A very nice feature I must say. Wish I knew about that when I started the reverse engineering of the 1013D

All the ARM instructions used are thumb or thumb-2 since the Cortex-M23 does not support the full ARM instruction set. Jump addresses have the lowest bit set because of this.

Attached both files but had to add the .txt extension to upload them.

[mkstevo]

I don't seek to claim that Hameg should be worried by FNIRSI, the two are polar opposites, but for the life of me I can't understand the snobbery towards FNIRSI.

Despite your experience you have overlooked the most basic of scope requirements, input sensitivity and input ratings !

With a max sensitivity of only 50mV/div and 40V max at 1x input attenuation severely limits this scope for even basic use. Only by adding a 10x probe is the input rating increased to 400V, a rating that is standard at 1x for most other DSO's available however with a 10x probe max sensitivity becomes 500mV/div !

Snobbery, be buggered, practical usefulness is what really matters.

I'm not sure I did overlook that. I've never once needed to measure 0.0x Volts. The aircraft monitoring systems we used to manufacture used a pressure transducer that gave an output of nominally 30mV before amplification, that would certainly be visible when checking that a valid signal was being presented to the amplifier. In the industry I now work in everything has 5V, 3.3V or 1.8V logic. Would 50mV be enough to display that? Yes. At home where I use my FNIRSI, it is mainly used for tracing faults in valve (tube) audio and transistorised audio, vintage video equipment repairs and my personal designs for electronic clocks. All with voltages well above 50mV.

Is it not possible to accept that for some people, the FNIRSI is all that they might need? I accept not for people who need that bit more in the way of performance and have the budget to pay for that performance, but for a hobbyist, with limited requirements and limited funds the FNIRSI is a value alternative and eminently practical and useful.

[tunk]

Review by Kerry Wong, summed up as "oh man, this is bad":

[tunk]

Is it not possible to accept that for some people, the FNIRSI is all that they might need?

All tools have their uses, and if you know their limitations they may be good tools.
But I'm not sure if your 30mV transducer is a good example. The 50mV/div setting is
in software only, in hardware it's 100mV/div. The +/-5% accuracy and 1V full scale
gives 50mV inaccuracy, so your 30mV may drown in noise and inaccuracy.

[pcprogrammer]

Apparently not a lot of people find the postings about test equipment on EEVblog There is a lot of comments on the video stating how glad people are he did the review and that it is not a positive one.

All that is shown in the video was already known way back from the work done on the 1013D and the 1014D.

Around 8:50 in the video he even does not notice the sudden rise in amplitude when the signal goes from ~41MHz to ~42MHz, which is when the software starts to calculate the sine wave instead of using the actual points, just as it does in the 1013D.

Around 15:09 he assumes the firmware to live on the SD card, which we all know is not the case. He should have consulted this thread before doing his review. Have noticed this missing with other reviewers too. A bit of a shame because this blog is full with useful information.

It seems he has a later unit fitted with the F1C200s instead of the F1C100s, which we also already knew from joseph4511 his posts.

All in all "mosterd na de maaltijd" like the Dutch would say. (Literally translated "mustard after the meal" and meaning "too little too late")

[chupocro]

Quote from: pcprogrammer on May 05, 2022, 06:42:35 pm

You can just take the SD card from the scope and use a card reader/writer directly connected to the PC. Check that the FSI-1014D.bin file is no longer on the card. An option is to just re-format the card with FAT32 as type. The scope does not need any files to be on the card. It will create the needed files when they are missing.

Hi, I've seen you've done an excellent job reverese engineering 1014D and I've been through all the posts (and briefly checked the github repositories) but still couldn't find out what exactly is the purpose of SD card in that oscilloscope.

I thougth the device needs the SD card to boot but you said everything would work even if SD card is formatted. What is the SD card then used for? A swap file or for some temporary files during the operation? What happens if the device is turned on without SD card?

Do you thing it would be possible to add protocol decoders (I2C, SPI, ...) to the firmware?

[pcprogrammer]

Hi chupocro,

the SD card is used for storing the screen capture (picture) and waveform files you can make with the scope. Without a card in the scope it will not startup. It will instead show an "SD ERROR" message.

I did not fully reverse engineer the 1014D, nor the 1013D for that matter. Did the schematics and partially the software for both. For the 1013D I wrote new firmware based on knowledge gained from the partial reverse engineering of the software, but thanks for your praise

Adding protocol decoders is not simple to do, because the sampling is not continues over time and the sample memory is to small. It would require a hardware implementation in the FPGA, and then still would not be so easy.

A bit of a problem with these two FNIRSI scopes is that there is no simple way to update the bit stream for the FPGA. For the firmware there is support in the original firmware to do updates, but not for the bit stream.

[chupocro]

Quote from: pcprogrammer on Yesterday at 07:01:20 am

Hi chupocro,

the SD card is used for storing the screen capture (picture) and waveform files you can make with the scope. Without a card in the scope it will not startup. It will instead show an "SD ERROR" message.

I did not fully reverse engineer the 1014D, nor the 1013D for that matter. Did the schematics and partially the software for both. For the 1013D I wrote new firmware based on knowledge gained from the partial reverse engineering of the software, but thanks for your praise

Adding protocol decoders is not simple to do, because the sampling is not continues over time and the sample memory is to small. It would require a hardware implementation in the FPGA, and then still would not be so easy.

A bit of a problem with these two FNIRSI scopes is that there is no simple way to update the bit stream for the FPGA. For the firmware there is support in the original firmware to do updates, but not for the bit stream.

I am going to buy that oscilloscope as I don't need bandwidth greater than a few MHz and even 100 mV/DIV is more than enough for the measurements I'll be doing. I like it boots very fast, is very lighweight and can be powered from the battery pack. For decoding protocols I can still use logic analyser and PulseView.

DSO2D10 might have better bandwidth and more memory for wave capturing but it costs $80 - $100 more and I don't like how trigger level is jumping when changing the time scale and besides it seems to be much slower than 1014D.

I can see you are an expert at reverse engineering, do you by any chance know which would be the easiest way of reversing the Motorola HC908 code? I'd like to reverse engineer parts of the code from MC68HC908AZ60 microcontroller and I could do that by disassembling the .hex and examining it but I wonder if I could use Ghidra with that instruction set. I once reversed the code form 12F629 which was under 1k but it took me a while to analyse the complete code and it was quite tedious. That's why I'd like to know if there is a better way of analsying HC908 code. I somewhere read there is IDA plugin for HC908 arhitecture but I couldn't find if Ghidra could be used as well.

[pcprogrammer]

Hi chupocro,

you seem to not be aware of the "Quote" button, judging by the way you quoted my previous post. Also there is no need to repeat someones text if there are no other posts in between. I'm just mentioning this because there was a lot of turmoil lately on the forum and unneeded quoting was mentioned as being annoying.

If the features of the scope are sufficient for your needs, then sure, it is usable. And since you mention having looked into the DSO2D10 you made a weighted decisions and that is the way to do it.

For the reverse engineering of HC908 code I have no idea if Ghidra can be used for it. I'm no real expert on reverse engineering. The FNIRSI was my first go at it and even with Ghidra it was difficult and tedious to get to the bottom of things. It depends a lot on how big and complex the code is of course, and also if you already have an understanding of what the target is doing.

The thread about the FNIRSI 1013D shows the whole process over time. It also shows that I wrote my own emulator to run the scope code on the computer, just to be able to trace what functions where doing. This because it used a lot of function pointers. These are almost impossible to figure out from just a dissembled piece of code.

[Rasz]

Review by Kerry Wong, summed up as "oh man, this is bad":

Fnirsi should perhaps rebrand to 差不多 (Cha bu duo)

[MrAl]

Hello there,

Someone i know just bought one of these Fnirsi 1014S scopes and the specs for the sale were quoted as 100MHz and 1GS/s.
From this thread and the tests shown here, it is only around 30MHz and 200MS/s.

Is there any chance that it was updated to get a higher bandwidth?

He is thinking of asking for a discount from the original price tag but we dont have any way of testing it without buying a new function generator the only one we have right now only goes up to 20MHz so we cant use that.  We also dont really know what the rise time of that generator is so it may do no good to try to test via the rise time of the scope.
If it is as low as tested here, he should be able to get a discount, but if they updated it then he can not get a discount, but we can not test it without buying more test equipment.

Any information on this would be appreciated. Thanks.

[Fungus]

Is there any chance that it was updated to get a higher bandwidth?

No.

[pcprogrammer]

To see if it might be a new version open it up and take a picture of the PCB. Then post that picture here so we can check it for differences. Or search for pictures of the PCB in this thread.

But it is most likely like what Fungus answered, a big fat NO.

[Fungus]

But it is most likely like what Fungus answered, a big fat NO.

They've ALWAYS been sold as 100MHz and 1GS/s - see the very first post in this tread.

[pcprogrammer]

Yep, just like the 1013D from FNIRSI and the other brands it has been sold under.

It is all a big fat LIE

As with a lot of these cheap scopes that can be found on Aliexpres, Banggood and evilbay

[MrAl]

Yep, just like the 1013D from FNIRSI and the other brands it has been sold under.

It is all a big fat LIE

As with a lot of these cheap scopes that can be found on Aliexpres, Banggood and evilbay

That's what i thought.  How can they be so deceptive i mean 100MHz vs 30MHz that's a huge difference not even close.
They try to catch people off guard thinking it is a much cheaper scope than the other 100Mhz units, what balls they have.  Maybe they should be reported.
The function generator is strange too, it 'loads' very easy its internal impedance must be high.
Some controls are easy to use but some other controls are hard to use.
He paid $140 USD for it, maybe it is worth that much but it would have been better not to lie about it.

I like that "evilbay" and "Bang-u-good" ha ha.

[MrAl]

Is there any chance that it was updated to get a higher bandwidth?

No.

I thought so was just hoping for the best.  We tested it the best we could with the equipment we had on hand and it does look like the bandwidth really is 30MHz nowhere near 100MHz.  That's very ballsy of them i think.
I am wondering if he could get a discount now.  They didnt even send a stupid 5v wall wart with it.

[pcprogrammer]

They try to catch people off guard thinking it is a much cheaper scope than the other 100Mhz units, what balls they have.  Maybe they should be reported.

Yeah that is what they do and they don't give a crap if it is reported.

The function generator is strange too, it 'loads' very easy its internal impedance must be high.

The schematics can be found here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics/1014D

Some controls are easy to use but some other controls are hard to use.

It starts up relatively quick and responds rather well. Better then the Hantek DSO2D10 I also have. The latter actually has a better front end and can do 1 channel at 1GSa/s.

He paid $140 USD for it, maybe it is worth that much but it would have been better not to lie about it.

Not a bad price. Mine was ~170 euro.

[Fungus]

They try to catch people off guard thinking it is a much cheaper scope than the other 100Mhz units, what balls they have.  Maybe they should be reported.

Yeah that is what they do and they don't give a crap if it is reported.

Who you gonna "report" it to?

[pcprogrammer]

Who you gonna "report" it to?

There is such a thing as false advertising. Not sure if you will win when you start a dispute on Aliexpress over this, when bought there of course, and hiring a lawyer to sue might bankrupt you

[MrAl]

They try to catch people off guard thinking it is a much cheaper scope than the other 100Mhz units, what balls they have.  Maybe they should be reported.

Yeah that is what they do and they don't give a crap if it is reported.

The function generator is strange too, it 'loads' very easy its internal impedance must be high.

The schematics can be found here: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics/1014D

Some controls are easy to use but some other controls are hard to use.

It starts up relatively quick and responds rather well. Better then the Hantek DSO2D10 I also have. The latter actually has a better front end and can do 1 channel at 1GSa/s.

He paid $140 USD for it, maybe it is worth that much but it would have been better not to lie about it.

Not a bad price. Mine was ~170 euro.

Thanks for the link to the schematic i didnt know they published that.
I'll have to take a look and see what is up with this thing.

[MrAl]

They try to catch people off guard thinking it is a much cheaper scope than the other 100Mhz units, what balls they have.  Maybe they should be reported.

Yeah that is what they do and they don't give a crap if it is reported.

Who you gonna "report" it to?

I will surely tell their parents on them (ha ha).

I was thinking maybe the sites that they sell them on.  Not sure if the BBB would help or not.
I would not want to see them stop selling though, just being more honest about the specs.

[MrAl]

Who you gonna "report" it to?

There is such a thing as false advertising. Not sure if you will win when you start a dispute on Aliexpress over this, when bought there of course, and hiring a lawyer to sue might bankrupt you

He bought his on evilbay.  Not sure if he can get a discount yet or not i think he will try though.

It amazes me how much scopes have come down though in the past 20 years.  Back then a 20MHz would cost about $400 USD and that was for a bottom line cheapie CRT beast.

I once used a 50MHz true phosphor type CRT storage scope way back in the 1970's.  It was a huge thing the size of a small refrigerator.  It was around $3000 USD i think back then.  Almost bought one at Princeton too back in the 1980's but it was so big i didnt want to have that laying around.

[pcprogrammer]

Thanks for the link to the schematic i didnt know they published that.

They didn't. I reversed engineered it. Only thing I did not do is measure the capacitors.

A lot of the software in this thing is also the same as in the 1013D, which I reverse engineered and wrote new firmware for.

The root of the repository the schematics are in, holds a lot of information about both the scopes.

[MrAl]

Thanks for the link to the schematic i didnt know they published that.

They didn't. I reversed engineered it. Only thing I did not do is measure the capacitors.

A lot of the software in this thing is also the same as in the 1013D, which I reverse engineered and wrote new firmware for.

The root of the repository the schematics are in, holds a lot of information about both the scopes.

Hi,

Oh geeze, that must have been one hell of an undertaking, how did you do that?  Did you have to follow all the traces around the boards?

I just did one for a special kind of relay that had an internal circuit and even that was a pain with one IC chip one transistor and a bunch of resistors, diodes, and caps.  Didnt like doing it either but wanted to know for sure how that thing worked.
Yes i found the small caps unmarked too and probably have to unsolder them to check the values.

I'll check out the other stuff too on that site thanks a bunch for all the work you did.

[pcprogrammer]

Oh geeze, that must have been one hell of an undertaking, how did you do that?  Did you have to follow all the traces around the boards?

With the use of a digital multi meter and pictures it is not that big an undertaking. Reverse engineering the software and the FPGA, those are the real undertakings. The software for the 1013D took about a year (not full time of course) to get from the first disassembly / de-compile to newly written functioning firmware. The FPGA took at least 6 months to get from almost zero to a full understanding on what it is made up with.

Wrote about it here: https://www.eevblog.com/forum/fpga/reverse-engineering-anlogic-al3_10-fpga/

[chupocro]

I wonder if anyone designed a convenient circuit that could be connected to 1014D's function generator and would be used for adjusting the amplitude.

Maybe an emitter follower not to overload the output followed by non-inverting adjustable amplifier using op-amp(s). Gain should be adjustable from less than 1.0 to some max value (e.g. 12 V).

[chupocro]

I tested it with an old circuit I made a few years ago for experimenting with DDS sound synthesis.

ATmega8 @ 8 MHz internal oscillator is generating 15686.27 Hz PWM signal while interrupt routine running at the same frequency is used to adjust duty cycle.

https://youtu.be/n-j5uSacw70

[donwulff]

Spectacular work with the reverse-engineered firmware! I've been wondering though, given this is the FNIRSI 1014D thread, what are the chances of building open-source firmware for the 1014D as well? it sounds like their hardware is very similar, save for the signal generator? For the price it might be a nice platform to perhaps try some simple signal processing/UI improvements. Maybe I should start with some of the tear-down comparisons of the two models people were referring to?

Also about the true performance. If I understand right both probes have two-channel 100 megasample 8 bit ADC:s? So if the FPGA is indeed driving this at 100 megasamples (And I see the datasheet might have little leeway to increase that higher, maybe?) that would be 2x200 megasamples at 7.5bit?  3nS rise-time spec would mean 6 times oversampling, but I guess the real rise-time is more like 10nS? The 1 Gs/s, while made up, is close to the combined analog bandwidth, so I guess if you knew the waveform and/or it was repeating, you could interpolate up to that? ~200Mhz sine-wave? Then again I suppose they're already using a lot of those tricks.

Basically wondering what the actual specs & capabilities are, derived from the firmware, and if the stock firmware is already using those to the max. Still could benefit from things like stacked & fading traces, trace differences etc.

[py-bb]

What's the 100mhz @ 1Gsample/sec mean? Surely that'd be 500mhz(ish) scope? Or is it combining 5 samples into 1 to use a shitty DAC for better dynamic range?

[pcprogrammer]

Spectacular work with the reverse-engineered firmware! I've been wondering though, given this is the FNIRSI 1014D thread, what are the chances of building open-source firmware for the 1014D as well? it sounds like their hardware is very similar, save for the signal generator? For the price it might be a nice platform to perhaps try some simple signal processing/UI improvements. Maybe I should start with some of the tear-down comparisons of the two models people were referring to?

Yes the hardware is very similar to the 1013D. Only differences are the function generator and the user interface.

The function generator is based on an eight bit R-2R network connected to FPGA output pins. In the FPGA it uses a block of memory to create the signal. Partially looked into the FPGA design while reverse engineering the 1013D FPGA. The sampling system is most likely the same.

The user interface is handled by an ARM MCU which scans the buttons and rotaries and sends the needed information to the F1C100s processor.

The firmware is also very similar, but instead of being controlled with a touch screen it processes the serial data from the secondary ARM MCU. Another difference is the function generator. A lot of the investigation has already been done. There is a Ghidra project with already a lot of the functions identified.

It should not be to big of a deal to make new firmware for it based on what I wrote for the 1013D, but I'm not going to do it 

Also about the true performance. If I understand right both probes have two-channel 100 megasample 8 bit ADC:s? So if the FPGA is indeed driving this at 100 megasamples (And I see the datasheet might have little leeway to increase that higher, maybe?) that would be 2x200 megasamples at 7.5bit?  3nS rise-time spec would mean 6 times oversampling, but I guess the real rise-time is more like 10nS? The 1 Gs/s, while made up, is close to the combined analog bandwidth, so I guess if you knew the waveform and/or it was repeating, you could interpolate up to that? ~200Mhz sine-wave? Then again I suppose they're already using a lot of those tricks.

The performance of the system is based on 200MSa/s for the fastest time per division settings. It then has 3000 samples available of which only ~2500 are used on the display. There is a lot of filtering to make it look smooth. (I removed all of that) For the other time per division settings it only uses one ADC and 1500 samples at max. The sample rate is controlled with the time per division setting. (Which I changed in the new 1013D firmware)

Above ~44MHz the software just calculates a sine wave based on the measured zero crossings and the measured max amplitude. (This has also been stripped)

It might look very nice on the screen, but for realistic measurements it is crap.

Another drawback is the vertical sensitivity, which with only 100mV per division true range with a 1x probe setting it is not very good. The advertised 50mV per division is based on software zoom.

Basically wondering what the actual specs & capabilities are, derived from the firmware, and if the stock firmware is already using those to the max. Still could benefit from things like stacked & fading traces, trace differences etc.

The new firmware could do with improvements and there is also some room in the number of available samples. Now using 3000 samples, but in the FPGA it has room for 4096. But as I wrote above, I'm not going to do any work on it in the foreseeable future.

Take a look at the reverse engineering repository, if not already done so. https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack

[donwulff]

Just for the record, I'm aware of the sampling theorem, ie. "a signal has to be sampled at least with twice the frequency of the original signal". "at least" is doing a lot of work there. With 100MHz signal you'd like to have at least 5 samples per cycle to recover any of the waveform. Of course, if you already know the signal is around 200MHz, it would be possible to fit a sine (or square) wave to even fewer measurements. According to the ADC datasheet, it could possibly handle up to 475Mhz (the analog paths likely can't) if you know the waveform you're looking for.

Practical example: Matching signal edges on a bus/to a clock, where you know the signal frequency and are only interested in determining the phase.

[pcprogrammer]

Even if the used ADC's are genuine it does not matter because the front end is bandwidth limited to ~30MHz. Did not check the order of the filter, but at 200MHz on the input I don't think there will be much signal left to sample. Can't test it because my signal generator only goes up to 100MHz.

There are plenty threads on this forum about sampling and the theory behind it, so not going to fill this one with it.

To do more interesting things with these scope(s) one should write up a better FPGA implementation to at least make use of the available memory in it, to quadruple the memory to 24KB per channel. Still not much compared to for instance the Hantek DSO2D15.

It is a nice platform to play on and develop skills in developing scopes, but that is it, at least for me.

[Fungus]

Just for the record, I'm aware of the sampling theorem, ie. "a signal has to be sampled at least with twice the frequency of the original signal".

Not quite.

It should be: "a signal has to be sampled at least with twice the bandwidth of the original signal".

Bandwidth != frequency.

[donwulff]

Not me derailing the thread to sampling theory, ahem...  Anyway, bandwidth is an important concept for any kind of high-frequency instruments. The sampling theorem was mostly for the benefit of @py-bb asking if 1Gs/s 2 channel scope shouldn't be 500MHz, as well as to pre-empt anyone needing to point out to me that you can't turn 200Ms/s per channel into a full-fledged 200MHz scope, nor should anyone expect that sort of performance. (The sampling theorem doesn't fully hold, however, if the signal isn't fully unknown, which is why I've successfully used true 100MHz scope to align 200MHz bus signals, for example).

But the Nyquist-Shannon sampling theorem is a purely mathematical construct, and as such it assumes a perfectly spherical cow. In other words, the Shannon theorem paraphrased above actually goes "If a function x(t) contains no frequencies higher than B hertz, it is completely determined by giving its ordinates at a series of points spaced 1/(2B) seconds apart." Of course, the interesting signals in real world aren't pure sine waves (In fact, a perfect square wave is an infinite series of harmonics, to well, infinite frequency. Luckily you don't get a perfect square wave in practice, either) and hence 5 samples per frequency cycle is good minimum to interpolate min, max and zero crossings. And you need to also be able to get your 2 or 5 samples, where every component along the way has a bandwidth limit/attenuation.

I actually acknowledged that with "the analog paths likely can't". In retrospect, it makes sense that there would be an intentional filter around the actual capability of the scope's ADC's, so you don't get aliasing and other unwanted effects from higher frequencies. As a counterpoint though you could alter that filter, and for the signal-aligning use-cases I mentioned, you don't even care about significant attenuation as long as the peaks are discernible. But in the end, I don't expect the hardware can be pushed much further that way. It's just a thought because there ARE use-cases where you don't care about the exact waveform, or where the signal is repetitive so you could fold over the measurements (Unless the sampling rate is a perfect multiple of the signal, you don't even need to shift the sampling points, just align them in software).

Regarding modifying the FPGA, that's a thought, but reviewing some of the earlier thread it seems there's no way to re-program the FPGA via USB or SD-card for example (Could there be a hidden command for it though?) so while exciting, the actual number of people who would be doing that is probably fairly low... At least here in Europe the FNIRSI 1014D is less than half of the Hantek DSO2D15 for example, which places it a price category where you can buy one to toss around, experiment & possibly break, OR use if for hobbyist projects in the 20-30MHz range. But it's certainly cheaper to buy DSO2D15 or even 1013D than trying to replace the existing firmware for personal use. It does look like there's already something bootable for 1014D in the repo though, so who knows.

[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?

[pcprogrammer]

The sampling part of the 1013D code has been reverse engineered so far, to say with confidence there is no equivalent time sampling in there. They use some strange filtering technique on the sampled data to make it look good on the display causing it to be so slow that the display looks very stable.

The new firmware does no filtering and just displays the samples as is, directly after getting them from the FPGA memory. This makes it look a bit skittish, but it is much closer to the real signal. The moment you lower your sampling rate to below your signal frequency it will show aliasing in both versions of the firmware. I don't think you can reconstruct the original signal even when you process multiple sample buffers, unless maybe with doing a hell of a lot of processing on the data, and even then I'm not sure it will lead to anything good. But I'm no expert in the field.

Strange that you can't find much on the hantek scopes. There are at least four threads here on the forum.

https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/
https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/
https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/
https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/

The used ADC in it is assumed to be the ADC08D500 because it matches the pin out used on the board. It might well be a clone.

[donwulff]

I think I need more X's in the search strings, though I did just add reference to it on my notes. To note though, https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/475/ last posts, review isn't glowing, and the cheap price link is 335 EUR with shipping for me.  250 EUR:ish isn't bad for "utility scope" and it sounds like they haven't yet plugged the upgrade-hole (So that means the AWG BNC is always in place?), but doesn't quite make the <200 "gadget price" cut, and sounds like it runs the risk of not having everything enabled. Couldn't figure if the Linux build which doesn't need to be flashed in can do anything with the DSO part, but that's just a little bit of reverse engineering, right? It's interesting these are at a price point where I think shipping actually makes major part of the product price, and even labor/assembly despite it being China.

But ahem, 1014D thread, still kinda trying to focus on that I'll definitely be keeping an eye on the Hantek one though.

[pcprogrammer]

(So that means the AWG BNC is always in place?)

Yes because it is also used for the external trigger input, so always there.

And yes it has plenty of bugs that makes it not the best.

Reverse engineering it, despite it running on linux is no small feat though. There was some talk about it, but not much happened since.

[pcprogrammer]

I looked at the link you added to your notes about equivalent time sampling (https://www.tek.com/en/documents/application-note/real-time-versus-equivalent-time-sampling) which provides interesting information, but confirms my believe it can't be done with the 1013D or 1014D as is. You need to be able to set a specified delay on the trigger to get the shift in the samples needed to reconstruct the original signal. The trigger system in the FPGA does not cater for this.

It also states that the maximum bandwidth that can be measured with this technique is the analog bandwidth, which in these scopes is ~30MHz. This is also below the real time bandwidth of 80MHz (200MSa/s / 2.5), so no need for equivalent time sampling.

[donwulff]

Anyway, sorry to distract from the arguments lol, but finally got around to testing loading the 1013D firmware (Remote Desktop Infrastructure maps the SD as a remote drive, and Cygwin can't even compile gparted, and I mostly have Windows at work, on lunch break lol). I partitioned a blank image on remote Linux machine, used Cygwin dd to install things (Of note: Writing 8 GB flash on 1014D took almost 4 hours, at 611kB/s, also needlessly used up flash endurance, don't do that). Turns out the Pecos firmware at least really needs FAT partition, so I built dosfstools on Cygwin and ./mkfs.fat -F32 -v /dev/sdb1

The screen seems to work without any changes, and I'm really digging the look in the Pecos firmware, although the knobs & buttons don't work of course so I can't actually do anything yet. Looks like I may have to figure out some other differences though, because it's showing about 10 volt 40 uS rounded sawtooth on both channels, but connecting anything to the probe channels changes nothing. But this is definitely a good spot to start from, as I can see the UI and, well, something is working haha. Of course, after partitioning & FAT32 format this is just smooth sailing as I can use just dd.

Unfortunately I can't yet switch the Pecos firmware to USB writing mode, and sunxi-fel seems to suffer from common libusb ailment of not being able to find a device whose parent is the Remote Desktop terminal-server host.

https://github.com/pecostm32/FNIRSI_1013D_Firmware/tree/main/fnirsi_1013d_scope/dist/Debug/GNU_ARM-Linux says "The other file fnirsi_1013d_scope.bin can be loaded to DRAM with sunxi-fel and the scope in FEL mode to do testing without writing to the SD card." so I think I need to figure out this sunxi-fel stuff & build environment next, and I'm not even getting through reading the thousands of messages on the threads, most of which are just people who wouldn't get the scope anyway bitching about it. How_to_load_scope.txt tells how to use "sunxi-fel" which might require writing https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/sunxi_stuff or https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Binaries/Hacked%20files/sunxi_stuff on SPI or SD. Though https://linux-sunxi.org/FEL has link to the sunxi-fel utility repository.

However, I grabbed https://github.com/linux-sunxi/sunxi-tools which in turn required building https://mirrors.edge.kernel.org/pub/software/utils/dtc/ which requires adding -Wno-error=char-subscripts to WARNINGS because I CBA to fix the coding violation, and PREFIX to /usr/ so the default build can find it.

At this point I might almost try to fix the libusb error, although I briefly tried earlier, or see if sunxi-fel can be easily changed to get around that issue.

[pcprogrammer]

As I'm a Linux user for my development I can't help with any Windows related problems 

But there are a couple of things to mention here.
To be able to load data to the DRAM with sunxi-fel the scope needs to be booted with the FEL boot I wrote. The difference between standard FEL and what I wrote is that the DRAM is not enabled in standard mode. (Standard mode is when the F1C100s finds no bootable program in either the FLASH memory or on the SD card.)

So to get the scope in this DRAM enabled FEL mode you have to write the FEL boot image I wrote to the SD card, just like you did with the 1013D firmware. With this one in it the scope boots into FEL mode after enabling the DRAM, and now you can load a binary file to the DRAM with sunxi-fel and execute it.

The DRAM starts at location 0x80000000. I load the binary to 0x7FFFFFE0 to get rid of the boot header that is present before the code. This is of course only if your make is setup to create this boot header, but without it, you can't boot your code from the SD card or the FLASH.

There is also an issue with sunxi-fel. I needed to get the source code including the FLASH read and write part to interact with the FLASH. There are versions that don't have this. When you only use it for loading to DRAM it does not matter of course.

I did build it from source, but don't remember from which repository. It is on my other computer and would have to look on that to find it.

About the partition type, the original firmware needs the card to be FAT, and I stuck with that. The reason for this is that both firmware's make use of open source code for the fat file system. (Google FatFs)

You mention the Pecos firmware and that is what I wrote.    Hope you do realize that pcprogrammer and pecostm32 are the same person. Had the github account before EEVblog and wanted a different user name for it.

In the 1013D thread you can skip many pages to get to the reverse engineering stuff. You can also just look at the posts in my profile starting from the first one on the last page. https://www.eevblog.com/forum/profile/?u=754690;area=showposts;start=2525 My first year on EEVblog was mainly in the 1013D thread 

To get a grip on controlling the firmware from the serial link look into the statemachine.c file (https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/statemachine.c). It starts with the touch_handler function.

There is a lot of comments in the source code so should be easy to understand what the intentions are.

[donwulff]

Haha, yes I'm aware it's your firmware, been saying that. I wondered if I should just say 'your firmware', both felt weird but because they splash screen says 'pecos score' I thought people might have better idea what I'm talking about.

FAT32 is fine, it's just it didn't even boot without the filesystem formatted, which is fine. All the details are very helpful though.

Shouldn't really get into that, but business requirement is we have Windows Remote Desktop Infrastructure at work. As might be for a lot of remote work too, now. It's annoying enough for things like this I'm almost ready to just hook the scope up to Linux AI development platform, lol. 😅 USB drives aren't mapped as raw devices but just remote drives, and for some reason Cygwin is missing all the low level stuff for drives too. But dd is ubiquitous.

And because the USB HUB isn't on the server, it's virtual, and libusb horks on that because it's missing some of the physical properties and I guess most importantly isn't actually 'HUB' class device. Since libusb won't 'see' it there's no easy workaround. There's business case for fixing that because it means basically most libusb software doesn't work, so I might actually get around to fixing it. Just need to learn everything about Windows USB enumeration first 🤓

I guess Windows 'support' for the scope/development would be nice too, but that's definitely a side quest.

Writing the SD card on another device works, and I have Linux at home of course. But right now I'm working on it, like just on lunch breaks/waiting for something to finish mainly. Having it display UI and basically run is encouraging though. I will need to go through reverse engineering the knob serial link anyway, and figure out setting up development environment, after which I believe I should be able to just hook USB disk mode to some button.

Also have a look at the FPGA, particularly as I'm not sure the scope trace should be doing what it's doing now. In theory lifting the low pass filter is easy, whether I want to actually do it is another matter entirely because it's a function of the Nyquist frequency. But anyway let's see where it goes.

[pcprogrammer]

  The PECOs comes from the first to letters of both my first and my last name as can be seen on my youtube account. Just as the pc in pcprogrammer are my initials. Some where thinking it stood for personal computer 

I thought about the connection between the two MCU's, and it might be easier to hook up a cheap logic analyzer and decode the data with sigrok. With pressing the buttons and turning the knobs the commands should be seen. Saves going through the GD32 code.

Don't remember what the communication speed is. Otherwise two CH340 serial to USB converters would do the trick too.

Edit: I did notice a difference in the acquisition part of the 1014D code, but can't recall what it was. Either they send an additional command or one less. Most of it is the same. It can be found in the Ghidra archive. One thing to keep in mind that the "special ic" part can be ignored fully because it is just doing fixed conversions on the presented data. This means all the 0x6X FPGA commands.

[donwulff]

Ha, I need to do less posting & more doing though, but hey, well planned is half done forever, and all that... Anyway so TL;DR was it's not that I can't or don't want to use Linux, but sometimes you just gotta use Windows. And I think things would work fine with Cygwin with no help needed, but Microsoft's RDP RemoteFX USB redirection is just broken...

Looking at the schematics & data sheet, I think that can only be UART1 serial, which gives easy enough port addresses to look for in the Ghidra output. Mainly for baud rate & framing, although I suppose I could scoop that too. Assuming the main processor isn't expected to send anything, it's just a few tries to find out what it's sending for keys and work from there... If it does send, I'll have to play with the emulator. I'd hate having to solder things on the pins.

Trouble is, I couldn't find instructions on setting up development environment yet. https://linux-sunxi.org/Toolchain is well hidden, and suggests nothing special is needed for the cross-toolchain, and if I'm seeing right, no libc? I'll go with something I already have around, like arm-none-eabi-gcc-10.3.1

I think the scope performance would, at some point, be limited by the cheap Runic Tech OpAmp slew rate. Taken at face value, 180 V/uS would mean it would take 7 nanoseconds to swing the 1.5V (That's the ADC range more or less?). It's strange to me the signal rise-time spec doesn't seem to account for amplitude anywhere. I put in an order for a bunch of OPA356's from AlieExpress in case I evet get to that, with 360 V/uS it should be able to do 3.5 nanoseconds rail to rail at least if the filter is relaxed. marauder indicated they might send fake chips, maybe, we'll see. Thinking if there'd be any practical way to switch/control the low-pass filter, the front-end is using mechanical relays but there aren't even any control lines free. FPGA JTAG pins might, in theory, be reconfigured as outputs. Also I didn't actually check which OpAmp my board has, but I assume it's the RS8751.

I was wondering if there's been any clarity to the "special IC", is it just crude attempt at copy prevention? If so, that'd be two extra I/O's, unfortunately both need FPGA design. Filter switching would actually need KAQY214S or similar.

[pcprogrammer]

After thinking about it a bit, I remembered that the one big difference between the 1014D and the 1013D is the clock setup for the FPGA. The MS5351M clock synthesizer needs to be initialized. This is not needed in the 1013D because it does not have it.

It needs bit banged I2C to do the initialization. There is code for it in the 1013D to read the touch panel data. But instead of PA2 and PA3 it needs to be on PA0 (SDA) and PA1 (SCL).

The first channel is used to provide the main clock to the FPGA and probably needs to be 50MHz, so input times 2. The other channel is probably for the AWG. I think this is how the frequency of the AWG is controlled. Just modify the output frequency of the second channel and have the FPGA run through a fixed number of addresses.

[pcprogrammer]

Looking at the schematics & data sheet, I think that can only be UART1 serial, which gives easy enough port addresses to look for in the Ghidra output. Mainly for baud rate & framing, although I suppose I could scoop that too. Assuming the main processor isn't expected to send anything, it's just a few tries to find out what it's sending for keys and work from there... If it does send, I'll have to play with the emulator. I'd hate having to solder things on the pins.

Yes it is UART1 that is being used. I already named a lot of the functions in the Ghidra archive for it. See the attached images. All you have to do is check the code on what is written to the UART registers starting with 0x01C254.

You already have the manual for the F1C100s in the repository. It is the same as the F1C200s which I used because it has an index.

It is probably the easiest to solder the wires on the GD32 chip end 

[pcprogrammer]

I was wondering if there's been any clarity to the "special IC", is it just crude attempt at copy prevention? If so, that'd be two extra I/O's, unfortunately both need FPGA design. Filter switching would actually need KAQY214S or similar.

I have no idea why they added this in. All it does is create problems. The I2C implementation in the FPGA is crap and I have seen it go wrong often and needing a resend of the data. The scope became more reliable after I removed the usage all together. First needed to figure out what it did of course 

But when you use 8 if statements to make up an XOR who knows what other weird stuff you think up being great.

The FPGA has 17 pins free to be used, but soldering wires to it is a young mans game.  At least for me that is. Even with a microscope it is hard for me.

[Fungus]

Imagine how many more of these they could sell if they open-sourced the firmware.

[pcprogrammer]

Yeah, would be interesting to see if the 1013D sales went up after my firmware came available 

It would make it a lot easier to improve on it if they did open source it.

[pcprogrammer]

I looked on my other system and it looks like I got the sources for the sunxi tools from here: https://github.com/linux-sunxi/sunxi-tools
Other info about it: https://linux-sunxi.org/Sunxi-tools

[pcprogrammer]

Some pictures I found that might be of help. Might have posted them earlier.

[donwulff]

Hi thanks! That can be inhered from your well done schematics (Though I was initially confused because the signals of the JTAG footprint aren't named the same as the pins on the FPGA  ). And looking at the datasheets for the possible uses of the pins / register addresses.

I'm really, really hoping I don't have to solder anything on the legs of the main chips, if I can avoid it at all, with the reverse-engineering that's been done that should probably be way easier. I was going to ignore GD32E230 and let it be as it is at the start, but I suppose it might be easier to localize the protocol from that. Even if I somehow hit the legs on the processors, that wouldn't really be a repeatable hack for a lot of people. Getting extra pins from JTAG or in a pinch from the "Special IC" would indeed be preferable, IFF it turns out there's any benefit to that.

The optoisolated solid state relay COSMO KAQY214S must be a copy of Philips AQY214S, looking at the data-sheet main difference seems to be KAQY214 *claims* ON-resistance of 20 to 30 ohms, whereas the Philips one is 25-35 ohms. This would change the frequency response, probably for the worse. On the other hand, if a COSMO KAQY214S connected in parallel with the R62/R80 on the 1014D schematic, it should alter that from 150 ohms to about 18 ohms. According to the simulation on the Russian site ( https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3147914/#msg3147914 ) it should raise the low-pass filter for Nyquist/aliasing to around ~100MHz when the photodiode is driven (While maintaining the 400 V signal/1500V isolation) with minimum components/noise. Then again, I haven't independently verified the simulation, and it looks to me like it MIGHT apply mostly to AC-coupled mode, but the easiest solution is probably to just try ~20 ohm resistor in parallel once I get unmangled readings from the ADC with the new firmware (And maybe OPA356's to get faster rise time).

Speaking of MS5351M clock-generator, looking at the board on thermal camera, that thing's running at 50C+ hottest thing on the board while everything seems to assume it should be ran at room temperature. I don't think there's floating inputs or anything possible, so just normal? https://www.qrp-labs.com/synth/ms5351m.html says it's Si5351A clone, which is presumably where I'll find the I2C protocol/commands. Something like https://media.digikey.com/pdf/Data%20Sheets/Silicon%20Laboratories%20PDFs/Si5351A_B_C.pdf Of course reverse-engineering source can confirm values.

Firmware needs straight-forward Windows installer, although I'm wondering if there's different sizes of SD cards, too. It's kind of shame they didn't make the SD card external if they were going with one...

[pcprogrammer]

I looked back at the schematics and noticed that I did not connect the JTAG connector labels to the FPGA 

The JTAG pins are dedicated and can't be used as a normal IO pin, so no luck there. I can understand not wanting to solder any wires to the IC's as part of a new setup to be widely used. Similar to the reason for not making a new FPGA programming for it.

The two pins used for the special IC, are available and can easily be connected to on the provisioned header. Only problem is the IC on the lines.

The datasheet of the MS5351 is in the repository, but there is no programming info in it, so I guess it needs to come from the Si5351 manuals, and try to find it in the firmware.

I'm no expert on analog stuff, so can't really help on that. I had some electronics education and worked in the field a bit, but mostly digital and moved on to programming. A couple of years back I returned to the electronics hobby with an emphasis on microcontroller projects. Digital audio synthesis has my interest, and to have a small scope near my computer was the reason for buying the 1013D. It arrived with a problem in the touch panel, and that is what got the reverse engineering hobby started.

[donwulff]

Same, same. That's why I'm asking Though analog electronics comes up a whole lot in digital/embedded, but generally not OpAmp frontends. I think I was looking for an affordable hobby scope for learning/experimenting that I can use for anything without having to worry about breaking it on AliExpress, and you gotta admit the 1013D/1014D specs catch the eye. But with the Chinese stores, well I'd say 110% of them qualify as some kind of scam, starting with how every entry lists the price of some wire or something and not the expensive thing in the listing, the affordable thing is sold out, shipping is more than the product etc. but the one thing is you typically get the same thing that everyone else. So you have to Google it, and this thread comes up, and I know about the 30-40MHz useable bandwidth etc. (However I'll not this is still fairly confusing, because the rule of thumb is that any scope is only professionally suitable for signals 1/5th the bandwith on the front plate, so by that FNIRSI would be for ~20MHz signals. That said sampling rate is big deal, making it 40MHz plate equivalent, and thus maybe 8MHz real? And let's not talk about the sensitivity, which makes it indicator rather than signal integrity. But let's be honest that's MOST of what one would use a scope for.). The irony is it's going about open firmware for it, but turns out it doesn't work on the 1014D That's fine though, if I was going to play with the firmware, I might just as well try to make it work.

I'm trying to actually figure out Evi's ground offset mod at https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4536116/#msg4536116 - the schematic shows the negative reference going to pin 2 of the ADC. So that must be biasing the signal to -1.125V with -2.5V ref, but seems like that would flatten the signal, if I'm following double the rise-time for the OpAmp although probably reduce noise at the ADC? Though I suppose the first question is do I need / benefit from that at all. Also looking at that board picture, that's a whole lot of wires acting as antennas, which I'm worried for any modifications.

I think people would be fine, even eager to make small changes to the scope. If the new firmware works better than original, I'm sure anyone actually using a scope anyway could handle desoldering the chip. Even without that I guess that gives one in and (more importantly) one out signal without breaking anything, as long as the FPGA can be replaced. Of course, still need cheap SPI programmer, and something to connect the IO's to. But yeah, yeah, let's see if there's any point to that.

[pcprogrammer]

The 1014D has the advantage of the FPGA JTAG connector. It is possible to program the FLASH with the Anlogic IDE and the JTAG interface I wrote about earlier.

About the mod of evi, yes it could bring some noise into the signal. Though with the sensitivity as is don't think it will be a big problem. The ground thing is a problem when you connect the USB interface and have the probe ground on the same ground as the computer. That would be solved with the mod.

[donwulff]

Thanks, I wasn't seeing much divergence from ground in normal use and was wondering if that's a problem in some scopes because I didn't see any context for that mod. But figuring out why the level goes all wrong when plugged to computer has been in the back of my mind, because that needs to be fixed for any kind of data logger use... Although avoiding ground loops is a big thing with scopes, so haven't really looked at how that works yet.

As for the FPGA, turns out the SPI flash on my scope is actually ZB25VQ80ATIG which is one reason reading it was so hard. Latest flashrom binary (with Bus Pirate and 1014D in same USB, 3v3 not connected) doesn't recognize the chip, but finally produces 1 megabyte dump using some standard mode (The FPGA needs to be able to read it, after all). It doesn't match the 1013D one in your repository, but that's probably to be expected. I seem to recall seeing a link to some header information in one of the threads, but now can't find it.

Based on differences only starting on 92nd byte, I suspect the SPI reading was OK and I think there's a good chance the FPGA part is still the same though.

     92  34 ^\   344 M-d
     95 222 M-^R  36 ^^
     96  15 ^M   156 n
    165   0 ^@    23 ^S
    166   0 ^@    30 ^X
    167   0 ^@   200 M-^@
    168  54 ,     40
    316   0 ^@     2 ^B
(more differences)

Since the PFGA can't be field-upgraded, the FPGA interface must still be same with all 1014D's. Or well, 1014D has two different display variant, with different firmware updates from FNIRSI, so I suppose technically they COULD have different FPGA interface too.

Edit: cmp -lb dump above starts at index 1 and whos byte values in octal, which makes it near useless, certainly if you try to match to the hexdump below...

[pcprogrammer]

For as far as I know they did not tinker with the FPGA - MCU interface on hardware level. It is the same setup in all the 1013D's and 1014D's I know of.

I did generate a partial net list for the 1014D FPGA, so if you are interested I can upload what I have to the FPGA reversal repository. Because it was an exploratory and educational adventure, I did not feel the urge to make a full fledged reversal software package for the Anlogic FPGA's, and due to this the clock nets of the 1014D are not listed. Did them by hand for the 1013D. I did look into the AWG part and memory usage a bit and found that the sampling memory setup is the same as in the 1013D and one additional memory block is used for the AWG.

Basically the same crap design.

Edit: Here is a link to a repository I got a lot of the used information about the Anlogic FPGA's from: https://github.com/mmicko/prjtang

[donwulff]

Thanks again, after wading around a bit found the main thing I was after, the bitstream format/header: https://github.com/mmicko/prjtang/blob/master/docs/architecture/bitstream_format.rst

00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000020  cc 55 aa 33 f0 00 00 06  18 00 6c 31 0b b7 c2 00  |.U.3......l1....|
00000030  00 06 d1 00 05 00 e9 93  c3 00 00 06 d7 b0 4b b0  |..............K.|
00000040  af f0 c7 00 00 06 04 33  01 01 a6 53 c8 00 00 06  |.......3...S....|
00000050  00 00 04 80 98 88 c1 00  00 06 00 e4 00 00 1e 6e  |...............n|
00000060  c4 00 00 06 02 00 00 20  6b 60 f1 00 00 04 00 00  |....... k`......|
00000070  78 af ec f0 04 33 00 00  b0 00 00 00 00 00 02 c0  |x....3..........|
00000080  00 02 c0 00 00 00 00 00  0b 00 00 00 2c 00 00 00  |............,...|
00000090  00 00 00 b0 00 00 b0 00  00 00 00 00 02 c0 00 00  |................|
000000a0  0b 00 00 00 13 18 80 20  00 00 2c 00 00 00 00 00  |....... ..,.....|
000000b0  00 b0 00 00 02 c0 00 00  00 00 00 0b 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 b0 00 00 00 00 00 02  |................|
000000d0  c0 00 02 c0 00 00 00 00  00 0b 00 00 00 2c 00 00  |.............,..|
000000e0  00 00 00 00 b0 00 00 b0  00 00 00 00 00 02 c0 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 b0  |................|
00000100  00 00 00 00 00 02 c0 00  02 c0 00 00 00 00 00 0b  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

No idea about the ff's or cc 55 aa 33, maybe some sort of header, but then we get:

f0 (device id packet) 00 (flags) 0006 (6 bytes) 18006c31 (al3_10) 0bb7 (crc) - which happens to be the al3_10 identifier, so yup, same device, which is main thing I wanted to know.

First difference looks like starting at 0x56, c1 that is VERSION_UCODE, on mine that is 00e40000, in your repository 001c0000

The rest of the changes are after the "ec f0 0433" identifier, which I'm not sure from that description, but seems to indicate that's the actual FPGA blocks already. 0x0433 = 1075 = number of frames in Anlogic AL3 family.

I may return to the FPGA later, but probably a good time to get libusb RDP and/or scope traces and knobs working.

[pcprogrammer]

No idea about the ff's or cc 55 aa 33, maybe some sort of header, but then we get:

That is just a pre amble. Probably used when FPGA's are daisy chained with the configurations in one FLASH.

The rest of the changes are after the "ec f0 0433" identifier, which I'm not sure from that description, but seems to indicate that's the actual FPGA blocks already. 0x0433 = 1075 = number of frames in Anlogic AL3 family.

Yep that is the number of frames in there. There is also another identifier that gives the number of memory pre loading frames. The size of the bit stream can be longer when the memory is initialized via it.

The code I wrote to analyze the bit stream does not handle that, but it does process all the normal configuration bits. Was quite a task to figure it all out with the information at hand, because it did not mention where the padding of the frames sits or how the bits mapped to the data base information. The whole adventure is described in the FPGA reverse engineering thread. The trickiest part was to figure out the routing through the fabric. Wasn't until I stumbled on information about Gowin FPGA's that the light went on 

[donwulff]

Clock generator chip registers, in Chinese: https://datasheet.lcsc.com/lcsc/2012241239_Hangzhou-Ruimeng-Tech-MS5351M_C1509083.pdf
Guess need to feed that to translator, although the should be pretty much same as https://media.digikey.com/pdf/Data%20Sheets/Silicon%20Laboratories%20PDFs/Si5351A_B_C.pdf which features desktop software for designing the register values.

Ghidra decompile of the clock chip is giving me a headache, looks like the registers are changed for different time-divs, and presumably there's a table of at least some of the register values in memory, but also some dynamic stuff, and I'm not conversant enough in Ghidra to figure that out yet (looks complicated, to be fair. Need to also compare to the 1013D source code to make sure what it's doing).

The I2C pull-ups are right under the clock generator chip, right hand side for the bus-side, it would be relatively easy to attach Bus Pirate and try to capture the register profiles. Not a big fan of unnecessary soldering though. The values are presumably just straight out the ADC clocks for each channel, so using the Silicon Labs software to design optimal values for the clocks might work too.

In the 1014D design the clock generator and knob processor are on the same pins as the touch on 1013D. Funnily enough, the I2C is on alternate pins of the four though... I disabled the touch code just to be sure, but I guess the clock gen has just empty default configuration so there's no change to the scope trace from that yet.

Serial-port/knob controller next, so I can easily program SD-card in place for testing?

Link-time optimization makes the binary size grow? I guess that's what you get for compiling at -O3. I'm actually not sure how full the memory is currently. Shame they didn't just but F1C200s on all.

[pcprogrammer]

The way I worked with the scope while developing was having the special FEL boot on the SD card and use the sunxi-fel tool to load the fresh build code to test things. This way there is no wear on the SD card and the process has a quick turnaround.

Don't worry about memory. There is 32MB and the code itself is very small. 229KB for the 1013D. It uses a chunk of the memory to store the screen data and buffers for the samples which is less then 4MB. (Did not check the actual amount).

Adding extra code won't make it that much bigger.

In Ghidra it is possible to de-compile to pseudo C, which makes things easier to read. But then still, it takes it's time to become an expert with it.

A simple test you can do is to just setup channel 1 of the clock synth to generate 50MHz and see if the sampling starts to work. I'm quite sure they don't change this clock to adjust the sampling rate simply because the other parts of the FPGA design depend on this clock to be set at a fixed value.

Channel 2 will be a different story.

The pin assignments they did in the 1013D for the touch panel are another example of stupid. There is a two wire interface available on other pins of the MCU they could have used instead of bit banging. The same goes for the 1014D. The swapping of the SDA and SCL pins between the 1014D and 1013D design has to do with UART1.

[pcprogrammer]

Damn you for raising my curiosity 

I did some measurements on the clock signals. As I suspected the main clock input is set at 50MHz and stays fixed on that. The other one varies with frequency settings of the AWG.

The only thing is that I made an error in the schematic. CLK0 (pin 10) is for the AWG and CLK1 (pin 9) is for the main clock.

The relation between the AWG frequency and the clock frequency looks a bit odd. For sine wave at 10MHz the clock is 200MHz and at 9MHz I measured 180MHz, but for 8MHz it went back up to 200MHz, so there is more to it then just controlling this clock. I have to say that I did not do accurate measurements. Just probed the signal with my big scope set to 10ns/div and frequency measurement on between two cursors. Due to DC offset and noise it was not very stable.

It is probably easier to get the information from reverse engineering the code.

I also found that I left my scope in FEL mode. When I booted it to do the measurements it stayed stuck on the boot screen, and both clock signals were off. I removed the SD card and it booted with "SD error" message. Now the clocks were running, both at 50MHz. I got another blank formatted SD card and it booted normally with the main clock at 50MHz and the other one very very low. Turned out the AWG was set to 0.005Hz 

So try to modify the startup of the 1013D code to write settings to the clock IC to set both channels to 50MHz before initializing the FPGA, and see if the sampling starts to work.

[pcprogrammer]

I could not resist to take a peak at the code 

In the Ghidra project there are two versions of the 1014D firmware, and in V3 I named two functions to be for the clock control I2C.

The function more_i2c_stuff_for_fpga_clock takes two parameters, which I named setting1 and setting2.
The function some_i2c_stuff_for_fpga_clock takes one parameter, which is a byte to be send out on the I2C bus.

In the function more_i2c_stuff_for_fpga_clock it first sends 0xC0 followed by setting1 and setting2. Have not hold it against the datasheet of the clock ic.

The other functions in the FPGA init function probably do some calculations on data to come to the setting bytes to be send to the clock ic.

I uploaded a new archive to the repository.

Edit: Renamed the functions and the parameters after looking at the datasheet. Confirmed that the 0xC0 is addressing the ic for write, followed by a register address and the data for it. So the two functions are the low level bit for writing a register in the ic. (Look for fpga_clock_ic in the Ghidra project 1014D_program_V3)

Attached is the Ghidra C output for the two functions.

[donwulff]

Whee, now we're doing duplicate work, like I said I've been looking at Ghidra I was wondering if I should've posted the garbage that it decompiled, haha. But yeah I figured the basics, the actual register files not so much... But after the last post I was reading machine translation of the Chinese datasheet for the clock gen, until I discovered it's all explained in AN619 of the Silicon Labs chip https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/application-notes/AN619.pdf (Is it as simple as PLL 30 x 25 = 750MHz VCO / MS 30 = 50MHz? I'll find out!). Now that I understand the values bit better and know they're not magic, the register settings are starting to make a bit more sense to me. There's also Arduino library https://github.com/etherkit/Si5351Arduino which I'd forgotten about for directly calculating & setting the values dynamically, so could even just use that.

I guess I shouldn't be surprised if the clocks are really distributed that way... There's an odd extra function called for the second clock, but other than that they look pretty symmetrical in code. (Function names random guessed of course).

Code: [Select]

void fpga_init(void)

{
  uint *puVar1;
  uint uVar2;
 
  init_porta_0_1_output();
  uVar2 = DAT_80017534;
  i2c_fpga_clockgen_ch0_reset(DAT_80017534);
  i2c_fpga_clockgen_ch1_reset(uVar2);
  i2c_fpga_clockgen_ch1_set(1);
  puVar1 = DAT_80017538;
  gpio_config_pin(DAT_80017538,9,1);

Which is Ghidra being weird, because yes, both initial functions are called with the same parameter = 02FAF080h.

Then the i2c_fpga_clockgen_ch0_reset() ends in:

Code: [Select]

LAB_80026220:
  if ((uVar3 <= uVar4) && (uVar4 = uVar3, uVar3 < uVar1)) {
    uVar4 = uVar1;
  }
  uVar1 = (uint)((ulonglong)uVar4 * (ulonglong)DAT_800262f8 >> 0x37);
  iVar6 = DAT_800262fc * uVar1;
  uVar5 = FUN_8003bd3c(uVar4 + iVar6 * 0x40,iVar6,DAT_800262fc,
                       (int)((ulonglong)uVar4 * (ulonglong)DAT_800262f8));
  uVar5 = FUN_8003bde8(uVar5,DAT_80026300);
  FUN_8003ba60(uVar5,DAT_80026304);
  uVar5 = FUN_8003bcb8();
  i2c_fpga_clockgen_config_pll(0x1a,uVar1 & 0xff,uVar5,DAT_80026308);
  if (uVar2 < uVar7 - 0x9c4) {
    i2c_fpga_clockgen_config_ms(0x2a,4,0xc);
  }
  else {
    i2c_fpga_clockgen_config_ms(0x2a,unaff_r6,bVar8);
  }
  i2c_fpga_clockgen_reg(0xb1,0x20);
  ptr = DAT_8001e440;
  set_gpio_pin_high(DAT_8001e440,0);
  set_gpio_pin_high(ptr,1);
  set_gpio_pin_low(ptr,0);
  _delay(10);
  set_gpio_pin_low(ptr,1);
  _delay(10);
  _delay(10);
  i2c_fpga_clockgen_chg(0xc0);
  _delay(10);
  i2c_fpga_clockgen_chg(0x10);
  _delay(10);
  i2c_fpga_clockgen_chg(0x4f);
  _delay(10);
  set_gpio_pin_low(ptr,1);
  _delay(10);
  set_gpio_pin_low(ptr,0);
  _delay(10);
  set_gpio_pin_high(ptr,1);
  _delay(10);
  set_gpio_pin_high(ptr,0);
  delay(10);
  return;

So we have a LOT of weird functions (possibly more before that point) with pointers for figuring out the values. We set the PLL divider and then the MultiSynth counters with out magic values. Register 0xb1 = 177 = PLL RESET, specifically PLLA here, which makes the new parameters take force. Then, for who knows what reason, we have the register setting protocol expanded out. Register 0x10 = 16 = CLK0 Control. Maximum 8 mA drive, clock from MultiSynth 0 in "integer mode" to improve jitter.

Of note, none of this is actually going according to either the Silicon Labs or chinese datasheet. They have "disable output, power down output drivers" before divider settings and tell to use 177 = 0xAC to reset PLL.

The second clock is handled in exactly the same way, only the register addresses seem to change for the second clock. But of course THEN we get the i2c_fpga_clockgen_ch1_set() which changes the MultiSynth values based on yet other functions... And looking again, i2c_fpaga_clockgen_ch0_reset is called again in relation to the scope, but I guess i2c_fpaga_clockgen_ch0_reset and i2c_fpaga_clockgen_ch0_set are never called again after initialization.

Unknown function end:

Code: [Select]

  fpga_write_cmd('G');
  fpga_write_data((uchar)((*(ushort *)(iVar2 + 2) - 1) * 0x10000 >> 0x18));
  fpga_write_data(*(char *)(iVar2 + 2) + 0xff);
  uVar13 = DAT_8001c128;
  uVar8 = *(uint *)(iVar2 + 4) * (uint)*(ushort *)(iVar2 + 2);
  if (DAT_8001c124 < uVar8) {
    uVar8 = DAT_8001c124;
  }
  if (*(uint *)(iVar2 + 4) < 10) {
    *(undefined *)(iVar2 + 0xb) = 1;
    if (uVar8 < 0xfa) {
      uVar8 = 0xfa;
    }
    i2c_fpga_clockgen_ch0_reset(uVar8 * 10);
  }
  else {
    *(undefined *)(iVar2 + 0xb) = 0;
    if (uVar8 < uVar13) {
      uVar8 = DAT_8001c128;
    }
    i2c_fpga_clockgen_ch0_reset(uVar8);
  }
  fpga_write_cmd('H');
  fpga_write_data(*(uchar *)(iVar2 + 0xb));
  if (*(int *)(iVar2 + 4) == 0) {
    fpga_write_cmd('F');
    uVar13 = 0;
    do {
      fpga_write_data('c');
      uVar13 = uVar13 + 1 & 0xfffeffff;
    } while (uVar13 < 1000);
    return;
  }
  fpga_write_cmd('F');
  uVar13 = 0;
  do {
    fpga_write_data(pbVar3[uVar13]);
    uVar13 = uVar13 + 1 & 0xfffeffff;
  } while (uVar13 < 1000);
  return;

None of those FPGA commands are in the https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/FPGA%20explained/FPGA%20explained.txt document, so that's some more reverse engineering along with trying to find out what it does to the clock gen. And whoops, just re-read what you said with thought, so this must be for the clock-gen whereas the other, fixed output with extra function is indeed for the oscilloscope. No wonder I was thinking it was being changed!

It seems like I might need a crash-course in Ghidra. I'm going to try to solve these BEFORE posting, though

EDIT: Oh yeah, also want to use FEL for all the reasons, but as complained before, libusb doesn't really work over Microsoft RDP RemoteFX USB pass-through. Or it does, if the USB device is part of a composite device and the software looks for that device directly and not the composite device... but yeah, let's just say it doesn't work until fixed.

EDITn: Yes I also looked at how the Sipeed Lichee Nano with F1C100s has 16MB flash, so I guess the 1MB set aside for firmware on the SD-card is just a matter of choice and guessing it won't grow above that. It would also theoretically be possible to load different modules from SD into memory?

Si5351A ClockBuilder Pro lets me choose 200MHz + 50MHz clock even though I guess it's way beyond spec (actually looks like it's in, but needs special settings). So this is something like what I should be looking for in the code. I wonder why there's so many functions & apparent dynamicity to the setting in FNIRSI, just stupid choice/ready-made library I guess? Also note you can write i2c in consequential manner, even according to the Chinese clone datasheet, no need to give write & register address for each. And most registers default to 0x00 value after reset, so those register writes can generally be ignored (unless needed to cover a gap in the register sequence), but that's on ClockBuilder Pro.

Also, this dump shows I still really don't understand the register configuration. The math of "Fvco = 32 x 25MHz = 800MHz, CLK0 divider 4 = 200MHz, CLK1 divider 16 = 50MHz" is just as I'd expect, then in the register file... 0x00E00. WTAF

Code: [Select]

/*
 * Si5351A Rev B Configuration Register Export Header File
 *
 * This file represents a series of Skyworks Si5351A Rev B
 * register writes that can be performed to load a single configuration
 * on a device. It was created by a Skyworks ClockBuilder Pro
 * export tool.
 *
 * Part:                                        Si5351A Rev B
 * Design ID:                                         
 * Includes Pre/Post Download Control Register Writes: Yes
 * Created By:                                         ClockBuilder Pro v4.7 [2022-11-18]
 * Timestamp:                                          2023-01-06 18:41:46 GMT+02:00
 *
 * A complete design report corresponding to this export is included at the end
 * of this header file.
 *
 */

#ifndef SI5351A_REVB_REG_CONFIG_HEADER
#define SI5351A_REVB_REG_CONFIG_HEADER

#define SI5351A_REVB_REG_CONFIG_NUM_REGS 53

typedef struct
{
unsigned int address; /* 16-bit register address */
unsigned char value; /* 8-bit register data */

} si5351a_revb_register_t;

si5351a_revb_register_t const si5351a_revb_registers[SI5351A_REVB_REG_CONFIG_NUM_REGS] =
{
{ 0x0002, 0x53 },
{ 0x0003, 0x00 },
{ 0x0004, 0x20 },
{ 0x0007, 0x00 },
{ 0x000F, 0x00 },
{ 0x0010, 0x4F },
{ 0x0011, 0x0F },
{ 0x0012, 0x8C },
{ 0x0013, 0x8C },
{ 0x0014, 0x8C },
{ 0x0015, 0x8C },
{ 0x0016, 0x8C },
{ 0x0017, 0x8C },
{ 0x0018, 0x0A },
{ 0x001A, 0x00 },
{ 0x001B, 0x01 },
{ 0x001C, 0x00 },
{ 0x001D, 0x0E },
{ 0x001E, 0x00 },
{ 0x001F, 0x00 },
{ 0x0020, 0x00 },
{ 0x0021, 0x00 },
{ 0x002A, 0x00 },
{ 0x002B, 0x01 },
{ 0x002C, 0x0C },
{ 0x002D, 0x00 },
{ 0x002E, 0x00 },
{ 0x002F, 0x00 },
{ 0x0030, 0x00 },
{ 0x0031, 0x00 },
{ 0x0032, 0x00 },
{ 0x0033, 0x01 },
{ 0x0034, 0x00 },
{ 0x0035, 0x06 },
{ 0x0036, 0x00 },
{ 0x0037, 0x00 },
{ 0x0038, 0x00 },
{ 0x0039, 0x00 },
{ 0x005A, 0x00 },
{ 0x005B, 0x00 },
{ 0x0095, 0x00 },
{ 0x0096, 0x00 },
{ 0x0097, 0x00 },
{ 0x0098, 0x00 },
{ 0x0099, 0x00 },
{ 0x009A, 0x00 },
{ 0x009B, 0x00 },
{ 0x00A2, 0x00 },
{ 0x00A3, 0x00 },
{ 0x00A4, 0x00 },
{ 0x00A5, 0x00 },
{ 0x00A6, 0x00 },
{ 0x00B7, 0x92 },

};

/*
 * Design Report
 *
 * Overview
 * ========
 * Part:               Si5351A
 * Created By:         ClockBuilder Pro v4.7 [2022-11-18]
 * Timestamp:          2023-01-06 18:41:46 GMT+02:00
 *
 * Design Rule Check
 * =================
 * Errors:
 * - No errors
 *
 * Warnings:
 * - No warnings
 *
 * Design
 * ======
 * I2C Address: 0x60
 *
 * Inputs:
 *     IN0: 25 MHz
 *
 * Outputs:
 *    OUT0: 200 MHz
 *          Enabled LVCMOS 8 mA
 *          Offset 0.000 s
 *    OUT1: 50 MHz
 *          Enabled LVCMOS 8 mA
 *          Offset 0.000 s
 *    OUT2: Unused
 *
 * Frequency Plan
 * ==============
 * PLL_A:
 *    Enabled Features = None
 *    Fvco             = 800 MHz
 *    M                = 32
 *    Input0:
 *       Source           = Crystal
 *       Source Frequency = 25 MHz
 *       Fpfd             = 25 MHz
 *       Load Capacitance = Load_08pF
 *    Output0:
 *       Features       = None
 *       Disabled State = HiZ
 *       R              = 1  (2^0)
 *       Fout           = 200 MHz
 *       N              = 4
 *    Output1:
 *       Features       = None
 *       Disabled State = HiZ
 *       R              = 1  (2^0)
 *       Fout           = 50 MHz
 *       N              = 16
 *
 * Settings
 * ========
 *
 * Location      Setting Name    Decimal Value      Hex Value       
 * ------------  --------------  -----------------  -----------------
 * 0x0002[3]     XO_LOS_MASK     0                  0x0             
 * 0x0002[4]     CLK_LOS_MASK    1                  0x1             
 * 0x0002[5]     LOL_A_MASK      0                  0x0             
 * 0x0002[6]     LOL_B_MASK      1                  0x1             
 * 0x0002[7]     SYS_INIT_MASK   0                  0x0             
 * 0x0003[7:0]   CLK_OEB         0                  0x00             
 * 0x0004[4]     DIS_RESET_LOLA  0                  0x0             
 * 0x0004[5]     DIS_RESET_LOLB  1                  0x1             
 * 0x0007[7:4]   I2C_ADDR_CTRL   0                  0x0             
 * 0x000F[2]     PLLA_SRC        0                  0x0             
 * 0x000F[3]     PLLB_SRC        0                  0x0             
 * 0x000F[4]     PLLA_INSELB     0                  0x0             
 * 0x000F[5]     PLLB_INSELB     0                  0x0             
 * 0x000F[7:6]   CLKIN_DIV       0                  0x0             
 * 0x0010[1:0]   CLK0_IDRV       3                  0x3             
 * 0x0010[3:2]   CLK0_SRC        3                  0x3             
 * 0x0010[4]     CLK0_INV        0                  0x0             
 * 0x0010[5]     MS0_SRC         0                  0x0             
 * 0x0010[6]     MS0_INT         1                  0x1             
 * 0x0010[7]     CLK0_PDN        0                  0x0             
 * 0x0011[1:0]   CLK1_IDRV       3                  0x3             
 * 0x0011[3:2]   CLK1_SRC        3                  0x3             
 * 0x0011[4]     CLK1_INV        0                  0x0             
 * 0x0011[5]     MS1_SRC         0                  0x0             
 * 0x0011[6]     MS1_INT         0                  0x0             
 * 0x0011[7]     CLK1_PDN        0                  0x0             
 * 0x0012[1:0]   CLK2_IDRV       0                  0x0             
 * 0x0012[3:2]   CLK2_SRC        3                  0x3             
 * 0x0012[4]     CLK2_INV        0                  0x0             
 * 0x0012[5]     MS2_SRC         0                  0x0             
 * 0x0012[6]     MS2_INT         0                  0x0             
 * 0x0012[7]     CLK2_PDN        1                  0x1             
 * 0x0013[1:0]   CLK3_IDRV       0                  0x0             
 * 0x0013[3:2]   CLK3_SRC        3                  0x3             
 * 0x0013[4]     CLK3_INV        0                  0x0             
 * 0x0013[5]     MS3_SRC         0                  0x0             
 * 0x0013[6]     MS3_INT         0                  0x0             
 * 0x0013[7]     CLK3_PDN        1                  0x1             
 * 0x0014[1:0]   CLK4_IDRV       0                  0x0             
 * 0x0014[3:2]   CLK4_SRC        3                  0x3             
 * 0x0014[4]     CLK4_INV        0                  0x0             
 * 0x0014[5]     MS4_SRC         0                  0x0             
 * 0x0014[6]     MS4_INT         0                  0x0             
 * 0x0014[7]     CLK4_PDN        1                  0x1             
 * 0x0015[1:0]   CLK5_IDRV       0                  0x0             
 * 0x0015[3:2]   CLK5_SRC        3                  0x3             
 * 0x0015[4]     CLK5_INV        0                  0x0             
 * 0x0015[5]     MS5_SRC         0                  0x0             
 * 0x0015[6]     MS5_INT         0                  0x0             
 * 0x0015[7]     CLK5_PDN        1                  0x1             
 * 0x0016[1:0]   CLK6_IDRV       0                  0x0             
 * 0x0016[3:2]   CLK6_SRC        3                  0x3             
 * 0x0016[4]     CLK6_INV        0                  0x0             
 * 0x0016[5]     MS6_SRC         0                  0x0             
 * 0x0016[6]     FBA_INT         0                  0x0             
 * 0x0016[7]     CLK6_PDN        1                  0x1             
 * 0x0017[1:0]   CLK7_IDRV       0                  0x0             
 * 0x0017[3:2]   CLK7_SRC        3                  0x3             
 * 0x0017[4]     CLK7_INV        0                  0x0             
 * 0x0017[5]     MS7_SRC         0                  0x0             
 * 0x0017[6]     FBB_INT         0                  0x0             
 * 0x0017[7]     CLK7_PDN        1                  0x1             
 * 0x0018[1:0]   CLK0_DIS_STATE  2                  0x2             
 * 0x0018[3:2]   CLK1_DIS_STATE  2                  0x2             
 * 0x001C[17:0]  MSNA_P1         3584               0x00E00         
 * 0x001F[19:0]  MSNA_P2         0                  0x00000         
 * 0x001F[23:4]  MSNA_P3         1                  0x00001         
 * 0x002C[17:0]  MS0_P1          0                  0x00000         
 * 0x002C[2]     MS0_DIVBY4_0    1                  0x1             
 * 0x002C[3]     MS0_DIVBY4_1    1                  0x1             
 * 0x002F[19:0]  MS0_P2          0                  0x00000         
 * 0x002F[23:4]  MS0_P4          1                  0x00001         
 * 0x0034[17:0]  MS1_P1          1536               0x00600         
 * 0x0037[19:0]  MS1_P2          0                  0x00000         
 * 0x0037[23:4]  MS1_P4          1                  0x00001         
 * 0x005A[7:0]   MS6_P2          0                  0x00             
 * 0x005B[7:0]   MS7_P2          0                  0x00             
 * 0x0095[14:0]  SSDN_P2         0                  0x0000           
 * 0x0095[7]     SSC_EN          0                  0x0             
 * 0x0097[14:0]  SSDN_P3         0                  0x0000           
 * 0x0097[7]     SSC_MODE        0                  0x0             
 * 0x0099[11:0]  SSDN_P1         0                  0x000           
 * 0x009A[15:4]  SSUDP           0                  0x000           
 * 0x00A2[21:0]  VCXO_PARAM      0                  0x000000         
 * 0x00A5[7:0]   CLK0_PHOFF      0                  0x00             
 * 0x00A6[7:0]   CLK1_PHOFF      0                  0x00             
 * 0x00B7[7:6]   XTAL_CL         2                  0x2
 *
 *
 */

#endif

[pcprogrammer]

Haha, I only looked at the lowest level of the code because I had already found those two functions before, but did not checked the parameters. I stopped after verifying that it was indeed addressing the clock chip.

Looked at the programming of the clock ic just a little bit and decided it was up to you to dig further, which you did 

I uploaded the stuff I created in regards with the 1014D FPGA to the reversal repository.

The commands in the  0x4X range are indeed unknown to me and chances are they have to do with the AWG. The clock synthesizer CLK0 output is the variable one. CLK1 is fixed on 50MHz, so verify that your findings match with this.

The command 0x46 ('F') looks like the one for loading the waveform memory. It loops to write a 1000 bytes to the FPGA, which more or less matches the 1KB I found available for it in the FPGA reversal.

Based on the measurements I did, I guess that with one of the other commands they set a clock divider and maybe a range of samples to use.

[pcprogrammer]

EDITn: Yes I also looked at how the Sipeed Lichee Nano with F1C100s has 16MB flash, so I guess the 1MB set aside for firmware on the SD-card is just a matter of choice and guessing it won't grow above that. It would also theoretically be possible to load different modules from SD into memory?

The 1MB is what most SD cards have with default formatting, and it still allows for growth of the firmware.

It would also theoretically be possible to load different modules from SD into memory?

Yes, that is basically how linux does it. You could load some files on the SD card and have the basic part of the firmware read them into memory and jump into that code.

Si5351A ClockBuilder Pro lets me choose 200MHz + 50MHz clock even though I guess it's way beyond spec. So this is something like what I should be looking for in the code. I wonder why there's so many functions & apparent dynamicity to the setting in FNIRSI, just stupid choice/ready-made library I guess? Also note you can write i2c in consequential manner, even according to the Chinese clone datasheet, no need to give write & register address for each.

Programming does not seem to be their forte 
I have found many stupid things in the 1013D code, for which I doubt ready made libraries were used. Like you wrote it is possible to send data for sequential registers in a single write action. Would mean a bit of a speed up, but does not really matter here though.

My code is a bit of a mess due to the way it all came together and could do with cleanup, restructuring and some bug fixing though.

[donwulff]

Edits galore in the above clock gen configuration post as I keep researching more. I still don't fully understand the register configuration, though I can at least see what the FNIRSI code is trying to do - although it seems at least for the scope part they could indeed do with just a couple of mostly sequential writes, for a code that'd be a pleasure to decompile with Ghidra But I suppose I can just dump the ClockBuilder Pro register file into i2c and hope for the best. Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming. But before that, some emergency work

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  7988MB  7988MB  primary  fat32        lba

Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway?

[pcprogrammer]

Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming.

That is a good idea. Should have thought of it myself 

I have used writing to file to capture al sorts of data during the reverse engineering and development, but also wrote stuff on the screen.

You can make a copy of the firmware backup project and use it to show the serial data. It has all but the serial part in it. Write to file can be done and the display lib is there to do the displaying on screen.

But before that, some emergency work

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  7988MB  7988MB  primary  fat32        lba

Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway?

Is that how the original card was done? I have also had something like that before, that I had to reformat the card to make space for the firmware. Might well have been the one of the 1014D.

[donwulff]

To the credit of pcprogrammer's original code (and schematics), configuring ClockGen over I2C using modified (8 bit address, different pins etc.) code worked fine first try. Only I did a classical copy & paste error, disabling the second clock output when I meant third, leading to some lengthy debugging... After finding that, there's now nice, almost flat scope traces (X1 20uS not so useful though!). The 200MHz is attenuated sine-wave even on my 2.5Gs/s Fluke Scopemeter 225C, but that's to be expected.

The clock generator configuration itself has a few oddities. The Chinese chip seems to be based on the Rev B chip, which goes up to 200MHz, and has datasheet and register description split apart: https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/application-notes/AN619.pdf

However, the ClockBuilder Pro generated register map writes to two registers marked as "Reserved" even in that. The generated dump names them "DIS_RESET_LOLB" (Disable something reset Loss of Lock PLL B? But this doesn't use PLL B) and I2C_ADDR_CTRL - I left both alone for now).

For the 50MHz out, the divider from 800MHz fVCO needs to be 32. That seems like an even integer to me, but the generated register map leaves MS1_INT as 0. Time to try what happens if I set it to 1. The ClockBuilder Pro logic seems indecipherable as it's even relying on the Reserved registers. There's the additional thing that I will most likely have to switch to use different PLL's for each clock, as it sounds the 200MHz clock may need more fine-tuning, which at >112.5 MHz can only be done by adjusting the PLL fVCO multiplier.

From what I can see, the original firmware leaves XTAL Crystal Load capacitance at default 10 pF. I have no idea which crystal the 1014D uses, but looking at available crystals, the vast majority of 25MHz crystals come with load capacitance of 8 pF, and the leads and pins will provide a bit of stray capacitance. AN619 specifies "crystal load capacitance" though, so maybe this should be 8 pF, but default 10 pF seems to just work.

And yes, the original 1014D SD-card had that wacky 32.3kB partition start. I guess making it small would make sense on a really small SD, the documents I think talk about 1G one, but you'd definitely want it aligned to some suitable power of two...

On towards the knob controller interface, though I'll probably stop updating on every small change. I'll stick them on GitHub when I have something useful, though I'm not using NetBeans (or some derived IDE?), and not sure how much it'd be worth it to combine the code. I'll see how much changes I'll have to do the the UI inputs; it might even be mostly just renaming the touchscreen functions to something interface-agnostic.

[pcprogrammer]

Well that is good news.

Yep 200MHz square wave needs a scope with a very high bandwidth to show it as square. My 500MHz Yokogawa DL9705L shows a sine too.

About the crystal, if it works it works, I would say.

Netbeans is just the IDE I'm using. Has no impact on the code. Just add a new directory to your fork of the repository and stick your work in it as a backup. When you have something that is usable as new firmware, I would suggest to make a new repository for it and stick it in there. You can also design your own splash screen    (Or make it work without it)

The touch handling in the firmware is based on detection of touch in one of the defined buttons or dedicated areas, and if it is a menu it will open that menu and use dedicated functions to handle the touch in that. It might not be easy to connect this to the input from the user interface controller. But everything for this is found in the "statemachine" and "scope_functions" files.

[pcprogrammer]

A pointer on something that is different between the 1013D and 1014D is the screen brightness setting in the FPGA. It uses the same command 0x38, but it takes only one byte as setting. 0x78 is full on. Have not looked at the settable range, so needs some experimentation.

Is simple to modify in the "fpga_control.c" file. Look at functions "fpga_set_translated_brightness" and "fpga_set_backlight_brightness".

[donwulff]

The touch handling in the firmware is based on detection of touch in one of the defined buttons or dedicated areas, and if it is a menu it will open that menu and use dedicated functions to handle the touch in that. It might not be easy to connect this to the input from the user interface controller. But everything for this is found in the "statemachine" and "scope_functions" files.

Yeah, touch is by necessity "modal" whereas the buttons are more global in nature. It bugs me because I wouldn't want to re-write the whole UI and then people would have to keep both implementations in synch. Maybe some event-driven model.

Did the same copy-paste (of my own code/defines) error for the serial port, making both Divisor Latch LSB/MSB register same, then writing 0 to MSB...  Something else that was different for 1014D, at least to your custom firmware, is the 1014D stock firmware sets the MCU clock to 576 MHz. This means the Divisor Latch is 4% too large for the 600 MHz clock. With those fixed I got the key values easy, so now I can start raking my head for the way to combine touch & buttons in meaningful way. It sends 0xff to the knob-processor before each read, which I guess works as rudimentary flow-control if it responds only when it receives 0xff. I haven't looked if there's a buffer beyond the FIFO on that side though. But at least all the pieces for programming it are there now.

The "PECOS SCOPE" load-screen is flashing in a weird way, I wonder if that is related to the brightness setting. The main scope screen is fine though, so that's not a problem. Because the speed of booting is one of the strengths of the scope, it might be skipped anyway.

Code: [Select]

1 RUN/STOP
2 AUTO
3 MENU
4 S PIC
5 S WAV
6 H CUR
7 V CUR
8 >
9 ^
10 OK
11 v
12 <
13 SLOW
14 CH1
15 CONF (CH1)
16 CH2
17 CONF (CH2)
18 ORIG
19 MODE
20 EDGE
21 CHX
22 50%
23 F1
24 F2
25 F3
26 F4
27 F5
28 F6
29 GEN
30 NEXT
31 LAST
32 DEL
33 SEE ALL
34 SEL
35 + SEL
36 - SEL
37 + POS (CH1)
38 - POS (CH1)
39 + POS (CH2)
40 - POS (CH2)
41 - POS (ORIG)
42 + POS (ORIG)
43 + LEVEL
44 - LEVEL

49 ON
200 OFF

[pcprogrammer]

The "PECOS SCOPE" load-screen is flashing in a weird way, I wonder if that is related to the brightness setting. The main scope screen is fine though, so that's not a problem. Because the speed of booting is one of the strengths of the scope, it might be skipped anyway.

Yes, that has to do with the brightness setting. By modifying the load screen code to just write 0x38 and then 0x78 to the FPGA instead of 0x38, 0xEA, 0x60 (if not mistaken out the top of my head) it will stop the flickering.

Had the same issue with the firmware backup program.

Good work on getting the commands send from the user interface controller. I wonder why they set the F1C100s to a lower clock then the 1013D. Will be fun to see the 1013D firmware working on the 1014D, but modifying the screen setup might be needed to deal with the function buttons on the right of the screen.

Edit: And there is the AWG of course. There in lies a lot of fun stuff to do, like sweeping to measure filter response.

[pcprogrammer]

I checked the command list with the front panel of my scope, and noticed the three bigger knobs are missing from it.

The channel sensitivities and the time base time per division selector.

The gap between - level and on is not large enough to fit them all, so do they have another set between on and off?

[donwulff]

Oh dang, they don't have label so I missed them.
45 - X CH1
46 + X CH1
47 - Y CH2
48 + Y CH2
49 - GEN (TIME)
50 + GEN (TIME)

The 49 is actually an error, it seems to report random/last encoder position on boot, which will be annoying. Could be sort of weird to have separate code for that, as the scope doesn't technically "see" it, and is physically same button. 200 does show up for the POWER button when it's running (and shuts down about a second after).

I have the plastic knobs off because I'm intending to check under the tin-cans, although AliExpress is having delays even mailing the KAQY214(S) chips, so will be a while until I'll be able to try anything with that... should probably put it back together before I break something.

And yes the AWG is still kind of open book, the scope will work without it though. But I hope I'll be able to find time to play with the AWG/mods and even FPGA. First step is getting it usable with the custom firmware though.

[donwulff]

Various issues, I'm not sure if I'm supposed to ask or just test & debug  Is there easier way to debug the AllWinner chip than just printing out debugs into file/screen?

Sometimes the traces don't come up right on startup (I'll check the initialization order/clocks and also need to get most of the settings bound to buttons so I can see if they still work)

scope_setup_usb_screen() it takes really long for the disk to become accessible (sometimes it fails entirely).

settings the trigger mode makes the scope hang. (Interesting, it runs through the set-up commands but just stops responding after that, need to see if there's some mode-specific code)

Auto setting doesn't really set up triggers or anything, just timescale and voltage I guess (I guess first step is checking if it should, actually I think the trigger isn't displaying correctly).


Well, nobody said it was gonna be easy Just in case there's anything known I need to take into account, though.

I needed some other components too so I went ahead and ordered the scope components from DigiKey as well (Took their last OpAmps, mwahahaa, and they don't have the Chinese KAQY214S's which claim lower on-resistance, just the Philips ones) and checked under the cans to verify I have the same OpAmp as everybody else. Too old to be soldering that fine components though, but I might try! And 125MHz frequency (250MSa/s ) seems to work, although whether it makes any sense will require getting some readings & higher bandwidth.

[pcprogrammer]

For as far as I know it does not have proper debug support, at least nothing that is documented. Have not looked in the ARM documentation if there could be something for it, but if it is there it would require code to work with it I suppose. There are no external connections for it like on newer ARM devices like the STM32 where you have SWD.

About the traces, I vaguely recall an extra FPGA command being used, so it might be needing it at some point. You can search for the fpga_write_cmd function in Ghidra, to see which commands are being send from where in the code.

Strange that the USB code is giving problems. Have not received any feedback on problems with it in the 1013D. With the code on the 1013D and linux mint that I'm using it worked every time I tested it. As a matter of fact, it is also used in the firmware backup code and did not see problems on the 1014D with it either.

It might be that the trigger part is where the 1014D FPGA differs, and needs something extra to make it work.

There is some report about a problem with the auto set function on the 1013D, and it might well be what you are writing about. I'm not sure but believe I set the trigger to 50% when auto set is used.

Indeed nobody will say it is easy, because if it was easy everybody would be doing it 

You state the 125MHz ADC clocking to be working, but how did you achieve that? Did you raise the FPGA main clock from 50MHz to 62.5MHz?

This might cause the timing to fail and result in problems in the data. It will also change the 1KHz calibration signal and the screen brightness control signal frequency, and all the rest that is derived from the main clock.

[donwulff]

It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.

EDIT: Then again, I didn't check into the MCU data acquisition path, maybe the ADC is starting to shift levels & FPGA commands fail at the same time, but the most parsimonious explanation is the FPGA is just hitting its limit.

The mounting delay may be Windows filesystem check because I'm just calling the USB disk function which expects touchscreen to terminate, time to fix that next.

And yeah the trigger mode-setting code seems to go through without hanging, and doesn't hang afterwards either unless the mode is actually changed. It's waiting for trigger indefinitely, isn't it?

Some interesting issues popping up, but yeah I don't have 1013D to test if they happen on it as well, and in some cases I may just be using the existing code wrong. But I'm making progress getting it responsive.

[pcprogrammer]

It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.

The sampling frequency depends on the time per div setting. To do the maximum possible the software needs to be set to 200MSa/s which is the case when time per div is 20ns or 10ns per division.

But not bad that it works with 75MHz main clock.

Since I have both I can do some tests and compare between the two of them. Just write up what to test and make the code available.

[donwulff]

I pushed current work at https://github.com/Donwulff/FNIRSI_1014D_Firmware/tree/PORT_A - it's not at all useful yet, other than getting to experiment with things a bit. (Yeah, I stuck everything into port_a module, and edited the NetBeant Debug makefile directly so NB will overwrite it and miss the new module). I have to focus on other things, and keep breaking the source, so better for me to save a copy now

Also a size comparison of Philips AQY214EHAX SSR relay. SMD model here is larger than the S model, but it could work as the other end isn't over the rest of the components. Cooking components will take a while to arrive, so may look at on resistance then, and possibly circuit simulation.

[pcprogrammer]

Top. I will take a look to see what you have been up to 

About the relays, if they had only looked a bit beyond the length of their nose and used a high speed 4051 analog multiplexer it would have been easy to have more ranges then they have now. The 3 control lines for the relays are unfortunately limited in the FPGA to the allowed range it has now, instead of having the limit in software, otherwise it would have been easier to make the change.

[donwulff]

I should have a look at that multiplexer, though the idea here is just to use the SSR to bypass the front resistor, which according to simulations is filtering the bandwidth... Because of that the on-resistance of the optoisolated SSR relay is pretty crucial, in fact if FNIRSI/whoever didn't account for it correctly, the one bypassing the AC coupling capacitor could be limiting the bandwidth further than they meant. (Also, we have to use optoisolated one there, because it's on the high-voltage size of the front-end). Once again though I'm aware that's not magic, for one thing that will cause higher frequencies to alias into lower ones due to the sample rate, however I want to test oveclocking the FPGA/ADC as well as potential for just getting phase of (known) higher frequency signals. That MAY require switching the OpAmp into the Texas Instruments one, with faster slew rate, and yeah that component's small too...

In the pic the SSR is placed with legs right around the resistor it's supposed to bypass... which I should note, is really small, and I'm not at all confident about successfully soldering that. Another possibility would be placing the SSR at the corner with lots of empty space, but that would mean longer leads with associated noise. I'm not at all sure if placing the component on top of the others is better, but at least the SSR shouldn't cause much noise. If it works, it can be driven by the "special IC" pin, eventually.

It seems the minimum sensitivity of the analog front-end is driven by the standard 1M resistor in the highest sensitivity configuration, so I'm not sure it's possible to push that further with sensible changes. There's been a mention of second op-amp stage somewhere. Note on the bench-top 1014D a separate analog switch for turning on extra circuits isn't entirely out of question, could be pretty indistinguishable from the standard user interface. However completely re-doing the analog front-end is just silly, and not something I particularly understand.


Also the 1014D firmware doesn't do much "useful" right now, I just setup the cock gen & UART and hooked up some of the main buttons I'm experimenting with, barely clobbered up. Trigger Mode currently disabled in the code because it hangs, time-div stops working when moved too far either direction have to figure what's up with that. At least I can select trigger channel, auto-set the settings and switch time-scale to 200Msa/s|500ns/div and get some readings.

4051 multiplexer, data-sheet says it has 125 ohm ON-resistance. Of course, depends where it's used, if you have 1M+ resistor in front might not matter that much. It also seems to have no voltage isolation spec, just ESD. I'm not sure how important it is after the big resistors, but the analog relays are still 220VDC signal/1800VAC isolation, would need separate opto-isolators to be safe and maybe replace frequently. At any case the Chinese are pro's at minimizing components, you can be sure they don't plan for end-user upgrades. Was interesting seeing spot for one unplaced component on the analog front-end though, I wonder what that's for. In any case we're limited by the ADC's, I'm wondering if one could use both ADC's on single signal. FPGA's I've worked with had configurable output delays on signals, so even if there aren't free PLL resources, I'm wondering if it would be theoretically possible. Little point doing highly involved one-off customizations nobody else is likely to use though.

Maintaining high-voltage separation is actually PITA with any modifications to the circuit. I wonder how much isolation the actual chip case offers. Placing the chip on top of others will also bring it closer to the tin-can cover which is connected to ground, and placing it to the empty corner would need passing long leads around the other components. The position displayed might be best spot due to that as well, but the clearances are going to suffer no matter what.

I should've probably looked at the Hantek schematics earlier, though I don't think there's anything that would be useful with the analog front-end already in place in the FNIRSI. I guess https://www.ti.com/product/LMH6702/part-details/LMH6702MFX/NOPB is equivalent of what they're using as buffer OpAmp, so could've looked at that instead (Although DigiKey doesn't have them, AliExpress could send some Chinese clone?). And a differential OpAmp possibly with some gain after that? Can't use that on 1014D of course.

Ah, and so much for attempting to get something else done, hah.

[pcprogrammer]

  I did not read your first post correctly. 

Thought you where on about the big relays and did not notice the extra component you put in 

I'm no expert on analog design at all, but the idea I had at some point was to just cut out the whole front end by slicing the traces to the ADC's and design a small circuit board with a new front end, but it is probably quite a bit of work to get it right and also not an easy setup for others to put in their scopes. Also things might get expensive and buying something better comes in reach quickly.

To me it feels best to just tinker with the software and maybe the FPGA to learn and play.

[Moley]

Hi all,

Sorry if this isn't the right place to post - just looking for purchasing advice.

I'm looking for an upgrade from my multimeter for audio frequency analysis. This scope has become quite cheap in Australia, so I thought I'd pick one up. I've considered similar Hantek models (quite a bit more expensive here), plus all the regular flagships (a LOT more expensive here) - from reading through this thread, I'm excited about the modification possibilities, and also convinced the major drawbacks won't have a significant impact on audible frequencies.

At AU$264 (currently US$181.50, 167 Euro), I just wanted to check this would fit the bill for basic audio circuit analysis. Any advice would be greatly appreciated.

Cheers,
Moley

[pcprogrammer]

Hi Moley,

welcome to the forum.

It depends on what information about your signals you want the scope to display. When it is just measuring on audio circuits to see if they come through as expected it could do the job, but keep in mind that the input sensitivity is not that high. 100mV per division with a 1x probe. (The 50mV per division is software zoom).

About modification possibilities it also depends what you are after. Both hardware and software wise there is room for improvement. The 1013D version (The one without the knobs) has working open source firmware for it and might be cheaper. (See this thread) Hardware is much the same.

[tunk]

No expert, but I think I rather would have an Owon or Hantek handheld.
You could also look into if your PC sound card could do the job.
And if you want to learn about scopes, this may be a good/cheaper starting point:
https://www.eevblog.com/forum/testgear/new-toy()-scope-dso154pro-1ch-claimed-40mss/

[donwulff]

I should probably emphasize in wherever that the FNIRSI (et al.) has terrible sensitivity, and is unsuitable for most signal integrity uses. In keeping with management systems, I like to describe it as "indicator". That said, the ADC is 8-bit ("Effective Number of Bits: 7.5") so in the right range you could have fairly good resolution (like, what can your cables and probes handle anyway?).

Indeed the FNIRSI's strongest point must be the price, and in EU anything which has a price over 150 € before taxes needs to be declared & taxes paid by the buyer (unless the seller holds to their agreement), which adds to the cost & effort. They can also be ran from USB power pack, so whether you're looking for hobbyist scope for limited use, a throwaway for the road, or one for experimenting and programming, it's worth giving a consideration. Just be aware of the limitations. It also seems to be something of a religion with plenty of "Thou shalt not buy a FNIRSI" people, so take that into consideration too

Unless you absolutely need the signal generator or the benchtop form-factor, 1013D may be a better choice, with currently working open firmware. I'm still working on the 1014D firmware, but need to get other things done & been bit under the weather, hopefully I'll have more time next month (Plus some of the components from China still haven't arrived). The firmware modified from @pcprogrammer's 1013D is booting & initializes main devices, but it's not useful quite yet. Signal generator is low priority for me. The stock firmware works well enough though, if one wants to just use it and not experiment with things.

[Postal2]

Hello. I bought FNIRSI-1014D and could not use it because bad. I made some improvements and now I can use it. Need 2 ferrite beads in power section, need switch ground to connectors and take out ac/dc switch. See photo and do accordingly.

[donwulff]

It seems the DC-bypass opto-switches have been intentionally shorted close, on the side of the lighter/khaki AC-coupling capacitor. This will of course take out the ability to AC-couple, but it's a good idea if AC-coupling is needed, because the opto-switch can reduce its frequency-bandwidth (Similar to the idea of the additional switch for reducing the resistance I've yet to try *cough*). The common ground of the probes is improved with a kind of ground-bar; the accompanying instructions of the scope indeed warns the foils between the probes may burn out if grounded to different potentials, so this seems like a great idea as well.

I can't spot the ferrite beads though, do they just go around the incoming USB power leads?




DOS2C10:
In other news I got the Hantek DSO2C10 to compare & see what all the hubbub is about and the price came down a bit. Since it's been pushed on this thread, a few quick notes before I get it for more of a spin. First it took 2 months to arrive, which may be record longest of any orders I've made. In the past I've had to fight with sellers over the customs taxes for items with base cost over 150 EUR, but it seems AliExpress just deducts them from the price, and you have to do the paperwork (Tariff code 90302000 for Oscilloscopes and oscillographs) and pay the taxes yourself.

The scope itself has more plastic feel to me, but that's subjective. Probably due to the heavy ventilation on the case, which also means that avoid dust and moisture, this isn't something to lug around on the field! The Ext Trig/Gen Out connector is indeed soldered on, while the product description gives the impression DSO2C10 model would lack it. According to other posts some other Analog Wave Generator components are NOT populated, it does seem to work for me with just arrived scope. A notable warning is it indeed comes with a single probe, which is odd choice for a dual-channel oscilloscope, so you'll probably just end up having to buy new ones, which adds quite a bit to total cost for comparison purposes. It has two USB ports (Type A and Type B for both client/host), but can only be powered by the AC lead. The scope however now comes with 1.0.3.0.0(230327.00) firmware, and the latest downloadable firmware on Hantek site is 20221028.

The upgrade instructions at https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217 seem to already mention the new firmware, and it turns out using the UPK on that link you don't need to change the firmware at all, just run the UPK to change the model. Multiple UPK's can be on USB at once, just select Utility button, F3 Update, Menu scroll to right UPK, press the scrollbar & then confirm with F3 Update - yeah what a weird sequence. Using the Backup Builder which is hidden at the end of the FAQ before update stuck at 35% and then just rebooted, but the backup appears to be more or less complete.

Edits: Single probe is PP-150 but actually only rated only 100MHz so wouldn't work with full bw anyway, new firmware, latest upgrade instructions.

[gargamel777]

Hello, my first post here.

I just purchased my first scope FNIRSI 1014D. Tested it, works ok.

Then I mistakenly connected 12V barrel  jack to it. Original is powered from 5V, but uses same barrel jack as most 9V -12V equipment. So my mistake and now wouldn't power on. I can hear relay click inside when press power button.

Thank you for any advice, before I break the thing apart?

Rok

[donwulff]

That's quite unfortunate, all of the power regulators and DAC amp https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_Power_Supply.png are connected straight to the 5V bus with no obvious over-voltage protection, as they do warn to use only the 5V supply that comes with it. And the MOSFET switch & diode are rated for 12V+ plus, so there's a good chance of frying a number of the power regulators, at the very least.

I wonder which relay that would be, however, best bet is probably to connect 5V and start measuring which of the regulators are working, though there seem to be other components on harm's way on the LCD path as well. I'm not going to check all of their data-sheets, but some of them could tolerate 12V input at least for a while, but at least the LCD DC-DC converters are strictly 5V input. There's no easy test points and I can't immediately identify the location of all the regulators, and if several components are fried, or shorted, it could quickly get more expensive to repair than get a new one, even if you're good with soldering iron.

[Postal2]

I can't spot the ferrite beads though, do they just go around the incoming USB power leads?

Marked on photo.

It's impossible to use it without those improvements. Absolutely not. May be if you school boy.

[gargamel777]

That's quite unfortunate, all of the power regulators and DAC amp https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1014D/Scope_1014D_Power_Supply.png are connected straight to the 5V bus with no obvious over-voltage protection, as they do warn to use only the 5V supply that comes with it. And the MOSFET switch & diode are rated for 12V+ plus, so there's a good chance of frying a number of the power regulators, at the very least.

I wonder which relay that would be, however, best bet is probably to connect 5V and start measuring which of the regulators are working, though there seem to be other components on harm's way on the LCD path as well. I'm not going to check all of their data-sheets, but some of them could tolerate 12V input at least for a while, but at least the LCD DC-DC converters are strictly 5V input. There's no easy test points and I can't immediately identify the location of all the regulators, and if several components are fried, or shorted, it could quickly get more expensive to repair than get a new one, even if you're good with soldering iron.

Thank you,

It was just the boost driver for the backlight. Wish I knew there was a schematics available online for this scope. But good lesson learning & fixing  without it.

(I'm 1980s electronics guy who moved  soon in 1990s to IT, but somehow ended up fixing marine electrical/electronics  stuff on liveaboards in Indonesia these years :-)

Thanks again. I love this forum.

[zenon]

This oscilloscope has an incredibly poorly designed input attenuator!
For different input sensitivity, the values ​​of different frequencies are totally different!
Has anyone dealt with this problem?
Otherwise, for fun, I made a voltage limiter to possibly protect the device from blowing up if the supply voltage rises. Voltage threshold is somewhere around 5.3V and depends on the zener diode.

[zenon]

Hello!
I was able to adjust the attenuator on this unit to some extent.
Trimmer capacitors are 10-30pF, but it is good to use ones with a smaller value (5-20 or something similar).

[galiy]

Hello! This is input 1014D. These parts burned out. Please tell me the type of these parts, I need to replace them.

@zenon

[Atlan]

https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics

[zenon]

@galiy
10 Ohm

[galiy]

Thaks!

[naiclub]

Anyone know how to fix this? Generator allows you to adjust Amplified or not? In the original, there was very little signal from this point. which does not have sufficient sensitivity to receive

[pcprogrammer]

https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics

Take a look at the schematics. The signal generator is very simple. A resistive (2R-R) network driven by the FPGA and an opamp driver. Output is limited to 3V3.

Any signal amplitude change is done in "software" and reduces the resolution on the output. Not even sure if it is possible to adjust. Never used it.

[naiclub]

https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Schematics

Take a look at the schematics. The signal generator is very simple. A resistive (2R-R) network driven by the FPGA and an opamp driver. Output is limited to 3V3.

Any signal amplitude change is done in "software" and reduces the resolution on the output. Not even sure if it is possible to adjust. Never used it.

Thank you. Where can I add volume? so that we can adjust the amplitude

[pcprogrammer]

Thank you. Where can I add volume? so that we can adjust the amplitude

Easiest would be to add an external amplifier run of a separate power supply.

[naiclub]

Thank you. Where can I add volume? so that we can adjust the amplitude

Easiest would be to add an external amplifier run of a separate power supply.

Thank you. Could you please draw a circuit diagram for me?

[pcprogrammer]

Search the internet. There are plenty examples to be found.

Something like this for instance: https://www.eleccircuit.com/the-signal-amplifiers-can-set-input-and-output-ratio/

[naiclub]

Search the internet. There are plenty examples to be found.

Something like this for instance: https://www.eleccircuit.com/the-signal-amplifiers-can-set-input-and-output-ratio/

Found this clip. Very interesting

[naiclub]

Problems with this scope With very high frequency generators the signal amplitude is greatly reduced. Hardly anything can be measured.

[pcprogrammer]

Yep, FNIRSI lies about the specifications. The scope has a bandwidth of about 30MHz. Max sample rate per channel 200MSa/s. Sample memory less then 4KByte per channel.

[Atlan]

When you measure it, do you have the probe switched to 10?

[naiclub]

Yep, FNIRSI lies about the specifications. The scope has a bandwidth of about 30MHz. Max sample rate per channel 200MSa/s. Sample memory less then 4KByte per channel.

I am very disappointed with the money I paid.

When you measure it, do you have the probe switched to 10?

If you measure this level Can't see the waveform. Must be adjusted to X1 only.

[pcprogrammer]

With the probe set to x1 the bandwidth drops to about 6MHz. It even says so in the manual. The one thing they did not lie about 

[naiclub]

With the probe set to x1 the bandwidth drops to about 6MHz. It even says so in the manual. The one thing they did not lie about 

https://www.eevblog.com/forum/testgear/fnirsi-1014d-function-gen-square-wave/msg5301730/#msg5301730
I want you to read this thread. Can I improve the generator like the owner of this thread?

[bunaziua]

pcprogrammer from europe reverse engineering electronics from china, the circle is now complete 

[bunaziua]

I got the scope recently, needed something portable to find why my car did not want to run.

In my use case I found 2 areas lacking:

1)If you use a wide time band (ex. 100ms per division) it will miss a lot of data. Theoretically it could capture the data (with a supposed 1GSa/s) , but seems like the limitation is in the sample memory (supposedly 240 Kbit). When the trigger hits, the oscilloscope captures 30 time divisions. With one sample supposedly 8 bits, you get 30K samples over 30 divisions, so 1K samples per division. But I really doubt it's 1K samples per division, and I am a beginner with oscilloscopes so not sure if I have correct assumptions. So if you don't know what the frequency of the signal will be, you might miss some important details if you use too wide of a time division.

2) The trigger behavior seems odd. I used a Rigol DS5102CA before, and the trigger was intuitive. With the FNIRSI it seems odd and I didn't use it enough to say what is wrong, but it feels like it's not a good implementation.

What I chose to buy it:
In my area you can't find a good oscilloscope for a decent price. I needed a portable scope, and with all the drawbacks this one is the best option.

If I would be in the North America I would get the Rigol DHO802 for 330$ and not waste my money on the FNIRSI. But I am in eastern europe and the DHO802 is 415 euro, and I have to also add 20% customs VAT (and potentially shipping), so that makes it 500+ euro. So the 130 euro FNIRSI it is.

It's not something you can confidently use if you need it for serious/responsible work (at least that is my opinion), but for a lot of use cases it gets the job done.

[Atlan]

Why didn't you buy the 1013D, it's actually a portable version of the 1014D.

[Harrow]

Hi all, I just joined the FRISNI 1014D club today. Found one for under $200 AUD on eBay, so it will tide me over until the SDS814X makes it to our shores.

I can understand why so many people love to hate it, but I'm already quite fond of it. I understand its limitations, which is why I plan on getting something better, but for what it is, I think it's pretty good. I find the controls and layout quite intuitive, and while it won't be up to scratch for detailed design, it's certainly handy for basic diagnostics and hobby tinkering. I like the idea of being able to take it anywhere and run it off a power pack. I think the trigger level encoder is already playing up a little after two days, lol, but I expected as much at this price level. It will be like owning a Triumph. ;-)

[Atlan]

Hantek is close to this price level, and it can already be called an oscilloscope.

[csuhi17]

I got the scope recently, needed something portable to find why my car did not want to run.

In my use case I found 2 areas lacking:

1)If you use a wide time band (ex. 100ms per division) it will miss a lot of data. Theoretically it could capture the data (with a supposed 1GSa/s) , but seems like the limitation is in the sample memory (supposedly 240 Kbit). When the trigger hits, the oscilloscope captures 30 time divisions. With one sample supposedly 8 bits, you get 30K samples over 30 divisions, so 1K samples per division. But I really doubt it's 1K samples per division, and I am a beginner with oscilloscopes so not sure if I have correct assumptions. So if you don't know what the frequency of the signal will be, you might miss some important details if you use too wide of a time division.

2) The trigger behavior seems odd. I used a Rigol DS5102CA before, and the trigger was intuitive. With the FNIRSI it seems odd and I didn't use it enough to say what is wrong, but it feels like it's not a good implementation.

What I chose to buy it:
In my area you can't find a good oscilloscope for a decent price. I needed a portable scope, and with all the drawbacks this one is the best option.

If I would be in the North America I would get the Rigol DHO802 for 330$ and not waste my money on the FNIRSI. But I am in eastern europe and the DHO802 is 415 euro, and I have to also add 20% customs VAT (and potentially shipping), so that makes it 500+ euro. So the 130 euro FNIRSI it is.

It's not something you can confidently use if you need it for serious/responsible work (at least that is my opinion), but for a lot of use cases it gets the job done.

Are you sure about that? that 1Gs/s is the real sampling?!
Based on tests, the oscilloscope corresponds to a maximum of 30 Mhz.

I tried what you wrote with the 1013D with its factory firmware.
I gave it a 51Khz square signal, with a 100ms time base, then stopped it, then tried to zoom in on it, but it wouldn't let me.
When I set the trigger to Single, the time base was automatically set to 10mS.

I don't know what other people's experience with this device is, but I don't think it will be suitable for what you want.

I quickly tested it with my Micsig.
I can't upload a picture now because I have to go to work, maybe tomorrow if you're interested.
I gave a 51Khz square signal to both.

My Micsig memory is limited to 28k.
The time base is 10ms, because only then does Fnirsi allow me to zoom in on the stopped wave.

The difference between the two waves is heaven and earth.
On my Micsig, the whole wave is continuous, and I have to zoom in even more to see the waveform.
Fnirsin is worthless in comparison.

So does Fnirsi use much less memory?

Maybe you would be better off with a Hantek 1112. Although there are many complaints about that.

[pcprogrammer]

Both the 1013D and 1014D only use a small amount of the available memory in the FPGA to store the samples. In the software it even uses less depending on the time base setting. Only on the shortest times per division does it use both ADC's per channel with the related storage. For the rest of the settings it uses only half the storage space and in the roll mode it only stores a single display.

We are talking max 1500 or 3000 samples per channel.

The 1014D FPGA configuration is for the most part the same as for the 1013D. I almost fully reverse engineered the one for the 1013D and looked at the one for the 1014D to find matching parts.

The basic conclusion is that the design is crap and only ok for simple hobby use. The original firmware polishes the signal to make it look good, but it is utter crap.

The new firmware for the 1013D improves things quite a bit especially now that Atlan took over to tweak things and implement the parts I skipped. Unfortunately for some it can't be used on the 1014D. Efforts on porting it seem to have stopped.

[bunaziua]

Why didn't you buy the 1013D, it's actually a portable version of the 1014D.

I got what was available locally since I didn't want to wait for shipping from china. And I like the knobs more than touch screen, and the fact that you can use it with a power bank instead of a integrated battery that might go bad after some years.

Are you sure about that? that 1Gs/s is the real sampling?!
Based on tests, the oscilloscope corresponds to a maximum of 30 Mhz.

I know that the specs are exaggerated, like usual chinese cheap stuff

I tried what you wrote with the 1013D with its factory firmware.
I gave it a 51Khz square signal, with a 100ms time base, then stopped it, then tried to zoom in on it, but it wouldn't let me.
When I set the trigger to Single, the time base was automatically set to 10mS.

This might be one of the reasons the trigger seemed so bad, will test it later and post the findings.

I quickly tested it with my Micsig.
I can't upload a picture now because I have to go to work, maybe tomorrow if you're interested.
I gave a 51Khz square signal to both.

My Micsig memory is limited to 28k.
The time base is 10ms, because only then does Fnirsi allow me to zoom in on the stopped wave.

The difference between the two waves is heaven and earth.
On my Micsig, the whole wave is continuous, and I have to zoom in even more to see the waveform.
Fnirsin is worthless in comparison.

Haha, I believe you, FNIRSI seems to capture so little data

Maybe you would be better off with a Hantek 1112. Although there are many complaints about that.

The specs look better than the FNIRSI regarding sample memory will look into the Hantek 1112, if it is indeed good.

Both the 1013D and 1014D only use a small amount of the available memory in the FPGA to store the samples. In the software it even uses less depending on the time base setting. Only on the shortest times per division does it use both ADC's per channel with the related storage. For the rest of the settings it uses only half the storage space and in the roll mode it only stores a single display.

We are talking max 1500 or 3000 samples per channel.

The 1014D FPGA configuration is for the most part the same as for the 1013D. I almost fully reverse engineered the one for the 1013D and looked at the one for the 1014D to find matching parts.

The basic conclusion is that the design is crap and only ok for simple hobby use. The original firmware polishes the signal to make it look good, but it is utter crap.

The new firmware for the 1013D improves things quite a bit especially now that Atlan took over to tweak things and implement the parts I skipped. Unfortunately for some it can't be used on the 1014D. Efforts on porting it seem to have stopped.

Thank you for pointing it out. One screen is 14 divisions, so in the worst case it's 1500 samples for 14 divisions = ~100 samples per division (but it feels even lower than that hehe).

[Atlan]

Setting up an oscilloscope that has a touch screen is a joy (not completely because one encoder would be needed), but doing it on an oscilloscope that has buttons and 7 encoders is a punishment.  P.S. CHANGING THE BATTERY is not a problem.

In addition, 1013D allows you to switch between original and alternative software.

[Harrow]

I got what was available locally since I didn't want to wait for shipping from china. And I like the knobs more than touch screen, and the fact that you can use it with a power bank instead of an integrated battery that might go bad after some years.

I also prefer knobs instead of touch screens, and external battery power.

[Postal2]

I quickly tested it with my Micsig.

Micsig is good, I have it. I made it's screen dirty with hands and hole in screen with iron before I buy 1014D. Now Micsig in safe place, but only one time I played with it because HF trace of printboard searching was needed and high sensitivity was needed for this. All other works I proceed with 1014D perfectly (phase delay between two signals of 24MHz etc.).
By the way, Micsig complected with poor power adapter, need change. HF pulses from adapter cannot be filtered without change it.

[thomasx]

So I was offered a second hand Fnirsi 1014D at what seemed to be a reasonable price.

But having browsed a few posts in this thread, the recommendation seems to be: STAY AWAY FROM FNIRSI.

[Harrow]

What do you want to use it for? If you can get one for under $100 and you just want to do a little tinkering with audio frequencies, but otherwise wouldn't be buying a scope, then it might be all you need. But if you are even just a half-serious hobbyist, it really is kind of a toy. Having said that, it works and it's very easy to use. I'm quite fond of its simplicity and I've already had a lot of fun with it. I lend mine to my friend's son without needing to worry about it too much, but after just a few weeks, I'm now ordering a 'real' scope.

[thomasx]

My impression is that any entry level Rigol or Siglent is way better than this, at more or less the same cost, and way better value for money.

[csuhi17]

Even a Hantek is better than this...

[Aldo22]

Even a Hantek is better than this...

I had also looked at this Fnirsi 1014D and found the 50mV/div disturbing and therefore did not pursue it any further.
With the Hantek DSO2C10 I can still measure frequencies at e.g. 230µV RMS (attachment). If I see things correctly, the Fnirsi can't even dream of that.
The Hantek certainly does not reach the quality of Rigol or Siglent, but they are more expensive.
For the same price as this Fnirsi (I bought the Hantek for $130) it is much more powerful, I think.

[csuhi17]

I had also looked at this Fnirsi 1014D and found the 50mV/div disturbing and therefore did not pursue it any further.
With the Hantek DSO2C10 I can still measure frequencies at e.g. 230µV RMS (attachment). If I see things correctly, the Fnirsi can't even dream of that.
The Hantek certainly does not reach the quality of Rigol or Siglent, but they are more expensive.
For the same price as this Fnirsi (I bought the Hantek for $130) it is much more powerful, I think.

As far as I know, the 10x position of the probe is 50mV.
5mV in 1x position.
Yes, that's why I recommended Hantek to several people, but it turned out afterwards that it has a lot of bugs, I don't have such a scope and I didn't really look into it, so I don't know exactly what they're complaining about.

[Aldo22]

As far as I know, the 10x position of the probe is 50mV.
5mV in 1x position.

I don't think so.
It is the official specification. Why would they write 50mV when it's 5mV?
That would be a marketing disaster.

Yes, that's why I recommended Hantek to several people, but it turned out afterwards that it has a lot of bugs, I don't have such a scope and I didn't really look into it, so I don't know exactly what they're complaining about.

I have a Hantek and it's good enough for me so far.
After the last FW update a month ago, I haven't had a single crash.

The trick with the Hantek is to be careful not to pay too much for it. Unfortunately the prices vary a lot.
For example, Hantek France sells them for €347 VAT included.
You shouldn't pay that much! That is ridiculous. 
I wouldn't pay much more than $150 for a DSO2C10 and I would only recommend the DSO2C10, because the more expensive versions are all technically the same afaik.

But for the comparable price, it's imo generally a better tool than the Fnirsi 1014D.

[tunk]

IIRC and if it's like the 1013D, then the 50mV/div is in software
only, in hardware it's 100mV/div (or 1V/div with a 10x probe).

[pcprogrammer]

IIRC and if it's like the 1013D, then the 50mV/div is in software
only, in hardware it's 100mV/div (or 1V/div with a 10x probe).

That is correct.

A small downside of the Hantek is that it comes with only one probe. 

As many on this forum already stated, it is better to save up our money and buy a Siglent or Rigol scope. Much better scopes for not that much more money.

I have a line up of these cheap scopes and hardly use them. Sometimes the Hantek because it starts quicker than the Rigol, but only for very simple checks on easy to scope signals.

Had fun with the FNIRSI's doing the reverse engineering, so feel I got my moneys worth, but that is it. 

[Aldo22]

As many on this forum already stated, it is better to save up our money and buy a Siglent or Rigol scope. Much better scopes for not that much more money.

But you can't compare these.
Maybe it depends on where you live, but for me a Rigol DHO802 from Batronix would cost me CHF 430 delivered (2Ch, 70Mhz).
I paid CHF 126.70 for the Hantek (2Ch, 100Mhz).
That's not just a little less, it's a completely different price range and decision.
And not everyone always needs the latest, greatest features etc.
The Hantek is enough for me at the moment. Maybe in 5 years I'll buy a Rigol or Siglent. Let's see what's all the rage then.