Archive

Archive for the ‘Hobby’ Category

How to use an old multimedia mobile phone as an music player – The signal integrity issues

November 17, 2014 Leave a comment

It is quite easy to convert a mobile phone into a music player, just connect your amplifier to the audio connector on the phone. Just that simple. However, problems start creeping up, when you want to power up both the phone and the amplifier out of the same supply. That means the phone doesn’t have a battery and is getting power form a 4.2V(Assuming original battery was Li-ion) regulator that you have built, and connected to the battery terminals. The problem is that in this case there is a lot of noise in the audio compared to the case with battery.

The Problem Statement

The reason is that the phone’s audio ground is no longer same as the amplifier ground. There are two cases. Case 1 is that the output stage of the phone has a bridge configuration. Case 2 is that the battery circuit uses low side current measurement. Case 1 is less probable because both the Left and Right channels share the common connector on the jack. For case 2, I have no clue why so many engineers prefer low side current measurement for the battery (connecting a resistor in series with the phone ground and battery negative terminal).

Phone audio electrical ground difference

In the figure, based on activity in the ‘Noisy Digital Circuit’ I1, the current through R1 changes and hence the voltage across it. This causes a varying voltage between the amplifier ground and the phone ground. The no-load voltage between Out+ and amplifier ground shall be V(R1) + V1. V(R1) is the noise introduced.

My case was only case 2. I could hear a lot of noise from the voltage converters on the phone. Because, based on their current consumption my phone’s ground was changing, and as a result the audio signal was also changing. The problem is illustrated in the figure above. The problem below shows the equivalent circuit used for simulation (Along with the solution circuit).

The LT-Spice circuit used for simulation of ground noise.

The LT-Spice circuit used for simulation of ground noise.

Here is a simulation output form the circuit above

Red is the op-amp's output voltage and green is the voltage at Out+

Red is the op-amp’s output voltage and green is the voltage at Out+

What is the solution?

The tough part is understanding the problem. Solution is simple – just use a difference amplifier with high common mode rejection ratio(CMRR).

Solution is to use a difference amplifier. Here is the one I used.

Solution is to use a difference amplifier. Here is the one I used.

The high CMRR is a catch here. As you can see from the problem statement diagram, the impedance on the two lines (Out+ and Out-) are in most cases, not matched. R2 shall add-up with R5 of the difference amplifier. R2 is typically a low resistance 10-33 ohms to protect the audio generator circuit in case of a short circuit, at the audio jack. A high CMRR can be achieved by increasing R5 and all the other resistors accordingly. 150k for R5 was a reasonable choice between CMRR and the op-amp bias current.

Still I have a bit of noise coupled from power supply remains. Already have the phone and amplifier grounds in a ‘star ground’ configuration. Hence very unlikely that noise is coupled through ground. Probably I have to add a voltage regulator for the amplifier.

Advertisements

Project Mozart2: How to make a music synthesizer out of your Raspberry Pi and Atmega32

October 18, 2014 Leave a comment

This is a nice and simple project for all those who has their interest at the intersection of electronics, computers, and music. I will show how I made a musical keyboard. As the project uses Jack (Jack Audio Connection Kit) to finally create the Music, it will be very easy to extend this project for any kind of sound application that you can think of.

What you need are:

  1. an Atmega32 or any similar microcontroller that has got 12 or more GPIO pins and a UART.
  2. a Raspberry Pi with some form of Linux. (A linux PC with a serial port also will work!)
  3. 2 1k resistor to make the level shifter circuit
  4. Something that looks like a piano keyboard. (Synthesizer needs to know of the pitch you are interested in playing!). If you don’t have one, probably you have to make some kind switch matrix, with switches arranged in a line
Mozart_Overview

Top level design

Inside the Mega32

We use 12 GPIO pins of the Mega32 in a 4×8 arrangement to create a 32 key key-matrix, as shown in picture. The 4 lines on the left are configured to output and are activated sequentially one after the other. At any given time only one line will be active. The other 8 GPIOs of the controller are configured as input, and they will be active or inactive depending on what all keys of the keyboard are pressed. The firmware will keep repeating the pattern on the GPIO outputs, and keep reading the input pins repeatedly, and very fast. The firmware keeps on checking checking changes in keys from scan to scan. Once it detects a key press or a key release, it formats a 4byte frame containing bytes indicating

  1. frame start indicator byte
  2. Key press/release indicator byte
  3. the pitch indicator
  4. the amplitude/key velocity indicator (hard-coded to 64)

The firmware then sends the frame out to the Raspberry Pi through the UART port.

The key matrix

The key matrix as originally used looks like in picture

The switch matrix

The switch matrix

However this kind of switch matrix has a problem known as phantom-key/Ghost key. This is felt like if you press certain pairs of keys, the mega32 controller will think that two other keys(ghost keys) are also pressed.

You can go to http://www.dribin.org/dave/keyboard/one_html/ for a nice explanation, and a solution for this. The solution is to add one diode each in series with each of the switch.

UART and Level Shifter

We use only the Tx port of the Atmega32 and the Rx port of Raspberry Pi, with a baud rate of 115200. I was running the atmega32 at 5V. But the Raspberry Pi IOs are only 3.3V capable. So a level shifter was needed. If you can run your atmega off a 3.3V supply, you can avoid the level shifter. I just used a resistive divided(don’t remember the exact values — it doesn’t really matter). Something made of a 2k and 1k resistor should work, I think.

The Raspberry Pi

The ‘MIDI encoder’ is the only block to be implemented in the Raspberry Pi side. Rest everything is off the shelf. We first configure the UART port and then keep reading the data out of UART from file /dev/ttyAMA0. Once we get a full frame from mega23, we re-encode it to MIDI format as accepted by JACK. The software then calls a Jack API to transfer the MIDI data to Jack. Jack then transports it to synthesizer(I used Hexter). Synthesizer converts MIDI commands to PCM audio, and gives back to Jack. Jack sends it to the Linux Audio stack, and it gets converted to an analog signal at the audio jack. You can connect an active speaker/headphone to hear the music.

Here are a few pictures of my prototype

The key-matrix, the level shifter(on breadboard) and the mega32

The key-matrix, the level shifter(on breadboard) and the mega32

Level shifter, Mega32, and the Raspberry Pi

Level shifter, Mega32, and the Raspberry Pi

The code at raspberry side (including a code::blocks project file) is available at: https://github.com/nitrojacob/s2jmidi. The serial format is described in the README file.

ARM development under Ubuntu 10.04

March 6, 2011 1 comment

Introduction

ARM is a very popular microprocessor architecture for embedded systems. Many mobile phones, netbooks and other similar portable computing and communication devices have an ARM core inside. Usually these ARM based embedded systems will have some operating system as well. Hence application development for ARM can be either on top of the OS or without the OS. In this page I will be describing about development of ARM applications without an OS (bare metal development).

C is the language of preference for embedded development, especially when it comes to systems without OS. I’m using the following set of tools to develop the C code and turn it into a machine language.

Tools

Code::Blocks IDE

Compiler, Linker etc.

Computer with Ubuntu Linux

Setting up the system

Code::Blocks is an easy to use Integrated Development Environment, which can be installed form Synaptic Package Manager or Ubuntu Software Center. Install Code::Blocks from one of these application.

Some of the bare metal development tools are listed here. Download the GNU GCC Toolchain for Linux. Extract the archive file by right click >> extract here. Now open the terminal and move the extracted folder to /usr/local/ directory. This can be done by issuing the command sudo mv arm /usr/local/. Though it is not absolutely necessary to move it to the /usr/local/ directory, it is the neat way. Add the location of the binaries to PATH, by issuing echo ‘export PATH=/usr/local/arm/bin:$PATH’ >> ~/.profile. You will need a reboot(Logging out and Logging in may be enough) of your computer for the new path to take effect. Verify whether the steps so far are done correctly by issuing arm-elf-gcc -v and see if the gcc is reporting the version. With this the tool chain installation is done.

You have to configure Code::Blocks to use the ARM GCC Toolchain. For this, goto Settings>>Compiler and Debugger…. A dialog box as shown below should appear.

Change Selected Compiler to GNU ARM GCC Compiler. Choose the Linker settings Tab, and add to other linker options -TLPC2129-ROM.ld, as shown. This configures the Code Blocks to use the file named LPC2129-ROM.ld as the linker configuration script.

In the Search directories tab, add /usr/local/arm/arm-elf/include for Compiler and /usr/local/arm/arm-elf/lib for Linker. This step make the Include and lib directory known to Code::Blocks and hence the compiler/linker.

Click on the arrow to the right of the Search directories tab, to reveal more tabs. In the Toolchain executables tab, set the Compiler’s Installation Directory to /usr/local/arm. Press OK to save the configuration. Code::Blocks is now configured correctly with the ARM GCC toolchain.

Starting an ARM project

Choose File>>New>>Project. Select Empty Project from the dialog box, and press Go. Enter ‘Folder to create Project in:’ and ‘Project Title:’ and press Next. Choose GNU ARM GCC Compiler, and clear the ‘Create “Release” Configuration’ checkbox, and press Finish. Now you can add your own source codes to the project. Do remember to add a crt0.S file to the project and to keep a file named LPC2129-ROM.ld in the project’s directory.

Categories: Hobby, Tech Tags: , , , , , ,

JACK Audio Connection Kit

Last weekend, I was trying out the JACK Audio Connection Kit on Linux Environment. They say its not limited to Linux and is/will be available for other UNIX like OS, Windows & Mac. I was lazy and involved with some HTML learning, so I could only understand and execute the basic program provided with it. Coming weekend I may try it for other programs and give you a better article. The following are a few of the things I noticed.

  • JACK is a very simple & intuitive API, for routing & processing digital audio, in realtime.
  • JACK is meant for professional audio, and not very good for very low processing power embedded sytems. May be you can do simple processings with an ARM.
  • JACK is in concept similar to analog modular synthesisers, where you connect one/more modules (eg: sound generators) to one/more other modules (eg: filters), using patch cords. The modules being replaced by software programs(like music players, your own programs etc.), and the interconnection of each module specified in the programs.
  • You can implement your own realtime Audio Processing Algorithm, in C using JACK API.
  • The API is huge and repel many amateurs. The fact is that with 10 to 12 functions, you can build fairly complex audio softwares.

You can expect more of my experiences with JACK in the weeks that follow.

A Musical Beginning!

This is my first blog!

I’ll be writing about the hobby project I did this Saturday and Sunday. Friday evening i had a thought of getting a bit musical. I don’t have any instrument with me. So decided on reviving one of my old project titled ‘project mozart’, which was originally written in C language for 8051 kind of microcontrollers. The 8051 I used for that couldn’t support anything more than 2MIPS. At that power only continuous notes, like that from a violin continuously bowed, could be produced. This ability alone didn’t satisfy me. So i decided to implement it in my newly bought Atmega32 controller, supporting upto 16MIPS.

I had architecture of the circuit, part in my mind, and part in the C file. The circuit is rather simple with a microcontroller, a DAC0808 digital to analog convertor, and a 741 op amp configured as a current to voltage convertor. Breadboarded it quickly. Then ported the C file to the new hardware.

My expectations out of the device were as follows. I wanted a device like a piano/synthesiser, that has 32keys (White + black). There are 12 keys per octave on a standard piano/keyboard. This touches 3 octaves, with 2 in full and one partial. For my design it stretched form 175.28Hz to 1108.7kHz. (F2 to C5). Another aim was to have a full polyphony. You can press any number of keys, you should get mixture of all that notes. In addition to this, another objective — to have the Attack-Decay-Sustain-Release sort of sound (sound similar to that of a bell, which is not continuous like a violin). The sample rate chosen was 2793.6kHz for legacy reason and because, anything more is not computationally possible on that 8 bit chip.

The working of the software is as follows (Sorry i can’t make it any simpler). The software would scan the keyboard and identify the keys pressed at approx. 10 times per second. For the keys pressed the timer ISR, would If a new key is pressed, corresponding sinusoidal signal will be played. The sinusoidal signal is made know to the program in the form of a table of size 256bytes, which together represented the values of a single cycle of a sinusoid. If I send each of the table values to the DAC in each sample interval again and again, cycling through the wavetable, I will get a sine wave of 2793.6/256 = 10.955Hz. If I send every 16th entry of the table to the DAC, i will get, 10.955*16=175.28Hz sine wave, which is almost F2. Similarly you can calculate which sample to be played with the help of a bit music theory, which you can learn from wikipedia.

By the method presented so far, we could only get continuous note like that of a violin/saxophone. I need notes like that of a piano/bell/guitar. For this I will generate an envelope based on the duration for which each key is pressed, and will multiply that envelope with the continuous signal produced. This way, I could do the Attack-Sustain-Release phases. The decay phase is yet to be implemented.

At this poor bit depth(8bit) and poor sample rate too, the sound looks pretty good. I know of some possible additions, like addition of wave tables for more real life instruments, a full attack-decay-sustain-release cycle for each instrument, better sampling rate, better bit depth for the sound etc…. Your suggestions and links to your project pages are welcome.