$10 O-Scope revisited

Yesterday evening I played a little with this scope, an ESC, a BLDC and a bike battary box..

Some annots..
1st..
My STM32-O-Scope Wiki.pdf tells me on pin usage, PB0 is input and PB1 test signal.
But my source stolen from Git is telling vice versa, PB0 test and PB1 input.
TFT backlight was PA3..

Just even stolen ino is telling PB1 for both, test&input, PB0 for board_LED ???

2nd..
Playing with the scope I forgot, it’s only a breakout, for I read something like 3V/div.
Unfortunately my batt has 7.2(8.4) V..
Magic smoke escaped immediately and forced some bad bad smell
But the screen was still displayed, only the graph was gone.
So I recompiled with switched ports:
test&input on PA3/4, backlight on PB0.
First all was fine.
But time after time weired things happend, double pics appeared moved and rotated.
After connecting backlight to VCC all was fine again.
Maybe frying of PB1 has damaged PB0 too.

So always keep in mind:
O-Scope isn’t a tiny osci, no input divider, breakout only!!

bianchifan wrote:Yesterday evening I played a little with this scope, an ESC, a BLDC and a bike battary box..
Magic smoke escaped immediately and forced some bad bad smell

mrmonteith wrote:bianchifan wrote:Yesterday evening I played a little with this scope, an ESC, a BLDC and a bike battary box..
Magic smoke escaped immediately and forced some bad bad smell

The lack of input protection, and the experimental nature of the $10 scope has been mentioned a few times, in fact, it has been mentioned at least three times in this thread.

viewtopic.php?t=107&start=190#p8868

viewtopic.php?t=107&start=70#p1614

viewtopic.php?t=107&start=170#p6908

… and so far as I recall in Ray’s original version, from which this developed.

I’m open to suggestions for improvement, so if someone feels like designing a protected front end for it (preferably software controlled ) and is willing to share that design, then I’ll take a crack at improving the software. Input protection in the form of an attenuator, zeners to clamp the voltage, a fuse and perhaps a mov would be the bare minimum, but as I say, I’m open to any ideas.

Oh.. and a warm welcome bianchifan to the Magic Smoke club…. It is a popular venue, with four pages of contributions.

Andy,
I might start looking around at some options. My first initial thought is a good op-amp front end. It would allow attenuation/gain control as well as protection. Better to sacrifice the op-amp than the micro. Putting zener protection after the op-amp as a last attempt at further protection.

I’ve also been looking at playing with programmable potentiometers. I had to purchase some for a project that I assembled. The guy used it to tune a circuit. So it those might work for programmable attenuation etc. They would also make for calibration as well.

Anyway I’ll see what I find on the subject and share what I come up with, right or wrong. I’m all for sharing. That’s how you learn. You share what you have and sometimes you learn from others what might be something you haven’t thought of.

Michael

ahull wrote:I’m open to suggestions for improvement.

bianchifan wrote:ahull wrote:I’m open to suggestions for improvement.

Input protection for an inexpensive scope is fairly straight forward at low frequencies. For example, an image search on Google for “oscilloscope input protection circuit” will provide numerous circuits, many passive. Were I doing an implementation, I would probably put it into a SPICE package and play with square wave inputs.

pcscopecircuit.jpg

pcscopecircuit.jpg (22.84 KiB) Viewed 1773 times

Looks like we may have a confused pig.

DavidPilling has spotted an issue with the data array order, full details in the link below.

https://github.com/pingumacpenguin/STM3 … -180469664

It seems I have assumed the order of the samples in the array to be ADC1, ADC2 but in reality the data appears in the array as ADC2,ADC1 and this will make the plots somewhat jaggy. I haven’t had time to verify this, as I’m caught up with other things these days, can anybody verify that David is correct. Better still can they suggest a fix. Can we change the ordering of the data as it is placed in the array, or do we simply need to honour that order while spitting out the results, to the display and/or the serial port?

I’d be happy to tweek the code (assuming it needs it), but I don’t have a TFT at the moment, so if I do it, it will take a few weeks.

David Pilling wrote:I’d be happy to tweek the code (assuming it needs it), but I don’t have a TFT at the moment, so if I do it, it will take a few weeks.

I’ll do that and let you know…

David Pilling wrote:I’ll do that and let you know…

I’ve been playing with the HC-SR04 ultrasonic ranging module. For many purposes it works fine as supplied. But I’ve been using it at short ranges measuring small changes in distance. To do that requires extracting the analogue signals from it. I’ve done that and got the results I wanted using ATMega 328p and very modest analogue signal processing. However I fancied having a go at digital signal processing – which is where the STM32 and your o-scope code came in.

David Pilling wrote:I’ve been playing with the HC-SR04 ultrasonic ranging module. For many purposes it works fine as supplied. But I’ve been using it at short ranges measuring small changes in distance. To do that requires extracting the analogue signals from it. I’ve done that and got the results I wanted using ATMega 328p and very modest analogue signal processing. However I fancied having a go at digital signal processing – which is where the STM32 and your o-scope code came in.

ahull wrote:David Pilling wrote:I’ve been playing with the HC-SR04 ultrasonic ranging module. For many purposes it works fine as supplied. But I’ve been using it at short ranges measuring small changes in distance.

I’ve managed to setup arduino IDE 1.6.3 with Arduino_STM32 hardware library.

I’m able to compile blinky example and other examples but I’m having a problem with O-Scope code.
I’ve already downloaded Time library and SerialCommands also.

But I’m getting these errors:

STM32-O-Scope.ino: In function ‘void setup()’:
STM32-O-Scope.ino:261:12: error: ‘setADCs’ was not declared in this scope
STM32-O-Scope.ino:266:34: error: ‘setCurrentTime’ was not declared in this scope
STM32-O-Scope.ino:267:34: error: ‘serialCurrentTime’ was not declared in this scope

I know that I can manually add the prototypes on the beggining of the code for each one but it’s a pain and if it works for other there might be something wrong in my setup…

Help?

Edit: I’m using 1.6.3 because 1.6.5 wasn’t working but I’ve tested now on 1.6.5 and it has the same errors.

See http://www.stm32duino.com/viewtopic.php … =140#p4959 for details, but its a bug in the code whereby the

#define TOUCH_SCREEN_AVAILABLE stuff doesn’t work as expected. Leave the TOUCH_SCREEN_AVAILABLE defined, and it should work.

ahull wrote:See http://www.stm32duino.com/viewtopic.php … =140#p4959 for details, but its a bug in the code whereby the

#define TOUCH_SCREEN_AVAILABLE stuff doesn’t work as expected. Leave the TOUCH_SCREEN_AVAILABLE defined, and it should work.

rexnanet wrote:
<…>
Then I got the “Time” library issue, renamed to “Time1.h .cpp”.
<…>