Beagle-Board - Beaglebone Black - re-flash it

Yes, OK OK, another post on internet about how to re-flash a Beagle-board Beaglebone black (BBB).
Why ?

Well, I needed to bring back to the origins my BBB and I found tons of instructions if you have Windows or Mac and some contradictory or incomplete instructions for Linux.
So, here my brief note to describe how to re-flash a BBB.

This procedure should be used in order to install the image on the BBB internal memory.
Basically the image will be copied on the internal memory.

Download the image

The image to download MUST BE one for the flash.
Normally is called BBB-eMMC-flasher-yyyy.mm.dd.img.xz from the Beagleboard latest images  link.
oh wait .. WHAT image ?

Well, I wanted to restore the original configuration as when I received the board, so Angstrom.

Prepare the image

On the net there are many places that describe how to do that under Window or Mac OS.
I'm using Ubuntu 10.04 LTS. Any versions however should do.
It is needed :

• Archive Manager
• Disk Utilities
• dd

With the Archive Manager extract the image from the compressed file.

Load the image on the card 

You will end up with a file approx 3.6 Gbyte, so better to use at least a 4 Gbyte micro SD card or better, 8 Gbyte one like I did.
Put the micro SD card in a reader and connect it to the USB port.
Using Disk Utilities identify the added driver, it will be something in the range /dev/sdx.
Also, using the Disk Utility, unmount any partition eventually present on the microSD card.

Open a terminal, go in the directory where is contained the image file and in sudo mode type this command :

sudo dd if=BBB-eMMC-flasher-yyyy.mm.dd.img of=/dev/sdx bs=1M

where yyyy.mm.dd is the part of the image name with the date and x is the correct driver associated with the inserted SD card.
BE VERY CAREFUL in this phase.
A misspelled driver name can format something else !

After few minutes the SD card will be ready.

Flashing the board

Time to flash the board.
ATTENTION !  The procedure can take quite a while !
Allow at least 30 to 45 minutes ! It could take longer though.

Follow these steps :

• Be sure to have the board powered down
• Remove any cape and USB stuff
• Insert the microSD card in the microSD card slot
• Push down the S2 button
• Power up the board KEEPING PUSHED S2
• When the 4 LEDs goes on, release S2
• Some activity on the LEDs will indicate the loading process
• Wait until ALL the 4 LEDs  are back ON - steady ON
• Power off the board
• Remove the microSD card
• Reconnect cape and USB stuff if you have it
• power up again the board

I found in my case, that it is important to have the "bare" board, no capes or USB stuff attached.
I had a USB dongle for an external wireless keyboard and I was unable to flash the NAND.
After removing LCD cape and USB dongle, I was able to flash the NAND without any problem.

Now I have the board running happily with full X server on the LCD.

Hope this article can help somebody

iFood - bread Bodini

Well, technology is my world, but I'm a human being  too, and one who loves to eat.
This blog is technical oriented, preparing food is an art but involve technology too ... OK OK, today I'm feeling to share one of my recipes.
When I have time or when I'm in the mood for bread or pizza, the only way to satisfy such mood, is to prepare the bread or pizza by myself.
I love to cook many other things, on my Pinterest table "iFood" i show something ... if you are curious enough to see that :)

Bodini's bread and pizza recipe

Example of bread obtained with this recipe

Tools

• Bread machine.
  To prepare the dough, use a bread machine.
  Nothing special, almost every generic low cost bread machine will work.
  Just be sure that it can prepare the 2 pounds loaf. Usually such kind of bread machine cost around $40.
• 2 cups Pyrex to measure liquids.
• Set of measurement spoons, from 1/4 tsp to 1 tbs
  tsp = teaspoon
  tbs = tablespoon
• Set of “cups” to measure the flour. Usually these sets goes from 1/4 Cup up to 1 Cup
• wooden mattarello
• dough cutter 
• sprayer for water
• round cutter (for “panini”)
• rectangular nonstick baking trays for the bread.
• Round nonstick baking trays for pizza. Much much better if they have holes, like this one :
  

Bread/Pizza dough

Ingredients

Ingredients for 20 “panini” or 4 pizzas :

• 1 ¾ cup room temperature water
  It is strongly suggested to use filtered water, left in a jar for at least a night.
  Impurities will be on the bottom and the water will be at room temperature.
  Never underestimate the quality of the ingredients, especially the water !
  Water with chlorine or other impurities will make difficult to the dough to raise and will leave a sour taste !
• 2 tsp fine salt
• 2 tsp sugar
• Extra virgin oil
  - Bread : pour enough oil to cover ¾ of the water surface
  - Pizza : the oil have to cover the entire water surface
• 6 cup “normal” flour ( 00 )
• 3 tsp yeast for bread machine or fast raising

Preparation

Put in the bread machine bake pan the ingredients, in this order :

• water
  
• salt
  
• sugar
  
• oil
  
• flour (level it )
  
• yeast
  

Set the program “only dough”, NO BAKING !

This is IMPORTANT because the quantity of the ingredients is above the baking capability of the bread machine !!

Bread preparation

When the dough is ready in the bread machine, remove it from the baking pan and put it on a table.
In order to prepare “panini”, use the “mattarello” to flat the dough.
Flat it at least to reach ½ inch thick.
Then use a round cutter to cut at least 10-14 “round panini”.
Put them on a nonstick baking tray (is possible to use also the pizza round baking tray).
Leave some space between the panini since they will raise a bit and leave them on it at least for 1 hour (don't go over 2 hours !)

The left over dough can be put together and flattened again, then cut it in triangles and then roll the triangles to form a mini roll.
At the end of the raising time, spray the bread with water and put them in the per-heated oven at 400-405 degrees Fahrenheit for at least 18 minutes.

Check sometime the bottom of the bread. If is yellow/brown is ready.

Remove it from the oven and left it to cool down at least for an hour before to eat it.

The best way to cool it down, is to remove the bread from the baking tray (use mittens or oven gloves, it will be HOT !) and put it in a basket.

The best way to taste it is to cut it in half and then put some salami or cooked ham, a little bit of mayo or some cheese (swiss cheese will be great).

It is possible to put the bread in the freezer.
Put it in small quantities (4 to 6 paninis) in a 1 gallon freezer plastic bag. Gently squeeze out the air before to seal it.
The bread will last at least two to three months.

To re-heat it, pre-heat the oven to 350 degrees Fahrenheit, then put it still frozen (out of the bag !) for at least 8 to 10 minutes. Will be like just made.

The bread will last at least a couple of days if not put in the freezer.

Pizza preparation

When the dough is ready in the bread machine, remove it from the baking pan and put it on a table.

Create a big roll and divide it in 2, 3 or 4 pieces.

2 pieces if you like a “soft pizza”, 3 for a normal pizza, 4 for thin and crunchy pizza.

The best result is with 3 pieces.

It is also important to considering the type of topping.
Cheese topping will require short cooking time, topping with vegetables or other ingredients will require more time.
A thin crust will be OK for cheesy pizza.
Thin crust will cook MUCH faster than normal crust ! Remember that !

Using the “mattarello” flat each piece in a round shape.
Spray with flour and turn upside down the pizza during this stage, multiple times.
The dimension of the pizza has to match the round baking tray and thus will determine the “thickness” of the pizza.

Put the flatten dough on a round baking tray.

With a spoon put the basic topping (see below) over the pizza. It must be spread uniformly.

When the oven is per-heated (again 400-405 degrees Fahrenheit) place the pizza in it.
The baking will happens in two phases.

1. Phase one
   Put the pizza with the basic topping on it in the oven at least for 9 minutes (thin pizza) to 12 minutes (thick pizza).
2. Phase two
   Remove the pizza from the oven and spread it uniformly with a lot of shredded mozzarella cheese.
   Put the pizza back in the oven for at least 9 minutes more.
   Check the mozzarella ! When it start to become yellow/orange the pizza is ready !!
   If the mozzarella does not have yellow/orange spots, then is NOT yet ready !
   Don't over bake it.

Topping

How to prepare the basic topping for almost every type of pizza.

In a container, pour the content of a big can of crushed tomato.
Be careful to use ONLY crushed tomato ! Not crushed tomato with basil, or garlic, or other stuff in it.

Then add some extra virgin oil (a couple of table spoon), salt (two or three tea spoon), sugar (1 or 2 tea spoon), oregano (as much as you like, however too much will make the sauce too sour).

Mix it very well.

These quantities are enough for 4 pizzas

For 4 pizza, you will need also at least 8 to 10 cups of shredded mozzarella.
More if you like a “cheesy” pizza.

Quality time with my daughter

My daughter this year choose to do something different from the usual "biology" science fair project.
She choose to build an electric motor and do some tests to see how is possible to improve the conversion of electricity into kinetic energy.
So it was natural my direct involvement in this.

The science fair project had some specific guidelines and "things to do", but from a more practical point of view, the first thing to do was  to build a basic electric motor.
We found  a lot of suggestions on the net about how to do so. In the end the choice depended about the availability of material and simplicity of building.
Here a brief video showing the motor running.

Oh ... she won the Third place for her category at school :)
She also participated to the regional science fair. Unfortunately the motor broke down during the presentation (see notes "Problems" at the end of this article)

Third place for the category

Building a motor

There are many ways to build an electric motor and there are many types of electric motors.
There are AC motors and DC motors.
The object of the experiment was to show how some components of the motor could affect it's performance, when changed.
So we picked up one of the basic-simple type of electric motor, a DC static magnet rotor motor.
The type of motor we wanted to build, had fixed magnet on the moving part (rotor) and an electromagnet on the base (stator).
Many commercial motors have the electromagnet on the rotor and the fixed magnets in the stator, or both electromagnets for rotor and stator, but they are more complex since it must exists a way to bring the electricity on the rotor, a moving part.

Principle

The type of electric motor we choose to build  is extremely simple.
The idea is to have two or more magnets on the rotor. The magnets need to be "paired", i.e. they need to be aligned to themselves.

This simple schematic can help to understand the principle.
When a magnet is close to the Reed switch (a switch activated by a magnetic field) it powers the electromagnet.
The electromagnet generates a magnetic filed with the same polarity of the magnet glued to the rotor, "kicking" it and thus forcing the rotor to spin.
As soon the rotor starts to spin the magnet close to the Reed switch is going away, thus the electromagnets cease to work.
The rotor however continues to rotate for mechanical inertia until the sequence restart, i.e. magnet close to reed switch, electromagnet activated, kick to the other magnet, and so on.

There are some constrains :

• the magnets need to be glued on the rotor facing with the same pole
• the position of the Reed switch must be as much as possible aligned with the position of the electromagnet
• the distance between the Reed switch and the magnet on the rotor is critical. If too far the Reed switch is not activating.
• the distance between the electromagnet and the rotor is critical too. If too close the magnet on the rotor "attach" to the electromagnet when it is disabled.

Rotor

The rotor is the part of the motor that "rotates" and, for the experiment, is the part we decided to change in order to evaluate the performance of the motor.
The rotors were  built using an empty thread spool, magnets and office pins.
Two or more magnets (always in pair) were  glued on the spools and two pins were glued on the spool central hole to form the axe.

Gluing the magnets on the spool

The spools with the inserted pins to form the axe

We chose to orient the static magnets on the rotor with the South pole facing out, mainly because the RPM meter sensor works on the South pole of a magnet.

We used a simple app for a smartphone to determine the magnet polarity.

Stator

The stator is, for our purposes, everything around the rotor.
We used a wooden base and wooden blocks to build the support for the rotor, the electromagnet, the Reed switch and accessories (main switch, RPM meter, ecc.)

The basic components of the stator, a wooden base and wooden blocks

The electromagnet was connected to a battery and a Reed switch.
The Reed switch is necessary because we need to turn on and off the electromagnet in order to generate a magnetic field only when a rotor's magnet is close by.

Electromagnet

We needed something metal and an insulated electric wire in order to build a coil around the metal part.
Since we used  using small voltage for the project (up to 4.5 Volt) we needed a lot of wire.
We used a nail as metal core of the electromagnet, with the wire coiled directly around it.

We used a drill to facilitate the winding of the wire around the nail

Electromagnet, Reed switch and wooden blocks

Prototypes

Two prototypes were built.
The first one was built mainly to prove the concepts and experiment positioning the components.
The second prototype was the one used to actually perform the test and it was built differently, since we learned from the first one what NOT to do.

First prototype

The first prototype was built positioning the electromagnet on the top of the rotor and the Reed switch fixed at the base.
The idea was to have the Reed switch easily glued at the base and position the electromagnet on the top, it was easier to adjust the distance between the electromagnet and the rotor.

The first prototype

The first prototype was working however it had many problems, like :

• the electromagnet was moving, required more strong holding
• the distance between the rotor and the Reed switch was fixed
• it was difficult to change the rotor
• the rotor was not strongly hold on the wooden blocks
• the electromagnet was too weak
• the voltage used was too high

In the end we realized it was better to rebuild it with different principles.

Second prototype

The second prototype was built with  the idea to be able to easily change the rotor and position the electromagnet/Reed switch more easily.

The second prototype layout

A new electromagnet was built, using a 3 inches nail and almost 250 feet of wire, held by a wooden block carved to the shape of  the electromagnet.

The electromagnet holder, a wooden block carved to the electromagnet shape

The new layout included also a better support for the rotor and the attachment of an RPM meter.

The second prototype used for the test. The RPM meter is shown on the  lower right corner

The RPM meter

In order to evaluate the motor performance, we decided to use the speed of the rotor.
To measure the rotor RPM we needed a tool, an RPM meter or 'tachometer'.
So I built an easy tachometer using one of the boards I had around.

The experiment

At this point we had everything ready for the experiment.

We had a motor base, capable to support a rotor and an RPM meter.

We built 5 different rotors, changing the type of the magnets and the number of the magnets.

• Rotor 1
  Two ceramic 0.5 inch magnets - Weight : 12.5 g 
• Rotor 2
  Two Neodymium 0.5 inch magnets - Weight : 20.9 g 
• Rotor 3
  Two Neodymium 0.2 inch magnets - Weight : 12.7 g 
• Rotor 4
  Four ceramic 0.5 inch magnets - Weight : 16.4 g 
• Rotor 5
  Four Neodymium 0.2 inch magnets - Weight : 14.4 g

We decided to proceed in this way :

For each rotor, we choose to perform the test 4 times.

During each test, we set up the RPM meter, let the rotor run for about a minute to "stabilize" the system and then start a 2 minutes timer.
Every 10 seconds we took a reading from the RPM meter.

In this way we ended up with 5 different set of data, one for each rotor.

Capturing the data

Setting the RPM meter

Reading the RPM meter every 10 seconds

From the readings we created 5 graphs to better compare the performance using different rotors.

Here they are :

All the graphs were built using the same scale, so it was possible to compare them directly.

Looking at them resulted that indeed changing the type of the magnet and the number of magnets, the motor had different performances.

Problems

We also experienced a problem.

After building the second prototype we started to collect data for the experiment.

However some rotors had problems. They were spinning at very low RPM and often they were not spinning at all.

We checked the motor and apparently everything was OK .. only apparently.

In the end we discovered that the Reed switch was defective or damaged somehow and it was not always capable to react to the magnet on the rotor.

We decided to substitute the defective Reed switch with a new one, and all the rotors were behaving as expected.

The same problem happened later, during the regional science fair.
The Reed switch broke down again.  The very probably cause of the broke down is the spike of voltage generated by the electromagnet when the Reed switch opens.
Hooking up an oscilloscope we saw spikes up to 250V. On the long run, spikes like that can warm up the metal of the contacts, bending them and leaving the Reed switch unable to operate correctly.
i.e. on the long run the Reed switch mechanical characteristics are compromised by the sparks generated by the electromagnet generated spikes.

The spike in full view - each vertical block is 50 V

A detail of the spike

The poster

Here a couple of pictures of the poster my daughter prepared for the presentation.

Chromecast - quick review

I recently bought a Chromecast device to test.

I already have an Android based "pen-USB" streamer connected to my TV and I was curious to see how a different system was working.

Here some impressions.

Opening

The package itself is quite fascinating.

The device is quite small, actually little bit smaller than the USB Android pen device I'm currently use.

In the box, well packed, there is the device, a power supply, a micro USB cable and an HDMI extension cord, just in case is not possible to connect the device directly to the TV.

Installing

Installing the Chromecast device is quite straightforward.
Just plug it in into a HDMI port on the TV and connect the power.
Some TV have an USB hub integrated, so in this case will there no need for the external power supply.

After a few seconds a screen will appear on the TV.

At this point the best way is to use an Android system (or iOS) and follow the instructions.
A Chromecast application is installed on the smartphone/tablet and from there is enough to follow the directions.

The required time to install Chromecast is around 5-10 minutes top.

Use

One thing must be understood immediately.
Chromecast is working with specific stream services !

In other words Chromecast can stream ONLY services that have an "app" for Chromecast.

Chromecast is NOT :

• a generic Android system connected to the TV
• a relay of the screen of your phone or tablet
• a stand alone computer

Currently is possible to stream from YouTube, Netflix, Hulu, Pandora and few other services but a lot of people is working to bring more apps to Chromecast, to allow more streaming.

The quality of the streaming  is very very good actually, much more better than my USB pen-based Android streamer and also the WiFi management seems better and more reliable than the USB Android pen-based streamer.

The connection to the streaming servers is totally transparent, i.e. no need to set up accounts or passwords. So if somebody with a smartphone has a subscription to some service (like Netflix)  the Chromecast will use that to be connected.

Problems

Well, actually there are few problems, but I'm quite sure they  are depending about my particular configuration of the network.

On my network I have almost everything  with a fixed IP. I do have a DHCP server but the majority of the appliances have a fixed IP (for many reasons).

Chromecast currently is NOT supporting the fixed IP configuration.
So sometimes my DHCP server assigns an address that for some reasons is not working well, leaving the  Chromecast not working. 

On "standard" domestic/consumer oriented networks, where everything is under DHCP, there are actually no problems that I'm aware off.

Another issue is the impossibility to easily stream from a local server.
It is possible to have some streaming done from the phone but there is not an easy way to do so yet.
I'm sure it will be fixed for the future.

Conclusion

Well, for the price I would say that is a "must to have" little device.

Is NOT meant to substitute a self-contained Android terminal connected to the TV, but is incredibly useful to see on TV the most popular streaming using a smartphone or tablet as "intelligent remote".
While watching a streaming the smartphone or tablet remains free to do other things or look for other programs.

And is fun too. Friends with a smartphone/tablet (Android or iOS) can connect to the Chromecast ( after installing the application on the smartphone/tablet) and show their stream selection to everybody.

Update

Just a quick note.
Chromecast can be used also with Apple products.
i.e. is not necessary to have Android smartphone or tablet in order to use Chromecast.
It is also possible to stream from any PC/Mac running Chrome (via  a plug-in for Chromecast) but honestly if you are already in front a computer, is not really important to stream on a TV (my opinion of course).

An anti-spam device - introduction

Notes about the feasibility of an anti-spam phone calls device.

Spammers.
Any day there is always somebody, or somewhat, that place a call to advertise the last offer for a credit card, or to sell the latest life insurance or who knows what else.

Unless to pay for some provider options, usually expensive, the main weapon against these pests, is the caller-ID.

Often is enough to see the number to identify the caller as spammer.
But sometime the number is "local", one of the many tricks spammers use to make more hard to identify a spam call.
Instead to use a 1 800 or 1 888 or other "free" or "commercial" numbers, they use local numbers, to trick the users.
Because of that, the second weapon against these pests, is the answering machine.
With that, you can "screen" the incoming call and identify a spammer or a real call.

The third weapon is our hand.
Everytime an incoming call is recognized as spam, is enough to off-hook the handset and then on-hook it, just to avoid to have the phone ringing and/or a useless and annoying message be put on the answering machine.

But since I'm lazy ... why don't build an appliance capable to do what I normally do ?

The idea is to have an appliance capable of screen the incoming calls and eventually close calls coming from known spammers.
It can not prevent the 100% of spammers to annoy with the calls, but it can limit the disturb.

How it works

The idea is quite simple.
Everytime an incoming call arrive, the system reads the caller ID and compare it with an internal data base.
If the number or name is recognized, the system will pick up (off-hook) and immediately put down (on-hook), closing the incoming call.
Or alternatively, the system can go off-hook, play a message and then on-hook.

If the number is NOT recognized, the system will wait for the user to push a button.
The last received number will be retained, so at any moment pressing the pushbutton, the number will be stored and put in the search list, if not already present.
From the user perspective, if a call is coming from a spammer, will be enough to press a button to let the system to remember the offensive number.
After that, every call coming from that number will be answered by the system.
Of course the system is not 100% accurate because unfortunately some calls doesn't have any caller-ID associated or they have a generic "private" or "unknown" indication.
Some policies are necessary, with a set of limitations, to deal with these special cases.

Specifications

The system will be capable of :

• be connected to a PSTN phone line, POTS interface,  in parallel 
• be capable to recognize when an incoming call happens
• be capable to read the caller-ID of the incoming line
• to search in a database if the caller exists
• be capable to simulate the off-hook / on-hook and eventually to send a audio message on line
• be capable to "edit" the database contents (for example to remove a user put in black list)
• store information about incoming calls (date, hour, lenght of the call, ecc.)
• (optionally) have a LAN interface for management/remote administration

Architecture

The system is built around a processor and logical modules.
Every module describe the functionality, not how it is done.

 
Ring detector

The ring detector circuit, alerts the processor about an incoming call. 

Caller ID reader

The caller ID reader, is sending to the processor the data of the incoming call in ASCIIZ format.

Off-hook/On-hook circuit

The Off-hook/On-hook circuit allows to simulate the handset operation, forcing the line off-hook and on-hook.

Input/Output

At least a display and small keyboard will allow to interact with the appliance.
Depending the processor/platform used, a remote connection (serial/LAN/wireless/ecc.) could allow a computer to extract data/edit the database 

Possible systems

There are many different approaches in order to build such appliance.
The operations to do are simple enough to be executed by a small processor.
Any MCU capable to handle few I/O and having some comunication capabilities, is suitable to be used.
For example a PIC or Arduino or MSP430 can do the trick.

I have around a nice candidate for such project,  the Olimex board with the MSP430f169, that also has a SD card reader/writer, in order to store the phone numbers.
An Arduino board is probably the most efficient solution.

Another approach, is to use a ready made high level system, using maybe embedded Linux as main system.
For example the FriendlyARM board, that supply the processor/memory/user input/display functionality or a Beagleboard or similar card.

Another  board, connected using an RS232 port and I/O, can provide for the Caller ID reading capability, line detection and off-hook/on-hook functionality.

It is indeed quite an overshoot to use a board like the FriendlyArm, but assuming to have the development environment ready, it should be much more easy to build the system.
With such board become also feasible to create an interface to access the data remotely via web.

In any case a board with the POTS interface needs to be built and then interfaced to the system.
An old caller-ID kit is used for the caller ID functionality.

Mc145447 demo board

Centuries ago I bough a kit based on the Motorola MC145447 chipset.
This chip-set allows to decode the incoming caller-ID frame and extract it in ASCIIZ on a RS232 line.
The chip set also provide the ring detection circuit, in order to know if a call is incoming.

Here the schematic of the ITU kit based on the MC145447.

Note that this chip-set is long out of production, but amazingly is still available !

POTS interface

Test #1
A board capable to handle all the POTS operation can be built, starting with the caller ID circuit.
Here a schematic of a test circuit to do the first experiments :

   


The transformer is used mainly to give the correct load when simulating the off-hook, but in future it is possible to use it to send audio messages on line.
For example is possible to simulate the "disconnected  tone" usually sent by the telco provider, in the hope that the calling system will stop to place calls.

Or, just to vent out some stress, to play bad messages toward the spammer :-)

The first tests are done on a breadboard with recycled components.
To the ITU Caller ID kit (the green PCB on the breadboard)  I attached an old modem transformer and a reed relay.
A push-button gives the signal to activate the relay (it will be replaced by a MCU I/O).

The first tests are positive. The circuit is connected to the phone line in parallel and when the phone is ringing, pressing the push-button the call is taken and then released, simulating the off-hook/on-hook operation.

Attaching an audio source to the other side of the transformer (see the plug) is possible to hear it on the remote phone when the system is on off-hook.

In the picture is visible also the Olimex board.

 
Test #2

The next step is to start to integrate the POTS interface toward the micro, in this case the MSP430F169.
The breadboard is more populated, with the addition of a voltage regulator, a more easy to use power switch and the Olimex board, with some signals hooked.
Also some signals from the MC145547 chipset are brought out.

Here a new schematic.

and a picture of the new populated breadboard.

For the moment the MC145547 chip (green board) is interfaced to a normal RS232 connector.
Note the Olimex board with some signals brought out.
The Olimex board will be usually powered by the JTAG, only for tests it can be powered (as in the picture) from the 5V regulator.

This is what I did so far, a very quick prototype to test the feasibility of the idea.

The next step is to build a more reliable circuit and choose the final board.
In the example, the Olimex board with the MSP430f169 was used but probably an Arduino or something Linux based it should be better and more flexible.
As usual I have to wait to find the time and resources to do it ...

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