DSO firmware version 3.64

BenF, can you planing to add FFT functionality from Paulvvz FFT firmware?

The current feature set is using every single byte of RAM so there really aren’t resources left to implement FFT. A one-off analysis is possible if you export to XML and extract a FFT series from this file with a PC utility.

Hi BenF!

So ROM (program size) is not the problem but the RAM (work memory) is? Do you have to keep everything in RAM which is used in normal mode in FFT mode too? Or is the problem the the whole ROM program has to fit in RAM while running? Two separate program modules? A small loader which gives you choices which program to load?

Kind regards
David

Hi!
Just upgraded to BenF’s firmware 3.62 and i wonder if there are
any required procedures now after? like gain calibration or so?

In my DSO Nano v2 box i got one black probe and one white, which use for plus and minus for measuring?

Nothing is strictly required, but gain calibration can optionally be used to tune the Nano for best possible accuracy. The firmware user’s guide has more information on this topic.

Let’s hope black is minus as this is common convention for DC probes, but you can verify this yourself by connecting the probes to a small battery and check if the measurement (Vavg) agrees with probe polarity and your expectation.

As long as the Nano operates on battery power (not connected to USB), you can safely reverse the probes. Waveforms will then appear inverted and DC measurements will be negative. Do NOT connect the negative (black) probe to the Nano signal generator however as this will short the signal output to ground.

the probe wire with the white strip is positive

Ah, i tried it out today and as you said… white is minus and black is plus :slight_smile:

Im really happy with the firmware! Much better than the original!

BenF,

A few things:

  1. Any chance a continuous “roll” mode could be added; at least for slower time scales? For instance on 1s/div it would be nice to see a continuous real time rolling update (like the old strip recorders) rather than a discreet trigger every 12 seconds …

  2. Is a "pulse’ trigger out of the question? I realize you are looking for a trigger event in real time on a circular buffer rather than doing a search after the fact. I assume that limits the complexity of features/events you can trigger on?

  3. I noticed more strange things from the FIT mode for slow signals. The signal in question is a 0V to 3V square wave @ 10Hz and 10% duty cycle (100ms period, 0V for 90ms, 3V for 10ms). When FIT triggering is used, it settles out at 0.1V/Div, 2ms/Div and a ground reference position slightly below mid screen. Obviously the 3V portion of the signal is off screen. It sometimes finds a slightly different operating point … but it is always close to the above.

Finally:

I’m not sure exactly what the history is between you and seeed, and I’m not sure I want to, but I wish there was a way to get things resolved. I (and it appears many others on this forum) would really like to have access the most recent source. If there is anything we can do to help make that happen, please let us know!

There is an endless list of little things I would like to try and implement (both for utility and for fun), but having to constantly go back an forth between v3.11/3.12 (to use any modifications I might make), and v3.62 to use all the features you have added since, is just not worth it. Out of frustration, I occasionally feel tempted to start an effort to redo your work, but I don’t have the time (or even the skills/knowledge yet). Even if I did, it just wouldn’t feel right to do that. I’ve learned a lot from working with the v3.11 code, and will likely continue to do so mainly out of curiosity, but without the latest source, that’s all it will ever be for me … an interesting curiosity/learning exercise.

I’m really sorry for the rant! You are obviously a decent guy who put a lot of work in on this, and I do appreciate that very much. You turned what was a cool idea with potential into a very useful tool. I just wish I could modify it, see how you accomplished some of the recent improvements, and perhaps even contribute something useful to it myself some day.

Again, let us know if there is anything we can do …

Regards,
Dave

The firmware will change to real-time display mode (triggers ignored) when set to AUTO and T/Div greater/equal to 100ms/Div. This is referred to as SCAN mode in the users guide. Reading your request, I’m sensing that this feature escaped you …?

As long as we can process triggers from a single sequential scan of the input buffer, we should be ok with additional trigger mechanisms. A pulse trigger (high/low greater/less/equal) would be a fairly modest enhancement. Adding a good user interface for setting up the trigger is more of a challenge.

I realize there is a lot to be desired in terms of logic analysis and a lot we could do to improve what we currently have. Going down this path however will be restricted by the lack of a digital connector (the Nano has just about everything required to support 8 high speed channels, except the connector). Putting the same effort into a purpose built device would give a greater return. There are also excellent low cost logic analyzers already available from several sources.

I already looked into this based on your previous comment and realized that automatic ground level positioning is not as straight forward as I thought. The issue is with ground level calibration kicking in and needing time to settle between adjustments (FIT worked quite well in 3.61 and prior). More effort will be needed to get this right.

As for source availability, I was hoping to see some radical new development (hybrid versions) for audio, auto diagnostics and what not. In this context 3.12 may be a better starting point as this version is less optimized with more RAM still available.

BenF,

Thanks for the reply.

This feature did escape me as I rarely use auto trigger. It is similar to what I’m interested in, however not exactly the same. The Roll mode I’m used to (on Agilent scopes … not sure how Tek’s Roll mode works these days) causes the entire waveform to move slowly across the oscilloscope’s display from right to left with the point farthest to the right always being the most recent data point. This (in my opinion at least) gives a much more pleasant display than scanning back and fourth across the screen. It also makes for a nicer, cleaner looking screen capture of continuous trace across the entire span of the screen instead of one with a piece missing. Unfortunately this requires that the entire waveform be redrawn for every new point plotted, but with the very slow update rates needed at these timescales, I think that should not be a huge issue … it could cause some flickering I guess?

I guess I still don’t understand the hangup with the source. Perhaps I never will coming from the academic world where open source is king! The v3.12 code may be the most appropriate for those interested in making radical new developments or “hybrid versions” as you put it, but it is not the greatest for people who simply want to customize their unit, making small changes to the interface, triggering, measurements, color preferences, etc., or who just want to understand better “how things work”, unless they are willing to give up all the progress made since last November. You have indicated in the past that there is little space left for adding new features, and that you have pushed this hardware about as far as is possible. The feature set you have chosen is good, and perhaps even optimal in a general purpose sense, but it would be nice (at least for me) to have the option to personalize it, and if necessary due to space constraints, dump features I won’t often use in favor of implementing features that I would. I try to suggest things here that I think would be of general benefit, but chances are my personal preferences and my wish list are not that same as others, so those preferences/features are not likely to get implemented by you.

Anyways, my apologies for grousing about this again … it’s just a little frustrating. If you want me to drop it, say so and I will.

Best,
Dave

BenF,

I commented on this to tgo in the Quad DSO forum.

The current source code for the Quad DSO (APP_235, SYS_134) is not particularly complex, or well written for that matter (chuckle). It would be not so difficult to simply write these again in a similar way that you have done with the Nano. APP_313 for the Nano appears well coded and well structured, as professional software development should be.

Now it would be great not to have to re-invent the wheel for the Quad DSO since you have already progressed so far with the Nano. Looking through the APP_313 source, there are many, many coding structures that could simply be ported directly to the Quad DSO, and then built upon in order to suit the Quad DSO. The other nice thing with this is that there would be consistent features and usability between the Nano and the Quad DSO.

So I would ask, how about it? Are you prepared to share the source code for v3.62 under the basis that it is to be ported to the Quad DSO and then developed to work with that hardware, by those people that would like to take it on?

The comment that the Quad DSO is a “diamond in the rough” I feel is correct about the Quad DSO, and after looking at the hardware design and currently available resources, it has a lot of potential but is not there yet :slight_smile:.

So why not go ahead then?

It’s not a matter of re-inventing the wheel as you could copy the basic feature set (design ideas) from the Nano and adapt it for the Quad. That is you would know what users expect and need for common fault finding/diagnostics measurement tasks just from reading the Nano users guide. Also there should be plenty to get you started in the Nano 3.12 project files in terms of setting up the development environment, overall design, user interface elements (pop-up’s), profiles and numeric measurement calculations. The 3.62 version is highly optimized for the Nano architecture and so less suitable for direct porting.

Architectural differences between Nano and Quad require some re-thinking in terms of menu navigation, file management and data acquisition, but the fundamental user requirements are the same. If you consider a design where you separate the data acquisition and user interface parts it may be easier to merge future updates from the Quad development team. You could start with replacing the user interface and take on acquisitions, buffer management at a later stage.

Anyway I believe it is matter of getting started with coding and show Quad owners some real progress. If you have what it takes – the building blocks are there to get you started.

BenF,

This answers the question of starting point :slight_smile:, besides I have never been keen on a straight port, as the QuadDSO has its own set of potential and features, and that needs to be developed specifically. Otherwise I believe that we have answered the necessary questions for starting from the best point, apart from the latest source versions for the QuadDSO directly. Agreed, that if the system blocks are carefully seperated, menu, capture, processing, then original firmware developments, can easily be incorporated. Quite besides, the menu and navigation is a more simplistic starting point to re-stucture the coding and design.

You shude be abel to to change the name of the file without a computer.
Why, I do not know what the file is and what it is from :confused:

High capacity SD cards (SDHC) now appear to be easier to come by than their lower capacity predecessors. The 3.64 version update of the firmware allows either type to be used. Increased capacity may in itself not be a concern, but I trust availability is. Use the FAT32 file system with the high capacity cards.

Hi all,

I just bought the nano based on recommendations on diyaudio. I installed Ben’s latest firmware. I want to use it for tube-amplifier measurements. As a start I tried to measure the ripple on a 24V power supply. All I get is a straight line at the 24V DC-level of the psu. I read Ben’s user guide. I tried several things. (FIT doesnt work.) I searched the web. How can I get a nice big sinus of the ripple sitting on the 24V-rail? How can I do the same for lets say a 400V PSU? Can it be done at all?

Merten

For accurate ripple measurements, you need an AC coupled probe and this is not standard issue with a Nano. AC coupling acts like a high pass filter where the DC component gets eliminated from the input so that the full DSO range can be used for the ripple itself. This is typically handled by circuitry internal to the DSO, but the Nano is hardware limited to DC coupling.

Due to its relatively high vertical sampling resolution, Nano users may still get a decent measure of ripple for low voltage circuits, and some provisions were made in firmware to facilitate this. Forum user lygra prepared a video that explains this in some detail.

http://www.youtube.com/watch?v=NUx9ulEjvLA

For 24V circuits and beyond however, this approach may not be practical.

Thank You. I tried a cap (0,1 µF) in series with the probe. it seems to work fine. i already measured rms-voltages around 100 volts in a tube amp. for reference i measured a pure ac signal with and without cap: the results are similar, maybe the same.

best regards, Merten

Glad to see you’re still around BenF. May we please have some simple IIR low, high, and bandpass/stop filters for the scope in the latest firmware?

I have found a bug in the latest firmware (v3.64).
My DSO nano V1 gets stuck every time that I try to enter the “ME” mode with “DSO BenF Firmware v3.64”.
I have downgraded it to “DSO BenF Firmware v3.62” and now it works fine.