Peak Oil

Yesterday I helped two other grown men push a small van up a slight hill. Together, the three of us moved it maybe 30cm before giving up. Have you ever considered how much energy is contained in a single drop of oil?

For the past few months I have been reading all I can about Peak Oil. The basic idea is that the global oil supply will soon (around 2010) be less than oil demand. As oil is so fundamental to our lives (all transport, manufacturing, fertilisers for agriculture) this will cause big problems. Some people think modern society will end (literally), others predict a global depression, and some the death of the suburbs as the world reconfigures itself for a low energy lifestyle.

Here are some common predictions that I rate as plausible:

  • Oil prices will sky rocket, like over $150/barrel, causing the price of everything to increase, i.e. high inflation.
  • Stock markets tumble as every stock is based on the assumption of continuing economic growth sustained by cheap energy.
  • Widespread unemployment as whole industries collapse, i.e. “demand destruction”. Starvation in less developed countries (no fertilisers)
  • People with very high debt levels (the norm in Australia) will be in deep trouble. Overpriced housing markets collapse. The “perfect storm” for a modern economy.
  • As the taxation base decreases the government will be less help. For example they won’t be able to fund a switch to renewables, pay unemployment benefits, fix blackouts.

After a few months of research I am convinced Peak Oil is for real. While I am not in the survivalist camp (I think modern society will pull through) my best guess is that there will be very tough times for the world economy.

A powerful DVD on the subject which I recommend is A Crude Awakening. A really good book is Half Gone by Jeremy Legget, which nicely explains both Peak Oil and Global Warming. Or just Google on Peak Oil.

Governments (except Sweden) are ignoring the problem. This means that if Peak Oil hits, we will be largely unprepared, as we will have squandered the time required to prepare for transitioning from fossil fuels. So it’s probably up to individuals and communities to do what they can to cushion the blow.

You know what scares me about the Peak Oil problem? As an engineer I am used to solving problems. Software doesn’t work, you fix it. Hardware bug? Start debugging. You know that there is always a fix, somewhere. Peak Oil scares me because I just can’t see the fix. Anywhere.

So I am thinking about what I can do to “kick the carbon habit” and prepare for Peak Oil. Tactics like reducing debt, an electric vehicle (EV) conversion, improving my household energy budget, re-arranging my stock portfolio, and getting a grid-connect Photovoltaic (PV) array for my household electricity. All good stuff, even if Peak Oil isn’t for real. More on this later.

I am also interested in the possibilities of using Free Telephony to help a post Peak Oil world. I figure if people are moving around less and have less money, then low cost, low power telephony based on open hardware and software may be very useful for connecting the world.
to adding ringtones slide sidekickadp ringtoneslg sprint ringtone pcs 1200scp 8100 sanyo ringtone freearrington adleralf ringtonespolyphonic free nec 525 ringtonebarrington good in advocate shepherd Map

Open Hardware Battery Charger

I am very interested in open hardware and the capacity it has to help the developing world. Now I could visit a developing country and work on projects in that local area. However I figure that the biggest impact I can have is injecting a little free IP into the world. A well engineered design can be multiplied a million times over. Open software is a good example.

I am particularly interested in hardware that can be made locally in developing countries. My friends at Air Jaldi in Dharamsala, India agree. Pauli Nç?rhi has recently developed the Jaldi Charger. This charger has been custom designed to deal with the very demanding realities of rural India (and rural areas elsewhere), for example wildly varying AC line voltages and lightning strikes.

The charger has been designed to be constructed in India using a single layer PCB and parts that are largely available locally – important considerations that those of us in fully developed countries seldom understand.

Nice work Pauli!

alaska loans developer-development alaska autoand alliance leisti loans eragloan calculatoralcp college program loan alabamaadminastrater loansmortgage cheap mortgagesloans info abbey mortgagesmotg 223 loansloans 102 home finansure Mapaccredited chemistry onlinenew colleges hampshire in accreditedcredit account sol reportbuyers accredited representative courseinternet credit casino account merchant cardwashington merchant account credit card cheapcare achieve aged accreditation inair force joint credit tour Mapnaked free movieshuge movies dildomovie clips hardcoreporn dans moviesblow movies job free bestnaked movies womenteen girls free moviespenetration double free movies Mapgirls hooterorgies showergay toonnude girlfriendxxx dvdsex monsterasian twinksteen latina Map

Building an Embedded Asterisk PBX Part 4

About 2 weeks ago I received the first batch of 50 production IP04s from the guys at Atcom. I would have blogged about this earlier but to be honest I have been so busy testing and shipping that I haven’t had time! Here the IP04 is pictured on the bottom, with a WRT54G for size comparison:

I now have now been using the IP04 for a few months (both prototype and production models). Here are a couple of things I really like:

  1. The IP04 is actually easier to set up than an x86 Asterisk system, as it comes with uClinux and Asterisk pre-installed. Apply power and 60 seconds later you have dial tone. You can telnet in and edit Asterisk config files just like a regular x86 box.
  2. The tiny embedded form factor is very cool. You can see from the photo above it is about the same size as a WRT54G (the WRT is a little deeper, the IP04 a little wider). The IP04 is fanless, and draws just 4.5W
  3. Compared to other embedded systems, the IP04 has a huge amount of NAND flash – 256 Mbytes. This means plenty of room for prompts, voicemail, and even your own programs. My experience with most other embedded systems is that you are always running out of flash. The IP04 feels more like a hard disk based system.
  4. The yaffs file system is working really well. It even appears that no special shut down procedure is required to ensure data is written to the NAND flash. For example if I edit a file then pull the power plug out the data is still there when I re-boot!

FXS Noise

After some initial testing we discovered a hardware bug – the FXS ports had relatively high levels of background noise. This was especially obvious on FXS to FXS calls. Over a busy weekend I worked with Alex Tao (Shenzen, China) and Alen Chen (Atcom) on this bug.

Alex discovered that if we used an external 3V3 power supply then the noise went away. This led us to a fix – insert some inductance (in the form of a ferrite bead) in the 3V3 rail of each FXS module to block noise getting into the module. This part was actually suggested by the Silicon Labs Si3210 datasheet, but most FXS module designs tend to leave it out. Anyway, I have retrofitted these beads to the IP04s I am shipping so now the FXS ports sound much better.

This was another example of “open hardware” in action. Alex, Alen and I working together to bounce ideas off each other and solve tough bugs together, using email and chat.

I must admit that I have been impressed by the quality of the Atcom IP04 hardware. I used to own a telephony hardware company, and the first batches of our products had far more issues than these IP04s. Virtually every IP04 I fire up works first time. Of course there are still a few software glitches – but I am sure we can fix these over the next few months.

Here is a picture “under the hood” – you can see the four FXS/FXO modules (in this case two modules of each type):

You can also see the little green RS232 daughter board that is used for console access.

Strong Sales

After about two weeks I am nearly out of stock, maybe only 5 left. Some new stock is due in mid September, and hopefully an 8 port version later in the year. I intend to spend the rest of this year maintaining the IP04 and chasing down any bugs, plus work on a few other projects like the $10 ATA.

The Oslec open source echo canceller seems to be working well on the Blackfin (as well as on x86 machines).

Just like the prototype IP04s, the Atcom production units have proven very reliable. I have had one running for several weeks without any stability problems. Like any new product there are lots of improvements we can think of, for example expansion to 8 ports, fixing a few software bugs, speeding up boot time, improving speech quality etc.

Important Milestone

The release of the production IP04 is an important milestone in the Free Telephony Project as no hardware assembly (like soldering) is required. To date much of the technology we have been developing required hardware assembly. Fun for us, but not for everybody!

There are many more software hackers out there than hardware hackers, so for the growth of the project it was important to develop production, pre-assembled hardware. Now you can experiment with embedded Asterisk on a powerful DSP-enabled platform at a very reasonable cost (around $450). This is less that it would cost to buy a 4 port PCI card and a x86 PC!

This strategy seems to be working. The first batch of IP04s have sold out very quickly, and the forum traffic and contributions are growing steadily. Bugs are being solved, and exciting new project like embedded E1/T1 and BR-ISDN Appliances have been kicked off.

It was exactly two year ago when I started working on this project (Asterisk on the Blackfin). I wasn’t sure if Asterisk would run on uClinux – back then uClinux didn’t even support shared libraries! Since then, with the help of many people, we have developed a range of open hardware designs, and even sprouted a small industry of people who are earning income from this area through product manufacture, sales, development, and consultancy.

The future looks even brighter – the technology is maturing rapidly and will soon be deployed to the mass market. This is possibly a first: a commerical, mass market product developed from free software and open hardware.


IP04 home page
Buy an IP04 from the Free Telephony Project on-line store
Blackfin Asterisk Forum
Building an Embedded Asterisk PBX Part 1
Building an Embedded Asterisk PBX Part 2
Building an Embedded Asterisk PBX Part 3
IP04 and the Asterisk Appliance
shemale clips movieteen free sex moviestinas moviesmovies usedxxx movies cheerleaderxxx movies teenever most scariest 10 moviesadult search movie Map$5000 loans credit bad100 guaranteed loans student200 loan pay dayquick loans 300502 loan directloan 9 nursing studentloan uk aaadjustable rate texas loan Map

Great Experience with Toshiba Laptop Repair

This is a bit off my regular topics, but I just wanted to thank Toshiba publicly for the amazingly fast repair they performed on my daughters laptop.

My daughters CD/DVD driver was skipping on her laptop. Thinking back to my previous experience with warranty repairs to anything electronic, I told her to kiss her laptop good bye for a few months. So I reluctantly phoned the Toshiba service centre on Wednesday, and the call centre told me to hit their warranty repairs web site. About 20 minutes after I filled in the form a guy phoned me and said their would be a courier arriving shortly. They even had a PDF address label that I just downloaded and printed. Fortunately I had the original packing so it was easy to get it ready. Sure enough, a few hours later a courier turned up and off it went. I waved it a teary fair well, wondering if I would ever see it again! The repair depot was in Perth, about 3000km away.

A day later I get an email that says the repair is complete! WTF?

At 9am Friday morning the laptop is back, about 40 hours after it left my house, despite a round trip of 6000 km. And the repair was completed and it worked fine. I must admit I was amazed at this sort of service.

Well done Toshiba!
eroticas Chicas Fotoskostenlos Asian scatBehaarte hegenLehre Mom zu teen fuckpics Ebony kostenlos pussyPissing verstecktBilder Transsexuelle Vaginaxxx Clits reife Mappics alia shawkat sexyrumble essex 1929 seattgp 3dpornteen model alekanymph sex allentown101 positons sexanalysis strategic alditeen fiction amputee Mapchemistry accredited onlineaccredited colleges hampshire in newcredit sol report accountaccredited buyers representative coursecard merchant account credit casino internetwashington merchant credit account card cheapachieve care in accreditation agedforce air joint tour credit Mapon credit purchases 1940 scredit carpet abbeyace credit program recoverycourses credits students degree institution accreditedave auto sales mass credit 1258derivatives isda credit 2003 definitionsloans wheel 5thaccredited credits degree institution courses students Mapcartoon free movies pornprivate movies pornsexy stars moviehorse free movie sexaebn movies streamingmovies porn cartoon freemovies free asian sexmovie job hand Map

Open Source Echo Canceller Part 5 – Ready for Beta Testing

The continued trials and tribulations of echo canceller development! Since the last post the echo canceller (named Oslec) has been tested at several alpha sites. Oslec is performing well and is now ready for Beta testing. See the Oslec home page for the current status of the echo canceller.

The core of Oslec is the echo.c file.

Why X100P Cards Have Echo Problems

After the good results I obtained in the previous post I asked a few friends to test Oslec on their Asterisk systems. These guys were using X100P cards for the FXO interface. Oslec performed poorly so I asked them to collect some samples of the echo signal so I could analyse them off line. As part of the development strategy Oslec has built in echo sampling code.

Here is a plot of the X100P signals. Open it in another window or tab. Note that the green receive signal has a slight DC offset, it doesn’t quite sit on the zero line. Note also that the echo canceller output (blue) is quite large, i.e. the cancellation is poor.

There is also a series of small spikes on the green and blue signals – this is 60Hz hum that the X100P has mistakenly delivered to us. We don’t normally hear this hum as the phones we use tend to filter it out.

The combination of DC offset and 60 Hz hum confuses the echo canceller algorithm and make it converge slowly. This means poor performance and lots of echo.

The trick was to remove the hum and DC with a simple high pass filter. Here is a plot of the X100P signals with the high pass filter. To see the effect of the filter use your browsers forward and backward buttons to flick between the two images (with and without filtering).

See how the hum and DC offset have gone away after filtering? The green and blue lines are both now on the 0 line. But best of all the echo level (blue) has been greatly reduced, as without the hum and DC offset the echo canceller can do a much better job. Pretty cool, huh? DSP in action :-)

The observant will also note a DC offset on the (red) transmit signal. I am not sure why this is present, it’s in the signal from the SIP phone in this particular test. Perhaps a DC offset in the SIP phone electronics.

Since the filter was added Oslec has been in constant use on a X100P home IP-PBX system in Ottawa with great results.

This is an exciting result – it means low cost ($10) FXO hardware can have high quality echo cancellation.

Handling Background Noise

Inside echo cancellers there is an animal called a “Non Linear Processor” or NLP. After the adaptive filter part of the echo canceller has done it’s best this gizmo is used to remove any remaining echo.

Initially Oslec had a very simple mute algorithm – if the residual echo level was low enough the output would be muted. You can see this muting in action in the X100P plot above. Around sample 1000, the blue line “flat lines” as the NLP cuts off any residual echo.

The problem is that muting is crude – it removes echo but also throws out the background noise. Without background noise the calls sounds unnatural.

I experimented with a couple of ideas here. The first was to insert “comfort noise” instead of muting. The level of the noise is set to match that of the background noise level. However the noise I used sounded unnatural compared to the actual background noise (which in my office is computer fans).

The best NLP solution I have found so far is simply to clip the residual echo signal to the level of the background noise:
/* This sounds much better than CNG */
if (ec->clean_nlp > ec->Lbgn)
ec->clean_nlp = ec->Lbgn;
if (ec->clean_nlp < -ec->Lbgn)
ec->clean_nlp = -ec->Lbgn;

This works surprisingly well, even very weird background noise like a lawnmower working in my backyard came through fine and I still couldn’t hear any echo. BTW I found the idea of clipping on the data sheet of a commercial “hardware” echo cancellation chip.

I struggled with the code to estimate the background noise level for some time before settling on a really simple algorithm. I just average the level using a slow (1 second time const) filter if the current level is less than a (experimentally derived) constant:
if (ec->Lclean < 40) {
ec->Lbgn_acc = abs(ec->clean) - ec->Lbgn;
ec->Lbgn = (ec->Lbgn_acc (1<<11)) >> 12;

The 40 was measured experimentally, and is roughly the lowest level of any near end speech. The idea is that we don’t want to include any near end speech (which is generally higher in level than background noise) in our estimate of the background noise level. This estimator has worked well to date however I would welcome feedback from beta testers on Oslec background noise performance.

Fun with Soft Phones

One gentleman (Pavel) who tested Oslec complained of echo break through with pop sounds like “P” in Peter. He was using a kiax soft phone connected to an FXO port via Asterisk. The problem was due to a interesting combination of high quality audio (the microphone and sound blaster) and the telephone network.

Pavel had initially thought his microphone was faulty is some way, however it turns out it was too good! The microphone/sound blaster combination lets low frequency signals (e.g. down to 20Hz) through to the FXO Port. However the FXO port electronics (in particular the hybrid) is designed for telephone bandwidth signals (300-3300Hz). The results was a temporary failure of the hybrid, which let some echo slip through.

Figure 1 is a close up of the “pop” waveform. The red line (tx) is the microphone signal. Note how around sample 300 it goes down off the screen then comes back up around sample 400. This signal is very low frequency compared to normal speech (it changes slowly compared to other parts of the red tx signal).

In Figure 2 the lower brown line shows how well the FXO port hybrid is working. It normally varies between 6-15dB. However near the pop it first goes up to 60 then down to 0 dB. The low frequency pop signal is messing up the hybrid, making it non-linear. This means the echo canceller cannot cope, in fact it resets the coefficients. Echo cancellers depend on the hybrid working in a linear mode all the time.

So the solution is to high pass filter the tx signal the microphone sends to your FXO port. By removing the low frequency pop energy your the hybrid will remain linear, and the echo canceller will work with soft phones like kiax.

Are 128ms Tails Really Needed?

There is a school of thought that says a “128ms tail” is required for “serious” echo cancellation. I am not sure where that requirement comes from. I have collected many echo samples from all over the world and 9/10 would have worked with a 16ms tail. The 10th was a long distance T1 line, and even that fits comfortably in a 32ms tail.

If any PSTN FXO phone line has a 128ms echo then an analog phone connected to that line would be unusable. My understanding (and experience) is that Telcos insert network echo cancellers after a certain delay, for example on long distance calls. That’s why you can make regular long distance calls without echo.

Perhaps 128ms tails are required for operating inside of Telco networks or when Telcos handle international trunks. Anyway I suspect that the 128ms requirement is just another piece of FUD that surrounds echo cancellation, like “hardware echo cancellation is superior to software” or “you must have a DSP chip”. Perhaps “128ms tail” has become confused with “a working echo canceller algorithm”.

So my alpha testers and I typically use Oslec with a 16 or 32ms tail and it works just fine. BTW I would love to see a sample that refutes this argument. If anyone can send me a sample that shows a tail greater than 32ms for a PSTN FXO line I will happily publish it here and recant my heresy against the church of the 128ms tail!

Open Development Works!

In Part One I spoke about the idea of people collecting and sending samples of bad echo. This has really worked well. Several times during testing something went wrong at an alpha site, and collecting a sample really helped me work out why and improve Oslec. Thanks especially to Mark, Pawel, and Pavel plus many others for sending in samples.

I have also had a lot of useful comments from my DSP “brains trust” – Steve, Jean-Marc and Ramakrishnan.

This was truly an open development effort. Echo cancellers are tricky voodoo, requiring lots or practical tricks on top of the standard DSP algorithms. I have tried off and on for 15 years to come up with a viable echo canceller. The Zaptel echo cancellers have been works-in-progress for 6 years. Other companies have invested 10’s of man years (e.g. teams of 20 people for several years).

So I think this is a great example of where open development techniques have been used to achieve excellent results in a short time.

How to Test an Echo Canceller

Testing an echo canceller can be tricky. This section explains how to test an echo canceller, along with some of the traps.

Set up a SIP phone to FXS call. This way there is plenty of delay in the circuit and you will get a nice echo. An analog to analog call (say FXS to FXS) might be TDM bridged and not have any delay.

Once the call is running mute the analog phone. Most phones have a button for this – if they don’t then unplug the handset from the phone base. To test an echo canceller is is important to have no near end speech present. If the FXS phone is in a different room it’s OK to leave it un muted – just make sure it can’t pick up anything you are saying into the SIP Phone.

Speak loudly into the SIP phone and listen for any echos. It is fun to try this with the Oslec control panel:

For example try the “Disable” and “Enable” buttons and listen to the echo with and without the echo canceller.

Another good test is double talk. Get a person in a different room to use the FXS phone while you use the SIP phone. Get them to speak constantly and try to talk on top of them. Double talk is a good test as it can confuse echo cancellers.

If you are testing a SIP to FXO call, make sure the phone at the other end of the connection (say a cell or desktop phone) is out of audio range of the SIP phone, for example in another room. Alternatively, mute the telephone.


A good quality line echo canceller has been a missing part of the open source telephony scene for a long time. Through the efforts of a team of DSP engineers and several alpha testers we have developed a good candidate for a free (as in speech) line echo canceller. Please try Oslec yourself and tell us what you think.

Reading Further

Oslec Home Page
Part 1 – Introduction
Part 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Phone Calls
ringtone download free 100ringtone series tv 24add to mobile ringtones phoneringtone mp3 24for g 3 free ringtonealltel ringtones comfree ringtone 100 musicringtones show 24 the Mappokemon hentai clips movieporn movie zone starmovies rapidsharemovies round assin disney sex moviesshemales moviesstrapon movies sexdildo pussy movie tight Mapaapne banaya ringtone aashiqaddiction janes ringtoneringtone 8830 forumringtones 1997 edge16 ringtone tonsadulf ringtone proofmiles 500 ringtonea650 ringtone install Mapembedded videos pornporn ember downloademergent porngeorge pornstar emilysimons porn emilyporn in emmaemma star star pornpink emma starr porn Map

8 Port Low Cost FXS USB Channel Bank

Last week I attended a presentation at Adelaide University by a student named Tim Ansell. For his honors project Tim has developed an 8 channel FXS channel bank that connects to a host PC via USB, not unlike the Xorcom Astribank products.

The channel bank uses FXS interface chips and a PIC microcontroller. Signal processing such as echo cancellation and DTMF detection is performed by the Host PC. The advantage of this design is low cost.

Tim demonstrated telephones making calls to each other, using the the PIC to perform some simple switching. His next steps are to complete the interface to the Host PC and Tim also has many ideas for cost reduction.

Tim is considering commercialising his design – please email him directly for more information.

loans cash about quickequity loans home adjustablecash houston advance loanhour loan 24loans mortgage down 50cash advance loan emergencyloan advance washington cashsignature 1st bank loans Mapoversized clitsteen chubby kirsten modelwife share .uk amateurbreasts massive minkapissing girls voyeurfucking ans sister brotherasian nude modelmini skirt sluts sexy Map

The Louder Router – a low cost PC for the Blind

This post describes a project to build a very low cost PC for the blind using commodity router hardware. It has the potential to dramatically improve the lives of millions of blind people, especially in developing countries. We need some OpenWRT gurus and embedded hardware hackers to help this very worthwhile project!


A few months ago I attended BarCampAdelaide, down in the lovely sea-side suburb of Moana.

Moana beach

I was flicking through a pile of Make magazines that I think Kim Hawtin had brought along. Having never seen a Make magazine before it was a fascinating read – especially in the laid back, geeky atmosphere of a BarCamp.

I came across an article by the remarkable Fernando Botelho. Fernando has a dream – a $200 PC for the blind. Blind people currently need to pay close to $2000 to get a PC, speech synthesiser, and the commercial software they need to use a PC and connect to the Internet. So Fernando came up with the concept of a dedicated PC design just for the blind, that could be built for $200.

Light bulbs went on in my head. Hey – I know how to do this! So I contacted Fernando and with a small team we have been brainstorming this project and even prototyping some of the software on a WRT54GL router.

Blind PC Concept

This is the concept:

  1. There is a range of open source software for the blind, for example screen readers such as YASR, and extensions to emacs such as such as SpeechD-el and Emacspeak that provide a complete “Audio Desktop”. With these packages and a speech synthesiser a blind person can browse the web, use email, chat, and perform text editing.
  2. There are open speech synthesisers such as Festival and Flite that can be used instead of dedicated hardware synthesisers. Software synthesizers do not sound as pleasant as commercial hardware units however the price is right!
  3. Here is the cool bit. A PC for a blind person does not need a screen. Sounds obvious but this has several important implications. A screen is the most expensive part in any PC. No screen means no GUI, which is a major consumer of system resources such as memory, CPU cycles and dedicated hardware. No GUI means console-based applications – a perfect match for free and open source software. The low system requirements mean we can build a Blind PC for less than $50 using hardware similar to that in a commodity router, i.e. much cheaper than a conventional PC!

So the proposed PC will be a box like a small router or Ipod. It will have a headphone jack and possibly a speaker, and a socket for a full size keyboard. It will have a router-class CPU (say 200MHz), and possibly a wireless connection. We need plenty of flash (256 Mbytes minimum) to store the applications and data, but just a modest amount of RAM, say 16-32Mbytes. This sort of box could be mass produced for less than $50 using the same production lines as todays routers.

A Day in the Life of a Blind PC User

A blind person will be able to sit down at work and connect via the wireless or Ethernet. They can then answer email, use chat, and access the web. Imagine communicating with some one who owns one of these boxes. If your were chatting or emailing with them you would not know they are blind. In fact, I will guarantee they would outperform you in many tasks such as typing, memory, and comprehension of verbal information. This simple example shows how this device could make a blind person highly productive in an office environment. That means a job, and an income. All for just $50 and some open software.

When they leave work for the day they pick up their box and hop on the bus. While they are travelling they can play “audio books” or maybe listen to their email. When they get home they associate with their home wireless network and they can use the device to pay a few bills and catch up with friends on line.

A low cost PC for the blind can change the lives of many people. The $2,000 cost for the current solutions is simply impossible for blind children in developing countries. Worldwide there around 6 million blind children who will never be educated using todays expensive technology. A low cost blind PC will get them connected. Get them connected and they can communicate and be educated. They can raise their standard of living, have a great future, and the ability to earn a living.

Ported Software

To test the concept I have implemented chunks of the software on a WRT54G router using the OpenWRT kamikaze build environment. To get around the lack of audio I/O on a WRT I used various techniques to pipe the audio to my x86 laptop over a LAN. An alternative is to use a router with a USB port and a USB sound card.

Thank you very much to the OpenWRT community – I have had a lot of fun working with your software and found it well written and easy to use and modify.

Fortunately Flite (the Festival light speech synthesiser) was already supported. It runs at about 5 times real time on the WRT, which is fast enough for our needs. The speed of execution of Flite was a major concern as this is likely to be the most CPU cycle hungry part of the system.

We have ported (well partially ported) several new packages to OpenWRT:

  1. A full Emacs implementation. That’s right – full blown emacs operating on a WRT! You can even play tetris (M-x tetris) through a terminal! This was tricky to port – emacs uses a bootstrap method during the build procedure which doesn’t map well to a cross compilation environment. So at the moment I just run temacs, which takes a while to start as all the .el files need to be loaded. I also place temacs and the LISP files on a nfs drive, as the internal WRT flash is too small.
  2. Eflite. This is a middleware server that glues applications like Flite and EmacsSpeak together.
  3. Yasr (Yet another Screen Reader). This is a screen reader developed by Michael P. Gorse. It actually works quite well on the WRT. It also uses eflite to access the speech synthesiser. I actually cheated a little bit here and ran the eflite server on my desktop. This was because I couldn’t get the speech samples from eflite to net-cat over my LAN correctly, it worked out easier to run eflite on my PC. I feel comfortable with this hack, as I had already demonstrated eflite and Flite operating on the WRT OK, it’s more a configuration issue that I needed to work around.
  4. I attempted to get EmacsSpeak working on the WRT. The build process for emacspeak requires a bunch of LISP code to be compiled using emacs. Now this is fine when you are building Emacspeak on the same machine as where it will run. However in our case we need to build it on a PC and run on the WRT. So I need to work out a way to run part of the build process on the target WRT system. Tricky, but not impossible. I am sure with some help we can get EmacsSpeak running on the WRT.
  5. Speech-D-el

    Speech-D-el requires a server/middleware package called Speech Dispatcher. However I ran into a snag here – glib version 2 is required for Speech Dispatcher which hasn’t been ported to the WRT (at least not yet). Porting the actual speechd-el code looks straight forward.

    By using the trick of running the speech-dispatcher server on my laptop, I managed to get speechd-el running on the WRT. As explained above this gets us around porting a big library to the WRT (glib 2), which is OK for proving the concept.
    The current problem is that speechd-el runs slooooowly, you press a key and have to a few seconds for the speech. I am not exactly sure why but I have some ideas:

    1. The router processor might not be up to the job.
    2. I may not have built emacs correctly.
    3. I haven’t byte-compiled the speechd-el lisp code (it is suggested in the docs that I do).
    4. Perhaps the fact that I am running the speech dispatcher remotely, there some unwanted buffering going on. Or perhaps the use of NFS for the LISP files.
    5. Emacs by itself runs OK, I can type at normal speed, e.g. I can play games like the built in tetris OK.

    Curiously, Yasr was fast enough. So I guess the speed issue is probably a configuration problem, I can use emacs fine on my old 133MHz Pentium and this router has a faster processor. How much CPU can be involved in processing emacs code for one key stroke?

    Of course more testing is required, I have just typed a few things and not really explored the functionality of speechd-el yet.


    So we have demonstrated the viability of building a low cost Blind PC using commodity, router-class hardware. Several important packages have been partially ported and important functionality (Flite, emacs etc) has been demonstrated.

    Now we would like to open the project for community input. To progress the project further we would really appreciate some help from some people with skills in OpenWRT and embedded hardware.

    Development Plan

    We have three phases planned:

    In Phase 1 we would like to plug together a commodity router, USB sound card, USB memory stick, and a USB keyboard. This is the fastest path to getting a useful product deployed. OpenWRT configuration and software gurus are really need here. We have named this device the Louder Router.

    In Phase 2 we would like to develop a small USB or Ethernet peripheral (e.g. a dongle) that combines sound output, 256M of flash memory, and a keyboard interface. This would reduce the “number of boxes” required to build the system to just two (the router and the dongle). People experienced in microcontroller development would be very useful in this phase – I think a small PIC or Atmel would do the job.

    In Phase 3 we intend to develop a full-custom product and put it into mass production. This will be a neat single box solution at the lowest possible price. Given my experience with similar board-level designs on the Free Telephony Project I am sure such a box can be built for less that $50 in modest volume. Would any hardware/embedded linux people out there like to work on developing this hardware?

    Getting Involved

    We are adopting an open hardware and software approach. This technology can and should be free to all.

    The Blind PC project is hosted on the LouderLinux site (cool name I think). LouderLinux is a community supporting the development of assistive technologies for the blind.

    What we really need are OpenWRT, C, and hardware developers who can can help us integrate and develop the current prototype code into a Louder Router that is deployable to Beta users over the next few months.

    Please email Fernando Botelho for general enquiries and especially if you would like to help out. For technical questions, please contact David Rowe.


    Louder Router Blind PC Project

Freest Phone call ever?

Li Yuqian (Beijing, China) and I (Adelaide, South Australia) just made the first IP04 to IP04 phone call. We used IAX2 and a GSM codec and it sounded just fine. On January 15 2007, Wojtek Tryc (Ottawa, Canada) and Dimitar Penev (Sofia, Bulgaria) from the BlackfinOne community made a phone call using a BlackfinOne and 4fx combination. Could these be the freest (as in speech) phone calls ever?

  1. Open source Asterisk software was used.
  2. The operating system was uClinux.
  3. The hardware designs are open and free for anyone to use.
  4. The hardware was designed using open source gEDA tools.
  5. We used VOIP so the call cost was approximately zero.
  6. Each IP04 cost us less than $200 to build, way cheaper than any other comparable IP-PBX.
  7. Both Li and I hand assembled (as in soldered) the IP04 hardware ourselves. This has nothing to do with the call being free. It’s just cool :-)

Hmm, maybe we should have used Speex. That would have been even freer than GSM!

So it occurred to me that Li, myself, and the BlackfinOne community may have been making the most open phone calls ever. Even the inventor of the telephone Alexander Graham Bell was very wrapped up in 19th century patent wars over his hardware!

a buffalo casino aroundbest gambling affiliatecasino merchant risk high offshore accountlounge in and casino newtown 4bearsakwasanee hogansburg ny casinoprograms aaa casino affiliatecaps racing center american casinomerchant ach gambling account Mapportals ts asian pornasian porn twinsteen porn underage asianvegetable asian pornvietnamese asian pornasian porn womanasian porn youpornasianbabe porn Mapcelebrity porn fakescelebrity online free porngolden celebrity porn showercelebrity porn movieporn online celebritypictures porn celebritycelebrity porn searchtapes porn free celebrity Mapporn me emailedvideos embedded pornporn download emberemergent pornemily pornstar georgeporn simons emilyemma porn instar porn star emma Mapline xanax mainxanax combination deadly methadone andmedicine xanax outpatient detox nonaddictivetypes xanax of pictureswithdrawl ear from ringing xanaxto sexual favors xanax getxanax lunesta with takingwhat xanax bars are 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:
# David Rowe 3 April 2007

rm -f /tmp/lotsofcalls.txt
touch /tmp/lotsofcalls.txt
rm -f /var/spool/asterisk/outgoing/
while [ 1 ]
cp /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