IP0X Web Firmware Updates

The IP04 IP-PBXes I sell run the BAPS firmware. This is a package based system similar to apt-get. While updating applications is easy updating the Linux uImage requires an awkward RS232 serial cable. This is fine for geeks but very difficult for the average person using an IP04 as their small office phone system. The alternative Astfin and Switchfin IP0X build systems have a web based image update which is much cooler. Web based firmware updates are also common for other embedded devices like OpenWRT and even IP phones.

Briefly, the steps for a BAPs image installation are:

  1. tftp the image, flash the uImage and boot with the RAM based file system
  2. copy the root file system from RAM to flash (mtdblock2), then reboot with

The problem is the “root=/dev/mtdblock0” and “root=/dev/mtdblock2” steps need to be performed in the boot loader using the serial cable. Not for the faint hearted. It also makes switching between IP0X firmware distributions painful.

So I have developed a two stage flashing procedure that works like this. First, flash uImage_r2.mtd0 from the Linux command line:
(cd /persistent if an Astfin box)
root:~> wget http://rowetel.com/ucasterisk/downloads/uImage_r2.mtd0
root:~> dd if=uImage_r2.mtd0 of=/dev/mtdblock1
root:~> reboot

The neat trick is that this image has “root=/dev/mtdblock0” hard coded in the kernel (via a small kernel patch), over-riding the u-boot “root=” settings. This patch doesn’t affect the Ethernet MAC. This image then boots, erases the mtdblock2 flash, then copies the RAM file system to flash. It then wgets uImage_r2.mtd2, which has “root=/dev/mtdblock2” hard coded into the kernel, and flashes this. This second image then installs various packages to bring up an IP0X ready to make phone calls. If an Internet connection is not available it looks for uImage_r2.mtd2 on a local tftp server on

The system works quite well and is fast and reliable in practice. I’ve tested it by flashing about 20 IP0Xs. The IP01s need a special image to install their special brand of zaptel (the only change is one line to pull down the zaptel-ip01 package):
(cd /persistent if an Astfin box)
root:~> wget http://rowetel.com/ucasterisk/downloads/uImage_r2.mtd0.ip01
root:~> dd if=uImage_r2.mtd0.ip01 of=/dev/mtdblock1
root:~> reboot

I have also modified the BAPS uClinux.mk file to automatically make the .mtd0 and .mtd2 targets. You can customise the packages installed by tweaking the rc.normal file and rebuilding uImage_r2.mtd0:
host$ make -f uClinux.mk uImage.mtd0
The rc (executed by uImage_r2.mtd0) and rc.normal (executed by uImage_r2.mtd2) files are captured in this patch.

IP0X Roadmap and Ease of Use

This feature is part of a series of IP0X upgrades, including Asterisk 1.6, Dahdi, security upgrades, bug fixes, uClinux upgrades, and more work on the Mini Asterisk GUI. In particular I am really interested in exploring the ease of use meme. My goal is make the IP0X really easy to install and use in the small office environment for people who know nothing about Asterisk, Linux, and telephony.

I have a theory I would like to explore. One “problem” with the IP0X range is it’s low price (hundreds of $) compared to normal PBXes (thousands of $). There is just no room for regular margins needed by the “PBX guy” to install and maintain an IP0X phone system. So I think the IP0X needs to be really easy to set up and use. More like a Wifi router, ATA or DSL modem. That’s my thinking behind Mini Asterisk.

A Drive in the Mitsubishi MIEV

Today I was fortunate enough to go for a drive in a MIEV, the single demo unit that is on tour around Australia! This will probably be the first of the new generation of production electric cars (fingers crossed).

Funny how these things come about. I was sitting down to lunch on Sunday talking to one of my wife’s friends, Nina. She mentioned that she was a receptionist at Mitsubishi Adelaide, and told us the staff would be having a test drive of the MIEV today.

Say what? I didn’t even know it was in town. I was pretty excited so Nina kindly asked the Mitsubishi people if I could take a look at the car, and I was invited to join Nina on a test drive! WOW!

So at 3pm today I hopped in my EV and electo-commuted down to Mitsubishi HQ. Just as I entered the car park I saw the little MIEV cruising around. It pulled over as they changed drivers. Suddenly, just as I was passing the MIEV suddenly shot out in front of me – if I hadn’t hit the brakes we might have had the first EV on EV collision. Try explaining that to the bosses back in Japan!

The MIEV had a big sticker “Australia’s first Electric car” on the back. Ahem. Really? Then what, exactly, am I and probably 100 other Australians driving? They can’t even say “first production EV”. Yet (production starts in July).

Anyway Nina and I waited patiently and soon is was our turn. I hopped in the spacious rear of the car (heaps of leg room and height) while the Mitsubishi engineer minding the MIEV (Ashley) showed Nina how it worked. It has an automatic style gear selector but basically its D to drive and off you go. Nina drove us around the nearly empty and spacious Mitsubishi car park, getting up to about 50km/hr. We got a good feel for the acceleration and regenerative braking (both good). It felt nice and light compared to my lead-acid EV, especially over speed bumps. Easy to drive and a nice little car.

The instrumentation was a speedo, a charge/discharge gauge, and a battery bar graph. I missed the presence of an ammeter and voltmeter, but I guess part of the magic of a production EV is abstracting some of the technical detail away from end users.

It has a home charger (overnight) and a fast charger (30 minutes to 80%). The fast charger requires something like 50kW – equivalent to a whole suburban block here. It would make the street lights go dim! Anyway I figure that just like our EV the regular charger is good enough. Filling up an EV is not like filling a petrol car, you don’t stand around waiting for it to fill up. It’s more like a mobile phone, you just plug in and walk away.

After the MIEV Nina asked if she could try my EV! We followed the same course and curiously it felt and drove much the same. Nina said both cars felt great. If my car had Lithium batteries (i.e. equivalent range and weight) there wouldn’t be much in it at all.

The MIEV project is one of the new breed of factory EVs. I really hope it goes into large scale production and turns up in a showroom soon at a reasonable price. Good on Mitsubishi for making this happen.

IP01 – SOHO Asterisk Appliance

Atcom have recently built a 1 port version of the IP04, called the IP01. The IP01 is a palm sized Asterisk IP-PBX. It has an ATA form factor with serious CPU horsepower for around US$160 (plus analog module). Ideal for an office or home that has SIP phone extensions and VOIP trunks and maybe one legacy device like an analog phone or Fax. Sure beats a x86 PC with a X100P FXO card for form factor!

The single module can be either FXO or FXS. A full DB-9 is broken out on the back for the serial console – I really like this as it makes hacking easier. The IP01 is based on the open hardware and software IP04, and runs all the same software; including uClinux, Asterisk, Zaptel, Oslec echo cancellation, and the new Asterisk Now 2.0 GUI.

It is totally overpowered with a 400 MHz Blackfin BF532, so it can handle serious DSP work like echo cancellation and transcoding.

With a 256 Mbyte of flash and 64M byte of fast SDRAM the IP01 has plenty of room for uncompressed voice prompts and voice mail, plus all the software you will ever need on an embedded device. For comparison the IP01 is about 10 times the CPU power (faster CPU clock and more importantly SDRAM bus speed) of a WRT54 and has 64 times the flash. Compared to an ATA it has high quality echo cancellation, runs a real operating system (uClinux), and is totally open (hardware and software) and therefore very hackable.

For more information, here is the IP01 brochure. If you would like to experiment with the IP01 I will be getting some samples in about 2 weeks, available from my store.

Open Hardware 3 Years On

In 2005 I started working with Asterisk on the Blackfin. This led to the Free Telephony Project, and the idea of using open hardware techniques for telephony. The idea of open hardware (people collaborating to build free hardware designs just like open software) was a big experiment, especially when it came to commercial products.

Back in 2006 I posted my initial ideas on Open Hardware. Much has happened since then. Many people and companies are now working on Blackfin Asterisk projects. New projects, and even businesses have spun out of the project. Coolest of all – open hardware products are now in volume production, as real world, commercial products like the IP04. People are buying and using these products – often in preference to products developed using traditional closed development models. Open hardware works!

Open Hardware in Business

As the idea of Open Hardware matures a few patterns seem to be shaking out. The form of open hardware distributions seems to be the schematic. Companies are largely keeping the PCB designs and other tooling information closed. This gives them some sort of protection against direct copies hurting their business. At least that is the perception – I actually think the PCB is a small part of the total business picture.

Directly cloning open hardware designs doesn’t seem to work as a business model. The prototype IP04 design (schematic and PCB) is entirely open – all the CAD files are free for anyone to use. In theory this means you can give these files to your local surface mount assembly line, ask them to build 100 IP04s for you, and be in the IP04 business. I get 1-2 emails/month from companies intending to do this.

However in practice you need the skills to find small hardware faults, an understanding of the design, experience in building and flashing the firmware, testing, QA, support. Like many valuable things in life, these skills must be acquired, and can’t be copied. You need that hacker mindset to understand how the beast works. The IP04 hardware and software is rather complicated so you really need the support of the community. This requires a community outlook. Those interested only in $ don’t share these values, lose patience and move on.

The real power of open hardware seems to be providing a baseline for your product development. Take the hardware and tweak it. Add a different line interface, more ports, less ports, hardware rather than software echo. Add your software application to the baseline build system. Code up your own build system.

Open Hardware, Closed Tools

Most people are developing their open hardware with closed source schematic/PCB CAD tools. Bit of a pity, but ultimately hackers will use the best tools for the job, open or closed. That is why many hackers use open source software – it’s just better. Hopefully this gap in CAD tool performance will be filled soon.

Open Hardware is Software

Curiously, the “open hardware” projects are dominated by software complexity. The effort involved in the fun stuff (soldering, schematic and PCB design) is dwarfed by the effort involved in the software, e.g. maintaining build systems, porting applications, testing. The majority of my time on this project has been spent on build system work, then software, then the actual hardware. This is part of the general trend of hardware functionality shifting to software. The vast complexity of the software means a lot of time needs to be spent managing it with configuration control and build systems.

Open Hardware is Hard to Grok

Just like Open Software in 1992, the concept of Open Hardware is hard to understand. The ground rules are still being worked out. Full points to companies like Atcom for overcoming these concerns and embracing open hardware.

Some memes that are particularly tough:

  1. If it’s open won’t people just copy my product? Well, this doesn’t seem to be a big problem in practice. Many other factors are required for a successful business, as discussed throughout this post. Value tends to shift to other parts of the business, and the advantages of sharing and community outweigh closed development and secret sauce.
  2. For the open source community, re-flashing commodity hardware (e.g. OpenWRT on a WRT54) is now common practice. However moving from this to open hardware takes a big shift in mindset. Here is the dirty little secret of the hardware game: hardware products are 95% software. The man hours invested something like OpenWRT or Asterisk are orders of magnitude greater than those put into developing the WRT54 hardware or a PCI telephony card. And yet open software communities wait nervously for the next commodity hardware box, only to find it doesn’t have the feature they require, or goes out of production, or the manufacturer won’t release the internal data, or it doesn’t have enough flash etc. In the mean time the manufacturers and chip set vendors are having a great time making money from using your open software in their products.
  3. Open hardware is not that hard. The truth is that a modest community effort can develop and bring into production a full custom open hardware device (designed exactly to your specification), and arrange to have it volume manufactured at a reasonable price. We have done exactly this with the IP04.

Extreme Open Hardware

Some of the radical uses of Open Hardware I had hoped for haven’t happened yet. I am particularly interested in seeing Open Hardware being used to help people in developing countries. For example new business models like IP04 assembly in Africa for local markets, or volume manufacture at cost price (give 20,000 people telephones for $500,000). The Mesh Potato is part of a fresh new project where we are using open hardware and software to help bring telephony the developing world.

IPO Opportunity

I do this work largely as a volunteer (although I derive a modest income from IP04 sales and contract work), so like many hackers I choose to work in areas that interest me. This year I have been shifting my focus to telephony for the developing world. I am not personally motivated by the business side. So the IP04, while very usable, still requires an understanding of the Linux command line and Asterisk conf file skills (although the GUIs are steadily improving).

There are several companies working with open hardware Blackfin Asterisk technology. So far I see companies that are good at manufacturing, some that are good at build systems, and fewer still that are good at software optimisation, hardware and DSP. A big opportunity exists for a company that can combine strong technical skills with solid marketing and business skills to produce a bug free, feature complete turn-key appliance product. This has proven surprisingly difficult to do – even with all of the hardware and software available in open form. To me this drives the lesson home that a business is much more than just the technology.

You know as a community we bring all of the above technical and business skills together. So the project as a whole is thriving, just no one person or company has a monopoly on the intellectual property and profits. And that, I put to you, is a good thing.

Open Hardware for Hackers

Call me a geek, but the greatest reward for me is a bunch of people soldering tigether their own uClinux Blackfin Asterisk boards at home, and bringing up their very own uClinux IP-PBX. There is nothing quite like seeing the root prompt come up on a Linux board you soldered together yourself, or hearing that phone handset ring for the first time. Open hardware gives the hacker the remarkable power to build IP-PBX products that took large teams to develop just a few years ago.


  1. An introduction to Open Hardware, written as the Free Telephony Project was just starting.
  2. See the amazing range of hardware and software in the Free Telephony Family Tree.
  3. Steve Song’s thoughts on Open Hardware for the Developing world.

Free Telephony Family Tree

In 2005 I started messing around with Asterisk on the Blackfin. This led to the Free Telephony Project, and the idea of using open hardware techniques for telephony. Much has happened since then. Many people and companies are now working on Blackfin Asterisk projects. New projects, and even new businesses have spun out of the project.

This post is my attempt to document the various hardware and software developments in family tree form. My role is fast diminishing as more and more people get involved – this is how it should be. None of this would have been possible without a bunch of good people from around the world working together as a community.

If I missed anything (or anyone) I humbly apologize – please let me know so I can update this post. I have left out a few top secret projects that are being performed behind closed doors in traditional “closed” development form. Plus I imagine there are many other people using this technology that I am not aware of.

There are also a bunch of other hardware products (such as the Digium Asterisk Appliance) that were developed independently using similar technology. This post only includes those projects that have some sort of direct relationship with the Free Telephony Project and open hardware.


Below is a map of all the open hardware projects and how they relate to one another. I count 14 separate hardware designs that have been built – amazing!

Wow – that’s a lot of obscure acronyms! Lets see if I can explain what all those line-noise names mean:

  • The Blackfin STAMP from Analog Devices was the first open hardware uClinux board design. I started playing with the STAMP in August 2005. Analog Devices took the unique step of releasing the schematic and PCB files. A post by Robin Getz opened my eyes to the possibility of open hardware. Got me thinking!
  • X100M hack: I modified the Zaptel drivers and soldered a Digium X100M FXO module to a Blackfin STAMP board. First Blackfin FXO phone call in Dec 2005. Asterisk on the Blackfin lives!
  • Fourfin: Some excellent early work (2006) on a 4 port BRI-ISDN daughter board for the STAMP by Philippe, Tom, and Thomas.
  • 4fx: Four analog port daughter board for the Blackfin STAMP, which was available in kit form (October 2006). Some work I did with Jerry Zeng from Analog Devices really helped this design along. The 4fx really got the ball rolling, as people could buy this card and a STAMP and start experimenting with Blackfin Asterisk.
  • The initial BlackfinOne V1.0 design (by Ivan and Dimitar) first appeared in mid 2006. This was an amazing project – a fully open uClinux Blackfin board designed with open source tools. I was interested in using it as a DSP motherboard for my telephony work so a group of us worked together to add dual Ethernet ports and a USB port to create the BlackfinOne V2.0.
  • The BlackfinOne V2.0 design and the 4fx were combined to create the first real product – the IP04 IP-PBX in April 2007. Atcom came on board to manufacture the IP04 which is now in volume production. Many have been sold and are in every day use around the world. Atcom are following up with the 8 port IP08 and single port IP01.
  • The PRI and BRI Appliance products are being developed by the Astfin team. The PR1 was a BlackfinOne V2.0 daughter board used for testing the PRI line interface.
  • Li at Edge PBX has been very busy developing a range of products (FX02, FX08, FX08D) with novel combinations of analog and PRI ports.
  • The Telesto TL-2XS is a 2 FXS port IP-PBX using the BF536 processor.

I should mention a couple of projects that are not Blackfin based, but still related to Free Telephony:

The $10 ATA was an idea I had for adding low cost FXS port capability to a wireless router. Although this project is currently inactive, there are two related active projects. One is the mega Mesh Potato, and the other a cool little project to build an Open USB FXS ATA being developed by Angelos.


In August 2005 I had the idea of running Asterisk on the Blackfin. I had some leave for the birth of my 3rd child but in typical hacker fashion spent most of the time hacking Asterisk to run on uClinux! First phone call (SIP phone to Asterisk on a Blackfin) was in September 2005.

Here is a breakdown of the various software projects:

  • uClinux-dist: Analog Devices do an incredible amount of work maintaining and supporting uClinux for the Blackfin.
  • uCasterisk: First build system (released Dec 2005) – OpenWRT hacked to build Asterisk for the Blackfin. Back then uClinux didn’t support shared libraries so some interesting but now obsolete hacks were required to run Asterisk.
  • Astfin 1 was a re-write of uCasterisk, based on the buildroot type approach (e.g. like OpenWRT). Lots of work went into this by Mark, Pawel, Alex and Li (plus many others) and it was very useful over the course of 2007.
  • As 2007 wore on several ideas for improved build systems appeared. The outcome was a package based build system called BAPS and Astfin 2.
  • To make the various line interface hardware (FXS/FXO analog, BRI-ISDN, T1/E1 PRI) work various drivers were ported to the Blackfin platform. Driver work is often harder, takes longer and is less fun than building the actual hardware. Lots of good driver work by Diego/Mark/Pawel (BRI) and Mathieu & Mark (PRI).
  • Voiptel have done a great job at porting the AsteriskNow GUI written by Digium to the IP04.
  • Steve Underwood’s Spandsp library was integrated with the IP04 by Jeff, and was used as the baseline for Oslec – the open source line echo canceller. Steve, along with Jean-Marc Valin of Speex fame are some of the few guys doing open source DSP work for telephony.

Low Power Asterisk – 4 telephones on 3W

For the last few days I have been working to reduce the power consumption of the IP04 configured with FXS ports. With some simple software changes I have managed to halve the idle power from 6W to 3W with 4 FXS ports running. A bonus is that the FXS modules run much cooler, which is great for reliability and extending their life.

Power consumption is a very big deal for developing world applications – in many parts of the world electricity is the the number one problem when running IT equipment (arguably more of an issue than capital cost). In places without an electricity supply, solar electricity is used. There is a great chapter on solar power systems in the Wireless networks for the Developing World book.

The cost of a solar power system is directly proportional to the power consumption. So if we can reduce our power consumption by 50%, the size (and expense) of the panel and battery are reduced by 50%.

My specific aim is to minimise the power consumption of an IP04 Wifi “node” in the proposed Village Telco network.

Halving the IP04 power consumption

I set up an IP04 in a “worst case” configuration – 4 FXS ports. FXS ports connect directly to analog telephones and need to supply the 48V line voltage to power each phone. Each FXS port module has a DC-DC converter for this purpose. I powered the IP04 from a bench power supply that was metered for current and voltage.

I am mainly concerned with the idle power consumption, as this is how phones spend much of their time. Unless of course the phone belongs to my wife or teenage daughter. The idle power dominates the calculations for the size of the solar panel and battery and therefore the cost of the system.

After trying a few calls I noticed something odd. Just after booting, 0.31A was being used. However after I made a call, the current jumped up to 0.36A and stayed there after the call had finished! This was repeated for all ports, such that after completing a call on each port the total idle current was now 0.51A (6.1W with a 12VDC supply voltage). Huh?

After a few hours of looking at the wcfxs.c driver and the Si Labs 3215 data sheet I worked out the problem. After a call was completed, the audio circuits of the 3215 chip were being left powered up. At boot time, the audio circuits were powered down. So the driver was setting the idle state to the incorrect mode at the end of each call. We don’t need to process audio while the handset is on hook, so a one line driver mod dropped the idle current from 0.51A (6.1W) to 0.31A (3.7W).

The other refinement was to use the wcfxs drivers lowpower option, i.e if you start the driver like this:
root:~> modprobe wcfxs lowpower=1
This sets the line voltage to 24V rather than 48V, lowering the idel current to 0.25A (3W). An added benefit is that the FXS modules run much cooler, extending their life and reliability. A lower line voltage is fine for many applications. The higher voltage is really only required for very long phone lines (1000’s or meters) to overcome line resistance. You are just burning power when using a 48V line voltage for shorter lines.

Installing the new Zaptel driver on your IP04
root:~> ipkg update
root:~> ipkg remove zaptel-spi
root:~> ipkg install zaptel-spi

Edit /etc/init.d/zaptel and set LOWPOWER=1, then reboot. If you measure the voltage across a FXS port it should be 24V.

Typical power consumption

While messing with the IP04 power consumption I took the opportunity to measure a bunch of common devices used for VOIP and Wifi:

Device Voltage (V) Current (A) Power (W)
IP04 – no analog modules 12 0.09 1.1
IP04 – 4 FXS ports idle 12 0.25 3
IP04 – 4 FXS ports off hook 12 0.6 7.2
WRT54GL – running OpenWRT 12 0.21 2.5
Minitar Wireless AP 12 0.21 2.5
Sipura SPA-2000 5 0.46 2.3
SipTone 2 SIP phone 12 0.2 2.4
1.6GHz x86 Laptop 18
500MHz x86 Desktop – no monitor 34

An Asterisk IP-PBX on 1W (no analog modules) is not too shabby (beats a much less powerful WRT54). But the real win is with 4 FXS ports, just 3W. By comparison a low-end 500MHz x86 Desktop with a Digium PCI card (4 analog modules) drew 34W. So an idle power of 3W for an Asterisk IP-PBX with multiple analog ports is a great result.

My friend Alberto from IT 46 did some quick calculations that showed we could power an IP04 plus Wifi router with a 20W panel (allowing extra power for cloudy days, charging the battery etc). That means we could install a four-phone Village Telco system using just a 20W panel.

Next step – set up a solar powered IP04 in my back yard!

Future work

This work only scratched the surface on reducing power consumption. All the IP04 really needs to do while idle is provide DC to the phones, and monitor the hook state. So it might be reduce the clock of the CPU (say from 400 to 40MHz), or put it in sleep mode awaiting a hook event or an incoming Ethernet packet (e.g. an incoming VOIP call). It would also be interesting to compare different FXS chipsets on the basis of power consumption.

This is the great thing about and software – you can modify the system to meet exactly your needs, rather than being constrained by what the manufacturer had in mind.

Now of only we had an open hardware wifi router……
pornography capturingcar porn mpgspornos caramelcaramel porn the starporn captors cardporn carebearcarey pornsites porn caribbean boys Map

FreePBX for Embedded Asterisk

This post tells the story of porting a LAMP stack application (FreePBX) to an embedded Asterisk system running uClinux on the Blackfin processor.

A few months ago I noticed that the Astfin guys had managed to get sqlite and PHP running on the Blackfin. Pretty impressive: a SQL database and PHP running on a uClinux box. This runs against conventional wisdom – embedded systems that run uClinux typically have a small amount of storage and use simple CGI based GUIs written in C, and a tiny web server like boa.

Could a FreePBX port to the Blackfin be possible? Is it really possible to build a LAMP application on uClinux, running on hardware that can (at minimum) be built with just 3-4 chips (CPU, flash, RAM, Ethernet)?

FreePBX is the popular Asterisk GUI, used in many Asterisk distros such as Trixbox and PBX-in-a-flash. A little investigation of the FreePBX code revealed some prototype support for sqlite3 (it usually runs with MySQL). I mentioned the idea to the Astfin guys, who also decided to start working on a port. So for the last month or so a loosely knit group of developers have been working on a port of FreePBX to the Blackfin. Sort of working in parallel, but bouncing a few ideas off each other and sharing our code.

We have now reached the stage where we have some alpha functionality – the FreePBX GUI screens work, we can set up extensions, save them to the database, and make calls. There are a few bugs, and I would like to do some more work to reduce memory consumption. But I am convinced that FreePBX on uClinux is possible.

Here is FreePBX running on an IP04. The Nokia palm top seemed appropriate!

I am still amazed that we can run FreePBX on a platform that can be built with just a few chips and consumes just 3W!

FreePBX is a big, chunky, web based application written mainly in PHP. The GUI screens talk to a SQL database and Asterisk via the Asterisk Manager interface. Every time a call is dialled, a PHP script is run via the Asterisk AGI mechanism to compute parts of the dialplan. This is heavy weight and scary for a little uClinux box!

The first challenge was to get sqlite3 support working. There was some partial support however it in needed updating for the latest FreePBX version. In particular the PHP 5 support for PEAR/DB had to be rebuilt. PEAR/DB is a database-independent backend for SQL databases. This wasn’t too hard, although as I haven’t got much experience in PHP or SQL (or FreePBX for that matter)) I had a learning curve to climb.

x86 FreePBX Sandbox

To make life easier I set up an x86 development environment for FreePBX. I figured it would be much easier to get sqlite3 support running on an x86 that messing around on the embedded target. However after I had a few goes at installing FreePBX on my Ubuntu laptop I noticed that it did a lot of messing around with the configuration of my laptop and my root file system. It also has a lot of dependencies that weren’t always handled nicely by my system, for example a certain version of a library might not be available as a pre-installed Ubuntu apt-get package. Due to my inexperience with FreePBX I got myself into configuration hell a few time (e.g. multiple copies of PHP) before I finally worked out how to get a basic FreePBX install working.

So to work on FreePBX on my x86 laptop I figured out a different way that I borrowed from embedded systems. I built up a “sandboxed” development environment for FreePBX where I compiled all of the applications I needed (and the exact versions I needed) from source. This build a simulated “root” file system that doesn’t interfere with the rest of my x86 laptop configuration. A single Makefile handles the whole thing, downloading the source tarballs and building PHP, lighttpd, sqlite3,and finally running the FreePBX installer.

Here is what the freepbx-sandbox directory looks like after everything is built:
[david@bunny freepbx-sandbox]$ ls
dl lighttpd-1.4.18 package.xml root
files Makefile patch sqlite3-0.5
freepbx-2.4.0 Makefile~ php-5.2.5 sqlite-3.5.6
freepbx-2.4.0-orig package2.xml README.txt xdebug-2.0.2
[david@bunny freepbx-sandbox]$ ls root/
bin etc include lib man sbin share var www
[david@bunny freepbx-sandbox]$

The Makefile takes care of all the intricate steps required for a manual FreePBX install, and also applies the patches I required for sqlite3 support. To make FreePBX run in my sandbox the Makefile also tweaks a few hard coded paths (like changing /etc/amportal.conf to /home/david/freepbx-sandbox/root/etc/amportal.conf) using sed. This means I get a consistent FreePBX development environment every time, without any manual install steps (one make command takes care of everything). More information of the freepbx-sandbox idea is available from SVN.

The sandbox idea is borrowed from the buildroot technique used for embedded work. For embedded systems we often download/patch/cross-compile applications and build up a root file system for the target, that is then burnt onto the embedded target system’s flash.

It was nice to find some synergy between embedded and x86 work.

Memory and Big uClinux Applications

Once the basic sqlite3 support was running on an x86, it was relatively straight forward to get the FreePBX GUI screens running on an IP04 target. The lighttpd web server was used rather than Apache to save memory – we don’t really need anything as heavy as Apache just to serve a few GUI screens to one person. Lighttpd was ported to the Blackfin by Mike Taht.

We discovered a few problems straight away – after a few minutes the system would run out of memory and the web server would core dump. The FreePBX Admin screen is pretty heavy duty for our little embedded system – it updates each second which involves the web server starting up an instance of PHP, loading and compiling a bunch of PHP code, connecting to the database, connecting to Asterisk, doing a “df” to determine a few system stats, and rendering the status page.

Loading PHP all the time is hard on a uClinux Blackfin system. An application that big is stored in NAND flash, which has a relatively low bandwidth. PHP is big – it typically uses 8M of the IP04’s SDRAM at run time. The Blackfin doesn’t have a MMU, so when PHP says “I need 2M”, then uClinux gives it 2M of physical memory. Your x86 would just allocate one 4k page and let the MMU allocate the rest of the 2M as (and if) it was needed. So as well as having a relatively small amount of memory (64M), the memory is often used inefficiently.

I have a suspicion that under uClinux most of the memory allocated by big applications like Asterisk and PHP is probably all zeros and remains unused (but unreclaimable).

uClinux also has memory fragmentation problems. As explained above, if you need 2M of memory, the operating system actually allocates 2M of physical memory. However this allocation may cause the memory map to become fragmented, as it means there is a “hole” in physical memory of 2M which limits the size of memory chunks that can be allocated either side of the 2M chunk:

Memory fragmentation is particularly a problem when you have many large allocations. It can lead to Out Of Memory (OOM) errors even when there is plenty of actual memory left. In the above example 3M of memory is available, however if we try to allocate a 2M block we will get an OOM error. Available physical memory may be too fragmented to allocate the continuous blocks needed by an application.

Mike had the idea of using the fast CGI feature of lighttpd and php-cgi. This means that php-cgi remains memory resident, removing the need to load PHP all the time and avoiding memory fragmentation issues (one big allocation at system start up is generally better than many big allocations over time). This worked pretty well, we could now run the Admin screen without any memory problems. You can see the php-cgi process running below on an IP04. It stays up all the time and communicates with lighttpd via a socket:

root:~> ps x
PID Uid VSZ Stat Command
39 root 602 S dhcpcd
62 root 13910 S asterisk -f
64 root 6610 S php-cgi -b
66 root 901 S lighttpd -D -f /etc/lighttpd.conf
68 root 1386 S -/bin/sh
69 root 13910 S asterisk -f
70 root 1242 S /bin/syslogd -n
72 root 1242 S /bin/klogd -n
73 root 13910 S asterisk -f

Note the php-cgi process is using 6.6M of memory, even when it is not doing much (i.e. just waiting for a connection).

Apply Configuration Changes

At the top of the FreePBX screen there is a clickable area marked “Apply Configuration Changes”:

After you make a few changes to the FreePBX configuration (e.g. setting up a SIP extension) you click on this area and the configuration information is loaded into Asterisk. To do this the FreePBX php-cgi process execs another PHP script called retrieve_conf. So we have two PHP instances running at the same time, which chews up about 30M total (15M each) of memory on our little uClinux system. Gulp.

This was proving too much for our IP04, when we clicked on “Apply Configuration Changes” and ran retrieve_conf we were running out of memory and copping the inevitable OOM error! A bit of investigation showed that retrieve_conf actually runs a lot of code (for example connecting to the SQL database, connecting to Asterisk) that the parent php-cgi process has already initialised. So with a bit of PHP hacking I re-arranged the retrieve_conf code to be an included function of the main php-cgi script rather than having to exec a whole new PHP process.

This meant we could run “Apply Configuration Changes” in around the same sort of memory as the regular admin GUI, saving a crucial 15M at run time. Faster, too. So now we were well on our way – we could run the FreePBX GUIs, use sqlite3 as the database, and apply the configuration changes to Asterisk.

Next step – lets make some calls!

AGIs for each Call

While I was working on the “Apply Configuration Changes” functionality the guys on the FreePBX forum pointed out that FreePBX runs a PHP script for every call dialled via the Asterisk AGI mechanism. This means that as Asterisk works through the dialplan:

exten => s,1,GotoIf($["${MOHCLASS}" = ""]?dial)
exten => s,n,SetMusicOnHold(${MOHCLASS})
exten => s,n(dial),AGI(dialparties.agi)

It shells out to a PHP script like dialparties.agi. This means that another instance of PHP must be exec-ed from Asterisk when each phone call is dialled. This, coupled with the fragmentation issue, had caused some problems on some earlier attempts to port FreePBX to the Blackfin.

To test the affect of PHP AGIs I set up a little automated AGI test to make 10,000 calls using the dialparties.agi script. This worked really well, no evidence of any fragmentation issues and all of the calls were completed OK.

I think the main problem with FreePBX AGIs on the Blackfin was not so much fragmentation as file buffering. You see by default uClinux on the Blackfin (up the the uClinux-dist-2007R1.1-RC3 releases at least) can use up to 100% of its memory to buffer files. However you can throttle this with something like:
echo 10 > /proc/sys/vm/pagecache_ratio
which sets aside a maximum of 10% of system memory for file buffers. If you leave this at the default 100% after system memory is gradually consumed to a point where large apps like PHP can’t load.

The AGI still sucked up about 9M every time it ran, but at least the system was stable. Note that dialling uses less memory than the GUIs (9M compared to 15M), this is because it loads and runs much less code.

Note: in the latest Blackfin uClinux-dist-2008 I understand that the memory used for file buffering can now be reclaimed if required automatically. However at the time of writing I still need to test how effective this is with FreePBX.

Putting the IP04 on a Diet

Next step – we needed to free up some more memory so that the GUI screens and dialling AGIs could all run happily at the same time. I tried a few tricks:

  1. Shrinking the default 8M rootfs partition down to 3M.
  2. I realised that the AGI scripts written in PHP only needs a subset of the PHP features required by php-cgi. So I tried compiling a small version of PHP (1.7M dynamically linked, c.f. normal 3.4M static version) and tried using that for the the AGI.

These steps worked well, and we now have a minimum of about 9-10M free when simultaneously looking at the admin screen (which refreshes every 1 sec) and dialling calls. Previously free memory was dipping down to just 3-4M, and it seemed to bounce around perhaps due to fragmentation issues.

FreePBX Installation on the IP04

On embedded systems running any kind of ‘make install’ process is uncommon. Usually the host system handles ‘installation’ at build time, and you flash the target with an image of the complete file system. This works OK for regular C applications where you can tell ‘make install’ to write the binaries to the target’s root file system that you are building on the host.

However FreePBX has an installer written in PHP, and it assumes that it is running on the target system. While it would be possible to manually do the install on the host, I decided to try the rather novel step of running the installer on the target embedded system.

So I actually download the entire 4.3M FreePBX-2.4.0 tar ball to the IP04, then run the install_amp script on the IP04! What makes this possible is the large amount of NAND flash (256 MBytes) available on the IP04. It’s more like using a hard disk based system than your typical embedded system.

To make life easier packages (using ipkg) were developed for all the FreePBX components. This actually makes FreePBX easier to install on the Blackfin than on some x86 platforms! The install procedure is described in detail here but is something like this:
root:~> ipkg install zaptel-spi asterisk
root:~> ipkg install freepbx
root:~> cd freepbx-2.4.0
root:~> cat SQL/newinstall.sqlite3.sql | sqlite3 /var/freepbx.db
root:~> ./install_amp

As the port is still alpha, there are currently some extra manual install steps which will eventually be taken care of by the ipkg install scripts. Here is the installer doing it’s thing on an IP04:

Much like an x86 installation. Also by using the FreePBX installer rather than a manual build-time installation we can more easily track any changes in FreePBX.


We have an Alpha version of FreePBX ported to the Blackfin, and running nicely on an IP04. We can configure using the GUI screens, apply changes to the system, and make calls. Still lots more testing, a few bugs, and some fine tuning to go to make FreePBX truly usable and reliable on the Blackfin. But it’s a good start.

Curiously, I am not quite sure why I spent the better part of a month trying to do something crazy like get FreePBX running on an IP04. I would like to have a logical reason but I can’t for the life of me think of one. I don’t even like GUIs much, and would rather use conf files! I just realised it was possible one day and it seemed worth investigating. Before I knew it I was “sucked in” to the project and working on it in every spare moment.

But it was interesting. I had never done any work on big web based apps, and had never used PHP or done much work with SQL. A chance to push the limits of the Blackfin and uClinux. Attempting things that a uClinux system was not meant to do. Guess that was the main motivation. Once you get started on a project – something compels you to drive it to some sort of finished state (Alpha functionality in this case).


I documented the development of FreePBX for the Blackfin on this Blackfin Asterisk Forum thread.

FreePBX forum thread on porting retrieve_conf and dialparties.agi testing.

FreePBX installation documentation for the IP04.

FreePBX sandbox documentation.
pay 60 loans dayrates 20 loan 80uk loan home in 90home 90 uk loansloan land equity acom loans aaaaa automobile loansloan acceptance companyloan savings account cash fastaccount loans payday savingssex function and acupuncture3-way sex1960 s hardcore pornamatuer sex animalof teenagers ambassadors americanamateur made pornporn star americas hot nextdegree 2nd sexual assault Maphome program accredited schoolloan building 228 creditpay credit accept month card minimumaccredited information computer in technology collegescards today remotely credit acceptbusiness small credits for cards acceptingprograms bachelor degree accreditedmerchant card credit account washington Mapmp3 lahdo ablahaddlaczego mp3 003mp3 semester abroad law judeminded absynthe mp3mp3 maia abelhamp3 abhirami andhadhimp3 ableton djingsaraca 004 mp3 inima Mapbandh mp3 aankhe karkelara atb mp3 9pmshrivastava aadesh mp3babi aala mp3mp3 record rpm 78 archiveskqrs show morning 92 mp3khuli aankhen mp39th at mp3 pine Mapluvana movies free carmenmovies gang bang freemovie taboo seriesmpeg lesbian movies freemovies of cocksuckingmovies xxx freethe movie dancing dirtyonline movies adult Map

Prototype IP08

This week I have been working on one of the first Atcom IP08s, an 8 port version of the popular IP04 Embedded Asterisk IP-PBX. The IP08 combines the BlackfinOne and two 4fx designs onto a single board the same size as the IP04.

Features include:

  • Dual port modules that are the same size as the regular single port modules. The guys at Atcom have used a clever layout so that single or dual port modules can be used and automatically detected and configured.
  • Dual Ethernet ports.
  • USB. This is pretty cool. I have some ideas about combining this with wireless USB keys to create a tiny, low power wireless VOIP PBX.
  • MMC slot for up to 4GB storage. Thanks to Alex Tao, we can now run MMC cards and Zaptel hardware at the same time.
  • 64MByte SDRAM.
  • 256MByte Flash.

So far we have brought up most of the IP08 hardware. The 8 analog ports are working, as well as new features like USB and both Ethernet ports. Compared to earlier designs I have blogged on, the IP08 bring-up was kinda boring – the open hardware approach we are taking means that everything “just works”!

To make life more interesting I have been using the new Blackfin Asterisk Package System (baps). This is a package based system (like apt-get) for the Blackfin. So basically I flash a small kernel/root file system then boot the IP08. Then, to install Zaptel/Asterisk, telnet into the IP08 and:
ip08$ ipkg install zaptel-sport
ip08$ ipkg install asterisk
ip08$ /etc/init.d/zaptel start
ip08$ /etc/init.d/asterisk start

Baps is an itch I am scratching – I couldn’t help thinking there was a better way to develop and maintain embedded systems than the buildroot/uClinux-dist approach of building “one big uImage”. More on baps in another post.

Some work remains:

  • Further optimisation of the wcfxs driver and Oslec echo canceller so the system can comfortably support 8 analog channels at the same time.
  • Testing the dual Ethernet and USB ports in realistic scenarios, for example WAN/LAN QoS routing and maybe a USB wireless interface.
  • Repeat of the load tests that were performed on the IP04 to give the system a good work out.

How much and when you all ask? The price of the IP08 is yet to be decided, however I am sure it will be competitive with other Asterisk Appliance type products out there. I would guess that the IP08 will be available for purchase around March 2008.

You can follow our IP08 progress by monitoring the IP08.txt task list file in IP04/IP08 SVN.


IP04 Open Hardware IP-PBX
Survey of Asterisk Appliance type products
IP04/IP08 Hardware SVN
1320 loans19 online faxing 27 payday loanrate federal student loans 2003 interest21 payday hour loan228 loan informationhour short loans term 24loans in mortgage 2nd london3 000 risk high personal loansauto 3000 loanspayday 39 56 online canadian loanhome 184 loanshome approval garanteed loan 100private new loans agriculture mexicoconsolidation services academic loanloans equity affordable home1000 installment loanpayments for loan yearly schedules amortizationapproval 99 loan paydayloan all-in-oneconforming 2008 loan limitfree teen clips moviefree vintage porn moviesfree movies wifeywmv movies free sexfucking machines moviesfucking movie clipsmovies porn full freefucking movie gay men clips blackgay sample moviegirl movieleicester allliance cards credittechnician surgical accredited programscard aib centre credit25,000 loan credit unsecured poorsurgical technician acredited programsaffirmitive card defenses suit creditcredit union 5pointacpe accredited Mapblack teens 14sex group photos amateuradult male sex 3d freeamature video pornoand sex adolescents15 free mins pornsex free adult gayyoutube porn adult Mapctu ringtone from 24nokia ringtone 3410 freeringtone nokia free downloadable 3390ringtone free kyocera alltel3410 download nokia ringtone freenokia free 1220 ringtone99 cents ringtonesringtone 3390 free nokia Map

IP04 and the Asterisk Appliance

A few people have asked me to compare the IP04 and the Digium Asterisk Appliance (AA).

  1. The architecture is very similar, a Blackfin connected to Silicon Labs line interface chips. For the record, both were developed by independent teams. BTW the hardware design is not rocket science – just plugging chips together. Most of the work is done by the uClinux and Asterisk software.
  2. The IP04 hardware design is open (free as in speech). Anyone is welcome to manufacture, sell, modify, improve. It has been developed by a community, for community reasons. The AA hardware design is closed.
  3. You are welcome to use the IP04 for non-Asterisk applications, for example Freeswitch, Yate, SER, Bayonne, Callweaver. It could even be used as a substitute for a PCI line interface card, e.g. a Ethernet channel bank.
  4. The IP04 uses Oslec software echo cancellation, the AA an Octasic hardware chip. The AA echo cancellation hardware adds $50 approx to the BOM (which translates to $150-$200 more on the street price) and is, well, closed. However it arguably has higher performance (at least today), and off loads cycles from the Blackfin. However we have plenty of spare cycles (like 90%) so why not do the echo cancellation in software for zero cost?
  5. The IP04 uses the BF532 rather than BF537. The BF537 is faster, has more on board RAM, and a built-in MAC. The BF532 is cheaper and can be hand loaded (important for a hackable design). This isn’t a significant difference in low density analog systems, as the CPU load is small.
  6. The Asterisk Appliance has WAN and LAN Ethernet ports (with a 4 port VLAN), the IP04 a single Ethernet port.
  7. There are some technical differences, for example the IP04 uses single port rather than 4 port modules, 256M on-board flash compared to 8M on the AA, the AA has a CF slot, the IP04 a MMC slot. The IP04 can be expanded to 8/12/etc ports, so no big differences in density.
  8. Both designs are beta at this stage, with no production hardware in general use. The current development hardware for the AA has a minimum retail of $2195.00. A Free telephony Project kit costs around $530 (starter kit STAMP motherboard). The suggested retail (AFAIK) for the AA will be $1000, the IP04 $400 (and falling).

Stop Press

I have just discovered a new entry to the Embedded Asterisk “Appliance” space, the TechnoCo Vdex 40. This Australian product has 4 FXO ports, uses a multiple ARM/DSP processor architecture and is sampling for US$695, with street price still TBD. Nice product guys – well done.

Stop Stop Press

Another Blackfin based Asterisk Appliance/IP04 type product has appeared, the Magiclink Asterisk Appliance. This looks similar in design to the AA and IP04, however has USB and CF ports. Quantity 100 pricing for 4 FXO ports is a low $299, which is great news. Good work Magiclink.

loans 2 html million bridge dollarscheck 2000 no credit loan2003 student loans rateapplication loan 2004 mortgagefinancing loan 2005 review car car24 equity home loans hourloan payday 36 refinance loan 25loans london mortgage 2nd2 federal 3 student loanscredit 3 report score loan andfor absoultely samsung free ringtones1000 words ringtonematter dont akon ringtonev4 6 converter ringtone6620 ringtone nokiaringtones agency mp3 for verizonalltel funny ringtonestreo palm ringtone 600 Mapaffirmations sexporn granny plus 70minneaplois minnesota adult toys sexpornstar africa32 flat tv direct analog viewof canal panama advantages1950 pornoamature scenes sex Mapbad loan credit $1000 andhour loan 1 unsecured2nd 125 loan value mortgageno credit check loans 20,000rate interest loans 4.5access servicing group loanloan accredited home problemsloans alabama car Map

Building an Embedded Asterisk PBX Part 3

The IP04 is a Four Port Embedded IP PBX that runs Asterisk. The hardware design is 100% open. I just built the first IP04 prototype (really built, as in soldered), and would like to tell you about it.

This post talks about the IP04 hardware, the bring up, an explosion (!).

Hot Solder

You know surface mount soldering is fun. Really fun. It’s a nice break from the thinking-oriented work I normally do, like DSP, programming, and fighting zillion level deep makefiles that are needed for embedded systems. There is just something about making stuff with your hands. It even looks nice at the end, you can hold it and show it off to your wife and kids. Of course they don’t actually care but you can still show them!

After building a BlackfinOne, I found the IP04 quite easy to put together. I would recommend it to anyone who wants a first surface mount or embedded Linux hardware project. It’s kind of amazing, but with a days work you can build (as in solder) your very own embedded Linux system.

Flux, a stereo microscope, and a good quality PCB really help make surface mount soldering a pleasure. Tip: I check each pin of the chips after soldering by attempting to wiggle it with a sewing needle.

So I had a very enjoyable day soldering the IP04 prototype under the stereo microscope. After loading the surface mount components I gave the board a “bath” to remove the flux residue. I actually put the PCB in a bowl of hot water and used a small brush to scrub that nasty conductive flux off (conductive flux residue caused me a lot of problems when building a BlackfinOne). After washing I soaked up excess water with paper towels then put it under a hot lamp to dry quickly.

Open Hardware Hacking

Curiously, hardware hacking is getting cheaper and easier. For example the tools for surface mount work are reasonably cheap (a soldering iron and stereo microscope), there is plenty of free CAD software, low cost PCB fabrication, and web based components stores like Digikey.

With the growth of open hardware projects, they are plenty of cool designs and people on line who can help you if you get stuck.

How the IP04 Works

Here is a block diagram of the IP04 hardware architecture:

You may also like to take a look at the IP04 schematic.

When power is applied, the Blackfin boot ROM starts reading from the little 256k SPI flash chip. The program it loads is called u-boot, a powerful boot loader that has been ported to the Blackfin by the Analog Devices Blackfin team. U-boot has a command line interface that lets you load other programs from flash or via Ethernet. In normal operation it automatically loads and executes the uClinux kernel.

NAND flash is used as the main storage for the IP04. NAND flash has the advantage of high density and low cost. It’s the same stuff that is used in your MP3 player, so prices have plummeted over recent years. However the Blackfin boot ROM can’t read the NAND flash directly, which is why we need the SPI flash chip and U-boot to support the start up process. Compared to many embedded linux systems, the IP04 requires a lot of flash storage (around 16M minimum) to store the Asterisk executable and audio prompts.

When the kernel boots it runs out of SDRAM, and the NAND flash is mapped to the root filesystem. We also use a portion of the SDRAM for temporary files, e.g. /tmp.

If you would like to learn more about IP-PBX design see the Resources section of the Free Telephony Project website.

An Explosion!

So it was time for the moment of truth. After a run of successful hardware projects I was feeling pretty confident, which of course angered the Gods of open hardware. I applied 12V and started poking about with my multimeter. About 3 seconds later – BANG!. A small mushroom cloud rises a few inches off the board and gently drifts across the bench. A nasty smell fills the air, along with a string of expletives that bring the family running.

“Dad, can you do it again?”, my 8 year old son asks! He was ejected from my office shortly afterwards.

I sniffed a few areas of the board to track down the general problem area. A peek through the microscope showed a capacitor had blown it’s guts out, the white fuzzy stuff on the left of this picture:

The problem was two capacitors had their labels swapped on the PCB silkscreen. This meant I had loaded a capacitor with a 6V rating where there should have been a 25V rated capacitor. When 12V was applied – the 6V rated capacitor expressed it’s displeasure!

Apart from that the remaining assembly and bring up went pretty smoothly. One mistake I made was forgetting to supply power to the Real Time Clock (RTC). This caused U-boot to stall when it started, waiting for the RTC clock to come up. Of course, when this bug appeared I had no idea if it was a hardware or software problem. So I had to hunt through various possibilities in “bug space”, for example sprinkling printfs through the U-boot code to find out where it was stalling. Unfortunately, each new load of software took 20 minutes to flash via the Igloo JTAG cable, so it was a slow process that took 2 minutes to fix once I found it.

I modified the u-boot and uClinux configuration a little from the BlackfinOne baseline due to minor differences between the two boards; for example the smaller SPI flash, one Ethernet port, and the use of NAND flash. This was fun – I learnt a lot about U-boot and the set up of NAND flash through the MTD driver. By this time I had u-boot running so I could download new images via Ethernet and test in a few seconds.

I was re-using tested building blocks from the BlackfinOne and 4fx designs so it all went smoothly. One week from initial power up uClinux was booting and Asterisk running with 4 analog ports. Rather than stressing over the little bugs and trying to race though I took my time and enjoyed the bring up process.

Finally, I lifted the handset on a telephone connected to the IP04 and there was the dial tone! Nice.

Automated Asterisk Load Testing

The Asterisk 1.4 GUI works although it isn’t stable at present on the IP04. Sometimes the GUI freezes and I can see some core dumps on the IP04 console. This could be a Blackfin specific issue, for example uClinux is more fussy about stack space than regular MMU-enabled Linux. Some more work required to sort this one out. In the mean time, vi and Asterisk conf files are OK with me!

I was keen to see how stable the new hardware was, so I used some scripts to load the PBX over a 12 hour period. Here is a block diagram of the test set up:

A simple shell script on the x86 Asterisk box:
# lotsofcalls.sh
# David Rowe 3 April 2007

rm -f /tmp/lotsofcalls.txt
touch /tmp/lotsofcalls.txt
rm -f /var/spool/asterisk/outgoing/callastfin.call
while [ 1 ]
cp callastfin.call /var/spool/asterisk/outgoing
sleep 60
calls=`expr 1 $calls`
echo $calls >> /tmp/lotsofcalls.txt

kicks off an outgoing IAX2/GSM call to the IP04 once every minute. The call makes FXS Port 4 ring, which is connected (via a phone cable) to FXO port 2. After a few rings FXO Port 2 answers and plays an IVR script for a few seconds, then hangs up. The analog phone connected to the x86 Asterisk box rings when the IP04 call connects. As long as this phone rings every minute I know the test is still running OK. I can also lift the phone when it rings, for example to make sure the audio quality is OK.

In practice I use a script to place two calls at the same time, so the total load is two IAX/GSM calls and 4 analog calls. I let this run for about 12 hours and the IP04 worked fine – 4000 calls were placed and the loadav was about 0.2 (10% of the Blackfins CPU). Much of the code is still unoptimised so this suggests we can go to much higher call loads in the future.

Anyway given that I was testing on hardware where the solder has barely cooled I was pretty happy.

Whats Next

There is still plenty to do, for example we have quite a few Astfin tickets that need working on. If anyone would like to help out please contact me or the Astfin team.

I am working with a manufacturer to put these designs into volume commercial production. The first batch of fully assembled production units will be available in mid 2007 for around $450:

In the mean time – if your feel like a cool project – you are welcome to build an IP04 yourself! Here is some more information on obtaining bare IP04 PCBs and FXS/FXO modules.

Update – Fully Assembled and Tested IP04s now Available

July 23, 2007: You can now buy your own IP04 from the Free Telephony Project on-line store. The store also stocks parts if you would like to assemble (as in solder) your own IP04. I have blogged on the Production IP04 in Part 4 of this series.


I stand on the shoulders of giants. I have tried to add just a little bit to their work. Thanks to the Astfin & BlackfinOne teams, uClinux, Analog Devices Blackfin team, and the Asterisk community. Thanks to Mike Taht for being my editor-in-chief for this post. Sorry if I forgot anybody.


IP04 home page
Buy an IP04 from the Free Telephony Project on-line store
IP04 Schematic, PCB, CPLD code, Errata, and more
Building an Embedded Asterisk PBX Part 1
Building an Embedded Asterisk PBX Part 2
Building an Embedded Asterisk PBX Part 4
Building a BlackfinOne
How to make your Blackfin fly Part 1
Open Source Echo Canceller Part 1
IP04 and the Asterisk Appliance

bonk advantages of loansloans afco autoneeds score loan home 518 creditsettlement loan ameriquestachieva sutdent loansmebane loan of 1st savings andamerican agcredit rates loanstudent loan acpe alaska Map