Articles Hierarchy

Articles Home » Arduino Projects » ARDUINO PROJECT: SCOPE


7. processing and firmata
here to mention also the processing using the firmata, means
on arduino you load a ready application FIRMATA ( from library),
and then you can use / operate / the I/O of the arduino board
just by the software on the PC ( inside the processing )
test from here:
-- a digital output to the onboard LED ( by mouse click )
-- a analog read of A0 : my onboard Voltmeter as a one line command!!
text("A0 [V]:"+float(arduino.analogRead(0))*5/1023,10,80);

with a jumper from analog input (A0) to
-- 5V read 5.000
-- digital output 13 ( on board LED ) read 4.830 ( if ON ) 0 ( if OFF )

using ARDUINO ( this way ) as linked I/O board ( ok USB is not very REMOTE I/O )
and doing the programming in processing ( on PC ) is a perfect environment
for learn and play. No upload required between tests.
The processing applications are not limited to ATmega specs,
and you have the higher features there like screen, keyboard, file I/O...
Much better as only a terminal window over your ARDUINO.

but for stand alone applications you need to do your own ARDUINO programming.
So using FIMATA and PROCESSING depends on what u want to build.
Mixing own program for ARDUINO and FIRMATA i need to test later.

from above processing and firmata doing a Volt meter
next step after bargraph indication is the scope.
lots of online info at arduino and friendly sites.

using libraries from
-- David Konsumer
-- controlP5
makes the processing window easy. But soon find out,
again its the serial interface what creates the problems.

-- using only the screen and doing a from firmata
works nice and easy, the samplerate is like the framerate processing, about 22Hz.

-- using his arduino sketch (6 Ain, and digital in too) at 115200 bd on the link
get always exeption error, but sample rate near 200Hz

-- not use the digital In part

-- reducing to 2 channel, also on arduino side, get over 500Hz

-- speed up by reduce from 10 to 8 bit AD could help even more on the arduino side.

Forget the speed ( Sample rate ),
( and as other have seen it too, netbook processor at 100% )
first the serial communication must be stabil.
( note there is a bug report about ARDUINO UNO serial problem at 57600 ( 2x mode) )

i will test a software handshake in the form of
-- processing ask for n analog readings ( if the analog read on ardiuno is too slow )
by sending a number 1 .. 6
-- arduino does the sampling and send the data ( same format )
-- processing answers again with the number of channels it wants to sample.
( filename: mini_scope_syncro_kll.pde ( for processing and arduino ))
so, it was not impressive, 120Hz at 2 channel, 80Hz at 6 channel.
but processor load on PC down to 70% and no communication problems.

so back to DAVIDs software.
- after making the channels ( ARDUINO jobs analog read ) adjustable,
key: 1,2,3,4,5,6 channels to read
- and also a delaytimer adjustable from default 6 ms up down
key + -
you can find a optimum samplerate for your system, with stabil communication.
but the rate:
-- 100 to 350 Hz on the netbook
-- 600 Hz on the desktop
thats not what a ARDUINO can do!

so we change from online to batch data transfer.
( on the original processing scope software from DAVID ( with above mods )
a new key entry / button switch ARDUINO to a one shot ZOOM

read 512 data of A0 to array, send it with start stop indication and delay to processing
and catch it there in a local array and open a new ZOOM window to show this data.

key z
need about 2 sec to fill the new window
with 512 samples of a timewindow of about 0.057 seconds.
-- see 28 PWM signal waves (490Hz) ( with 10 ..90% ontime good visual ) ( 18 samples / wave )
-- see 3 50 Hz waves noise
thats a sample rate of about 8900Hz. ( from the 10000Hz possible acc. to documentation )
and, if we later improve the ARDUINO code,
a higher rate is possible, because this way the datatransfer ( in batch we are kind of offline)
not causes any problems.
But we know the serial data transfer ( main window scope ) is the bottleneck
also see DAVIDs mail:
looks very cool!

Once I get a bit more time, I would be psyched to integrate this into the google code project.

I think maybe instead of looping + startbatch,endbatch it might make sense to do some binary pin magic,
and send less chars per frame. i am not so good at this, but may be able to find some help from a friend.

it seems like even sending data that looks like this might be a bit more efficient then either of us are using:

I feel like some binary pin magic on polling loop + a more efficient way of transmitting all the values
of the frames would further add better speed

thanks for your work on this. I am currently a bit swamped with work, but once I get a bit more free time,
I would be really happy to integrate these changes.

yes, thats the point, i see it in the 1000 loop count signal ( the high is longer as the low time )
and i see it in the samplerate, jump between 600Hz and 750Hz.
if a signal is HIGH we send "1023," in ascii as 5 characters, a LOW is "0," as 2 chars.
if we send as record ( integer ) and no seperator it would be 2 bytes only.
(!! integer ARDUINO 2 byte, integer Processing 4 bytes )
For a frame i selected 8 integer, as 16 bytes, 6 for analog read, 1 for digital in / spare, 1 for frameend, control..
and ended up with nearly same speed ( at 1 channel sampling, but 8 words sending, delay 0)
about 730 Hz. So also this was not a step foreward. if the bytes could be reduced to half
( by sending 1 byte per channel) we loose our resolution of 10bit.

so i go back to my ascii version and made it more nice ( with buttons ..)
the combination of 2 window and the controlP5 buttonfunction is tricky.

for testing i changed the ARDUINO code to get a 1 sec pulse on Dout 11. It would be nice if somebody with calibration hardware ( signalgenerator..) could verify any of my timing info. now in V0.5 A0zoom window has SAVE and FFT button (spectrum analysis).
( fft from the minim library of processing ),shown in the zoom window
and detail info printed in the debug window.
the set samplerate for this function (8900 Hz) to be checked.

the main scope window only 3 channel from ARDUINO reported with buttons

the zoom window on A0 reading a PWM signal 50% ON (D11)
the zoom window on A0 reading a PWM signal 10% ON (D10)
the zoom window on A0 reading a noise signal from fingertip ( must be 50Hz )
the zoom window on A0 reading a noise signal and made FFT

the processing program window with FFT debug list ( pls find 50Hz )

check out source code.

while working on analog signal output september 2013 i made new scope software , pls. follow up there at PMS3