Arduino Leonardo

Arduino Leonardo is a lower cost Arduino, but with enhanced capability. The lower cost comes from the use of the ATmega32u4, which has a USB core built in (eliminating one chip out of the board).

Very likely it was inspired by Teensy

In addition, compared to the “regular” Arduino it has the following enhancements:

• Extra .5K of RAM
• Additional 4 pins
• Can be programmed to emulate a USB HID (Human Interface Device -such as a mouse or keyboard)
• Number of external interrupts?  The chip supports 4 external interrupts. I have not found out how many interrupts are supported by the Arduino s/w

One of the main attractions is the USB HID aspects of the chip. Since I use a computer (iTunes) as music server, you can do some navigation (of  iTunes) with a keyboard. Arduino Leonardo (and Teensy) can be programmed as a keyboard, sending keyboard strokes to the computer through USB.

Update (4/1/12): I got my own teensy

REMOTE “KEYBOARD CONTROL”

Readers might remember that the “left” and “right” buttons of the Apple remote have not yet been mapped to anything in my code. This is a great opportunity to map these buttons to keystrokes that would allow song navigation in iTunes with the remote control.

You can already do this with “Teensyduino”, the add-on s/w to enable the use of Arduino s/w on the Teensy board. This example shows how to program sending a CTRL-ALT-DELETE sequence to a computer attached to the board:

// press and hold CTRL
Keyboard.set_modifier(MODIFIERKEY_CTRL);
Keyboard.send_now();

// press ALT while still holding CTRL
Keyboard.set_modifier(MODIFIERKEY_CTRL | MODIFIERKEY_ALT);
Keyboard.send_now();

// press DELETE, while CLTR and ALT still held
Keyboard.set_key1(KEY_DELETE);
Keyboard.send_now();

// release all the keys at the same instant
Keyboard.set_modifier(0);
Keyboard.set_key1(0);
Keyboard.send_now();

ARDUINO vs TEENSYDUINO

There is some information here regarding the support for USB HID in Arduino:

The Arduino 1.0 RC1 (found here: http://code.google.com/p/arduino/wiki/Arduino1 ) includes the core and a single example so you can get a feel for it.  There are a few remaining issues to be fixed and a lot more examples to write and I’d love to hear your feedback.

The core files are in hardware/arduino/cores/arduino.  The relevant bits are:
* USBAPI.h
* USBCore.cpp and .h
* USBDesc.h
* CDC.cpp
* HID.cpp
* plus a few changes in HardwareSerial, main.cpp, Arduino.h, and pins_arduino.h (now located under the new variants/leonardo structure)

This is all subject to change, of course, but this should be pretty close to complete.

The example is in libraries/Mouse.

On the other hand, Teensyduino has bee supporting USB HID for quite some time and it already supports Arduino 1.0 RC1, and everything is documented. Teensy can emulate the following USB devices:

• USB Mouse
• USB Keyboard
• USB Joystick
• USB MIDI
• USB Serial

The current support and documentation for USB HID in Arduino is pretty bare. Not enough to write some code [at least for the non-expert]. For the time being I think the only viable option is Teensy.  It is also good to see that the developer of Teensy is also involved in the development of Arduino, so we can expect that all the features of Teensy will be migrated to Arduino

TRYING LEONARDO WITHOUT LEONARDO

Adafruit board: (Now with Leonardo bootloader)

For now, the Arduino Leonardo board is not yet available for purchase but support for the ATmega32u4 chip is already included in Arduino 1.0 RC1. You can try the software with probably any ATmega32u4-based board. morecat_lab has done just that.

PROBLEMS WITH ROTARY ENCODERS?

Some users have reported problems when using rotary encoders with detents (“clicks”). The detents are typically specified as for example:

• 15 pulses per revolution / 30 detents
• 24 pulses per revolution / 24 detents

This effectively means ”two detents per pulse” in the first example and “one detent per pulse” in the second example.

The problems that have been reported is that there are two changes per click.

The rotary encoder routine used in the current version of the s/w is very simple: you generate an interrupt when there is a change in signal A and immediately compare the value of signal A with the value of signal B. The current version of the software specifies the interrupt handler like this:

  attachInterrupt(0, rotEncoder, CHANGE);

This means that for every pulse in the rotary encoder there are two interrupts: rising edge of the pulse (one change) and falling edge of the pulse (another change). If your rotary encoder has one detent per pulse (like the image below), then you will be processing two interrupts and therefore making two changes. See figure below.

In order to make a single change per detent, change the code to:

  attachInterrupt(0, rotEncoder, FALLING);

or

  attachInterrupt(0, rotEncoder, RISING);

The above change will cause the interrupt handler to generate an interrupt only with the rising or the falling edge of the pulse but not both.

The current code considers CCW (counter clock-wise) direction when signal A = signal B. CW direction is when signal A is not = signal B. This means that you could use either RISING or FALLING. But you can try them both.

If you have a rotary encoder with no detents, then making the change will cut the number of changes per revolution in half. If you feel your rotary encoder is “too sensitive”, then you can use the above change to make it
less “sensitive”.

If you continue to have problems, the only other option for attachInterrupt() is:

  attachInterrupt(0, rotEncoder, LOW);

For more info see the Arduino reference on attachInterrupt.

CHOICE OF ROTARY ENCODER

I have two rotary encoders that I have tested the code with: one with detents and one without detents. The One with detents is a discontinued (over 10 years ago!) Panasonic model (Panasonic EVQ-WTEF2515B) available in eBay for $6-$7 (Used to cost $1.50 at Electronics Goldmine, but sold out over there). I purchased this long time ago when I started to write code for the WM8741 and had forgotten how this rotary encoder behaves.

According to the datasheet, the Panasonic encoder has 15 pulses per revolution and 30 detents. This means two detents per pulse. That is why I had to use “CHANGE” as the condition for the interrupt handler.

I find ~30 clicks per revolution to be a good number for this application. Whether they are 1 or 2 clicks per pulse it probably doesn’t matter; you just have to make sure you use the interrupt routine properly as shown above

Stock of encoders change frequently so basically you need to look for a “mechanical encoder” with built-in switch and 30-40 detents.

BOURNS has two suitable encoders: 30 detents/30 pulses and 30 detents/15 pulses (both with switch)]. Check the data sheet.

ALPS also has suitable encoders: 30 detents/15 pulses (with switch) Model EC11B15242AE. Notice the location of the detents with respect to the pulse. There are also other other Alps encoders with 30 or 36 detents and built in switch. A recent search for Alps mechanical encoders with switch, 30-36 detents turned up 10 different models [link]. You can compare the different models with this listing [link] from Alps and take note on how you want to mount the encoder. For example:

• The 11B series is a horizontal configuration and threaded shaft (so you can attach it to a panel)
• The 11E and 11K series is a vertical configuration and not threaded (cannot be easily attached to a panel)

ALPS Model EC11B15242AE

Jitter: 100MHz Clock 10x Better Than 80MHz Clock?

I decided to compare the jitter value between the 100 MHz clock vs the 80 MHz clock based on the datasheet from Crystek. This is what I got:

80 MHz: 2.29 ps RMS

100 MHz: 0.24 ps RMS (almost 10x better!)

I used the online jitter calculator to determine the numerical value for the jitter based on the data points shown in the phase noise graph.

For the 80 MHz part: RMS jitter=2.2864 ps (keep in mind that most specifications start at 100 Hz whereas this measurement starts at 10 Hz)

For the 100 MHz part: RMS jitter=0.23586 ps! WOW. This is 10x lower than the 80 MHz part. (but whether you can hear a difference or not, that is another matter)

CLOSE-IN JITTER

Notice that most of the jitter in the RMS measurement comes from the close-in part of the frequency spectrum, in particular the region up to 100 Hz.

“Lower grade” clocks conveniently ignore this part of the measurements in their jitter specifications. For example, the specification for the Crystek C33XX, (the typical “small” clock found in many audio products) says:

Jitter RMS: 12kHz~80MHz: 0.5psec Typ., 1psec Max

DOES IT MATTER?

One authoritative paper is an AES paper titled Specifying the Jitter Performance of Audio Components. The concluding remark with respect to “useful” jitter measurement is the 100Hz value and the RMS jitter from 100 Hz to 40 KHz

Jitter spectra, when plotted properly, can be very useful.   They can be even more useful when accompanied by numbers for RMS wideband jitter (100Hz corner) and RMS baseband jitter (100Hz-40kHz).  The makers of audio clocking chips should consider providing this information in their product datasheets.

If we then compare both clocks starting from 100 Hz, then we get:

• 80MHz clock: 0.00462 ps (100Hz ->)
• 100MHz clock:  0.00123 ps (100 Hz ->)

Now we are talking about a difference of about 3 fs (femto-sec) or 340 atto-sec

Read more here and  here

Hifiduino-BII-Musiland in Japan…

Atsukita blog describes hacking a Musiland 03US for the I2S and feeding a BII controlled by an Arduino.

I like the use of a modular connector and using the aperture of the MULINK connector (which is not very useful for non Musiland DACs)

Here is the DAC playing 192K material over I2S:

Notice that the best DPLL setting for 192KHz is “medium”