i m watching the sources of DSO_gcc_v7.1 and have different questions…after 2 min of watching.
why do you still poll in timer handler the keyboard state(keys pressed), and don’t have keyboard interrupt, as any good hardware? what a strange idea - permanently poll rare events, if interrupts make it easy and in proper way.
Hi! I need help.
My device gives out the wrong form of a signal on the channel “A”. I repeatedly changed an firmware, the result on all is identical. I understand that malfunction is not in the program, and in the hardware. I ask to prompt to me, what details on a payment can be faulty?
I changed the probes, it didn’t solve a problem.
On a screenshot both channels (A and B) are connected to the same signal, only shifted for the period
I assume your input signal is square wave. Try adjusting the trimmers behind the battery - it may help. Looks like too much reactance compensation on Ch A and too little compensation for Ch B. This page has instructions:
No, in the channel “B” the true form of a signal is shown. It is checked for 100 % a serviceable oscillograph. It is a signal on the power unit of the amplifier (the enclosed file) in the points noted red. Many thanks for the reference, I will try according to your recommendation and I will report about results.
Don’t know why nobody notice this dramatic bug. There are tremendous timing mismatches between analog and digital channels in all firmwares.
Yes it is, thank you, but still no any efforts from developers side…
Heh, in the past 9 months, never has Seeed or eDesign co. fixed a single bug properly. There have been some updates, but the horrible triggering bugs and malfunctioning calibration remain as ever.
If there is hope… it lies in the community.
Legally speaking a product does not meet the specs. BTW, this is the cause for termination of sales according to the Law.
Hehe, surprisingly I wouldn’t return the device even if I could. As a portable oscilloscope, with all its defiencies, it’s still the best one I’ve ever owned. The typical 10 MSps multimeter-style devices with grayscale screens and no programs are nothing compared to the Quad.
Hi jpa.
I read your post about this problem related by kabron; maybe we can do the trick you used in your logic analizer program into the community app ?
Unfortunately the trick I used only works for slow samplerates (less than 1MHz etc.).
But it shouldn’t be too difficult to solve in the community app, just delay the digital traces by 5 samples.
I’m not sure, because the time lag or lead are different on various aquisition rates.
Hmm… haven’t tested much, but if it is the same effect I have seen, the difference should be always exactly 5 pixels on screen…
I have the same issue. After calibrating the DSO like 4 times, I cannot get a clear measure from a power supply at 5V. I always get ~1.8V difference, and what is worse, it seems to change after each restart.
I was able to get the DSO Quad to reflect accurate voltages on both the A and B channels. I was getting what I would describe as some offset voltage, always more that what should have been indicated. I found that if I moved the zero voltage all the way down to the bottom of the screen (using the Y adjustment) the voltage reading were good. I do feel I can get reliable voltage readings out of this unit now. I did spend a long time calibrating and recalibrating the voltages.
Take care.
–Spiro
Until now, it was a waste of money to me buy the DSO QUAD. After many firmwares updates, and calibrations. The value in the screen isn´t correct.
I tried what Spiro says, and the measure comes better. But not precise. Only shows better values in the bottom. If I want to see the negative part of the wave, I can´t.
Or I´m missing something, or it´s a Hardware problem.
My Hardware is v2.60
Hi developers,
I got a second DSO with the following description and a new firmware/APP.
Hardware version 2.60
sys version 1.51
App (plus A1) Version 1.00
It’s a massive improvement in navigation because the menu keys are entirely consistent in function. Full write up here:
viewtopic.php?f=10&t=2362&p=14296#p14296
It got me thinking that just a few changes are required to introduce a much easier menu scheme for the Community APP, namely the order of button selection. Obviously there are multiple solutions but here’s a couple of proposals:
- Right mouse navigation key scrolls always and only through menu groups. It rotates clockwise using right dab as today, so after TRG it would move to dV and then to dT, and so on down the vertical measurement menu, when displayed. When it gets to FrqD it moves to XPOS and further right dabs move it through T2, T1, Save, V2, V1, Ypos then back to ChA. Left dabs always move it anti clockwise.
This does produce more than one way to move around eg: from XPOS to trigger using navigation OR left mouse press as they are both orange group, but I don’t see a problem with that. It would mean an end to the struggle of how to get to eg: the cursors.
- Right mouse press toggles between Top Horizontal menu, Vertical menu when displayed, and Bottom horizontal menu. Once there, left/right and up/down work as today, but it does not jump from one group to the other, it wraps within the current group.
I think consistant button operation could be a very popular improvement. The ‘Plus A1’ is so nice to use in comparison that I have only updated the older DSO with the Community App even though it would significantly improve the new one as an actual scope.
Cheers,
Mike