I’ll say we should give them some time. I’m sure we are not being ignored.
BenF: is the reason why you cannot rewrite the firmware like the nano because part of it (the low level stuff) is not open source?
BenF recently released v3.62.
The following excerpt from BenF’s V3.61 more adequately describes the desired improvements as determined by BenF and Forum Users:
Three phase sampling (pre-fetch, trigger-fetch, post-fetch) guaranteed never to miss infrequent events
More efficient screen update (10-100 times faster than version 2.5e)
Eliminate all flickering and stuck pixels
Code is re-written to allow full compile time optimization (much faster and compact code all over)
A number of overflow bugs have been fixed (calculations for large time/div settings)
Scan has been replaced with a proper continues real-time scan mode
Configuration profiles can be saved to and restored from SD card or flash memory (default power on settings).
Waveforms can be saved to and restored from SD cards
Screen capture can be saved to bitmap files on SD cards
Snapshots of the full DSO sampling buffer can be exported to XML formatted files for further processing and analysis
XML formatted files can be imported to both the primary channel and the reference channel
Use oversampling and averaging to detect high frequency components on lower frequency waveforms
A number of issues with incorrect SD card support and file handling in 2.5e have been fixed
Files and directories will be created by the DSO Nano as needed without having to preload template files
Automatic waveform tuning (FIT mode) can be selected with a dedicated key combination
The full sampling buffer can be panned left right on the Nano display
Control sampling buffer usage for pre or post trigger priority or fast sampling rate
Waveform resizing and vertical scroll capability (zoom in on area of interest)
A more relevant collection of information fields is selected for on screen display
A more relevant selection of measurements
Simultaneous view of all measurements
Use common abbreviations and terminology
A completely redesigned user interface (no annoying blinking or color abuse)
Automatic ground level calibration and manual gain calibration for all input ranges
User selectable grid light intensity level
Fine tuning of output frequency to three digits
Set duty cycle (PWM) of output frequency from fully-off to fully-on in 1% increments
Single button quick select for frequently used functions
Although this list is extensive, this is what it takes to change a prototype toy into a viable and professional tool.
Apparently source code has been released for app, sys and fpga:
ourdev.cn/bbs/bbs_content.jsp?bb … bs_id=3053
post # 1070
I’ve created a forum thread with those files. I realize this is sort of a duplication, but I found it quite challenging to track down the referenced post, download and extract the files, and interpret the CHANGELOG.TXT – so hopefully this saves someone that work.
viewtopic.php?f=22&t=2021
It seems to me that Bure going back to dfuse makes a lot more sense. Admit the mistake and move back to dfuse if possible (with the FPGA). If FPGA is a problem, why not load the FPGA code into the STM and then run the STM to stuff the FPGA. Then load the STM with what it needs. Dfuse v3.01 supports all operating systems and includes 64-bit machines.
Hello Folks,
I am just starting to use my Quad for the first time as a tool to measure some I2C signals from sonar device. I am seeing a lot of flicker on the screen at 20usec/Div and the system only triggers about 1 time in 5 at 10usec/Div. I am using channels C/D for inputs. Channels A/B just gave me a badly slewed wave that was all but useless to read.
I was also wondering why there is a threshold on the trigger for C/D since they only show as logic 0/1 with a single Div difference. The only sensible trigger for these inputs it leading/falling edge. It gets confusing when you switch between trigger sources C/D only to find that the trigger level is set outside the signal level that you have no control over.
Since the inputs C/D have no signal processing like A/B I can only assume that the firmware is missing trigger events on these channels. I would be expecting to be able to see a 10 meg bandwidth at the very least on these inputs. Perhaps someone can look at the trigger logic for the digital inputs
Cheers Pete.
The features I need the most on the DSO Quad are time domain measurements. Frequency, duty cycle, etc.
Thanks.
as i tested ,the channel A/B can trace the I2C signals well , what do you mean by “a badly slewed wave that was all but useless to read”, would you please take a picture?
yes, as i think, the threshold on the trigger for C/D may not needed. i will sent your suggestion to the designer…thanks
The trigger exhibits some strange behaviour. For example…
In SINGLE at 20uS timebase, two trigger events are required to cause a displayed waveform. The first event displays HOLD but no waveform is displayed. The second event updates the waveform display while HOLD continues to be shown.
In NORMAL at 20uS, the unit does not trigger on every event but does so occasionally every few events and when it does, the display is only held for a half second or so. If the HOLD button is pressed while in NORMAL - the display will actually refresh on the first trigger event after the HOLD is pressed. ie. it does not actually hold the current display.
[quote="HugeManas i tested ,the channel A/B can trace the I2C signals well , what do you mean by “a badly slewed wave that was all but useless to read”, would you please take a picture?
[/quote]
Sure no problem, but i am out of the country for a week i will do it when i get back. But what i meant was that the wave was far from having vertical edges on the transitions and had apparent rise and fall on the logic high and low levels giving the impression of a saw tooth wave, although not quite as extreme
Cheers Pete.
i have tested, i use 200k signal ,20us, SINGLE, and it can be triggered …also the the NORMAL works well…
would you tell me what the frequency of your signal?
Sure no problem, but i am out of the country for a week i will do it when i get back. But what i meant was that the wave was far from having vertical edges on the transitions and had apparent rise and fall on the logic high and low levels giving the impression of a saw tooth wave, although not quite as extreme
Cheers Pete.
[/quote]
i got your meaning . but i think as the I2C signla (<100K), Quad should trigger the signal well.you should:
- conpensate the probe, you can download the maunu"how to adjust the C to calibrate probe " at viewtopic.php?f=22&t=1929
- maybe you can check the signal with aother oscilloscope, to check if the signal does what it looks like in the quad.
thanks
HugeMan wrote…
“i have tested, i use 200k signal ,20us, SINGLE, and it can be triggered …also the the NORMAL works well…
would you tell me what the frequency of your signal?”
My signal was a 5v 1mS pulse repeated once per second. So the frequency was 1Hz.
You will not see this effect if you use a 200KHz continuous waveform because the second triggering will occur immediately.
This becomes an issue when you want to capture eg. the next serial byte from an RS232 port. You set the scope to SINGLE, send the data byte (by hitting a key in Hyperteminal for example) the scope should trigger and hold the byte after it is transmitted. The Quad actually triggers and holds the second key you hit.
I hope this clarifies rather than confuses
Perhaps I should state what I consider to be NORMAL triggering mode.
NORMAL mode should wait until a trigger event then update the display waveform. This waveform should then be held indefinately until a new trigger event occurs. When a new event does occur, the display should be updated. The Quad seems to hold it only for a half second or so. This is how all Tektronix scopes work. (industry leaders)
I agree with your definition and after thinking about this for a while I now wonder:
With multiple traces, how do you accomplish asynchronous trace updates for multiple traces? The big question here is how do you clear one trace without affecting the other traces, especially if someone has the traces overlapping. Vertical positioning makes the trace real estate unknown the firmware considers min and max + vert offset to know which pixels to clear.
Maybe another approach is to delay asynchronous display updates and do them all together at the expense of waveform update rate.
Maybe another approach would be to redraw the old waveform with the pixels turned off, then load the display buffer with the new waveform and then draw the new waveform. Does anyone know how this works on th Quad?
The single trace Nano v3.62 works just as you have described, but the factory version 2.5e did not work that way. Once again the BenF User Guide explains the differences on the Nano.
I got my Quad yesterday, but haven’t had time for extensive testing yet. What I did notice was that the displayed 2Mhz from the Quad generator was completely unrecognizable. Yet a 3.5Mhz squarewave from my function generator looked fairly good with rounded leading edges indicating front end compensation issues. I have not yet tried to compensate the Quad.
This may be somewhat of a digression given the thread topic, but how this is handled has a significant impact on performance and for those with above average interest here is how it’s implemented in the BenF firmware:
On the Nano, this code was a big mess (and still is in the stock firmware) leading to low performance and occasional stuck pixels. The simple solution of course is to redraw everything for every refresh cycle. Unfortunately, a full screen refresh is so time-consuming that frame rate would be severely limited (read-on to see how much slower).
In the BenF firmware, every trace (main waveform, reference waveform, grid lines and cursors) have an identifier embedded as part of its color. That is, color is chosen such that a unique bit is present for each type of trace. So by looking at a single pixel, I can determine from its color code, all waveforms traced through this pixel. From this information it is simple and efficient to remove one trace and leave the others untouched. That is a new vector can be retraced without impacting traces it overlaps.
A waveform is a 300+ point vector whereas the full screen is 300x200 or 60,000 pixels. Reading before writing a pixel doubles processing requirements compared to write only (as would be the case with full refresh), but this is still only a doubling (300+ becomes 600+ pixel operations). Compared to rewriting 60,000 pixels however this is faster by approximately two orders of magnitude (a factor of 100) and so makes a big difference.
Still this issue seems trivial compared to the remaining challenges.
Today I attempted to do some Quad measurements (fresh out of the box sys 1.31, app 2.30. fpga?? (I wanted a base-line before I changed anything)) but I ran into a couple of snags:
All my waveform displays appear to be 1/10 of the sine wave input signal. Where do you set the 1x or 10x probe type? I can’t find a menu choice for that in the Quad Manual 0.91b. Is there a 10x probe selection option?
that is strange , i have tested it before i sent it to you . and , i have told by the designer the Quad do not have the set of 1X or 10X. it recongnize the probe as 1X only .
maybe you need check your peobe again, ensure it is 1X.
Thanks, I just wanted to make sure that there is no probe setting such as in the Nano. Just do the math in your head for 10x probes, OK, but …
There is an obvious mistake in your probe calibration (probe compensation) procedures because you ignore C1A and C2A for 1x probe compensation, yet those caps are always in the circuit and need to be considered. This is especially true if the Quad does not know when a 10x probe is attached. This needs to be sorted out and the probe compensation procedures revised accordingly.
As I said, I used a direct BNC cable, no probe involved. I also tested the MCX to BNC adapter and found zero ohms on the center conductor, so no attenuation there.
I suspect that the calibration is way off because on another scale the display is 1/3rd the input signal.
Apparently you did not test for amplitude on the two scales that I am using, 50mv/Div and 0.5v/Div.
I will calibrate these input ranges and then repeat the tests.
ok, i suggest you upgrage the app,sys and FPGA firmware first and then go on your testing . thanks for your testing reports and i will put your finding to the designer to seek improving the system.
i am now repeat your testing,especilly your finding on applitude error . with app 2.35 sys 1.34 and fpga 2.5