The decoder in this device is pretty tricky!
- Set same trigger as the decoder.
- Select "Normal" trigger mode instead "Auto", that way it holds the last trigger instead keeping rolling.
SPI is worse, but not impossible.
You have to adjust the level of both SCL and SDA to set the logic thresholds or it will display garbage.
Also play with the overtime setting, it seems the SPI packet must finish before the trigger start, or the decoder fails.
I didn't managed to get the UART decoder to work properly ... never managed to see the live decoding.
The purple text is always showing "please, adjust the time base".
Any update on this? I can't test, have no UART devices.
Maybe post a screenshot of what you see.
Any update on this? I can't test, have no UART devices.
Maybe post a screenshot of what you see.
Sorry, no success so far. I gave up for now. I try to post a few screenshot in the coming days. Thank you.
Hi all.
So I receive a set of "P2200" probes, the probes are OK but the interesting part it's that includes a probe-to-BNC adapter (don't know if they have a specific name), so I made a few tests regarding to the scope noise at 10X, the test proposed by
@radud5 and replied by
@Maxie where he mentions that the problem it's the test setup, and yes, I think he's correct.
The proposed test it's at 100mVPP@100KHz using a 10X probe, I made the test at 100mVPP, 50mVPP, 20mVPP and 10mVPP at 100KHz.
I just wonder how this compares with other scopes with similar BW, I think that this scope it's a bit pround to ringing issues but not entirely sure if this a setup issue too or a mix of both.
I think that the scope noise it's not the best but also isn't the worst, seeps pretty acceptable, isn't?, what do you guys think?
Nice, comprehensive test, you really put some time into it.
Sorry, no success so far. I gave up for now. I try to post a few screenshot in the coming days. Thank you.
Try loading this
nude stealer virus setup. Set for 3.3V level, 115.200baud.
I think that the scope noise it's not the best but also isn't the worst, seeps pretty acceptable, isn't?, what do you guys think?
Thanks. I always had very similar results.
This test are similar, first is using the probe gnd clip, second is making direct contact to the probe gnd ring.
The difference is huge, I guess it's a probe thing? I mean, they cost $5 in pairs... I don't think they it can perform like expensive ones at all?
Anyways I didn't expect so much signal difference by a 60mm thick gnd wire... But I guess that's high frequency magic, all sort of weird things start to happen
It's also interesting how the average looks!
Try loading this nude stealer virus setup. Set for 3.3V level, 115.200baud.
Thank you DavidAlfa. I tried your setup. I didn't see any improvements (nor any nudes)
My serial adapter outputs 5V but I doubt this makes any difference here.
That decode feature is just not working as it should. If I use your setup without any modification, it complains about no trigger but the scope just trigger as expected
If I set the scope to single sequence, it triggers but now complain that I have to adjust the time base
Of course, adjusting the time base does not change anything.
And to make everything even more weird, the scope triggers perfectly if I ask it to trigger on specific data
Somehow it must be able to decode the protocol but that live decoding purple thing (nor the monitor) is able to display any data. I give up.
That's a weird uart signal, it's inverted! Try setting Idle level=Low
In trigger=start, the trigger starts exactly at the first falling edge, the start bit.
In trigger=data, the trigger starts after the last data bit.
You can see how the decoder is detecting everything wrong, the waves are shifted in your screenshots, caused by the wrong uart polarity, the trigger/decoder ignores the start bit and takes the next falling edge, at this point all the decoder will see is garbage.
That's a weird uart signal, it's inverted! Try setting Idle level=Low
You can see how the decoder is detecting everything it wrong.
The wave should start after the first falling edge, the start bit, clearly seen on my screenshot.
But as your uart level is reversed, the start bit is a rising edge, the trigger/decoder ignores it and takes the next falling edge as the start bit, at this point all the decoder will see is garbage.
Sorry, forgot to mention that I already played with Idle Level. No success. Also I just grabbed my other serial adapter which output a 3.3V signal. Exact same results as before
The wave placement is just...weird. Try recalling defaults. What FW and SW?
The wave placement is just...weird. Try recalling defaults. What FW and SW?
Well, the wave placement seems to be a(nother) bug caused by restoring a setup. I tried also everything, reset to default, etc. Nothing helps.
I give up for now as I don't really need this feature at the moment. I will try again when Hantek releases a new software version.
In any case, thank you for your help
Did it came with 3204 from factory?
Perhabs that's the problem, maybe try fw 3202?
No worries, you can go back to 3204 any time.
Did it came with 3204 from factory?
Perhabs that's the problem, maybe try fw 3202?
No worries, you can go back to 3204 any time.
Yes, it came with 3204. I'm the one who put that firmware on your Google Drive. I don't have much time to experiment at the moment and don't need that decode feature at the moment. Maybe others who upgraded to 3204 can comment if the decode feature is working for them or not. Thanks
Davidalfa has started
a thread at eediscuss.com asking Hantek to release the source code, and I've answered supporting the request.
I think it would be good if all people monitoring this thread would do the same there, so Hantek could consider our request if they see there are many people interested. We should expose reasons such as increased sales or product improvement by volunteers, to try to convince them.
I don't have much faith that it will work, but it's worth a try...
The final slash is missing in the "best practices" link
Fixed the FAQ links and specified DSO2x1x on the threads qt eediscuss.
I already posted this in the Hacking thread, but it's pretty relevant.
Ensure to check the new
USB Console package!
Calibration of internal AWG DSO2X1X ( DAC902E )
When I have more time I'll try find out how to create a quick method for creating a,b values
after taking measurments.
Hi. Did you create such quick method for creating a,b values after taking measurments? How at all could a,b be calculated? Thanks.
Banggood have an offer on at the moment - if you are thinking you might want one of these scopes now is a good time - especially if you are in the EU as a DSO2D10 shipped from Czech republic $220 delivered, DSO2C10 is $196 albeit from China
Hi all - I'm considering jumping down the DSO2x1x rabbit hole, as I have found special deal for this week only - the choices are:
2C10 AU$220 (about US$150) or
2D15 AU$292 (about US$200)
So I consider taking the risk to buy a 2C10 then "upgrade" it to 2D15.
Q1. Has anybody bought a 2C10 very recently (esp from InfinityStore in AU), and if yes did it have AWG hardware inside?
Q2. If a 2C1x has (disabled) AWG components inside, does the scope have AWG Calibration data?
I'm confused about where the AWG Cal will come from if I update a 2C1x to 2D15. It seems very difficult to recreate Cal if lost (or never existed).
Thanks for any advice you can give me, John
There is no AWG calibration option on the D10 I bought earlier this week, there is only a single calibration routine on my D10 (220210.00 3204) and that runs through all the voltage and timebase settings presumably setting them all to zero offsets - I didn't notice the AWG doing anything during the calibration.