I'm finishing porting my oscope to my new serial library (serpro). So far everything is going smooth. Something you may expect is:
4 channel scope
prescale down to 4 (2 does not work yet - not sure why).
per-channel gain
per-channel vpos control
hpos control
My difficulties lay now on the user interface. Here's a snapshot (unconnected):
I wonder if you can help me improve the UI, so I can release a new version. Improvements may well be new types of components (widgets), like that knob you see there.
Thanks in advance,
Álvaro
PS: clarification - using prescaler 4 I cannot yet use trigger nor interrupt based processing. So, with prescalers 4 and 2 the arduino must be entirely dedicated to scope processing.
prescale down to 4 (2 does not work yet - not sure why).
I understand you've now highly optimized the assembly langage of the ADC ISR routine in order to handle low pre-scaling
Do you confirm being able to have now correct 4 oscope channels pre-scaled at 16 & 8 which I remember on another thread did not work for some reason inside the ADC hardware ?
Do you confirm being able to have now correct 4 oscope channels pre-scaled at 16 & 8 which I remember on another thread did not work for some reason inside the ADC hardware ?
Yes. But I did some changes:
1- Optimization was not done in assembly but in C. By looking at generated asm code I was able to identify pitfalls.
2- ADC now does not run while we transmit data. It actually does not need to, if you're using this as an oscope. If you require it to run, then you might ran into trouble, because it slows down transmission a lot (I'd say it's about 20x slower).
There are however a lot of quantization errors on ADC side at /8 and /4. I cannot do anything actually about it.
ADC now does not run while we transmit data. It actually does not need to, if you're using this as an oscope. If you require it to run, then you might ran into trouble, because it slows down transmission a lot (I'd say it's about 20x slower).
you mean that keeping ISR_ADC was really interfering SerialPro USB packet transmission between arduino & computer ?
There are however a lot of quantization errors on ADC side at /8 and /4. I cannot do anything actually about it.
this is wierd because meaning AVR spec of ADC is fully not respected !
You sure about this ? What data are you basing yourself for this statement ?
Well, when reading the atmega1280 datasheet (section 26, in partiuclar page 278), they say it is ok to go with very low pre-scaling (/2, /4, /8..). Of course, they warn than the resolution would be less that 10 bits plus some care should be taken when changing channels. Diminishing quantization is totally understandable when pre-scaling goes down but this does not explain error quantization which is another phenomae.
Well, when reading the atmega1280 datasheet (section 26, in partiuclar page 278), they say it is ok to go with very low pre-scaling (/2, /4, /8..). Of course, they warn than the resolution would be less that 10 bits plus some care should be taken when changing channels. Diminishing quantization is totally understandable when pre-scaling goes down but this does not explain error quantization which is another phenomae.
Well, they actually only mention prescaling, not core frequency. If you read the ADC specs (in Electrical Characteristics/ADC) you see some interesting numbers:
minimum 13us conversion time, in free-running conversion. Since ADC sample time is 13*ADC clock, this gives 1MHz max sample clock. With a system clock of 16, means 16 prescaler (correct me if I am wrong).
Typical 38.5KHz input bandwidth.
Absolute inaccuracy around 2/3 LSB (not sure if this applies to 8-bit or 10-bit mode).
There's also a note about impedance matching (10k) on ADC inputs, to minimize S&H errors. This one might well be more important than others, if we're to switch channels each sample.
If you read the ADC specs (in Electrical Characteristics/ADC) you see some interesting numbers:
minimum 13us conversion time, in free-running conversion. Since ADC sample time is 13*ADC clock, this gives 1MHz max sample clock. With a system clock of 16, means 16 prescaler (correct me if I am wrong).
Typical 38.5KHz input bandwidth.
very good observation so Atmel datasheet is contradictory between section 26 & ADC specs in Electrical characteristics
You're entirely right so we can only go as low as prescaling of 16 hence max sampling frequency of 16e6/13/16 = 76923 Hz.
Applying Shannon sampling theorem gives half of it hence 38461Hz bandwith explaining why datasheet says max 38,5KHz input frequency.
Ok guys, here's an updated screenshot collection for the new oscilloscope:
4 channel operation, full frame (962 samples each channel), sequential capture with trigger (triggers A, samples A, triggers A, samples B, triggers A, samples C, trigger A, samples D).
Another addition is the DFT (discrete fourier transform):
Not very useful because of bandwith limitation on ADC, but still interesting.
This could be useful for robotics applications. One doesn't need a high bandwidth scope to telemeter dynamic data from the robot itself. 30 KHz is more than enough (even 10 KHz is OK for things that are changing at maybe 100 Hz max for a balance bot). The 4 channels are nice.
As for buttons, somebody came up with a "multi-turn pot" for Processing that is pretty cool. Useful for adjusting PID parameters tightly. It takes quite a few lines of Java code to implement them though.
I've been following this off and on now for a bit; can you link back to your earlier threads that I missed? You mention the 1280; are you implementing this as a shield, a complete product, etc? I've been contemplating a cheap scope (I have available a couple of Parallax USB scopes I won in a Nuts and Volts contest a while back - software is 'doze only, but someone managed to get data out of them using Python, so I was thinking of building my own interface using Python and GTK).
BruceKG: As I remember your scope is in C++ ? How did you implement your dials ?
Custom GTK widget, using pango+cairo. I tried to do the same in Java, but a bug on the Java2D arcs prevented me to implement it properly.
wally: The above shown version is still screenshot only, right ?
(Not yet available for download ?)
How to run the java UI ?
Yes, not yet available. Should have been this week if my hard drive did not crash hard (don't worry I did not lost oscope sources): And no Java UI for now (until I find how to fix the arcs used to draw the knobs).
I've been following this off and on now for a bit; can you link back to your earlier threads that I missed? You mention the 1280; are you implementing this as a shield, a complete product, etc? I've been contemplating a cheap scope (I have available a couple of Parallax USB scopes I won in a Nuts and Volts contest a while back - software is 'doze only, but someone managed to get data out of them using Python, so I was thinking of building my own interface using Python and GTK).
This is all about software. If you need extra functionality on analog side I can help you design it. If you need help on GTK side to use Parallax data, feel free to email me (in a few days, my email system is "recovering" from the HDD crash).
Side Note: I took a look at those Processing knobs. I might use those on the Java version (not yet sure I can do that easily).
Why use knobs at all except for aesthetic reasons? Up/Down selection buttons, drop-down listboxes, custom fill-in text fields - all/any/combo of them is what is more standard in a GUI application, and all likely exist in some form or another in Java (as well as other widget sets).
I will keep your offer of help in mind if/when I get to the point of doing such an implementation (it would be one of those "side" projects that I may or may not get to any time soon)...
Why use knobs at all except for aesthetic reasons?
Technically, none Well, almost none. Those knobs do have some nice functionalities. Like angle-selection values, but yes, all sliders also exhibit those. Still it looks more like a real oscilloscope. I designed those myself, so, for example, if you press 'R' while a specific knob is selected (it changes colour when it has focus) it resets to default value.
Effort was not that high. Otherwise no one would show any interest for it (demoing technical abilities with nice look&feel is a key for success). And I only care about you (arduino fans) interest. Technically I use mostly data data analysers and command line to interact with it.
As for buttons, somebody came up with a "multi-turn pot" for Processing that is pretty cool. Useful for adjusting PID parameters tightly. It takes quite a few lines of Java code to implement them though.
Does someone knows how to convert this code into a java which could be then called from a higher level java UI running on my Macintosh which is compiled via Xcode ?
Sorry, I did not provide instructions on how to build it. I also switched to autotools for UI build, commited just a minute ago.
I'm still working on a nice build system. Until I have that figured out, do like this (linux):
mkdir oscope
cd oscope
git clone git://github.com/alvieboy/arduino-oscope.git -b serpro
git clone git://github.com/alvieboy/arduino-serpro.git -b development
cd arduino-oscope
for i in ../arduino-serpro/*.{cpp,h}; do ln -s $i; done
cd UI && ./configure && make
You will need gtk-2.0, cairo-xlib and optionally ffwt3 to build the UI.
Does someone knows how to convert this code into a java which could be then called from a higher level java UI running on my Macintosh which is compiled via Xcode ?
Working on it. It can be built without processing, but I need to figure out some stuff first. I'm now to update java version of oscope, and I'll use parts of that design (or as a whole, provided it works good without Processing).
Either that, or I need to port my app to processing, which is not probably hard at all.
Álvaro
