AquaCube (c) improvements notes

This is a note about how it would be possible to improve a pet fountains with some electronic.

Just bought an Aqua Cube for Freddy, our cat.
The AquaCube is a fountain with a filter capable to hold and keep clean and areate the water for the pet.
Very nice way to allow him to drink, but there are three problems to address.

Problems

1. remember to change the filter every 4 weeks 
2. remember to clean up the fountain every 5 to 6 weeks 
3. check the water level 

Change filter

The Aqua Cube has a charcoal filter and needs to be changed every 2 to 4 weeks (depending the number of pets using the fountain).It is hard to remember in such time lapse, when is time to change the filter.It is needed a reminder.

Cleaning

At least every 6 weeks the fountain should be placed off line and washed.
Also in this case it is needed a reminder.

Check water level

The pump must always run with water and of course, the pet must have water to drink.
It is necessary to have a system capable to stop the pump if there is not enough water and notify that water need to be added to the fountain.

The idea

Of course it is relatively easy to put together a contraption capable to perform such operations and eventually something extra.

Here some basic specifications for a circuit capable to cover these needs.

Specifications

• It must run with the power used for the pump 
• It must consume very low 
• It must have a battery backup in order to keep the count for the filter 
• It must be relatively stable (frequency) 
• It must be capable to drive a 12V rele' to power the pump 
• It must provide Visual/Acoustic notifications 
• It must have an input way to reset the conditions 
• Optional - sensing the presence of the cat to shut off the pump to avoid the noise 
• Optional - turning off the pump during some time (evaluate if there is an energy saving worth the job) 
• Optional - sending alert via email/SMS/RF/ something 

Building blocks

Processor

An easy way to build such contraption would be to use a MSP430 (Launchpad) with the 32Khz crystal.
This would be a great starting base for the project.

Battery backup

The contraption must have a battery backup kept charged when the main power for the pump is present (12V).

Water level detection

The next thing is to decide how to detect the water level.

Here some constraints :

• it must be NON toxic 
• there is no need for high precision 

Since the water is drank by pets, is better to avoid any contamination. So no metal bar in the water, better a touch-less way to measure the water level.

This paper contains some suggestions, but probably the easiest way is using a pressure sensor connected to a small plastic pipe, one used in aquarium, immersed in the water.

Notification

Maybe a LEDs capable to indicate the different status and/or acoustic signal to notify when there is not enough water.
Even better a SMS or email notification, indicating the reason of the alert.
It can contains details about the notification, like "water level too low", or "change filter" or "cleaning required".

Mechanical issues

Some constraints exists for the mechanical assembly.
The electronic should be placed in a sealed box, attached to the back of the fountain.
The box must be detachable from the fountain to allow it's cleaning.
From the box starts also a clean pipe for the water level. The pipe must be detachable as well.
In other words is better to avoid hardware modifications to the fountain in order to guarantee the prescribed maintenance as described on the user guide of the AquaCube unit.

Build fast a simple tachometer

The goal : measure the RPM of an home-made electric motor for a school experiment.

Requirements

The kind of motor built for the experiment is slow by definition, so the RPM meter (also called tachometer - http://en.wikipedia.org/wiki/Tachometer) must be capable to measure and display low revolutions per minute.
The other goal is to build the tool easily and in short time, possibly spending the less possible.

Acquiring Methods

The first problem to solve is how to acquire the rotor revolutions, i.e. how to translate a movement in an electric signal.
Usually there are two methods :

• magnetic
• optical 

Magnetic

Since the rotor has already magnets glued on it, it is relatively easy to add a magnetic sensor capable to generate a pulse every time a magnet pass close to it.
The sensor can be a reed switch or, typically, a Hall sensor. The Hall sensor is better than the Reed switch because is not mechanical, so is not generating false signals and is faster.
If an Hall sensor is used, it must be unipolar.
There are two kind of Hall sensors, unipolar and bypolar.
The bypolar requires to "see" a change pole. i.e. a change from South pole to North pole and viceversa. Every change, triggers the change of the electric signal.
The unipolar sensor change the state of the electric signal every time a South pole is close to the sensor.
Here a graph to show the two kind of Hall sensors :

The upper part shows a bipolar Hall sensor.
When the South pole is close to the sensor, the output signal goes down. Only when the North pole is close to the sensor, the output signal goes back high.
The lower part of the graph shows a unipolar Hall sensor.
When the South pole is close to the sensor, the output goes down and it goes up as soon as the South pole is going away from the sensor.

Optical

The other common way to acquire the revolution, is optical.
Typically on the rotor is glued a reflective surface in a spot. A Infrared ray is sent toward the rotor and a circuit can detect the reflection of the infrared ray when bounced back from the reflective surface.
As alternative is possible to attach a disc with holes to the rotor and have a light beam (or infrared beam) interrupted by such disc.
A third optical alternative is to attach to the rotor a "black and white" pattern and illuminate it with a stroboscopic light.
Changing the frequency of the light until the pattern is "stable" (or visible as it would be stopped) will give the RPM.

Measurement

We have a series of pulses generated by the sensor.
Let assume we are using the magnetic acquiring method, with a unipolar Hall sensor.

Depending how many magnets we have on the rotor we can have "n" pulses for every revolution.
i.e if we have two magnets on the rotor, we'll have two pulse every revolution. 4 magnets will generate 4 pulses and so on.

The "intuitive algorithm is quite easy. We need to count the number of pulses in a minute, then divide the number for the number of magnets and the result will be our RPM.

Unfortunately this method has a drawback. We need to wait a minute before to see the result and after that, we need to wait another minute before to see changes.
So we need to reduce the acquiring time and then estimate the RPM from the minor number of readings.
For example we can count the pulses for 1 second, then divide the number of pulses by the number of magnets. The number will represent the number of revolution for second. If we multiply that number for 60, will have the number of revolution per minute (1 minute = 60 seconds).

This can work well assuming the motor rotates at a constant rate and that rate is not too slow.
For very slow rotations, it is necessary to increase the counting time, maybe to two or three seconds (and then multiply accordingly)

The problem with that is the "visualization" of the measurement. More time to count the pulses means more time between the visualization of the result.

Building

It is possible to build the tachometer in many different ways.
Of course today is more simple to use a microcontroller rather than use more "traditional" ways, like using counters, decoders and LED display.
Any microntroller family is more than suitable for this application, especially because the measurements to do are not critical.
A microcontroller is also better than "traditional logic" because it require less components and only changing the software is possible to change the type of measurement.

Mostly because is something I already have around, the idea is to use the Texas Instrument MSP430 family of microcontroller, specifically a board with already the MSP430F169 and a Philips LCD display.

This board has everything we need to build a tachometer and we can easily change the parameters, like the number of magnet on the rotor and the acquisition time.

The software will be build using the GNU Msp430 Gcc compiler.

Note ! It is possible to use the software on different boards with few modifications.
For example the MSP430 Launchpad board is more than enough for this project.
Only two reasons did let me decide for the Olimex board :

1. I already had this board around picking up dust
2. This board has already a joystick and LCD display on it

Tools

In order to develop the RPM meter (or tachometer) some tools are necessary.
The software will be build under a Linux machine, using Code::Blocks as editor/IDE.
The compiler used is the open source version of the GNU Gcc for the MSP430 .
The debug system is based on the msp430-gdbserver.
An oscilloscope will be used to check the input signal from the Hall sensor.
The PC used to develop the code must have a traditional parallel port since the only GDB tool is parallel.
For the schematics, the FidoCad and Eagle programs will be used.
FidoCad allows to draw very simple schematics, Eagle is more sophisticate and can be used to produce a PCB (not necessary for this particular project though)

Hardware

As introduced before, the main hardware is the Olimex board based on the MSP430F169.
What is needed is the Hall sensor. I choose a Honeywell SS400 series Unipolar Hall sensor (SS441A ).

The sensor will be connected to an I/O pins of the board,  one capable to read the output signal from the sensor.
Since the board has plenty of available I/O Pins is not a problem.

Specifically will be used the Pin1.1 to read the signal from the Hall Sensor.

The P1.1 is capable to generate interrupts and it can be also connected to an internal timer in case a different measure approach is needed.
The sensor needs to be powered with a Vcc starting from 3.8 V. The Olimex board is operating at 3.3.V so an external regulator is needed and a 5V one is used. Because the MSP430F169 I/O pin are NOT 5V tolerant a resistor limiting the current is needed to avoid damage to the microcontroller.
The capacitors are the standard ones for the 78L05 regulators.

Here is possible to find the schematic of the Olimex board. 

Software

First draft

The software is a first simple draft to prove the concept and verify the hardware.
It is based on the original demo code coming with the board, modified for the specific needs.
The Hall sensor signal will be connected to an interrupt capable I/O in order to don't miss any "firing" of the signal.
One or more timers will be used for the time counting. The visualization will be placed in the main loop.

The algorithm is quite simple and based on two interrupts.
One interrupt is related to the I/O pin connected to the Hall sensor. Normally the signal is pulled up, so the interrupt is set to fire on the descending slope of the signal.
The interrupt function increment a counter every time the signal goes down.

The other interrupt is a timer.
A generic timer "fires" every "n" seconds (default is 1).
When the timer fires, the the counter is copied in a variable and the counter is set to zero.
A flag is set to one indicating the need to display the content.
In the main loop, the visualization loop check the variable updated by the visualization timer to show the result.

I/O Settings

Some I/O are "forced" by the nature of the board.
Here the main ones used other than the ones pre-wired on the board :


P1.1 Hall sensor input
Pulled up, the pin goes to zero when a South Pole magnetic field is close to the sensor
P2.1 Status LED - toggle at every Hal sensor signal
The LED is toggled at every sensor magnetic event
P2.2 Status clock
The pin is toggled at every timer firing. If the timer is set for 1 second, the signal will have 2 second period.
2 seconds timer will generate a 4 seconds period on the pin and so on.
P2.3 Debug pin
Generic debug pin

Clock settings

The Olimex MSP430F169 LCD board has two crystal sources.
A 32Khz crystal and a 8 Mhz crystal.
For this application one of them should be OK since the low time involved.
The minimum period needed is about 1 second, so also the slower but precise 32Khz source should be OK as clock.

In order to minimize the timer interrupts generated, the 32 Khz crystal is used in order to generate a 1 second timer used for the measurement, the rest of the board continue to use the DCO as main source of the clock.

To set the 32Khz crystal :
DOCTL = 0x60
modulation off, DCOx and RSELx ~800kHz
BCSCTL1 = 0xB7
XT2OFF = 1 - XTS = 0 - DIVAx = 3 - RSELx = 7
BCSCTL2 = 0x00
SELMx = 0 - DIVMx = 0 - SELS = 0 - DIVSx = 0 = DCOR = 0
BCSCTL3 = 0x0C
XT2Sx = 0 - LFXT1Sx = 0 - XCAPx = 12.5pF - XT2Of = 0 - LFXT1OF = 0

With this setting the ACLK is of 4096 Hz, the MCLCK/SMCLK of ~800kHz
Note : using the 32Khz for the main clock (MCLK) the display is not working properly.

Timer setting

A generic timer is handling some sub-timers used to count the Hall sensor pulse and display the value.
The timer_A 0 will be used in the up mode.
The clock source for the timer will be ACLK, i.e. 4096 Hz.
The Timer_A will be set with a /8 so that the value 512 placed in the TACCR0 will generate an interrupt every 1 second.

TACTL = TASSEL_1 + ID_3 + MC_1; /* Uses ACLK, divide by 8, count in up mode */
TACCTL0 = CCIE; /* Use TACCR0 to generate interrupt */
TACCR0 = TMRVALUE; /* 1s */

Menu

When the code starts, a menu appears.
Two choices are available :

• Set
• Measure

The Set allows to set up some parameters, like the number of seconds for the counter/display value or the number of magnets
The Measure starts the measurement.

Update

After few small modifications and settings, the tachometer was installed on the home-made experiment motor.
The sensor is placed on the top of the rotor using a wooden pole, so to be perfectly aligned with the rotor's magnets.

If somebody is interested to have the source code just contact me

How to unbrick a Sheevaplug

Sometime, doing development on a board, is possible to end up with the board bricked.
Bricked means that the board is TOTALLY dead, no prompts, no possibility to issue commands, nothing happens.

It happened to me today with a Sheevaplug.
Here how I unbricked my Sheevaplug.

As usual the first thing to do in these cases is to seat down, breath slowly and repeat : DON'T PANIC :)

Research

The first thing to do in these cases is to search for procedures/tools specific for the Sheevaplug.
Of course the main source of information almost always is broken. For example the main website for the Sheevaplug is the Plug website .
Until few months ago there was a nice Wiki containing all the information necessary to unbrick a Sheevaplug, now the wiki is missing.
A lot of posts are pointing to Wiki articles that are not existing anymore.

Unbrick it

There are many procedures that "in theory" can be used to unbrick a Sheevaplug.

However the one described here is the one that is working, found on this forum .

On the host machine connected to the Sheevaplug via USB, is necessary to have installed a package called openocd, telnet and screen.
My host machine is based on Xubuntu 12.04 so :

$ sudo apt-get install telnet screen openocd

At this point, be sure to have the Sheevaplug connected to the host machine via the USB cable (it simulating a serial port) and power it up.
Note ! In my case, the host machine is a virtual machine under VirtualBox, so it is necessary to go on Devices/USB Devices and enable the Sheevaplug serial port (it could be marked as FTDI Sheevaplug JTAGkey).

Then unless to work always with sudo, set the USB serial port to the user (in my case steve).
Usually the connection is set up as ttyUSB0, but better to check :

$ sudo chown steve /dev/ttyUSB0

then

$ screen /dev/ttyUSB0 115200

It is normal that nothing happens at this point.

Now we have to open a second terminal and run this command :

$ sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts

If everything is OK we should see something like that :

$ sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts
[sudo] password for steve:
Open On-Chip Debugger 0.5.0 (2011-12-03-08:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit

At this point nothing should happens.

Now we need to open another terminal and create a temporary directory where to store a bootloader :

$ mkdir temp
$ cd temp
$ wget http://www.downloadsnewit.co.uk/u-boot/recovery/sheevaplug/u-boot.elf
In the directory temp now we have a recovery version of the bootloader for the Sheevaplug.

From there we need to open a telnet session with openocd :

$ telnet localhost 4444

We should see something like that :

$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>

At this point we can issue the command :

> reset;sheevaplug_init;load_image u-boot.elf;resume 0x00600000

This should load the bootloader and start it.
If everything is OK, on the terminal connected to the Sheevaplug USB cable we should see :


__ __ _ _
| \/ | __ _ _ ____ _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_| \_/ \___|_|_|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
** MARVELL BOARD: SHEEVA PLUG LE

U-Boot 1.1.4 (Apr 9 2009 - 12:23:12) Marvell version: 3.4.16
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CEE60
Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz


DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000 size 256MB
DRAM CS[1] base 0x10000000 size 256MB
DRAM Total size 512MB 16bit width
Flash: 0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB
*** Warning - bad CRC or NAND, using default environment

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0

Better to hit any key to stop the autoboot.
A Marvel prompt will appear.

At this point a bootload is running on the Sheevaplug but it is necessary to write it in the NAND, otherwise the next time the unit is powering up, the unit will remain bricked !

There are many ways to save a bootloader in the NAND.
The first step is to retrieve a bootloader.
For this test I used a bootloader suggested from a blog describing how to install a Debian distribution on the Sheevaplug.
Here the link : http://people.debian.org/~tbm/u-boot/2011.12-3/sheevaplug/u-boot.kwb

I used  a TFTP server to load the bootloader on the Sheevaplug.
In the TFTP server (usually a directory called tftpboot) put the bootloader you want to be installed, it is usually named u-boot.kwb.

Then on the terminal connected to the serial port, at the prompt Marvel :

Marvell>> setenv serverip 192.168.2.61
Marvell>> setenv ipaddr 192.168.2.33

These two lines assign the IP address for the server hosting the TFTP and the IP address of the board.
A bootloader called u-boot.kwb is loaded in the tftpboot directory of the server.

Marvell>> tftpboot 0x0800000 u-boot.kwb
Using egiga0 device
TFTP from server 192.168.2.61; our IP address is 192.168.2.33
Filename 'u-boot.kwb'.
Load address: 0x800000
Loading: #################################################################
########
done
Bytes transferred = 372544 (5af40 hex)
Marvell>> nand erase 0x0 0x60000

At this point we have the bootloader code loaded in the Sheevaplug RAM.
We need to clean up the NAND and load the bootloader in it.

NAND erase: device 0 offset 0x0, size 0x60000
Erasing at 0x40000 -- 100% complete.
OK

Marvell>> nand write 0x0800000 0x0 0x60000
NAND write: device 0 offset 0x0, size 0x60000
393216 bytes written: OK
Marvell>>

If everything is OK, the new bootloader is loaded in the NAND.
Resetting the Sheevaplug we obtain :

U-Boot 2011.12 (Mar 11 2012 - 18:59:46)
Marvell-Sheevaplug - eSATA - SD/MMC

SoC: Kirkwood 88F6281_A1
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 512 MiB
NAND read from offset 60000 failed -74
*** Warning - readenv() failed, using default environment

In: serial
Out: serial
Err: serial
Net: egiga0

88E1116 Initialized on egiga0
Hit any key to stop autoboot: 0

We are almost done !
The last step is to assign the correct MAC address to the Sheevaplug.
To do so, first write down the MAC address of the board. The MAC address assigned to the board is present on a label on the bottom of the Sheevaplug.

Then, at the Marvell prompt :

Marvell>> setenv macaddr xx.xx.xx.xx.xx.xx  # where xx are the digits of the MAC address
Marvell>> saveenv   # save the new address


The Sheevaplug is unbricked and ready for a fresh new installation.

Useful links

Here some links that helped me.

• James post on NewIT
• Installing new bootloader
• Upgrade bootloader

Determine a magnet polarity

Knowing the polarity of a magnet is important in order to use the same polarity when more than one magnet are used in a motor for example.
Here some notes about how to determine the polarity of a magnet.

There are many different ways to determine the polarity of a magnet :

• using a compass or equivalent
• suspending the magnet freely and looking at the final direction (it is assumed to know where the Earth North pole is)
• comparing it with a known magnet

The most important thing is to know something about the standard.

In USA the "North" pole of a magnet, defined by the National Bureau of Standards (NBS) convention,is based on the following: 

"The North Pole of a magnet is that pole which is attracted to the geographic North Pole. 

Therefore, the North Pole of a magnet will repel the north seeking pole of a magnetic compass."

The magnets

For the experiment we'll be using round shape magnets, easier to be glued to a rotor.

Something like the ones in the picture.

On a disc, the poles are present on the surface.

Marking the poles

In order to figure out what pole is on a surface, the fastest method is to use a compass or an equivalent electronic one.

Pointing the disc surface toward the compass, will force one of the two side of the row toward the disc.

The North pole of the magnet will attract the South pole of the compass.

The South pole of the magnet will attract the North pole of the compass.

Since all the smartphones have a magnetic sensor (Hall effect sensor) it is relatively easy to build an application capable to identify a pole.

On the market there are already many different applications that do so.
For the purpose to identify what is the pole of a magnet we choose the Magnetic Pole Detector.

With this application is easy to identify the pole of a magnet.

It is enough to place the magnet with one surface toward the smartphone and push a button to see what is the pole.

The pictures show a measurement.
The face of the magnet oriented toward the phone, is the South pole of the magnet.
The opposite side is the North pole.

There are of course also many specific tools for this purpose if you down own or want to use a smartphone.

Here few examples :

• http://www.cndailymag.com/magnetic-pole-identifier.htm
• http://www.amazon.com/Magnetic-Pole-Detector-Identifier-Tester-for-Magnets/dp/B0019F90JW
• http://www.lessemf.com/dcgauss.html

Alphaline mod. 18281

Since I have a nice bricked Alphaline MP4 player, and nobody willing or able to service it,  why not take it apart and see what is inside ?

Open the player

The shell of the player is in plastic. No screws, only small plastic hooks.
With a very small screwdriver, start to gently force close to the bottom angles of the player, where the USB connector and phone connectors are.
Then very gently start to work all around the border of the player.
A certain point it will be possible to user the fingers to gently separate the shells.

The inside

After the shells are separated, the PCB and the battery appears (the gray "thingy" on the right).
3 big chipsets are visible, plus the microphone and the pinhole camera.
Also the micro SD card reader, the USB connector and the headphone jack are visible,

The three chipset are so marked :

• ATJ2259C - ZC55LBB B7A
  The microcontroller - So far I was unable to retrieve datasheet or even basic information about this controller.
  It is a Chinese processor and in the typical Chinese way, no information are released.
  Pity. We should really stop to buy stuff produced in China.
• Infineon HYB39S25616odt
  HYB39S256160DT-7 - 256-MBit Synchronous DRAM
• PF369 - AR - 1134
  Probably LCD/touchscreen manager but like the processor I was unable to find information.

Smartphone audio cable adapter

Unfortunately doesn't seems in the smartphone and tablet world, to exist a single standard for the audio connectors (see article about the smartphone audio jack).

On the market do exists cable converter of any kind, however they are often unnecessarily costly.

If you need an audio jack adapter between the main two standard in the smartphone world, OMTP and CTIA, here what I did.

Shopping list

Quite easy ... we need three things :

• a 4 wire cable
• a TRRS male jack
• a TRRS female jack

I solved buying the needed material from Sparkfun.

I ordered a TRRS male jack with 18" of cable (CAB-11580) for $1.95 and a TRRS jack breakout (BOB-11570) for $3.95.

The TRRS jack breakout

It is possible maybe to find just a TRRS female for less, but the breakout is more flexible since it can be used also to provide a test platform (hook up oscilloscope, ecc.).

For about 9$ (the material plus shipment) is possible to have all the necessary to build the adapter.

A ready made cable converter can be found usually around 11$ plus shipment, but  the advantage to build it is that can be modified for other type of connections.

Schematic

OMAP<--->CTIA

Well, is really quite straightforward.

It is simply matter to connect the Tip and first Ring directly, and then swap  the other two.
The TRRS jack with the cable has this pinout :

• Tip - red wire
• Ring - white wire
• Ring - green wire
• Sleeve - black wire

On the PCB are marked the positions, so it is straightforward to connect the wires.

Smartphone/tablets audio connectors

One of the few things really annoying is when manufactures decide to don't follow a single standard for the connectors of their products.
I have around some smartphones and there are differences on the audio (3.5 mm) connector.
These differences creates problems with some accessories.

For example I bought a very nice desktop phone stand from Aptiva, but I soon discovered that it is incompatible with my Sony Ericsson Xperia.
The same for a Hype Retro Walkie Talkie handset I wanted to use to enhance the Zello experience.
On the Sony is not working at all, on the Samsung tablet works in part (see the note on the bottom of this article).

So there are differences about the connection of the 3.5 mm audio port on these devices.
This article is trying to document the pinout of different phones/tablet and giving information about this problem and how to solve it.

Introduction

The typical 3.5 mm jack is divided in different areas :

• Sleeve
  The part of the connector close to the handler, the cover.
• Ring
  The part of the connector separated by a insulator ring
• Tip
  The far part of the connector, the "point"

There are many different types of jack.

In the figure below, there is an explanation of the main parts of such connector.

This type of  jack is called TRRS  (Tip/Ring/Ring/Sleeve) and it become the "standard" for smartphones.

The most known type of jack is the one used to connect the standard stereo headset.

This type of jack is called TRS, from the initials of the connections :
Tip - Ring - Sleeve

CTIA Audio jack

CTIA defined an audio connector.
It is a TRRS  :

• (sleeve) Microphone input
• (ring) Ground (common)
• (ring) Right Audio out
• (tip) Left Audio out

iPhone 4S

Many audio accessories are labeled as iPhone compatible.
This means that the majority of the audio accessories found on the market follow the Apple standard for the 3.5 mm audio connector.
The iPhone/iPad audio jack follows the specifications defined by CTIA.

So every accessories that declare to be iPhone compatible has the pinout shown above.

OMTP audio jack

Android, as general rule, seems follow a standard defined by a group called OMTP.

However different manufacturers choose to follow the CTIA, others didn't.

The main difference between the CTIA and  OMTP is switching the place from Ground and the Mic.

So each Android smartPhone or Android  tablet can have different audio jack pinouts. That's very very bad.

This is the OMTP connector :

So let see different brands what offers.

Keep in mind that usually models of the same brand uses the same pinout, but it could be different !

So never assume.

Sony Ericsson Xperia LT18a

OMTP standard

In order to use Apple iPhone standard accessories, is necessary to use a converter.
It is possible to search for CTIA<--->OMTP conversion cable or it is relatively easy to build one.

Samsung Galaxy Tablet 7" GT-3113

CTIA standard

Samsung SPH-M910

CTIA standard

FriendlyArm Tiny210 SDK

This OEM board can run Android 4.0.3.
It has a TRS jack for the audio output and a TS jack for the audio input.

Soldering helper

OK, small problem to solve.
Every time I need to solder some components/wires/ecc. the solder support is moving everywhere, often falling down the workplace.

Roomba 4xx test batteries - manual

Having a lot of Roomba batteries for the series 4xx (third and fourth generation), before to trash them in the recycle kit I just received,  I needed a way to see if a battery is good or bad.

To test a battery there are some steps to follow :

• measure the voltage of the battery - if below 15V the battery can have problems
• discharge the battery
• charge the battery
• discharge the battery on a calculated load - it should last a fixed amount of time depending the type of the battery. At least 1 hour for the older NiCd

Using the external iRobot charger modified (for manual), I did set up this environment.

The dis-charger is a 12V lamp.
I'm experimenting with a 12V 50W and a 12V 34W lamps.

Building

Building the contraption is easy.
The only trick is to pay attention to the polarity of the wires.
It would be great to use red/black cables, but as usual I use whatever I have around in my junk box.

 Here I'm using a 12V 50W lamp, but as soon as I find a socket for the other lamp, I'll try to use the 12V 34W lamp.
The ideal it would be to use a load that simulates the Roomba load. People doing this before me estimated that a 12V 25W lamp is a perfect load.
One of these days I'll try in different places to find the lamp, for now this is what I have around.

For mechanical reason, I put the switch (Switch A) in plastic box (of course re-used many many times for different projects).

The switch is actually a 3 position switch, so the label indicates ch (Charger), off (Off :) ) and dis (Dis-charger).
Because of that, there is really not need of the Switch B, since is enough to put the switch A in the Off position to measure the battery voltage with no load.
But for "logical" reasons, the Switch B still exists.
Let say that "Switch A in Off position",  is equivalent to say "Switch B open".

Here the contraption connected to the modified external charger.

Operations

In order to see if a battery is OK or not, here Step by Step list of things to do.

1. set the Switch A on Off (or set  the Switch A  to connect the battery to the dis-charger and set the Switch B of the dis-charger  open).
   In this way is possible to measure the voltage of the battery without load.
2. put the battery on the battery holder of the iRobot external charger.
   
   Low reading at this stage can already indicate if a battery is dead.
   A healthy battery should give a reading around at least 14.4V.
3. set the switch A on dis (Dis-charger) or set the Switch B On.
   Simply keep connect the battery to the dis-charger until the lamp is on.
   When the lamp goes off :
   - if lasted at least an hour for the NiCD and two hours for the NiMH the battery is OK (assuming a load of 12V 25W, less for bigger loads)
   - if last less the battery is not good anymore, however at least one charge cycle must be performed before to decide the battery is no good.
   Go to the point 4 if the battery needs to do at least a charge cycle
4. toggle the Switch A to connect the battery to the charger.
   If the battery has a chance to be OK, the battery charger is engaged (green LED ON).
   The charge operation can last up to three hours, depending the type of battery.
   - If the green LED flash, the battery must be dead. Discard it.
   - If the green LED goes OFF in few minutes, the battery could be dead.
     Check if the battery is warm. If not the charger refused to charge it. The battery is dead.
   - If the green LED goes OFF after at least 1 hour (black battery) or 2 hours or more (yellow battery), go back to the point 1

External iRobot battery charger modifications - manual

In order to test the Roomba 4xx series battery, it is needed a battery tester.
The ultimate goal is to design an automatic gadget, but first some experiments are needed.
More articles will follow.

The test battery project, uses different components.
The most important is the battery charger.
Instead to design one from the scratch, I decided to use the external iRobot charger model 02004, out of production for some time now but still available on eBay and modify it.

Battery charger 

As usual, before any modifications ...

CAUTION !
The modifications make void any guarantee and are potentially dangerous !
If you are not sure about what you are doing, DON'T DO IT !

There are some advantages to use it.

• the battery charger circuit is already done
• it provides mechanical support for the battery 
• it provides an optimal electrical connection to the battery

However it is not perfect. It was designed mainly for the traditional NiCd batteries, not the NiMh (APS - yellow ones).
It can charge them but it requires TWO charges (see the 02004 technical description by G. Plews )

Anyway, the first thing to do is to modify it in order to be able to connect the battery to the dis-charger and the voltmeter.

Battery charge modifications

The idea is to bring out the battery connectors, in order to connect the battery to the charger or to the dis-charger and the voltmeter.

To open the unit, there are 6 screws on the bottom, 4 of them hidden under the rubber pads. 

Once removed the screws the upper half of the charger separates from the base.

The electronics is anchored to the base.

There are two set of wires going in the upper shell.
Two wires are for the LED, and three wires are for the battery.
The three wires are the negative (black wire), the positive (red wire) and the thermistor feedback (blue wire).

To "bring out" the battery connections, I used a 4 pins audio connector (Radio Shack mod. 274-0002).
The choice of the connector was mostly due to what I was able to find to the local Radio Shack, it is enough for testing manually the batteries, for an automatic way more signals are needed to be brought  out.
The maximum current involved is less than 5 A, so this connector is perfect for the usage.

Pins usage :

1. + from battery
2. - from battery
3. - from charger
4. + from charger

The plug used with this connector is the Radio Shack mod. 274-0001.

The idea is to disconnect the 3 wires going to the electronic below, from the PCB with the micro-switches (only  the positive and negative connections) and connect them to the connector.

The charger with the connector.
With this modification I can now connect the battery to the charger, putting together the battery wires with the charger wires, or connect the battery to a dis-charger.

In the picture the battery is connected to the charger manually.