Reverse engineering FNIRSI-5012H

[ataradov]

Would LCSC has a dispute process if the shipment never shows up?

No idea. I never had issues with them.

I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.

That's going to be A LOT of work. It would be easier to start from scratch rather than alter that code to use internal ADC.

Do we know how many time/machine cycles we need to start up a scan on  GD32F407?  If we have some form of delay line we may start the scanning after an interrupt fires off.  How much delay we would need on such delay line?  In that case we can perform more detail time consuming processing after stocking up sufiicient number, say a few thousands, of scans since the VGs have an extra 512KB for data assuming it is fast enough for DMA...

I'm not sure what you mean here. VGs have more flash, not SRAM.

[Martinn]

My GD32 arrived very quickly from LCSC, that was before corona. But most passenger flights are now shut down and air freight that was transported along with these flights is grounded. Air shipping costs have risen up to 10x I have read.
If you are looking for a backup for the hot air station, you could use the chip quik alloy.

[robca]

I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.

That's going to be A LOT of work. It would be easier to start from scratch rather than alter that code to use internal ADC.

Agree. There already are quite a few STM32F407 internal ADC oscilloscope projects that can be found with a quick Google search (e.g. http://dso.naftilos76.com/dl/tutorial.pdf). The ocde for those is available, and changing the screen driver and buttons to map the device you have seems a better option. Out of curiosity (I'm following this project but don' t have the hardware), how hard would it be to re-route the analog input signal to the main CPU? That also seems gnarly and require cutting traces and adding bodge wire, as far as I can tell

[ataradov]

how hard would it be to re-route the analog input signal to the main CPU? That also seems gnarly and require cutting traces and adding bodge wire, as far as I can tell

It would definitively require cutting traces. There are not too many free pins left. I don't know if one of them has ADC function. I think one of the ADC data pins would have to be cut and routed to the buffer opamp.

But I really see no point in doing that.

[wasp09]

LCSC said they would check.  Tracking showed FD32's were leaving for Toronto on March 1 but have not showed up in Canadian Customs yet.   That is my first LSCS order.

STM development board had passed through Customs.  Last epacket took almost a month from west to east after clearing customs in B.C before that it used to take only a few days.   

Second hot air gun just showed up on tracking 20 days after order.  It is supposed to be shipped via epacket but really via 4PX instead.   

Probably would be a while before I can do anything on my 5012H.   

If my 5012H resets or freezes after everything is ready.  That gives me a good reason to tear it down. 

You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.  That is probably true.  I haven't looked at the instruction set yet.  I'll look into how much ram we need when my STM32F407 arrives. 

Thanks.

[ataradov]

You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.

Flash is VERY slow and has limited number of write cycles.

[mikerj]

You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.  That is probably true.  I haven't looked at the instruction set yet.  I'll look into how much ram we need when my STM32F407 arrives. 

Thanks.

You could use flash to store a waveform after it's been captured, but you couldn't possibly store directly to flash during a capture.  This is something you could do for a datalogger with a few samples per second, not for 100+ MS/s.

[wasp09]

Still no tracking update on my order of FD32F407's since March 1.  It is stuck in China somewhere.  Got a refund from LCSC today.  Even the STM32F407 development board hasn't showed up.  That one passed Canadian Customs March 11 and had an experted delivery of March 17.   My hot air station has not reached Canadian air space either.   Hence I won't be able to experiment on the 5012H any time soon. 

I did receive my ebay order of Si5351A breakout board and be able to test the 5012H with sinewave from 8K to over 100MHz. That works better than my old sign gen from the 70s. 

The front end of my 5012H sucks but is still able to show a sinewave up to around 100MHz if we aren't serious about the ampitude reading.  The 3dB point is way way below 100MHz.   

My 5012H restarts/hangs even with no probe connected on changing input gain or timebase.   To workaround that I have to put trigger in normal mode while changing gain or timebase and then put it back to auto trigger.  If the waveform is too complicated, it may also restarts/hangs on pressing the auto button.   

That may have something to do with the auto process.      You did not notice this issue as you probably swapped out the MCU right away.    However nobody else hit that is a bit strang  Perhaps I got a lemon after all, something like my 5012H is abnormally noisy.     Nothing works out so far. 

[ataradov]

Yes, it is probably not the best time for reliable shipping.

It would show something for a 100 MHz signal, of course. But there is no real point. All it really tells you that there is "something" on the input.

I personally have not run it nearly enough to tell if stock firmware has issues. I probably used it for less than 30 minutes before it became clear that it is a joke. But in that time I have not seen any locking up issues.

How noisy it actually is? Do you have pictures for a shorted input?

[wasp09]

I think it is the signal/noise it picks up during gain or timebase switch.  With no probe connected, sometimes it shows a big step on the screen when pressing the arrow buttons.  Grounding the input did not help.

On reset, it just blanks and then shows the start up screen.  When it hangs, usually nothing special on screen before freezes.   I can't realy tell what happens by reading the screen.

With probe connected, touching the tip with my finger to pick up some noise, it often hangs/reset when I press the auto button.    If the input is simple repetative, auto survives. 

It seems like the MCU hits some errors when working hard or takes too long that a watchdog kicks in.  Change gain/timebase manually or automatically may make the MCU work too hard.

[wasp09]

Vidioes would be too big for the forum.   Happened to be frozen with the ripple displayed.  I took the picture.

Input was grounded with probe set to x1.  Usually the input gain setting does not matter, the noise picked up would not increase with higher gain setting.  Actually it is less likely to freeze or reset with input set at the maximum gain. 

The worst zone is around 100ns to 200ns time base. On a bad day like today, it hangs/restarts almost everytime stepping 100/200ns timebase.  You would see it ripples at 100ns or 200ns with no input.  Sometimes it picks up a pulse of several ns with timebase set at 6ns, but usually it is clean.    I tried putting the whole thing inside an antistatic bag, it does not help.  The noise is somewhat internal.    You mentioned that the unit is overclocked perhaps mine isn't capable in overclocking.  The crystal on mine is running at 20MHz.   

On a good day, it does not freezes/restarts that ofen.  Let me try putting it in a fidge to see if lowering its temperture helps.  Currently my 5012H can only operate reliably as a low Mhz scope. 

BTW, nothing arrives.  Aliexpress refunded the STM32F407 development board as well. 

[ataradov]

Yes, this looks like overclocking is not working our so well. I don't remember it being that noisy. But the fact that it does not change with gain, means that it is added before the ADC after all the input dividers.

I'm not sure if locking and noise are related.

[serniko97]

Hi, I'm new to the forum.
I read all the thread and the GitHub repository as well.

I think that what you are doing is amazing but, at least to me, it's not clear what are the benefit of your firmware over the original at this point of the work and what would be in the future.

Often on GitHub for beta projects there is a checklist of features that have been added and what comes next. Something like this would be extremely helpful.

I love your work, keep it up

[ataradov]

It is better because it at least does not have a single shot trigger bug, which makes the original unusable for a lot of cases.

I have no significant work planned for this. I've allocated as much time as I can at this time. I need to work on other things too.

I'm also not very happy with the quality of the hardware, so without redesigning the hardware, there is very little point in working on the software. For this kind of device the hardware must be much simpler.

For now one significant benefit over the original firmware is that you can actually add your own code, if you are so inclined.

[wasp09]

Lowering the temperature of 5012H did not help.  It still locked up or reset after putting it in a ridge for several hours.   

My hot air gun finally arrived today, 36 days after the 2nd order.  Heating the 5012H up seemed making it more stable for a while.  I amost thought the issue was fixed, but it's not.

Now it was consistent in locking up or reset when we put the input at the lowest gain 2 settings i.e. 5V and 10V (x1) at timebase at 50ns or shorter.  If it did not lockup or reset, the 10V range sometimes picked up a few cycles of sinewave of around 62MHz at 6ns timebase. 

With no probe connected or with probe connected and grounded at x1 or x10 did not make any difference.  The amptitude of the sinewave was way too high to be coming from the probe. 

If we used a higher gain setting, 2V or above, including 100mV and 50mV, 5012H survived all timebase setting including 6ns and did not pick up the 62MHz noise.  This is the reverse of what we expected if the noise is coming from the input.

It suggests there may be a noisy grounding in the front end since in 5V/10V settings the input to the amplier sitting in front of the ADCs would be closer to ground Or there may be something wrong with switches themselves.   The input switches seem OK at DC with lower speed timebase.    Then with this "wetting" of -8V on the probe, I found that the 5V and 10V gain setting could survive the 6ns timebase.   The 5012H uses optical couplers, would a photo transister work correctly as a simple high frequency switch before saturation, i.e. without any "wetting"?   In the good old rotary selectors, we don't have to worry about that.   We have more relays in the older version, now we cut it down to one....

Anyway the 5012H front end sucks.  Even at DC I can tell that the probe isn't giving me 1/10 reading on 10x. 

I remember seeing a circuit drawing of the input attenuators/selectors. Do you know which page is it on?  I'll troubleshoot the 5V and 10V switches.  Don't have another scope capable at 6ns range, but I can do some bypassing.   
 
Lockup/reset on my 5012H may be a firmware bug or hardware related.  It seems to happen on handling more complex and higher frequency waveform.   The 62MHz noise picked up is not a continuous sinewave, its harmonics may be out of range.  I guess that noise is driving the firmware/hardware nuts more often than showing up on the display.

 

[ataradov]

Front-end schematic is here https://github.com/ataradov/open-5012h/blob/master/doc/frontend.jpg

I've been using this scope some more due to working from home and being lazy to pull out the real scope for small tasks. I kind of like the form factor, but I'm thinking of completely redoing the front end to a more fixed design within the same board layout. Something that would only expect 10X probe and will only accept -1 V to +1 V range or even smaller, but in a single vertical setting. It will hopefully  make tuning it much easier. And it is only suitable for microcontroller debugging type use anyway, so there is no particular need for super wide range.

[wasp09]

Ah there it is.   Thanks.

The scope input is really "grounded" via the refenence.   That may be why you warned about using the scrope while charging.

After my last post, I aso noticed shifting the baseline down in auto mode stabilized the 5V and 10V mode such that they survived 6ns. 

Since reference is controlled via ADC.  That strange behaviour actually makes sense.  The effect of shifting the base line is similair to applying "wetting" externally.   Actually I found the noise shifting from one voltage range to another by changing the vertical position of the baseline. 

It suggests that my 5012H probably has a noisy reference.   

Not sure if I can do a lot about it, because when we hit the auto button in auto mode, it centers the baseline as well as changes the input range during the auto process.  If we stabilize reference too much, the auto button may not work.   

Changing the input range and reference during the auto process is a dangerous move.  If it hits something non-linear, the process may not converage.   If it blows up on time or value the unit may lockup or reset.    The optical switches could be non-linear during switchng before they saturate. 

Anyway that is a theory,  but I have at least a workaround now.   Just shift the baseline down first if it locks up or resets.

I won't do anything too drastric as none of my FD/STM32F407 orders show up.    I still hope they would.

Take care and stay happy.

[wasp09]

When lowering the baseline is better, it may mean the more current we draw from the DAC makes it noiser... 

[wasp09]

Just like to mention that the USB cable came with 5012H isn't a regular usb cable.  I could not use that cable to connect my STM32F407 development board to my computer. 

BTW I ordered the cheapest DIYmore STM32F407 development boad that just extends the SMD pins out with minimum add-ons for power supply and clock generation.    There is a microSD connector but no USBserial chip.   When it arrived 3 months after ordering, it turned out worse than expected.  It has a STM32F407VET6 instead of the STM32F407VGT6 shown on the description and reviews... 

I need usb support trying to do hello world as there isn't a display.  It's harder to find projects for this bare board than arduino.  Finally I found a port of miropython.  While I was trying to uploading the build via ST-link, it turned out that the STM32F407 bootloader actually supports uploading via usb by emulating a DFU device.   Took me a while to figure out how boot1 and boot2 pins work.  Both are pulled high on that board, I need a jumper, not supplied with the board for uploading and normal operation. 

I totally agree with you, triggering on the 5012H stock firmware is miserable.   Even auto triggering has problems handling petty slow repeatitive waveform generated by DueArbitraryWaveformGenerator on the due. 

If you are sure that we cannot erase the stock firmware, I'll swap out the GD32F407... eventually when I have confidence with my heat gun. 

I wonder if PA11 and PA12 are available on the 5012H for an usb connector.    That would be useful for data transfer (and FW uploading if we untie bootx or force it to bootloader via software.)

Cheers.

[ataradov]

The cable that comes with it is a power-only cable. This is pretty typical for this kind of devices.

There is no obvious way to erase the firmware. I don't think there will be one found.

PA11 and PA12 are available, but realistically there is no need for data transfer. Firmware update is a more useful case.

[rigol52]

Source code is now available here https://github.com/ataradov/open-5012h

I've recently got FNIRSI-5012H, and it is a very neat device. Once again, I would not use it as a primary scope, but it is a nice addition to the multimeter.
It has a fast boot time and, finally, sane and intuitive controls from the keyboard.

Great effort Ataradov. Thank you.

I hope producer will follow you on  sensitivity battle field.

Tablet Scope FNIRSI 1013D vertical sensitivity of 50mV/div is really unacceptable poor.

Par example competitor Micsig last tablet model Micsig STO1152C Plus has 100 times better vertical sensitivity of 0.5mV/div.

Even micro toy DSO112A has better vertical sensitivity of 2mV/div.

One more thing that need to be improved.

[thinkfat]

I'd not call the Micsig a competitor They're in a different class, price and everything... It's 100x better but also 100x 5x more expensive...

[Vovk_Z]

Par example competitor Micsig last tablet model Micsig STO1152C Plus has 100 times better vertical sensitivity of 0.5mV/div.

I'm not sure STO1152 is a competitor because it costs about $400  or more.

[rigol52]

 They're in a different class .........It's 100x better but also 100x 5x more expensive...

Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.

[mikerj]

 They're in a different class .........It's 100x better but also 100x 5x more expensive...

Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.

I agree the vertical sensitivity is poor, but you are missing the point, the STO1152 is not a competitor.