Tiny Scope

Status
Not open for further replies.

Laur

Active member
I realize this is just a toy, but it's still fun to play with and pretty useful when I need to see whether the pins are signaling or just floating around. A picture is worth a thousand words:

aaa.jpg bbb.jpg ccc.jpg

There's an automatic voltmeter mode that kicks in when the input is relatively stable and I'd be staring at a flat line. There's a zero trigger and a sane ms/div value displayed (the grid changes to accomodate). I used the SSD1306 OLED screen. Code is here: https://github.com/laurb9/tiny_scope

This works on both Arduino UNO and Teensy 3.1. I'm using the stock analogRead() for now without any optimizations, but I do change the ADC parameters to get different sampling speeds. In the tiny_scope.ino, there is an ADC_MODE value that can be changed from 0 (slowest) to 5 (fastest). I can reach sampling rates from 10Ksps to about 300K on Teensy. I should probably add a button for that.

One thing I did notice though, with Arduino 1.0.6 code size is 26K and fastest sampling speed is about 330Ksps. Same code with Arduino 1.6 (beta) is 45K and speed drops to about 250K. Still a lot faster than what I get on the UNO.

This is the assembled project:
tiny_scope_on_teensy31.jpg
 
A pen sized analysis device, almost. One step closer to a sonic screwdriver... Now, just add a super inductive magic magneto unlocker thinga majig and you are set.
 
Nice implementation with the auto volt meter.

Now has me thinking if I could use a pen sized oscilloscope. Idea would be to have a earth lead hanging out the back and the display mounted sticking out the side near the probe tip so you could see both the test point and the wave form present, in a tool with only a single lead on it for minimal tangles.

Would be getting close to my dream of a wireless oscilloscope.

Question remains if attempting to do Anything else while poking a probe tip into something delicate is actually a good idea, or if you should just do it right the first time and use clips or a second pair of eyes.

May be time to see what the bits box has in it mini display wise.

GW
 
Last edited:
Thank you everybody. Next steps are to try and see if I can read the ADC any faster (I know on Arduino there is a lot of setup stuff in readAnalog() that only needs done once per loop), add a button to change sampling speed, and try and integrate an FFT lib to display frequency. Maybe auto select the correct time base range although that's not always a good idea.

What is the impedance of the ADC input ? thinking to use 10:1 voltage divider with two resistors and use the internal reference to handle 12V input.
 
If you are prepared to make things Teensy specific there is the ADC library
https://forum.pjrc.com/threads/25532-ADC-library-update-now-with-support-for-Teensy-3-1

Which offers a range of modes to achieve high throughput rates. I believe the theoretical peak rate is ~1Mhz for the ADC (at reduced resolution) which is quite remarkable. Still leaves a bunch of questions on usefully processing that data of course. Data sheet here:
https://www.pjrc.com/teensy/K20P64M50SF0.pdf
lists input resistance as 2K which I find surprising. Based on my own resistive divider setup I'd have called >1M unless that value is for the instant the capture and hold circuit is in operation

One thing to think about is how to trigger the capture of burst signals and the fun signal processing that brings.

Things do of course reach a point of diminishing returns when working in a 1 inch display and a generic uC ADC input but it's a nifty project.
 
Thanks, I'll take a look. 1MHz is actually faster than the spec sheet (818Msps) ?

The schematic on page 37 shows Radin to be in series with the input and not across ground, then it makes sense that the actual input impedance has to be orders of magnitude higher otherwise it would create a voltage divider itself.

I'm learning stuff as I do this, otherwise it would not be that much fun. This is my first uc project in many years.
 
I think the 1Mhz rate with running above speced clock at 8bit resolution with the ADC free running (producing values as it completed conversion, and not doing anything with them). The 800khz number seems more achievable in actual use.

Is the code all your work?

It seemed to be making a lot of hardware specific calls and inclusion of .Cpp and .H files that certainly worked but may be more robust in arduiniified form. On the other hand if it works don't knock it.
 
Yeah the code in the repo is mine*. It's maybe not great because my C++ is extremely rusty. I don't know what Arduinified means, but I didn't like working with a large .ino file if that's what it is. Plus I'm used to breaking up functionality in separate manageable modules hence the many files. Arduino does some strange things with the .ino source too and I didn't want that to interfere with the rest of the code, although that did create some interesting problems with linking against the other libraries.

*) except the printf piece that I found at the URL mentioned there, and the sbi/cbi business for setting the prescaler in adc_avr is from one of the URLs quoted at the top of that page.
 
Last edited:
It seemed to be making a lot of hardware specific calls and inclusion of .Cpp and .H files that certainly worked but may be more robust in arduiniified form. On the other hand if it works don't knock it.

I don't know what Arduinified means, but I didn't like working with a large .ino file if that's what it is.

Arduinified in this case means that whenever you have the choice between using an arduino-style interface (Serial.begin() - things like that) and directly manipulating hardware registers, you should use the available arduino-style interface. In that case it's easier for other to port your code to other hardware for which the same arduino-style interface is available.

(If you're using very specific hardware features other arduino-like hardware doesn't provide, you simply don't have the above choice.)
 
I see. In that case, that would be my preference as well, unfortunately I didn't find an Arduino way to change the ADC speed for the AVR side. On the Teensy side I haven't gotten that far so it's still teensified I guess :)
 
update

(update) using the pedvide ADC library, I was able to get up to 1.2Msps on the Teensy 3.1 (I think the LC also gets pretty close as well). At that speed it needs a strong input signal to get an accurate waveform, but it's nice to have nevertheless.

https://github.com/laurb9/tiny_scope/releases

DSC04718.JPG

DSC04717.JPG

(the older Arduino branch should work on most other boards, but at reduced speed)
 
Very Cool! When I take your code all seems well except for the 1306 library gives me this error with IDE 1.6.8? three times in { drawPixel, drawFastHLine, drawFastVLine }:

I:\Teensy168\hardware\teensy\avr\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp: In member function 'virtual void Adafruit_SSD1306::drawFastHLine(int16_t, int16_t, int16_t, uint16_t)':
I:\Teensy168\hardware\teensy\avr\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:565:16: error: 'swap' was not declared in this scope

swap(x, y);

<edit> BTW - this is the 1306 library from the TeensyDuinoInstall - as noted in the path linked above. Is this a problem from the library in use or perhaps some oddity from the 1.6.8 IDE? I'll have to build up a Teensy and display before I can try it - so I didn't look at the error myself as I assume it must be something obvious?

Looking at the code I see :
A1 (pin 15) as the sensor pin and Big Blue the Button as
Code:
// Which digital input the button is on - use to cycle through all the ADC modes
#define MODE_BUTTON_PIN 7
 
Last edited:
I found SWAP here :: Adafruit_SSD1306.cpp#L111
Code:
#define ssd1306_swap(a, b) { int16_t t = a; a = b; b = t; }

The current 1.28b1 TDInstall version of Adafruit_SSD1306 does not have that (or other) #define - but it does use "swap()" - that must have disappeared from whence it came? I don't see that in the 1.28b1 tree with a grep.

Paul / Luar :: Does this suggest that the SSD1306 needs updated from AdaFruit version? As it is I would guess nothing will build from the included Adafruit_SSD1306.
 
Very Cool! When I take your code all seems well except for the 1306 library gives me this error with IDE 1.6.8? three times in { drawPixel, drawFastHLine, drawFastVLine }:



<edit> BTW - this is the 1306 library from the TeensyDuinoInstall - as noted in the path linked above. Is this a problem from the library in use or perhaps some oddity from the 1.6.8 IDE? I'll have to build up a Teensy and display before I can try it - so I didn't look at the error myself as I assume it must be something obvious?

It does look like a problem with the library. I would check if the simple SSD_1306 example compiles at all. I use 1.6.7 myself.

Looking at the code I see :
A1 (pin 15) as the sensor pin and Big Blue the Button as
Code:
// Which digital input the button is on - use to cycle through all the ADC modes
#define MODE_BUTTON_PIN 7

Are you asking about the connections ? Take a look at the README.md file under Connections: https://github.com/laurb9/tiny_scope/blob/teensy/README.md
 
It does look like a problem with the library. I would check if the simple SSD_1306 example compiles at all. I use 1.6.7 myself.


Are you asking about the connections ? Take a look at the README.md file under Connections: https://github.com/laurb9/tiny_scope/blob/teensy/README.md

No that was meant as a statement -pulled from the code - the comment is 'yours'

Tried this sample - the build is broken - that new ssd1306_swap came into Adafruit and left wherever 'swap' was before:

BUSTED:
I:\Teensy168\hardware\teensy\avr\libraries\Adafruit_SSD1306\examples\ssd1306_128x64_i2c

TONS of COMPILE GRIEF - plus the SWAP :: View attachment 1306_128.txt
 
I just confirmed my that sample : I:\Teensy167\hardware\teensy\avr\libraries\Adafruit_SSD1306\examples\ssd1306_128x64_i2c

Does build with IDE 1.6.7 and TeensyDuino 1.27
 
I just confirmed my that sample : I:\Teensy167\hardware\teensy\avr\libraries\Adafruit_SSD1306\examples\ssd1306_128x64_i2c

Does build with IDE 1.6.7 and TeensyDuino 1.27

Thanks for confirming. I guess I'm not going to be upgrading just yet...
 
Status
Not open for further replies.
Back
Top