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

[snoopy]

Does anyone know anything about this ? Can't actually see a working unit. Just something from Solidworks. You know what they say, if it looks to good to be true....

DANIU ADS5012H Digital 2.4-inch IPS Screen Anti-burn Oscilloscope 500MS/s Sampling Rate 100MHz Analog Bandwidth Support Waveform Storage and Built-in Large 5000mah Capacity Lithium Battery

https://www.banggood.com/DANIU-ADS5012H-Digital-2_4-inch-IPS-Screen-Anti-burn-Oscilloscope-500MSs-Sampling-Rate-100MHz-Analog-Bandwidth-Support-Waveform-Storage-and-Built-in-Large-5000mah-Capacity-Lithium-Battery-p-1469066.html

Description:
 
The ADS5012H is a versatile, highly practical, cost-effective handheld oscilloscope for the maintenance industry and the R&D industry with AARONTEK's real-time sampling rate of up to 500MS/s and 100MHz analog bandwidth.With full trigger function (single, normal, automatic), it can be used freely for both periodic analog signals and non-periodic digital signals. The built-in high voltage protection module can withstand up to 400V continuous voltage and 600V peak voltage. There is no need to worry about the oscilloscope burnout caused by the high voltage not being probed to the 10X position.Large time base scan mode that monitors slow level changes. Equipped with high-efficiency one-button AUTO, the measured waveform can be displayed without complicated adjustment. Display high-definition LCD screen with 2.4-inch 320*240 resolution IPS full-vision technology, the visual effect is very good. Extremely convenient and fast waveform storage function, built-in 64M storage space, can store up to 2000 waveform pictures, the storage process is simple and fast, save the current waveform anytime and anywhere, just one touch, no cumbersome tips and choices. Powerful waveform file manager, support for thumbnail browsing, viewing, detail viewing, page turning, deletion and more. Built-in 5000mah high-quality lithium battery, can be used continuously for 12 hours when fully charged.The body is equipped with high-quality silicone protective cover, non-toxic and lead-free environmental protection, anti-skid, anti-shock and shockproof, comprehensive protection of the fuselage, soft texture, feel very comfortable.

Key Features:
 
1:Intelligent anti-burn,1X Can withstand up to 600V withstand voltage
2:Afterglow display technology
3:2.4 inch color display screen with IPS technology
4:100MHz analog bandwidth @ 500MS/s sampling rate(1X = 5MHz,10X = 100MHz)
5:One-button waveform storage
6:Built-in 64M storage space, the maximum storage of 2000 waveform pictures
7:Powerful waveform file manager, support thumbnail browsing, viewing, details view, flip, delete and other functions
8:High measurement voltage range, 1X can measure 0 ~ 80 V, 10X can measure 0 ~ 800V
9:Up to 12 parameters measurement:VPP,VP,Vmax,Vmin,Vavg,Vrms,Frequent,Duty+,Duty-,Time+,Time-,Time
10:At any time, the waveform display (pause function) is frozen
11:Equipped with high efficiency One-button AUTO
12:Complete triggering function (single, normal, automatic)
13:Built in 5000mAh rechargeable lithium battery,Fully charged for 12 hours of continuous use
14:Screen brightness adjustment
15:Memory compression technology, waveform refresh screen does not flicker
16:Anti-slip anti-drop silicone sleeve
17:Ultra small volume, easy to carry
 
Specifications:
 
1:Analog band width: 100MHz
2:Maximum real time sampling rate: 500MS/s
3:Vertical sensitivity: 50 mV/div ~ 100 V/div
4:Horizontal time base range: 50S/div ~ 6nS/div
5:Maximum test voltage: 80 V (1X probe), 800 V (10X probe)
6:Storage depth: 128KB
7:Input resistance: 1M
8:ADC precision: 8bits
9:Coupling mode: AC/DC
10:Trigger mode: Single, Normal, Auto
11:Trigger edge: Ascending/descending edge
12:External trigger voltage 0 – 80 V
13:Display: 2.4 inch - 320*240 - IPS process
14:Power supply: 5000 mAh lithium battery
15:Size: 114mm x 74mm x 33mm
16:Weight: 300g

[Kosmic]

Found some pictures on aliexpress

[snoopy]

Found some pictures on aliexpress

Wow, that's cheaper than I expected.

So this is an ETS scope made with STM32 ADC, analog switches and an CPLD delay line???

That's SMART!

It says real time sampling of 500 ms/s or is it really a subsampling scope ? Even so for the price it's a well specced scope to have in the toolbox when you're out in the field and need a quick measurement

cheers

[snoopy]

I like how it uses the standard BNC input connector for standard probes

Next question is who's got one of these ?

[jjoonathan]

So with 16 levels that looks like a 4 bit flash ADC. They claim 8 bits. Are they doing some folding or something? Or did the spec sheet just "gain something in translation"?

EDIT: There are 8 vertical divisions, a 4-bit converter would yield half-div resolution, but I'm pretty sure I can see wiggles smaller than that in the square waveform. Is it a two-stage conversion with three bits per stage for an idealized 6 bits, using the outputs of the first stage to subrange the second stage?

[tinhead]

So with 16 levels that looks like a 4 bit flash ADC. They claim 8 bits.

AD9288 or something, probably there is second one on the bottom side, it is 2x125MSps ADC, probably overclocked 80MSpS version anyway. Typical 10yrs old DSO design

[snoopy]

Someone done a review of this scope on youtube. Looks ok

[GeorgeOfTheJungle]

Looks good. Very good indeed.

[Kosmic]

I ordered one couple of weeks ago. The bandwidth is definitely not 100Mhz. Tested with my signal generator and on my unit, -3db point was around 63Mhz. Higher than that the signal is heavily attenuated and at 95-100 MHz the sin wave was completely distorted.

That been said, the auto mode is working pretty well and user interface is not too bad. I used it today to poke around a PSU and it was working great.

Personally I wanted a floating scope for a while and that was a cheap option. Not too sure if it's really safe though.

[snoopy]

I just ordered one from the bangood link in the youtube video. For the price it's a lot cheaper than looking for a 2nd hand Tektronix THS7XX scope

cheers

[GeorgeOfTheJungle]

I got mine, looks good, the screen is bright, the colours are good, battery life is 7 hours, buuut, the specs said 128kB storage depth, but there's no way to zoom or scroll the trace in single shot. The screen is 320*240, so this to me is looking more like 320 samples storage depth than 128 kB, which makes it a useless DSO. The UI is a bit of a mess too. Perhaps I'm doing it wrong?

[GeorgeOfTheJungle]

This needs a better firmware. It makes no sense that when you capture a one shot trace can only see the 320 samples that fit on the screen. The specs are wrong too because it clearly says 128kB storage depth. Even the cheapest $20 DSO shells can scroll the 4000 or so samples of a single shot capture. I can't return it because to do so I'd have to send it back to China which would cost me more than the thing itself.

IOW: MY RECOMMENDATION IS DON'T BUY

(In the meantime, I went to batronix and ordered a MicSig because I need a portable scope)

[GeorgeOfTheJungle]

One more thing: as the USB socket is recessed quite deep into the case, a normal micro-usb plug won't work: it comes with a special, weird, micro-usb plug with a longer prong:

[amspire]

I have had my 5012H for about a month. It is not a great scope, and I love it. Use it all the time.

It has a long battery life and is a super solid construction. Very bright, clear display. I use it for a quick look at waveforms when playing around with microcontrollers. It is very well insulated, and has a long battery life so it is great for connecting to an ungrounded source.

It would be great if someone wanted to write a new firmware for it, but I can use it as it is. It is fairly solid firmware.

It is not a substitute for a desktop scope unfortunately. Only the auto trigger works well - the manual trigger control is pretty bad.

GeorgeOfTheJungle is right about the special USB connector, but it wouldn't be that hard enlargening the hole so a conventional USB cable could be used.

The is no way to get saved waveforms out of the scope - the USB connector seems to be for power only.

So I wouldn't recommend it to anyone here, and I am extremely happy with my purchase.

Richard

[4thDoctorWhoFan]

Just checked out the Banggood link.
Price has been reduced to $69 US.

A footnote on the site says the display has changed from a IPS to a TFT screen & a smaller capacity 3000mAh battery.

Might be worth it for $69.

[GeorgeOfTheJungle]

@amspire I love it too but with this firmware it's useless as a DSO. What use have 128kB of storage depth if you can't see the stored samples? I want the scope to see the entire transaction between the ESP32 in the picture and the DHT22, but it can't show me but a small part of it. Where are the 128kB?

[adrianjball]

I bought one of these soon after Banggood had them available, and have been arguing with Banggood ever since over how an oscilloscope should work. I found that Auto trigger mode worked reasonably well, but Normal and Single modes don't work at all. A single pulse in Single mode does result in a trigger, but the triggering edge is not visible on the screen at all. And Normal mode just seems to trigger randomly - even a steady square wave just jumps around all over the screen.

I sent videos to Banggood showing the non-working trigger modes , who then (so they say) sent them on to DANIU, and DANIU supposedly responded that the operation is correct. So unless someone is lying I doubt there will be a firmware fix any time soon!

I note that in the video posted by Snoopy he quickly skips through the Single and Normal trigger modes, but as he goes through Normal mode it can be clearly seen that it isn't triggering, so it's not just a fault in the unit I have.

My advice would be: If all you need is to scope a repetitive waveform in Auto trigger mode, this is a nice package at a good price. But if you need the Single trigger mode of a real DSO, or any trace depth, then this is junk - don't buy it. You would be better off with a DS202 or similar, which while they don't have the bandwidth of the ADS5012H they DO actually work in Normal and Single trigger modes.

[amspire]

@amspire I love it too but with this firmware it's useless as a DSO. What use have 128kB of storage depth if you can't see the stored samples? I want the scope to see the entire transaction between the ESP32 in the picture and the DHT22, but it can't show me but a small part of it. Where are the 128kB?

I cannot agree with you more. New firmware could probably transform this into an almost acceptable scope, but there is a good chance that there will never be any new firmware. Without a working USB, there is probably no method for a simple firmware update.

I have only had a quick look inside. At some point, I probably will take it apart, photograph both sides of the board, try and read the ROM, and try and identify the chips. My one has at least one main chip with no identification. If it is the A/D, we may be able to work out what it is.

Richard.

[robca]

I cannot agree with you more. New firmware could probably transform this into an almost acceptable scope, but there is a good chance that there will never be any new firmware. Without a working USB, there is probably no method for a simple firmware update.

I have only had a quick look inside. At some point, I probably will take it apart, photograph both sides of the board, try and read the ROM, and try and identify the chips. My one has at least one main chip with no identification. If it is the A/D, we may be able to work out what it is.

Richard.

Since it uses a clone of the STM32F407, it would be pretty easy to reprogram the main CPU with any SWD interface. F407 also has onboard USB and DFU mode, so might be able to reprogram without opening it. The STM32F407 has more than enough internal flash for a scope firmware of that type (the VET6 model used in this DSO has 512k of flash onboard, and 192k RAM), so unlikely to have a separate ROM for code (and that Winbond chip is a 25064, only 8Mbytes). And I seriously doubt that Daniu did not set the protection fuse to prevent reading the onboard flash

So a clean new firmware would be the only option

Incidentally today is on sale together with a few other oscilloscopes for $65 https://www.banggood.com/marketing-HANTEK-Oscilloscope-Promotion/tid-2163.html

[snoopy]

I bought one of these soon after Banggood had them available, and have been arguing with Banggood ever since over how an oscilloscope should work. I found that Auto trigger mode worked reasonably well, but Normal and Single modes don't work at all. A single pulse in Single mode does result in a trigger, but the triggering edge is not visible on the screen at all. And Normal mode just seems to trigger randomly - even a steady square wave just jumps around all over the screen.

I sent videos to Banggood showing the non-working trigger modes , who then (so they say) sent them on to DANIU, and DANIU supposedly responded that the operation is correct. So unless someone is lying I doubt there will be a firmware fix any time soon!

I note that in the video posted by Snoopy he quickly skips through the Single and Normal trigger modes, but as he goes through Normal mode it can be clearly seen that it isn't triggering, so it's not just a fault in the unit I have.

My advice would be: If all you need is to scope a repetitive waveform in Auto trigger mode, this is a nice package at a good price. But if you need the Single trigger mode of a real DSO, or any trace depth, then this is junk - don't buy it. You would be better off with a DS202 or similar, which while they don't have the bandwidth of the ADS5012H they DO actually work in Normal and Single trigger modes.

I found that there is significant jitter at the higher sweep rates and also at lower vertical sensitivity it seems to use some sort of software multiplier with noticeable stair casing on the waveform.

The way it is, it's a bit of a toy which is a pity because it could be a lot better. Hopefully some firmware upgrades may fix some of the issues.

cheers
david

[cliffyk]

Well, despite the well thought out and documented shortcomings of this "too good to be true" cute little bugger, I bought one on Amazon ($79.98 w/ free 2-day shipping for Prime members). I viewed the higher priced option (vs. Bangood or Ali, etc) as a sound insurance policy.

Have had it for two days, it goes back Monday (9:00 Saturday night right now). While it does indeed have a 100MHZ bandwidth (mine actually had 3 to 6 dB gains at 60 to 80 MHz; v. 10 MHz);the "single" and "normal" trigger modes suck to the point of uselessness. On a triggered sweep scope the "normal" mode is supposed to trigger as configured (I.e. "triggered sweep" as opposed to timebase fired "recurrent" sweep 'scopes we had to use eons ago--this is this unit's "Auto: mode); show one sweep; and then wait for another valid trigger--this thing does not, it just seems to trigger randomly resulting in a useless display.

"Single" mode forces the trigger position to he far left of the display (as does "normal" mode), seemingly off-screen on some signals, "chopping off' the trigger event. Here is a "single mode" capture of  1 kHz, 5 cycle burst:

   

Note that 400 us or so of the first of the 5 cycles has been lost; and as the trigger position is  frozen to the left of the grid (in both "single" and "normal" trigger modes) it cannot be viewed.

It's too bad, as with proper firmware this could be a very nice little device--however as it is its just a giant step backwards to recurrent sweep 'scopes made obsolete by the advent of triggered sweep.

FWiW mine is the newer model with the TFT display and 3000 mAh battery; the display is great (my photo does not do it justice) anf I ran it 8-1/2 hours on the battery while playing with it--unfortunately "plaqying; is the correct word as as it is all it is is a pretty neat toy...

Also FWIW here is a capture of the same 5-cycle burst captured with one of the ADS2050H 5 Mhz/ 20Msps instruments; note that all 5 cycles were captured, though a bit more pre-trigger capture/display would be nice...



Bottomline: "If something sounds too good to be true..."

[ataradov]

I've started an effort of reverse engineering that thing and making an open firmware https://www.eevblog.com/forum/projects/reverse-engineering-fnirsi-5012h/

[cliffyk]

Cool, with firmware that made this behave as a proper triggered sweep 'scope it would be awesome. How have you bee able to communicate with the CPU? Via USB or something requiring a board level interface?

[ataradov]

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

There is no way to communicate with the CPU that I can see, it is locked in the most secure way. BOOT0 pin does nothing and SWD interface is not responsive. For now I will just swap the MCUs.

If someone can figure out how to get into this one, it would be great.

I have not spent a lot of time on that though, since I pretty much assume they locked it hard.

[amspire]

Alex, have you worked out what A/D they are using? Mine is unlabelled.

My guess is some kind of 3 channel video A/D and it must have a built in buffer - I don't see how the micro can be reading data at 500M samples/sec. Probably something like a 3x100MHz A/D that they are overclocking.

Lack of a dedicated FPGA to drive the A/D means the triggering will always be bad. There is nothing that can continuously monitor the signal looking for a trigger. The two priority encoders handle the buttons and it does mean you can get a very fast response from the buttons.

There will be a much slower sample rate that the micro can be reading the A/D continuously and perhaps it can be made to trigger reliably at that slower speed.

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. A wideband preamp. An eeprom chip for the waveforms. A lithium battery charger IC near the USB connector.

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.

Richard.

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

[Kosmic]

I tested a similar setup (9 pulse each 300ms) on my unit (older model with 4 relays). At 2.5kHz in single / normal it's working fine. 5 kHz it start struggling and the waveform is shifted to the left. At 10 kHz, half the waveform is shifted to the left.

Auto mode is just not working with this type of waveform.

[dave j]

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've been thinking about what could be done with software based trigger detection.

The DSP instructions in the MCU's Cortex-M4 core mean you could check 4 samples with a single USUB8 instruction. For a rising trigger, if you subtract the trigger values from 4 samples the result will be zero if none of the samples exceed the trigger. So processing 4 samples could be:

Code: [Select]

LDR samples, [buf], #4
USUB8 res, samples, triggers ; For rising trigger, swap samples and triggers for a falling one.
CBNZ res, found

With some loop unrolling and instruction reordering to hide the latency of the load you'd have code that looks like:

Code: [Select]

LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers

which would check for a trigger occurring in 4 samples every 3 processor clock cycles - or 224MSPS with the MCU's 168MHz clock..

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

[ataradov]

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

And that's exactly why I'm excited about this project. I never had a chance to do deep DSP optimizations on Cortex-M4. And this project is pretty contained in its scope (no pun intended).

[dave j]

And that's exactly why I'm excited about this project. I never had a chance to do deep DSP optimizations on Cortex-M4. And this project is pretty contained in its scope (no pun intended).

With MCU based scopes, most of the DSP fun comes from implementing the automatic measurement functions - which can be a bit of a rabbit hole if you let it. Best leave that until you've got the basic scope functionality working.

[rvalente]

Nice little gadget I would buy one if:

There was VGA screen instead of WVGA: after using my THS720P, U1602B, DS1052 and others the 320x240 is just to low be really useful.
Please ad a rotary encoder, this push to increase/decrease the time base and voltage scale is just non sense, even if they are shared between vertical and horizontal.

Besides that, yeah, for this money, why not? Oh, I would never use this in any mains connected stuff, zero protection from what I've seen

[ataradov]

The device is very well balanced. Bigger higher res screen will not add a whole lot of value.
Buttons also feel good. They are not overloaded as some other devices, so you get used to them pretty fast. I actually would not want an encoder on this specific unit. It is like a thing between the real scope and a multimeter, and it is surprisingly good for what it is.

Also, my shipment of GigaDevice parts from LCSC has been sitting at LAX airport for more than a week now. Not sure what is going on there.

[rvalente]

My complain with QVGA screen is that sometimes there is a high frequency in the middle, and you cant see nothing besides of a white filled polygon.
Screen resolution is always better, phones have gone crazy with it and is something we do not want to step back, also a QVGA and VGA screen costs basically the same nowadays.

As for the encoder, the majority of the scopes, except few handhelds, have been using them. its a personal taste but I feel its much more enjoyable to turn CW or CCW a dial with nice detents feedback to increase/decrease time base or volts scale them a rubber buttons but, as you said, they feel good and I never tried this equipment before.

[splin]

[

Code: [Select]

With some loop unrolling and instruction reordering to hide the latency of the load you'd have code that looks like:

[code]LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers
LDR samples, [buf], #4
CBNZ res, found
USUB8 res, samples, triggers

which would check for a trigger occurring in 4 samples every 3 processor clock cycles - or 224MSPS with the MCU's 168MHz clock..

Obviously the whole thing wouldn't go that fast, but I think that 100MSPS might be realistically achievable.

The Cortex M4 load instructions are actually 2 cycles to execute but sequential loads are pipelined so only the first takes 2 cycles. So best to load a block of registers first to minimize the extra cycle overhead of the first load.

Also the memory reads have to compete with the DMA writes of the ADC data to RAM so some loads may stall by an extra cycle. They might not of course - it depends on the relative priorities of the DMA and the M4 core and the implementation of the arbitration. Since DMA implementation is vendor specific I guess the behaviour will differ between the STM32F407 and the GD32 version.

The good news though is that, from the other thread, the GD32F407 must be overclocked to 250MHz, otherwise it wouldn't be able to read the ADC data at 125MSPs. Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Conclusion: hopefully it will be just possible to handle the triggering without the DMA overrunning, depending on the internal bus contention impact. There will also be some additional overhead in swapping the DMA buffers over, but this will be amortized over a whole buffer (64k?) so should be minimal.

It may be possible to avoid having to check, and reset, the 'DMA buffer half full flags' which you would normally do to know when to supply the DMA with the address of the next buffer when the current one is full. This might be avoidable by padding the trigger detect code with enough NOPs such that it's execution time exactly matches the incoming data rate.

[EDIT] Using a 'load multiple' instruction to load a block of ADC samples into registers might not work - I don't know if it would stall a DMA write until the ldm instruction completes which would cause a DMA overrun.

[ataradov]

Also the memory reads have to compete with the DMA writes of the ADC data to RAM so some loads may stall by an extra cycle. They might not of course - it depends on the relative priorities of the DMA and the M4 core and the implementation of the arbitration. Since DMA implementation is vendor specific I guess the behaviour will differ between the STM32F407 and the GD32 version.

The DMA has double buffer mode. And the buffers can be split between SRAM1 and SRAM2, which can be accessed concurrently. So DMA can fully autonomously receive the data while CPU processes the other buffer.

I frankly expected a bit more. I've got spoiled by SAM V71 where there is true multi-port SRAM and DMA with real linked transfers. But the double buffer mode may be better this this case actually, since reloading linked transfer descriptors also takes time.

SRAM2 is only 16K, so the total sample memory would be 32K samples.

The actual performance would have to be tested on the real hardware.

Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Where does it says this? I can't find it on a quick scanning of the datasheet.

[splin]

The DMA has double buffer mode. And the buffers can be split between SRAM1 and SRAM2, which can be accessed concurrently. So DMA can fully autonomously receive the data while CPU processes the other buffer.

I meant to point that out but I was assuming that it might be necessary to execute the code from SRAM code. Finally getting round to looking at the GD32 D/S I see the FLASH is zero wait state so not necessary.

I frankly expected a bit more. I've got spoiled by SAM V71 where there is true multi-port SRAM and DMA with real linked transfers. But the double buffer mode may be better this this case actually, since reloading linked transfer descriptors also takes time.

Yes I was a bit shocked when I discovered how basic it is, especially that the only documented way of monitoring progress is to use the buffer half full and full flags / interrupts which is limiting depending on fast the DMA is.  However it turns out you can monitor progress by reading the DMA destination address register which can be helpful.

Note that the STM32F407 requires 4 clock cycles for each GPIO to memory DMA transfer so it only works on the GD32.

Where does it says this? I can't find it on a quick scanning of the datasheet.

It's not in any documentation that I can find for any of the STM32 devices which is irritating. According to a post on the ST forums the read speed depends on a number of factors including bus contention,  FLASH accesses that are in program etc.  Also input data is resynchronised which will cost a clock or two. The CLK/4 comes from others experimentation - for writes at least, but I can't now find anything specific about GPIO reads so they could be even slower. There is some good information at:

cliffle.com/blog/pushing-pixels

He manged to achieve clk/4 for DMA writes to GPIOs so reads are unlikely to be any faster. Unfortunately his blog seems to be broken now so only part of this blog is navigable which is a shame because he gives some interesting insights into some poorly documented aspects of the STM32F407 buses and DMA and he does it in a concise but very readable form.

The GD32 implementation is presumably very different so his information wouldn't be relevant anyway.

You probably know but be aware that only DMA2 can be used for GPIO to memory (on the ST part anyway).

[rigol52]

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.