Tag Archives: Leonardo.

What if kids could hack a ball? (Prototyped with Arduino!)

via Arduino Blog


Hackaball is a smart and responsive ball that children can program to invent and play games. It was recently backed by more than 1000 people and reached the goal!

As many other projects on Kickstarter, Hackaball was initially prototyped with Arduino using sensors that detect motions like being dropped, bounced, kicked, shaken or being perfectly still.

We got in touch with its team and asked them to tell us a bit more about the creation process:

Our early versions of the ball worked with the Arduino Uno board, progressing to a breadboard Arduino and then making our own SMD designs with the Uno. In the latests prototypes we used the Arduino Leonardo and our current version runs on the Arduino Mega. Our production version will run on an ARM chip.

We hope to offer Arduino Compatibility as one of our stretch goals in the Kickstarter, so that people can buy a board and put their own code on it using the Arduino software, effectively moving one step up from the app in terms of hacking the ball and making it do what you want it to do. We also believe many adults would love an interactive ball that they can control and design their own interactions – its packed full of features! Hopefully it will also allow kids who’ve outgrown our app to experiment with our technology in a more challenging way, bringing longevity to the product.

We’ve approached the kids who’ll play with Hackaball as the future Makers. The idea of hacking and getting close to technology starts with how the ball first arrives in your home. Kids open the packaging to find the ball is broken: Hackaball has crash-landed on earth and needs to be put back together again. After their first achievement, making the ball, kids are challenged to play games, change existing ones, fix broken games and create new ones from scratch.

We specifically designed the ball and packaging to be gender neutral – making it feel accessible to both boys and girls from the very beginning. We also expanded on the ability of the ball to include both hard and soft skills – from the tactile and linear computational thinking, to the storytelling and imagination-driven game creation, teaching a new generation of Makers to combine technology and creativity. We think that the kids who play with Hackaball would move on to Arduino in their teens!


You still have some days to back the project and help them reach the stretch goals, making Hackaball even more hackable!

Follow your cat with FPV camera and Arduino Leonardo

via Arduino Blog


After the Bike Tachometer we posted back in September, Nikus  shared with us a new Instructable to show you how to build remote-controlled tank using a first person view (FPV) camera and Arduino Leonardo:

At the beginning I build only RC tank without FPV camera but when I was driving it in the house I have not seen where it is. So I came up with that I will add to it the camera mounted on a 2 servos. The range is about 100m, you can also ride with it at home. With this tank you can see what your cat is doing when you’re not looking. You can see it on a video :D

Watch it in action and follow the tutorial:


A bike tachometer measuring more than just speed

via Arduino Blog


Nikodem is a young maker  based in Poland and shared with us his latest project based on Arduino Leonardo. It’s a DIY bike tachometer providing you with a set of additional information:

It shows your speed, the average speed, the temperature, the trip time and the total distance. You can change it using the button. Additionally, the speed is shown on a tachometer. I built it because I like building new things, I have not found anything like this on the internet so I want to show you how to build a good speedometer as the one on my bike is not as cool as I want :) .

You can find all the steps to make one yourself on  his Instructable account, and in the meanwhile take a look at the two videos below.



Music and language skills get a boost with Toot

via Arduino Blog


Toot is an interactive and sound-active toy designed for children aged between 3 and 6 years old that wants to enhance their auditory, music and language skills. It was developed by Federico Lameri as his thesis project of Master of Interaction Design at Supsi and prototyped using Arduino Leonardo.

The toy is composed by eight little cubical speaker boxes:

On each speaker children are able to record a sound. In order to listen back to the recorded sound the speaker must be shaken as if the sound was physically trapped into a box. After having recorded sounds on them, the speakers can be placed in a sequence after Mr.toot, and by tapping on his head it is possible to trigger the playback of the speakers in a sequence. toot is also matched with a mobile application that offers different kind of interactions and experiences. it allows to play some exercise that will teach children to listen, understand and catalog sound and melodies.


The app expands the possibilities of interaction, offering different exercises created with the help of musicians and educators from different areas of expertise,  some of them are also inspired by a Montessori sensorial activity.

Take a look at the video interview with Montessori educator Fanny Bissa:


Let your Arduino talk with your Android

via Arduino Blog


Annikken Andee is a Bluetooth Arduino shield, currently on an Indiegogo campaign, that let  Arduino communicate with  Android device without writing Android code.

With the growing popularity of smart phones in this time and era it’s interesting to explore how Arduino could tap on the strength of smart phones – touch screen capability and smart phone capability. However for the integration to work, one has to develop the corresponding Smart phone app to handle the bluetooth communication and provide a stable GUI on the screen.

Therefore to make things easier for Arduino developers who wish to tap on the power on smartphone, the Singapore-based team came up Annikken Andee project, an Arduino shield, with supporting resources, that performs primarily the following actions:

  • handles the communication between Android and Arduino
  • GUI creation on smartphone by coding on Arduino. Requires no Smartphone App programming
  • accesses to Smartphone functions from Arduino Library
  • provides larger, portable and non-volatile storage

The shield communicates with Arduino via the ICSP header (SPI) and pin 8. An SD card Reader is available for external data storage for Arduino –  for huge data storage or extended period of data logging activity by Arduino. As Android has yet to support for Bluetooth 4.0/BLE, they are using bluetooth 2.1 module WT11i by Bluegiga for communicating with the Android phone. Currently the shield supports Arduino Uno, Mega and Leonardo.

Robin, part of the Team Annikken Ande, wrote us:

With Andee, Arduino user can program the UI on their Android phone by downloading the Andee Arduino Library onto their Arduino IDE and the Andee Android App into their Android phone from google play store. Using the functions in the Arduino library, user can easily design the UI on the Andee Android App without touching Android programming.

As we hope to spread the news of this invention to as many people as possible, we believe that arduino.cc is the perfect place to help us make this work.




Two Arduino-based Kickstarter projects worth a look

via Arduino Blog

SmartCitizen kit
Some weeks ago I read an article on the New York Times talking about Kickstarter. The author was exploring the logic of the platform and especially in which way backers shouldn’t really be considered like investors. They aren’t because their main aim is not looking for the project that will give them the greatest return on their money.

Kickstarter as a phenomenon is made much more comprehensible once you realize that it’s not following the logic of the free market; it’s following the logic of the gift […] People contribute to them because they’re friends who know the artist personally; they’re fans engaged in a highly personal if unidirectional relationship with the artist [creator]; or simply because they’re intrigued by the project and want some sense of participation in it.

Here we are then, highlighting  two Arduino-based projects because we are intrigued by them and hope you like them too.

Smart Citizen

After successfully putting the Smart Citizen Kit in the hand of over 150 users around Barcelona in Spain, the team – organized by Fablab Barcelona and involving collaborations from all over the world – is ready for the next, and most crucial step and they need your help. The Smart Citizen Kit infact is an Open-Source Environmental Monitoring Platform consisting of arduino-compatible hardware, data visualization web API, and mobile app, empowering communities to collect data of what’s actually happening in their environment.

GOAL: $50,000

PROJECT ENDS: June 16, 2013
Check out what are their plans in the video!


Bot Logic Hexapod

Many hexapods can’t sense they’ve reached the edge of a surface without a lot of additional hardware expense and complexity and this kit solves the problem! BOT-LOGIC is an easy-to-assemble hexapod kit & controller that enables servos to also act as sensors to control the force applied as well as measuring force at set positions. Robots are thus enabled to sense surface edges and uneven servo load as well as measure and maintain gripper force.

GOAL: $10,000

PROJECT ENDS: July 10, 2013

Check the details in the video below:

The joystick that changed a life and could help many more

via Arduino Blog


Robert Book is a tinkerer by nature and works at Silicon Valley Bank with Ian McCutcheon, a geek by nature. One day they were talking and Robert shared his big problem: his son Jerry, who suffers from Muscular Dystrophy, couldn’t use a keyboard anymore but loved to play computer games. Jerry could only be able to use a mouse with his right hand and very limited abilities in his left.

After a chat they realized that if they put their heads together they could make something that might enable him to play the different computer games with more ease and enjoyment.
Ian knew that Arduino Leonardo has a great capability, it can emulate a keyboard and a mouse and soon they came up with the first release of an augmented joystick making Jerry much happier. This collaboration became a great story  you can watch in the video below and it’s going to make even more people happy thanks to the shared code to build the joystick yourself.


How to make something like “Makey Makey” using Arduino

via Arduino Blog

Makey Makey with Arduino

Many people asked Alpesh Vitha how to create something like Makey Makey using Arduino and he created this cool video, together with Mowgli, to share with all of us how to use an Arduino Leonardo to accomplish the task. He lives in Kolkata and  runs a company called “Inventify” to popularize Arduino and science in Indian schools especially those with less resources. Enjoy the video tutorial !




Bleuette, the hexapod robot

via Arduino Blog

bleuette hexapod robot

Bleuette project is hexapod robot equipped with 6 legs that can be operated without any external guidance.

The french project is fully open hardware (made entirely with  an Ultimaker 3D printer) / opensource and operates on a Arduino Leonardo board with a custom shield developed for it and available on Hugo’s website, the author of the project. It is used mostly to control the 12 servos (+ 2 optional) for the legs, measure voltage and current.

Take a look at the robot’s first steps!


Hugo is also thinking about future developments for Bleuette, like equipping it with a Bluetooth connection, a magnetic sensor to keep an edge when walking and finally a mobile turret with an ultrasonic sensor to detect obstacles in front of it.

Interested in the code? you can find it on Github:

The Arcade Machine, by Timothy (15)

via Arduino Blog

[Timothy Zandelin], a 15 years old Arduino enthusiast has sent us his first Arduino Project, an arcade interface based on Arduino Leonardo.

The cabinet is made of 4mm HDF and were laser cut at “Fabriken” in Malmö. The red arcade sign in the top is produced in 5mm translucent acrylic. All design and construction drawings were made in Illustrator. I used an Arduino Leonardo to connect the joystick, buttons and the LED light.  The game installed, Superstar Chefs, is an old game developed by my dad’s cousins.

On the other hand, Timothy also built his own prototyping board to learn about how to use different inputs and outputs.

My prototype board was made with Fritzing.

It includes:

- 6 green 3mm LED’s,

- 11 resistors (6 330 ohm, 4 10K ohm and one 100 ohm),

-1 dip8 socket with an ATtiny45,

- 1 potentiometer,

- 4 pushbutton and header sockets.

I created this prototype board to easily get started with Arduino.

Timothy, welcome on board!

New Arduino Micro available

via Arduino Blog

We’re happy to announce the release of the new Arduino Micro board.

The Arduino Micro packs all of the power of the Arduino Leonardo in a 48mm x 18mm module (1.9? x 0.7?).

It makes it easier for makers to embed the Arduino technology inside their projects by providing a small and convenient module that can be either used on a breadboard or soldered to a custom designed PCB.

The Micro has been developed in collaboration with Adafruit Industries, one of the leaders of the Maker movement. Adafruit is already developing a series of accessories for the new board that will complement its power and simplicity.

Throughout the month of November the product is available exclusively from Adafruit online and Radio Shack in retail stores.

Main features of Arduino Micro:

  • The Arduino Micro is a microcontroller board based on the ATmega32u4.
  • Like its brother the Leonardo board, the Arduino Micro has one microcontroller with built-in USB. Using the ATmega32U4 as its sole microcontroller allows it to be cheaper and simpler. Also, because the 32U4 is handling the USB directly, code libraries are available which allow the board to emulate a computer keyboard, mouse, and more using the USB-HID protocol.
  • It has 20 digital input/output pins (of which 7 can be used as PWM outputs and 12 as analog inputs), a 16 MHz crystal oscillator, a micro USB connection, an ICSP header, and a reset button. It contains everything needed to support the microcontroller; simply connect it to a computer with a micro USB cable to get started.
  • This allows the Micro to appear to a connected computer as a mouse and keyboard, in addition to a virtual (CDC) serial / COM port.

Technical specifications:

  • Microcontroller: ATmega32u4
  • Operating Voltage: 5V
  • Input Voltage (recommended): 7-12V
  • Input Voltage (limits): 6-20V
  • Digital I/O Pins: 20
  • PWM Channels: 7
  • Analog Input Channels: 12
  • DC Current per I/O Pin: 40 mA
  • DC Current for 3.3V Pin: 50 mA
  • Flash Memory: 32 KB (ATmega32u4) of which 4 KB used by bootloader
  • SRAM: 2.5 KB (ATmega32u4)
  • EEPROM: 1 KB (ATmega32u4)
  • Clock Speed: 16 MHz

Sound Localization.

via coolarduino

Updated on 16 Oct. 2012.

Well, it’s elementary simple in theory, how to do sound localization based on phase difference of signals, that received by two spatially distant microphones. The Devil, as always, in details. I’ve not seen any such project created for arduino, and get curious if it’s possible at all. Long story short, here I’d like to present my project, which answer this question  - YES!

Let me stress, project based on phase delay, not TDOA.  Measurements results show, that current version of software (both copy of the source code, linked  below, they differ only in filtering technics) has minimum detectable phase offset 1 degree!!!

This gives astonishing special resolution. For example, 10 kHz sound wave has length in the air about 34 millimeters, and if I divide it by 360 degree – full period, I’d get about  0.1 millimeters per 1 degree of phase shift..

Of course, as object getting away from the microphones, accuracy would proportionally deteriorate. What important is a ratio between distance to the object and distance between two mic’s (base). Having the base equals to 65 millimeters,  device you can see in the video, capable detect location along horizontal line with accuracy 1 meter at distance 650 meters. Theoretically.

Moreover, quantity  of electronics components not much differs from what I’ve used in my previous blog.  Compare two drawings, you will notice only 4 resistors and 4 electret microphones (mic’s) were added! All circuitry is just a few capacitors, 9 resistors, one IC and mic’s.  Frankly speaking, writing a remix of oscilloscope, I was testing  an arduino analog inputs, keeping in mind to use it in junction with electret microphones in other projects, like sound pressure measurements (dBA),  voice recognition or something funny in “Color Music / Tears of Rainbow” series. As they call it – “a pilot” project?.  There are some issue (simplest ever) oscilloscope has, when doing fast rate sampling with 4 channels (settings 7, 8 and 9 Time/Div ) I already described, so I slightly reduce sampling down to 40 kHz here.

Note: *All of the above true for Arduino Leonardo. Hardware and Software would be different for arduino boards based on different chips, and must include pre-amplifiers with AtMega328 uCPU. 

One more important things to mention in this short introductory, as I used FFT algorithm for phase calculation ( I like FFT very much, you probably, already notice it ),

Arduino is capable not only track a flying object in 3D space, it also could identify / distinguish this object based on spectral characteristic of the radiated sound, tell if it’s aircraft or helicopter, what type / model, and for living species like insects it could tell if its MALE of FEMALE !!!!!


  As I say above, I choose 40 kHz for sampling rate, which is a good compromise between accuracy of the readings  and maximum audio frequency, that Localizator could hear. Getting signals from two mic’s simultaneously, upper limits for audio data is 10 kHz. No real-time, “conveyor belt” include 4 major separate stages:

  • sampling X dimension, two mic’s (interleaving);
  • FFT
  • phase calculation
  • delay time extracting
  • sampling Y dimension, two mic’s;
  • FFT
  • phase calculation
  • delay time extracting

4 mic’s split in 2 groups for X and Y coordinate consequently. Picking up 4 mic’s simultaneously is possible, but would reduce audio range down to 5 kHz, so I decided to process two dimension (horizontal and vertical planes)  separately, in series. Removing vertical tracking from the code, if it’s not necessary, would increase speed and accuracy in leftover plane. I’d refer you for description of the first and second stages to other blogs, FFT was brought w/o any modification at all. Essential and most important part of this project, stages 3 and 4.

Phase Calculation (3).

 Mathematical tutorial on a topic, I’m not any good as a teacher, so you better read somewhere else, to brush up a basic concept. Core of the process is arctangent function. This link says a number of cycles. In two words – too slow.  LUT ( Look Up Tables ) is the best solution for no-float uCPU to do complex math extremely fast, and reasonably (?) precise. Drawback of LUT is limited size, so it could be saved in FLASH memory, which in next tern  is also limited. This is what I did on “resource management” side: 1 kWords ( 16-bit integers, 2 kBytes) , 32 x 32 ( 5 x 5 bites) LUT, scaled up to 512 to get better “integer” resolution. There are a few values in top-right corner, that melted together as their differences are less than “1″ (not shown on the picture on right side). The “worst” resolution is in top-left corner, where “granularity” is reaching 256, or unacceptable 50% of the dynamic range. To stay as far away from this corner, I put a “Rainbow Noise Canceler” – single line with ” IF ” statement, which “disqualifies” any BIN with magnitude, calculated at the FFT stage, lower than 256.

IF (((sina * sina) + (cosina * cosina)) < 256) phase = -1;

 I called it “Rainbow” because of it’s shape, “red line” is an arc, going from 16 on top line to 16 on left side. Also, “Gain Reset” – 6 bit ( depends on the FFT size, has to be 6 bits for 128) was reduced to 5 bits, in order to get better sensitivity. This two parameters / settings, 5-bit and 3.5 bit magnitude (256) limit, create a “threshold” for weak spectral peaks. Basically, depends on application, both values can be adjusted in  different proportions.

 There are two category of tracking technics, with mic’s installed on moving platform, and stationary mic’s. First one is a little bit easier  to understand and build, calculates Relative direction to sound source. This what I’ve done. Stationary mic’s approach, when motors are moving laser pointer (or filming camera) alone, would require Absolute direction to sound source, and must include stage #5 – angle calculation via known delay time. Math is pretty simple, acrsine function, and at this point in program only one calculation per several frames would be necessary, so floating point math wouldn’t be an issue at all. No LUT, scaling, rounding/truncation. Elementary school geometry knowledge – thats all you need.

Delay Time Extraction (4).

 Subtraction phase value of one “qualified” mic’s data pull from another, produce phase difference. To turn phase difference in delay time, division by BIN number is performed. Lets call this operation “Denominator” process.  The denomination is necessary, because all data after this step going to be combine and process together, doesn’t matter of wave length, which is different for every bin. Frequency and wavelength related to each other via simple formula:  Wavelength = Velocity / Frequency, where velocity is a speed of sound wave in the air ( 340 m/sec at room temperature). As distance between two mic’s is a constant,  sound with different wavelength ( frequency ) produces different phase offset, and denomination make them proportional. (WikiPedia, I’m sure, would explain this much better, mind you, I’m a Magician, not mathematician).

First picture on right side shows  ”Nuisance 3: Incorrect arctan” correction. You will find two lines with “IF” statements in the code related to stage #3.

Second picture,  gives you an idea why one more correction at stage #4 is necessary As you can see, subtraction one arctan from another generates a rectangular “pulse” ( Diff. n. corr., violet line), whenever one function changes sign but other (delayed version) not yet. Light blue line (DIFF(B)) doesn’t have such abnormality. Math is simple, just two lines with “IF’s” in the same manner, only “double size” constants this time. 2048 on my scale corresponds to 2 x PI, 1024 – PI, and 512 – PI / 2.

Arduino has only 1 ADC, so there is always constant delay time equals to one sampling period ( T = 1/40 kHz = 25 usec), which also should be subtracted ( or added, depends how you associate input 1 and 2 – left / right side mic.)


 To fight reverberation and noise, I choose a Low Pass Filter, which I’d call here as a “Rolling Filter”. My research with regular LPF, shows that this class of filters is completely NOT appropriate for such type of data, due their high susceptibility to “spikes”, or sudden jump in magnitude level. For example, when system getting steady reading from 2-3 test frequencies with low values, let say -10, simple averaging ( should be -10 ) results will be corrupted with one accidental spike (magnitude +2000) during next 60 – 100 consecutive frames !!!  The Median Filter doing well eliminating sudden spikes, the same time is very hungry to CPU cycles, as it’s using “sort” algorithm each time new sample was arrived to the data pull. Having 64 frequencies, and setting filter kernel to 5 – 8 samples, arduino would be buried doing sorting at almost 40 ksps.  Even processing each frequencies data not individually,  and sorting only one 64 elements array still very time consuming job.  After thinking a while, I came up to conclusion, that “Rolling Filter” has almost the same efficiency as Median, but instead of “sorting” requires only 1 additive operation! On long run, the output value will “roll” and “stick” to the middle of the pull. ( Try to model it in LibreOffice. )  Adjusting “step” of the “Rolling Filter”, you can easy manipulate responsiveness,  which is almost impossible with Median Filters. (Things TO DO: Adaptive Filtering, real time adjustment depends on input data “quality”).

 To be continue…. 

Link to Arduino (Leonardo) sketch:  Localizator-beta-9.

 3 October 2012

Video clip posted. Arduino is running slightly modified version of software. Changes were made in the filtering algorithm, in order to eliminate motors interference. As you can see, one of the servo (Y dimension) is mounted at the back of moving platform, in close proximity to the mic’s. Filtering includes two stages this time,  “Rolling Filter” in every bin, plus averaging values  that are over noise canceling threshold. First stage is reducing phase noise at specific frequency. Second one, important in close environment with strong reverberation, when frequencies “appears” to come from different directions, even they all originated from the same source.

Link to Arduino (Leonardo) sketch:  Sound_Localization.

More Video:




 16 Oct. 2012

Version 3, and I think, it’s final release. I greatly re-worked sampling subroutine, with main goal to reduce a phase noise as much as possible. ADC is in auto triggering mode, via TIMER0, start conversion events strictly synchronize.  Please, read more details in this blog, at the end. Sampling rate pushed up to 50 ksps, providing 12.5 kHz audio range. That is much more, than small radio you can see in the video above could even reproduce!

Link to Arduino (Leonardo) sketch: Version 3 (Final)

Quasi real-time oscilloscope: REMIX

via coolarduino

 Updated on 21 Sept. 2012, version 4.

 Updated on 15 Oct. 2012, version 5.

Recently I was reviewing one of my oldest project, and decided to “refresh” previous design by taking full advantage of the new arduino Leonardo board.  Based on AtMega32U4, which include PGA (programmable gain amplifier), oscilloscope’s  analog front end doesn’t require external OPA this time, end could be build in 1-2 hours on prototype board, using 5 resistors, 5 capacitors and one IC. Short specification:

  • Four channels.
  • Switchable gain settings 1x, 10x, 40x, 200x.


 As you can see on drawings above, inputs are AC coupled with caps, and biased with 1.25V generated by LM317. Connector for other two inputs not installed yet.


Project keeps almost same  structure of commands (CLI – command line interface) as its ancestor, with only two new for channel and gain selection. Read comments, it explains how to use them. One more things, I removed “r” – re-print option from the list of available commands.

Have fun!.

Link to arduino Leonardo sketch:  Oscilloscope_Leonardo.

********************************************* Version 4*********************************************

 Well, even posted above sketch has low complexity, and its good for beginning, nevertheless it’s quite limited as measuring device. The most important feature for oscilloscope, except V/div,  is T/div, or timing, that has to be as much precise as possible.   This is why “standard” timing options based on TIMER1 were add to next version of software. There are 9 time settings Time/div (10 samples):

50ms, 20ms, 10ms, 5ms, 2ms, 1ms, 500us, 200us, 100usec

corresponding to

200Hz, 500Hz, 1kHz, 2kHz, 5kHz, 10kHz, 20kHz, 50kHz, 100kHz

sampling rate. You can choose any of of this in the same manner, entering a digit 1-9 and letter d (display). Zero would skip capture, and just do whatever next letter request. Basically, 0 should be used to print channels data from memory. Combination: 9d0i – capture at 100 kHz rate, print chart and info-table,
4c2g7d – select 4-th channel, set gain to 10, select 20 kHz sampling rate and display.

I also add multichannel sampling capability. Commands 2m, 3m or 4m would configure oscilloscope for 2, 3 or 4 channels simultaneously capturing input waveform.   As arduino has only 1 ADC, switching in multichannel mode would reduce sampling rate proportionally to number of channels, and this changes would be reflected in right top corner of the display. What more, arduino would automatically change vertical resolution per channel, to fit all 2 – 4 charts on one screen!

Known caveats:

  • Sampling rate 9, or 100 usec per division (10 usec per sample) could not be selected in multichannel mode, should be in use for single channel only (1m, 1c – 2c – 3c – 4c).
  • There is a “shift” in channel number, signal  presented at input 1 would show up on screen 2, and so on. This happens on time settings 7 (occasionally), 8 and 9 in 4x multichannel mode due delay in MUX registers switching. Shouldn’t be an issue for 2x channel mode, or when you have an “overview” of the signals shape in single channel mode (1m) before switching to 4x, so you would know what to expect at each input port.

Link to arduino Leonardo sketch:  Oscilloscope_LeonardoV4

********************************************* Version 5*********************************************

 New updated version. I was thinking how to improve simplest ever oscilloscope, and have made some structural changes in the code, mostly related to sampling in multichannel mode.

First of all, instead of “delay” 2 microseconds, that was used to give a multiplexer (and PGA amplifier) time to “settle” on new channel, I decided not to waste a time (that may be priceless in real-time application), rather start new conversion, than track samples based on the “history” of MUX settings, and store new sample in corresponding two dimensional array box. Now MUX and PGA would have more time,  and consequently I could reduce ADC pre-selector’s clock to get better readings. It solved all the problems with wrong association port number and picture on the screen.

Secondly,  as you, probably, already notice I’ve been working on another project recently, where phase is a PRIME factor of the whole idea of the design. Phase noise is a jitter, and it degrades  spatial resolution and the sensitivity of the sound localization.  Jitter always would be presented in the incoming signal – sampled waveform due “not synchronous” way of sampling, as “start new conversion” events were generated in “manual” mode. As microprocessor spend different amount of time to get inside of the ISR (interrupt subroutine) depends on where it was interrupted, time frame of the events, basically, was not defined. In order to get rid off the phase noise, I changed ADC settings to be triggered via TIMER 1. There is a code:

ADCSRA = ((1<< ADEN)| // 1 = ADC Enable
(0<< ADSC)| // 1 = ADC Start Conversion
(1 <<ADATE) | / / 1 = ADC Auto Trigger Enable
ADCSRB = ((1<<ADHSM)| // High Speed mode select
(0<< MUX5)| // 0 (10100) ADC1<->ADC4 Gain = 1x.
(1 <<ADTS2) | / / Sets Auto Trigger source Timer/Counter1 Compare Match B
(0 <<ADTS1) |
(1 <<ADTS0) );

For some unknown for me reason, Atmel designed TIMER 1 channel B to be an auto trigger source of the ADC, the same time to run TIMER 1 itself in CTC mode, channel A must be set. I simply “bind” two channels A and B in “parallel”, so both of them rise interrupt flag at the same moment, only A re-starts a TIMER 1, and B generates “start new conversion” event and calling ISR for “maintenance” – take a new sample waiting in the line and switch a MUX to another channel of the oscilloscope.

uint8_t take_it( int fast )
   ADCSRA &= 0xF8;
   if ( multChan -1 )
    switch( fast ) { 
       case 7: // 20 kHz / 
         ADCSRA |= 0×03; 
       case 8: // 50 kHz / 
         ADCSRA |= 0×02; 
       case 9: // 100 kHz / 
         Serial.print(F(“\n\t *** NOT SUPPORTED ***”));
         return 0;
        ADCSRA |= 0×04;
     switch( fast ) { 
        case 6: // 10 kHz / 
          ADCSRA |= 0×06; 
        case 7: // 20 kHz / 
          ADCSRA |= 0×05; 
        case 8: // 50 kHz / 
          ADCSRA |= 0×04; 
        case 9: // 100 kHz / 
          ADCSRA |= 0×03; 
          ADCSRA |= 0×07;
OCR1A   = smplTime[fast -1];
OCR1B   = smplTime[fast -1];
TCNT1   = 0;
TIFR1    |= (1<<OCF1B); 
TIMSK1 |= (1<<OCIE1B);
   flagSamp = 0; 
   while ( !flagSamp );
   for ( uint8_t indx, y = 0; y < multChan; y++){
      if ( multChan -1) indx = y;
      else indx = chanNumb;
   for ( int i = 0; i < INBUF; i++){
      if ( x[indx][i] & 0×0200) x[indx][i] += 0xFE00; // Convert to negative 16-bit word (2′s comp)
      else x[indx][i] += 0×200;
  return 1;
   static uint8_t n_sampl = 0;
   static uint8_t history = 0;
   x[history][n_sampl] = ADC;
    history = chanNumb; 
   if ( multChan -1 )
    if ( chanNumb >= multChan )
       chanNumb = 0;
     ADMUX &= 0xFC;
     ADMUX |= chanNumb; 
   if ( n_sampl >= INBUF )
      flagSamp = 1;
      n_sampl = 0;
TIMSK1 &= ~(1<<OCIE1B);


The only issue that not solved yet, is a sampling in multichannel mode in “9″ T/div. Probably, Atmel just was not design to do such things…