why the fact to merge marcosin’s source code into 2.51 makes any difference compared to using marcosin’s complete source code? why does it know compile with Os?
why the X-Y mode don’t work? Juste merging marcosin’s code doesn’t seem to me to be a suitable explanation…
Yes, you probably had the calibration settings messed up by the previous release.
Marco’s code doesn’t compile directly in gcc. There are a few differences between IAR and gcc source, like some datatypes.
The last version was more or less a straight port of Marco’s code to gcc, but it had issues, like you saw. (and something in the code didn’t “like” -Os).
Merging his code over the stable gcc 2.51 code I had actually involved more work/time than the previous attempt, but I knew I could control each step of the process to determine any incompatibilities with -Os.
Don’t know yet what’s the problem with X-Y part, but shouldn’t be hard to fix. (we’ve all heard that before )
I have a version ready that already fixes the max, min and vpp readings, but will try to fix X-Y also before release.
…by the way, I have just noticed that this firmware has been available since september 2011 (beta) and decembre 2011 (v1.00) on the chinese forum for the DSO203 (same as DSO Quad):
I was looking for a portable low cost oscilloscope and found DSO203. Looks like a good piece of equipment, but searching a bit I see there are quite some bugs and there is no real official change/fix log so hard to tell what of those has been fixed.
Triggering is, I would say, a bit unreliable. I wouldn’t say it’s useless, just unreliable.
It doesn’t work consistently in all situations. That’s about it.
It works for me, in most situations.
The triggering is done in the FPGA, and there’s currently no way to rebuild that code without purchasing a licence, and that I would say is my biggest gripe about it.
I find it a bit more sad that the analog bandwidth has been “strangled” due to some bad hardware design choices. The digital processing part is actually superior but you can’t take advantage of it.
ps: This build has correct frequency units, yes.
The official one (still) doesn’t.
ps2: In the end, it’s a (very nice) expensive toy, yes.
You can’t compare it to a professional dso, but then again, how many good dso’s do you know of this size?
Thanks for your contributions. Last night I upgraded the s/w with the latest sys and fpga. The only thing to watch out is to download the app using zip, otherwise you get an error. Have not have a chance to do any measurement, but the upgrading worked perfectly.
With regards to the FPGA code compiler license how much does that cost? The thing is that for other open source s/w, the tools are also free. Then how would people deal with open source fpga source?
I am not sure if the community is willing to contribute to buy a license, but it is something to think about.
is there any effort to continuing refinements of firmware for V2.6 HW?
I have freezing of DSO when particular specific analog signal is measured (pulse-phase modulation), when I have frequency counter enabled for input on the right-hand side panel in GUI.
Though, it is inductive load (commutated DC motor), but driven by 19 V as maximum + modulated wave form. So I don’t believe the cause are voltage spikes, since DSO can handle 70 Vpp.