DANIU ADS5012H 100MHz 500 Ms/s portable scope for $80 USD ??

[amspire]

Alex.

I just noticed the new thread. Looks like you have identified the A/D.

[dave j]

There is no hardware trigger, so we'll have to see what can be done there.

Might they be using the MCU's ADCs for a sort of low resolution trigger? e.g. The MCU samples using its internal ADCs at, say, 10MSps with the ADC analog watchdogs triggering an interrupt that is used to start the external ADC sampling at 250MSps. It would explain the trigger being off the left of the trace in single mode and the trace being jittery in normal mode.

If it is, some replacement firmware could start capturing the external ADC into a circular buffer and use the internal ADC analog watchdog interrupt to time stopping new captures and give a rough idea where in the captured data to start looking for the real trigger location.

[ataradov]

Might they be using the MCU's ADCs for a sort of low resolution trigger?

No, you can see entire pinout in my reveres engineering thread. This will not work anyway, since you need to have high speed ADC going to capture the pre-trigger signal.

And internal ADC had maximum sampling rate of 4.4 MSPS at 6-bit resolution. But it is not connected to the input signal, so it does not matter.

I believe there is a possibility for reading every sample for trigger detection may be at 25 MSPS or may be a bit more. After his, there will be windows of inactivity.
I don't think they tried to optimize very hard the capture process. With open firmware and ability to make incremental progress.

I do not have a good understanding of the GD hardware to gauge its performance without trying first. I will make a simple breakout board so I could play with the device without the rest of the scope.

I would rather move those internal details into reverse engineering thread.

[ataradov]

There is an isolated fet switch across the input capacitor to switch between AC and DC coupling. 4 relays and 3 optocouplers for the range switching.

You have an older board. New one has only one relay.

The USB connector is connected through to the microcontroller so USB programming may be possible. I haven't looked to see which micro pins are connected to the USB. I will try and get photos of both sides of the board posted in the next day.

It is connected to the programming pins. No chance of getting USB without a board mod.

[LeonR]

Just found out about that little scope today while browsing for what's new on those "brands" like DANIU, Aneng, etc. and a question popped up: Does anyone know who is the OEM/ODM for those? Aliexpress have a ton of results for "5012H", with a lot of non-branded ones alongside other smaller "brands".

[ataradov]

From what I can tell FNIRSI is the original one, at least they do design some of the stuff they sell. But I'm not 100% confident. There are no markings of any sort on the PCB.

[LeonR]

Looks like it's quite nice for the price. As of today, they're going for 69 USD at Banggood.

[ataradov]

Looks like it's quite nice for the price. As of today, they're going for 69 USD at Banggood.

FNIRSI official store also sells them for $70 on AliExpress.

[amspire]

The USB connector is connected through to the microcontroller so USB programming may be possible. I haven't looked to see which micro pins are connected to the USB. I will try and get photos of both sides of the board posted in the next day.

It is connected to the programming pins. No chance of getting USB without a board mod.

If a mod has to be done, my preference would be to add an isolated serial connection.

This will never be a great oscilloscope, but it could be very useful for using as an isolated scope for repetitive signals. I am guessing it will never be able to capture a huge number of samples in a single sweep.

Pity to hear that the processor cannot be reprogrammed, but replacing it with a new chip is not a massive problem. I am willing to give it a go.

Richard.

[cliffyk]

I got mine last Friday from Amazon; it was $79.98 with free 2-day shipping for Prime members. And as it is a "fulfilled by Amazon" item returning it for a full no questions asked refund is a simple as saying "I don't like it" and dropping it off at UPS--that's where mine is going tomorrow as it's triggered sweep modes (both "Single" and "Normal") are worthless--let me illustrate:

I set up my DDS signal generator to produce a chain of bursts of 10 cycles of a 10 kHz pulse wave, one burst each 500 ms. Displayed on my Hantek DSO 1062B (a fine instrument BTW) in "Normal" triggered mode it looked like this:



Applying that same signal to the 5012H produced this result (I apologise for the shaky image, that's what happens when you're 72 and you last stroke (#2 for me) was just 4 months ago):




Note that although the trigger fires, only the last 4 to 6 cycles of the burst are captured/displayed. This indicates to me that the start of signal acquisition or display is delayed, and is occurring some 400 to 600 μs after the trigger fires.

A 1 or 2 cycle burst fires the trigger but none of the waveform is displayed--this makes the instrument worthless for serious diagnosis of nearly any 21st Century device where aperiodic signals are the norm. The trigger will fire and if you are lucky some part of the active waveform's tail-end might be captured. But if you are looking for a single 200 μs pulse you will never see it.

It's as though a fixed delayed sweep is incorporated into the 'scopes hardware or software--it might be something inherent in the design.

So, mine goes back tomorrow (free return shipping for Prime members), and Amazon will issue a refund to your credit card within 30 to 50 minutes of UPS scanning the return label--i really wanted to like this cutie, however until they resolve these triggering issues it's JATO (Just Another Toy Oscilloscope).

A final note, my other toy 'scope--a FNIRSI ADS 2050H (what is it with this "H" stuff, revision 9?) [5 MHz, 20Msps] does this to some extent but only sporadically, and then just a 100 μs or so delay.

[ataradov]

Forget about the single event trigger on this scope. There is none. It just does the capture at a random time and then looks for the trigger condition in the data. If the acquisition happened to start in the middle of the pack, then you will get a trigger on a random pulse.

I have some ideas how this can be rectified to a certain extent in the modified firmware, but that will take some experimentation and will never work perfectly on higher sampling rates.

[cliffyk]

You guys know a lot more about these MCU systems than I am ever likely to (I cut my teeth on "mini-computers" (DEC PDP 8s and 11s, that were the size of a commercial washing machine--we used forklifts to deliver them).

I was surprised to see that the trigger seems to fire on the 1st pulse, but the acquisition is delayed by the 400 to 600 μs. If I feed it a 1, 2 or 3 cycle "burst" of the 10 kHz square wave the trigger fires but nothing is displayed?

[ataradov]

Try different trigger modes. See if AUTO makes it better (TRIG button to cycle modes). There you would see a trigger point and you should be able to move it around.

[ataradov]

Actually yes, this does appear to be a bug. I can reproduce it on my unit. It triggers pretty well, but the trigger point is moved to the left.

Single and normal trigger modes are affected.

More so the reason for a new firmware.

[cliffyk]

Here's what it looks like in "Auto" quite odd--it appears to support your conjecture that "it just does the capture at a random time and then looks for the trigger condition in the data.":

[ataradov]

Well, no what you see in single and normal modes is a bug. There is no way around it. It is far too consistent, It clearly captures the signal correctly and then displays it wrong.

So it does have a random capture window, but with those settings it can capture your signal in the window consistently. It just fails to display it.

[cliffyk]

Is it possible that in "Auto" mode with a repetitive signal the cycle displayed as that that triggered the sweep is not actually the one that did, which was rather a rather a cycle earlier in the capture and then the displayed waveform is displaced so as to display the "trigger point" of some cycle as the trigger point?

With a repetitive periodic wave it really doesn't matter that you observe the very same cycle that fired the trigger or some other one--they are all the same...

   

[ataradov]

I tested with UART and typed different symbols. It definitely triggers on and shows the right signal, just with some horizontal offset.

[cliffyk]

Well, mine goes back tomorrow which will make SWMBO happy, she says I have too many "line machines" anyway:

My workshop:

[amspire]

I tested with UART and typed different symbols. It definitely triggers on and shows the right signal, just with some horizontal offset.

[dave j]

I was surprised to see that the trigger seems to fire on the 1st pulse, but the acquisition is delayed by the 400 to 600 μs. If I feed it a 1, 2 or 3 cycle "burst" of the 10 kHz square wave the trigger fires but nothing is displayed?

What happens if you try to capture a single pulse or single short cycle burst? (Not one repeated periodically, just one pulse/burst.) Can it trigger on that reliably even if it doesn't show it? What about a single pulse that is long, say 500ms?

Speculation: In one shot mode the CPU repeatedly reads the incoming sample from the GPIO, comparing it to the trigger level. When a new sample crosses the trigger level compared to the previous one it knows a trigger has occurred and starts a DMA transfer (which it needs for speed) to do the capture. The problem with this is that the CPU isn't fast enough to check all the samples and can miss short pulses. The reason it triggers with long bursts of pulses is it is actually triggering on one of the later ones.

[cliffyk]

It does not trigger reliably at all , on any signal I've fed it, in either the "Single" or "Normal" mode. In fact it was playing with it on known signals from my 2013 Infiniti m37 that first alerted me to the triggering irregularities; when it captured nothing or just a portion of what I had expected to see. This is what led me to devise the definitive test I documented above.

For me any further mucking about with this otherwise painfully cute little bugger--so as to possibly determine what signal forms/frequencies it might trigger on properly and reliably--serves no purpose as I bought it to be a diagnostic tool--NOT a tool to be diagnosed .

As it is it will not function for any serious diagnostic purpose other than to determine if a circuit that it supposed to be carrying a repetitive periodic chain of squiggly lines does indeed have those squiggly lines.

Dropped it off at UPS an hour ago, Amazon has already issued the refund to my VISA! 

[dave j]

For me any further mucking about with this otherwise painfully cute little bugger--so as to possibly determine what signal forms/frequencies it might trigger on properly and reliably--serves no purpose as I bought it to be a diagnostic tool--NOT a tool to be diagnosed .

That's fair enough, it's completely understandable why you've sent it back.

My suggested tests were aimed at trying to figure out why it doesn't work as that may help Alex in his attempts to produce alternative firmware. Someone who still has a device might like to try them.

[ataradov]

Speculation: In one shot mode the CPU repeatedly reads the incoming sample from the GPIO, comparing it to the trigger level. When a new sample crosses the trigger level compared to the previous one it knows a trigger has occurred and starts a DMA transfer (which it needs for speed) to do the capture. The problem with this is that the CPU isn't fast enough to check all the samples and can miss short pulses. The reason it triggers with long bursts of pulses is it is actually triggering on one of the later ones.

I tried with UART and single byte "bursts". It reliably captures each byte. It also reliably shifts it to the left. It just has horizontal trigger position screwed up in those modes.

From the ADC capture behavior I observed on the scope, it simply enabled the ADC, captures the block of data, processes it, captures the next one. There is no way all my pressed bytes fell on the capture edge. So it must be a real bug. It is way too reproducible.

To be fair, I did buy a toy to modify. It is basically a nice kit for a handheld device. I had zero expectations of it being useful out of the box. And for that, it is an excellent device. I wish they did not lock the MCU or sold the units without any firmware in them.

[cliffyk]

My grandson just put forth that is was an oscilloscope simulator...