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:
# 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

A $10 ATA

In October 2006 I made my way to Dharamsala, northern India, where I visited the Tibetan Technology Center, and in particular a guy named Yahel Ben-David.

You see I am interested in developing low cost open hardware technology that can help people in the developing world. Yahel and the team at Tibtec are using commodity routers to build low cost community wireless networks. To date about 3000 computers have been connected to the Internet by the Tibtec team. As these computers are often shared it is fair to say that about 30,000 people now have Internet access thanks to the Tibtec team.

Now I have been working on some open hardware/software for building low cost embedded IP-PBXes. I had an idea that my work might be helpful to Yahel and the people at Tibtec.

As we got to talking, a few interesting economic points came up. Yahel can buy a WRT54G type router for $50 and an ATA for about the same price, due to the miracle of mass production. In small quantities, my open hardware designs couldn’t get close to this, even by removing all margins and selling them at cost. Also, for many applications, just one or two FXS ports are required, rather than a full blown PBX for 4-8 analog ports.

(Note: I have since reworked the IP-PBX design so that it can be built for less that $100 in quantity, however that is another story for another blog post).

So after leaving India, in the back of my mind was the need for a very low cost way to connect a telephone to a router.

A few months passed.

Recently, I became aware of Air-Stream – a community wireless network that extends over my home city, Adelaide, South Australia. Air-stream uses very similar technology to Tibtec – low cost commodity routers, high gain antennas, and hacking. It occurred to me that a “killer application” for Air-stream would be a way to carry phone calls for free over the Adelaide metropolitan area (in Australia we pay 25 cents for each local call).

However once again, if Airstream users can connect with a $50 commodity router, it would be nice to find a low cost way to hook up a telephone.

AVR Microcontrollers and DSP

At about the same time I came across a few articles that got me thinking. One was USBtiny – a way to implement USB in software on a low cost Atmel AVR ATtiny microcontroller. In this design the little $1.50 micro gets interrupted by each USB bit at a rate of up to 10MHz! And I thought the Zaptel 1ms interrupts were bad. For certain applications this allows very low cost USB interfaces to be built, cheaper than typical custom USB interface chips. Hmmmmmmm.

I then stumbled across a fantastic Circuit Cellar article by Marco Carnut on an AVR Phone Recorder and Telephony Platform. This project uses a $5 Atmel AVR ATMega microcontroller. As well as recording telephone signals and communicating with a host PC, the AVR also finds time for some real time DSP (DTMF decoding). What was news to me was that these little chips have some DSP capability built in – for example a relatively fast 2 cycle multiply. These AVR chips also have a bunch of other features, such as built in flash, RAM and A/D D/A converters that seem to work OK for speech signals. They are essentially little “systems on a chip” – just add crystal and stir (well, program). Hmmmmmmm (again).

So the big question is, can we use these chips to build a $10 ATA? Well, I think this might just be possible. To see why, lets first take a look at the design of a typical ATA.

ATA Design 101

The figure below shows the design of a typical ATA. Quite a lot going on. Typically the software components are implemented on some sort of fairly fast (200MHz, several MB of RAM and Flash) microcontroller that can run 1 or two channels of G729 and also support the SIP stack and perhaps a basic operating system.

The Analog FXS Interface is implemented with a chip set from companies like Silicon Labs. This chip set generates DC “battery” voltage to run the phone (e.g. 48VDC), 90Vrms ring signal, provides AC analog termination (e.g. 600 ohms impedance) and a hybrid – a gadget that separates and combines the transmit and receive voltages on the two phone wires. I have written an introduction to hybrids in an earlier post on echo cancellers.

Here is an equivalent electrical model of the Analog FXS Interface connected to a phone (click on the image for a larger version):

There are two paths – DC and AC. The DC path flows through Vbatt to Rdc and provides current to run the phone. Cblock prevents DC entering the AC path, and Ldc prevents and AC entering the DC path. This isolation allows the paths to have different impedances, for example a 200 ohm DC feed resistance Vbatt and a 600 ohm AC impedance (Zo an Zl) for audio signals.

The AC path flows from Vo through Zo and Zl (the audio signal the ATA send to the phone). In the other direction the audio from the phone is the AC path flowing from Vl through Zl and Zo. Zl and Zo are typically the “600 ohms” impedance you hear about when people talk about phone lines.

To ring the phone we switch in a low frequency (say 20Hz), high voltage ring signal Vring. When the phone answers, it closes the hook switch, which is detected by the Hook Detector.

The hybrid (not illustrated) separates Vo from Vl. It usually doesn’t get it quite right, which is where the echo canceller comes in to remove any transmit echo (residual Vo) from the received signal.

In a real world design, the actual parts Cblock, Ldc etc don’t really exist, these days electrical equivalents are all built into the chip set. For example Ldc is often implemented with transistors and a capacitor in a Gyrator circuit, as that is cheaper than using a large inductor. However this electrical model is still pretty accurate, and represents an equivalent circuit that is useful for analysis.

$10 ATA Design

So here is the proposed design of the $10 ATA:

The key points in the design are:

  1. Use a low cost ($3 in modest volume) AVR microcontroller to interface between the phone and the USB port of the router. Alternatively we can use RS232 which most routers support with slight modifications. Ethernet is also possible but costs more as we need an Ethernet chip. With RS232 it may even be possible to remove the RS232 line drivers (saving additional cost) if the line is short. Or perhaps use low cost analog circuit for the line driver alternative (given we have 12V available).
  2. Use the AVRs DSP capability to do DTMF detection.
  3. The built in RS232 UART can run at 115 kbit/s. We require approximately 64 kbit/s in either direction, so RS232 should be acceptable, even with the overhead for start and stop bits. A small amount of overhead is also required for signalling (hook status, DTMF), however this is just a few bytes per second.
  4. The AVR can also be used to implement the switch-mode power supply needed to generate a ring voltage in software (DC-DC converter). If this is not possible, we can connect a buzzer/beeper to the AVR. Instead of the phone ringing, we beep the (nearby) ATA. Usually ATAs are located close to the phone.
  5. We use the AVRs built in A/D and D/A to convert the analog signal.
  6. Use a DC “battery” voltage of 12VDC rather than 48VDC to run the phone – this is enough if the cable is only a few meters, phone only require about 6V, the 48VDC is there to overcome resistive losses on long cables.
  7. The router runs Asterisk (common on WRT54G-class routers). Asterisk talks to the ATA via USB/RS232 using a simple channel driver, for example something similar to chan_oss. The ATA is really not much more than a sound blaster – we push most of the processing to the router, which has a few more spare MIPS.
  8. Handle echo cancellation using echo training and fixed coefficients for the duration of the call. This is a low-MIPS approach that we can get away with due to the special nature of FXS lines. More on this below.
  9. Use a very simple hybrid (just an op-amp), and let the echo canceller do most of the work in separating the transmit and receive signals. We essentially move the hybrid from hardware into software, where it is free to implement.

Echo Cancellation

An FXS port is a special, rather well behaved case which fortunately is kind to echo cancellers. Cable runs are generally short (a few meters of cable) and the impedance match quite close to the ideal. This means only a short tail is required, perhaps only 8ms (64 taps).

Some other simplifications are possible. The echo path is unlikely to change during a call, so we can fix the echo canceller taps for the duration of the call. This removes about two thirds of the MIPS which are normally required to support continuous adaption.

Assuming fixed coefficients and a 64 tap FIR filter, the number of operations is 64 taps x 8000 samples/second x 5 ops/filter tap = 2.56 MIPS. This is acceptable on a 10-20 MIPS AVR. A specialised DSP chip would require just 1 operation per filter tap, however I am estimating 5 operations/filter tap for the AVR.

I have tested the fixed coefficient technique on FXS ports in the past and it works quite well when teamed with a simple echo suppressor to remove the small amount of residual echo. The filter taps can be calculated when the phone is taken off hook by sending an impulse down the line. This is the same algorithm as used by the Zaptel echo canceller when in “echotrain” mode.


There are several risks with the proposed $10 ATA design. Here is my current risk list:

  1. Speech quality through AVR A/D and D/A. What sort of anti-aliasing filters and reconstruction filter should we use (if any)? Should we over sample to reduce analog filtering requirements and possibly increase effective resolution e.g. via noise shaping in DSP? Will the A/D and D/A resolution deliver reasonable speech quality? Will we require some AGC to cope with the limited dynamic range of The A/D and D/A? Do we use companded (mulaw) over the RS232/USB link or linear?
  2. Will we run out of MIPS on the AVR or router?
  3. The AVR based DC-DC converter for ring generation. I am not familiar with DC-DC converters, however the plan is to use a similar topology to the Silicon Labs 3210, i.e. use the AVR to generate PWM that drives a switching transistor, with several safety cut outs. An alternative is to use a simple beeper, with tones generated by the AVR. This would be cheaper and faster to develop, but would only work when the ATA was close to the telephone.

An RS232 Phone

In many parts of the world analog phones are very cheap, for example in Vietnam they are about $2. This is one reason why a low cost ATA makes so much sense compared to even the cheapest SIP phone.

However there is another approach. We could use a $2 phone case, keypad and handset and put our own electronics inside. Sort of make our own “IP phone”. However it talks RS232 rather than SIP. The advantage of this approach is that we avoid most of the hassle in an ATA, i.e. dealing with the FXS interface (ring voltages, echo, 2 to four wire conversion). The microcontroller could be simpler, too.

So I thought I would mention the option of modifying a regular analog phone. It might just be cheaper and certainly less development effort. Perhaps both the $10 ATA and RS232 phone could be developed in parallel, as they share many subsystems.

Development Plan

I suggest that a staged approach to implementation be performed. We should attack the risky areas first to prove the feasibility. Here are the milestones:

  1. Milestone 1: Implement a RS232 sound blaster. Use the AVR A/D to sample speech from a phone handset, and play back speech to the handset. Connect to the router via RS232. Modify chan_oss to allow speech I/O from the RS232 port. Do not implement DTMF, echo can, or ringing power supply just yet. Control from the Asterisk CLI. The idea of this milestone is to confirm that the AVR can handle speech traffic via RS232 and that it sounds OK when teamed with Asterisk.
  2. Milestone 2: Add DTMF and echo cancellation, and implement the analog hybrid. Use a beeper for ringing, no DC-DC converter just yet. At this point we have a design that can be used in a $10 ATA of a RS232 phone.
  3. Milestone 3: Develop the ringing DC-DC converter and integrate.

Interested in Working on a $10 ATA?

I would really appreciate some help with this project, as I am kinda busy with a bunch of other stuff. People with experience or just plain interested in OpenWRT, Asterisk, channel drivers, AVR, and analog hardware development would be very welcome. In the mean time I will work on it on a part time basis.

The cool thing about this project is that the cost of entry is very low (by definition) and the hardware can be developed using plug-in bread board (no soldering required). This work also has the potential to help millions of people in the developing world get a telephone, so it is a very worthwhile project.

Please join our low cost ATA mailing list or contact David Rowe.

Ideas for Further Work

This work could be extended to multiple FXS ports with a more powerful DSP. For example if this design works, then a a $14 (Quantity 1 price) BF531 DSP chip could be used rather than a AVR. The Blackfin can run programs from internal memory requiring only a $1 SPI flash chip to boot. This DSP could handle multiple channels and possibly implement GSM or G729 compression as well. Perhaps a 8 channel FXS channel bank can be built this way for $30. This could serve a remote village, connected via the router using wireless Internet.

The $10 price point is for low volume. Imagine the possibilities given volume production. There are billions of people who need a telephone, and they have some of the cheapest labour on the planet. The circuit is simple and can be assembled by just about anyone. With a market this size, custom silicon is a possibility, which would allow us to further integrate functions into the chip.

So the possibilities for price reduction are endless. Ultimately the electronics is just sand, a little labour, and an open design.


$10 ATA Part 2

sexxx africa picsamiture cupels teensale for porn 1980 1970 moviesinformation addiction cybersexporn amature gymnast xxxvideo sex titmus abiaba teenagers withamerican daydreams porn Mapactrices pornoamateaur pornsenior sex amateur videosa transexual am itgp teen winters abby naturalmotel sex amatureteen age reason models ofbusiness process analysis airline Maploan about debt consolidationloan site add car5 5 loan autoloan credit a badmortgage home loans accessbankruptcy loans 13 studentbusiness small 26 loanloan personal hours 24 MapOrgasmus Soundclip WeiblicheGalerie Mütter Fett hässlichtranny Video Fuck TS sexFrauen Behaarte nackt FotoSharing-Swapping Frau Hahnereiteens petite YouhngSex Interrassisch Geheimnis dunkles Hahnerei GeschichtenBrustwarzen Nippel Laktierenden laktierenden Folter, Map

Improved Dragging on gEDA PCB

Over the past 12 months I have done quite a bit of design work with gEDA PCB, including some telephony designs and the BlackfinOne project.

During this work I developed an itch that needs scratching – I would like to improve the way tracks are dragged in PCB.

At present, when dragging tracks 45 degree angles are not maintained. This means that after the drag operation a lot of manual clean up is required. This consumes a lot of time, especially near the end of a board layout where moving one track may mean moving a bunch of other things out of the way. This sort of manual rework is something the computer should be able to do for me. In fact many (expensive and proprietary) PCB layout programs do just this sort of thing automatically.

Here is an example of the proposed change. Each stage is annotated with text:

So about a week ago I downloaded the PCB source and started looking into the proposed changes. Actually this was a lot of fun for me – I usually do embedded and DSP work so I found working on a x86 C application quite refreshing. The development environment is much nicer and my head doesn’t hurt as much!

Dragging Tracks

First I messed around with PCB to try and make dragging (moving) lines in rubber band mode a little easier to use, here is a video that demonstrates where I am at.

The first drag is how PCB currently works. I then switch off “All Directions Rubber Band”, which enables the new mode I am working on. Note how dragging horizontal and vertical lines maintains the 45 degree angles. This can save a lot of time when editing tracks that is currently spent in fiddly manual rework (I speak from experience).

BTW I really like the PCB source, lots of clean intuitive code. Thanks to all the various authors for their great work.

I find the process of discovery when working on new code exciting (sorry – that’s a very Geeky thing to say!). I first do a lot of ‘grep’-ing and ‘more’-ing, then sprinkle printfs here and there so I can work out what bit of code I need to work on. When I finally start to “get it” it’s a real “AH HA” experience :-) The first mod that you make that actually does something is very rewarding – you have grappled with the beast and have it under control. Well, sort of. Until the next bug at least.

Anyway the current status is that it works OK for vertical and horizontal lines (tracks), but doesn’t handle dragging components or diagonal lines yet. So it’s still early days.

Object Dragging

Of course it didn’t stop there. As the track dragging was working well I dreamed up a way I could drag an object (component) and have the tracks follow at nice 45 degrees. This required different code to dragging one track segment connected to another.

The prototype object-dragging sometimes works quite well, here is the latest video showing a mixture of components being dragged about.

Sometimes it works like magic.

It also has many cases where it makes a real mess :-) However I think its heading in the right direction, I am now going to test these dragging mods on some real PCB work for the next few weeks and see how it goes.

Trying it Out

I have developed some patches against the latest (at the time of writing) PCB snapshot: pcb-20070208p1. It’s not particularly stable and has been known to segfault at embarrassing times. Use it at your own risk!

Get a copy of pcb-20070208p1.tar.gz from Sourceforge (http://pcb.sourceforge.net), then:
$ wget http://www.rowetel.com/downloads/pcb-0.1.diff.tgz
$ tar xvzf pcb-20070208p1.tar.gz
$ tar xvzf pcb-0.1.diff.tgz
$ patch -p0 < pcb-0.1.diff
$ cd pcb-20070208p1
$ ./configure && make
$ cd src
$ /pcbtest.sh t.pcb&

The PCB files t1.pcb and t2.pcb are the demo files I have been using
for testing.

You can get a feel for where it works and the current limitations, like
dragging diagonal lines, and dragging horizontal or vertical lines too

Further Work

This work is far from finished, here some TODOs:

  • Ability drag diagonal lines and maintain 45 degrees.
  • Ability to drag points and maintain 45 degrees.
  • Sensible thing should happen when dragging past ends.
  • Handling T junctions, dragging cross should drag stem.
  • Why don’t selections rubber band drag?

First Impressions

After I wrote the post above I worked until 2:30am on my new IP04 four port IP-PBX design. I was working on routing the data bus which is quite tight as it needs to be kept short (133MHz bus on a 2 layer board):

My first impressions of the new features:

  • If I try to move a complex component with many tracks attached I get a segfault. Need to run PCB inside gdb to check this out. Autosave is my friend, but it would be nice if it saved a sequence of files (actually I think PCB did do this in past versions).
  • The track drag doesn’t do sensible things when you drag past the point where attached tracks go to zero length, this limits its usefulness. They should flip around and go in the other direction (this is hard to explain, sorry).
  • In the image above imagine trying to squeeze a new track right in the middle of the area to the left of C21. At the moment you need to delete and redraw lots of tracks. What I really need is a feature to push tracks out of the way without shorting any tracks. For example dragging one track should move all the others out of the way, intelligently rerouting as I drag.
  • The component dragging chose dumb positions (like on top of other tracks) most of the time in practice. In many cases it was easier to delete and re-draw. Sigh.
  • Overall they new routines were only useful in about 10% of the routing I did. I still find I am doing fiddly manual rip up and reroute most of the time. When they did work it was like magic – it’s far quicker to drag one track then delete three tracks and re-draw them.

So still plenty to do to make this work truly useful. It’s a humbling experience to use what you code, especially after a solid week of working on it :-) Anyway, now that I know a little about the PCB code I am getting lots of ideas on how to make these features truly useful. Thinking about coding and more itch-scratching while I lay out this PCB!

Open Source Echo Canceller Part 4 – First Phone Calls

I fired up the echo canceller in real time today, and tried a few calls on my home phone line. I used an Asterisk 1.2 system running a Digium TDM400 card, and integrated the new echo canceller into Zaptel. I had previously tried this same phone line with one of the Zaptel 1.2 built-in echo cancellers with poor results – it didn’t really converge. To be fair, I haven’t tried the latest Zaptel 1.4 echo cancellers, I will try that soon.

The new echo can worked OK, definitely an improvement. I could hear a little echo on about 3 occasions in about 10 minutes of talking, but it quickly reconverged each time.

There were a few little problems – the crude Non-Linear Processor (NLP) used simply mutes the near end and I can hear the background noise being switched on and off when I talk. I really need a better approach like comfort noise or variable gain here (thanks Jean-Marc Valin for your suggestions here). Plus from the simulation I am aware of a few other weaknesses, e.g. some G168 test fails that need looking into.

Obviously, the echo canceller also needs much wider testing, so this is just a very preliminary result.

Anyway, I am pretty happy with this. One big reason for this work was so I could use my Embedded Asterisk system on this FXO line, and I am now pretty close – just need to port to the Blackfin.

The echo canceller code and a short README that describes how to use it on your Asterisk system is checked into SVN if anyone would like to try it.

Please send me an email and tell me how well it works for you. If it doesn’t work please use the sampling system to send me a few samples from your phone line. I can use that information to improve the echo canceller.

Overall this is an encouraging start. Thanks to all those who have helped me over the past month.

Reading Further

Oslec Home Page
Part 1 – Introduction
Part 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Calls
Part 5 – Ready for Beta Testing
ringtones to sidekick adding slideringtones adp1200 sprint pcs lg ringtonefree ringtone scp sanyo 8100arrington adleralf ringtonespolyphonic free nec 525 ringtoneadvocate in good barrington shepherd Map9nu sw1x sloane street 17 londonsloane a-trans systemsloan all-in-one michigan constructionthe fifties sloan during alfred palgebra amortized loanp box address o ameriloanalla actual property loan macdonaldloan forbearance americorp Mapkey casino mobile allaccount merchant high risk offshore casinobuffalo a casino aroundbest affiliate gamblingcasino account offshore merchant risk high4bears casino lounge in newtown andakwasanee hogansburg ny casinocasino affiliate aaa programs Mapmovie amatuer home pornhousewife videos amatuer pornclips amatuer porn milfseattle amatuer pornporn amatuer trailersamatuer porn video clipsamatuer pornotube porn videosamatuer porn websites Map

Open Souce Echo Canceller Part 3 – Two Prototypes

Recently I have been experimenting with two prototype echo canceller algorithms. This post describes the prototypes and results so far. This post is pretty hard core DSP – it may not be of interest unless you already have a fair idea of how echo cancellers work. I am writing it mainly to help me clear my own head on progress so far. Part 1 and Part 2 of this series provide a gentler introduction.

If anyone wants further explanation please feel free to post a question or email me directly. The code is available via SVN.

The G168 Standard

After writing Part 1 of this series Steve Underwood suggested that a good approach would be to base the echo canceller development on the G168 standard.

This was an excellent suggestion – thanks Steve. Steve also pointed me at a prototype echo canceller and code he has developed to test the echo canceller against the G168 requirements, part of his very impressive spandsp DSP library. So I have been working with Steve’s software, adding to the echo canceller code and automating some of the tests.

I have been using a simulation of the echo canceller rather than a real time implementation. This means that rather than talking into a telephone saying “1..2..3..” and listening for good/bad echo I am running a command line program that simulates the effect of the telephone hardware to generate and measure the echo. This makes it much easier to experiment – for example I can dump internal states of the code at any time and generates objective results with automated pass/fail results. Once I am happy with the non-real time simulation the idea is to run the same code in real time.

Here is a sample run of the simulation code:
Performing test 2A(a) - Convergence with NLP enabled
test model ERL time Max Rin Max Sin Max Sout Result
2aa 1 -10.0 11.20s -14.98 -24.55 -100.00 PASS

This means that for G168 test 2A part (a) with echo model 1 and an Echo Return Loss (ERL) of 10dB we passed. The Rin (Receive In), Sin (Send In), Sout (Send Out) ports are the signal levels on various ports of the echo canceller in dBm0. Sout = -100 dBm0 basically means the echo is at a very low level by the end of this test. Wish that were true for all tests :-)

And here is a plot that shows what is going on:

Click on the image for a larger version. The echo is the blue signal. In less than 1 second (8000 samples) the echo is effectively removed.

G168 has about 20 basic tests that are repeated with a bunch of different permutations. It specifies the types of signals used to test the echo canceller and the expected results. The standard is available for free download (I use the 2004 version). Steve had already implemented much of the test code – this has been very helpful. I have been concentrating on automating the tests and trying to get the prototype echo cancellers to pass.

The two prototypes vary in how they control adaption. One uses an innovation on the Geigel Double Talk Detection (DTD) algorithm suggested to me by Steve called Tap Rotation, the other a Dual Path method from an early paper by Ochiai which was kindly pointed out to me by Ramakrishnan Muthukrishnan.

Geigel & Tap Rotation

The Geigel part of straight out of the classic Messerschmitt paper from Texas Instruments. The tap rotation algorithm works like this:

  • Instead of having one set of N filter taps we have three sets of N filter taps.
  • Every 1600 samples (200ms), we rotate to the next bank of taps, for example if we are using set 2, we start using set 3. This gives us a record of the previous state of the filter taps, for example if we are using set 3 then set 1 will be the oldest set.
  • If we detect double-talk (using the Geigel algorithm), we replace the current set of taps with the oldest set.

This algorithm protects us from failures of the Geigel DTD. For example it may take the Geigel DTD a few 10s of ms to detect double talk. In this time it is possible for the taps to diverge significantly. Tap rotation effectively tosses out the latest taps and replaces them with an older version, well before the DT started. This is like giving us 200-400ms of “pre-hangover” – we prevent adaption 200-400ms before DT. Combined with the hangover of the Geigel algorithm, it means we prevent adaption anywhere near the DT in both the positive and negative time directions.

Here is a plot of the algorithm in action (click for a larger version):

In the initial 5 second period the echo canceller is allowed to converge, then it gets blasted by high level near end speech for 5 seconds. Then there is a final 5 second segment where we look to see if the echo canceller has diverged. In this case it is doing a good job, you can see the echo level in the final 5 second section is similar to the first 5 second section.

The small green line at the bottom is the Double Talk Detector (DTD). You can see that it fires in the DT areas. On each “rising edge” of this signal the taps are reset to previous values.

As I have currently implemented it (and I freely admit I may have messed up somewhere), the Geigel/Tap Rotation Algorthim has a few problem areas:

  1. At low ERLs (e.g 6-8 dB) the DTD fires a lot, even when there isn’t double talk, as the high echo levels mimic near end speech. So we don’t converge fast enough in the 1s allowed for the convergence test.
  2. It struggles with near-end background noise (G168 Test 2c). The noise gets mistaken for near-end speech, and the taps get reset back to previous values all the time by the tap rotation logic. So it adapts very slowly and can’t converge within 1s.
  3. It also diverges a bit too much with low levels of near end speech (e.g. Test 3b part (b)) during double talk. It’s OK for double talk with high near end speech levels, such as the plot above (Test 3B part (a)).

Dual Path Algorithm

The second prototype has two filters to model the echo, a foreground and background filter. The background filter adapts continuously with only mininimal protection from double talk. When the background filter is performing better than the foreground, it’s taps are copied to the foreground filter. See the Ochiai paper for more information.

This algorithm passes the cases described above where the Giegel/Tap Rotation Algorithm is struggling. However it still fails several boundary cases like very low ERL & levels, but these fails are close calls (for example slightly slower convergence time than required) rather than complete failures of the algorithm.

For more information see the echo.c source code.

Automated Testing

I have automated pass/fail evaluation of a 5 test subset of Steve’s G168 test code, here is a sample output:
test ERL Max Rin Max Sin Max Sgen Max Sout Result
2aa -10 -14.98 -24.55 -100.00 -100.00 PASS
2ca -10 -14.98 -24.55 -30.01 -31.97 PASS
3a -10 -14.98 -24.55 -29.87 -51.32 PASS
3ba -10 -14.98 -24.55 -14.86 -53.44 PASS
3bb -10 -14.98 -24.55 -20.86 -53.46 PASS


2a (a) Basic convergence test
2c (a) Convergence test with near end noise
3a Convergence test with low levels of near end speech
3b (a) Double talk divergence with high levels of near end speech
3b (b) Double talk divergence with low levels of near end speech

Rin (receive in) Sin (Send in) etc are the nomenclature used in G168. Sgen (Send generator) is the near end speech/noise signal. I have used some different names for the same signals in earlier posts, these two figures explain:

So in Test 2c (a) the maximum near end (Sgen) signal (which is noise in this case) was -30 dBm0. The maximum echo signal (Sin) was -24.55dBm0 when the system was driven by a -14.98dBm0 (Rin) signal. If you look at the difference between Sin & Rin the ERL is actually more like 9.57dB.

Many of the G168 tests are very similar, so I have built up a bunch of C code functions as a sort of “test language” to make life a bit easier:
print_title("Performing test 2A(a)\n");

/* initial zero input as reqd by G168 */

run_test(200, MSEC);

/* Now test convergence */

run_test(1, SEC);
run_test(10, SEC);


The Octave script echo_dump.m is used to plot internal states of the echo canceller – this is really helpful in letting me drill down to the problems in the algorithm.

Testing on Real World Signals

The G168 tests are conducted with synthetic speech signals. As a sanity check I have run the two prototypes with echo signals sampled from a real phone line:

The canceller takes a little longer to converge in this case, as the speech segments “1..2..3..4” are short followed by long-ish pauses. However you can see that the echo (blue line) is removed.

You can even listen to the output. This is the echo signal before cancellation, this is the signal after cancellation using the Dual Path algorithm. You can hear the echo signal gradually decreasing as the canceller converges. It would be nice to speed up convergence – an ideal echo canceller would cancel almost immediately and the “after cancellation” file would just contain silence.

Next Steps and Help Wanted

I am enouraged by the progress so far, however there is still plenty to do:

  1. Test in real time on x86 and Blackfin. This is the reason for all this work in the first place. All I really want is to connect my shiny new embedded IP-PBX up to a FXO line without echo!
  2. Lots more G168 tests to implement and automate.
  3. Chase down current fail cases.
  4. Convert some float code to fixed point.Done
  5. Convert NLP to use comfort noise rather than muting.
  6. Make the canceller and sampling software hardware-agnostic. For Asterisk it should really integrate with Zaptel rather than the hardware driver.
  7. Implement algorithms to provide robustness (non divergence) with tones. I am not sure if this feature is strictly needed for my application (FXO port for an IP-PBX) but robustness for narrow band signals is required for G168 compliance.
  8. It would be interesting to run some other open source echo canceller algorithms through the G168 test framework. For example there are several echo cancellers in Zaptel, and Jean-Marc Valin’s acoustic echo canceller used in Speex.

Anyway if you are interested in working on an open source echo canceller you are very welcome to help out. Just send me an email. A lot of this work doesn’t require specialised DSP skills (for example integration and testing in real time on an x86 Asterisk system), so there is something here for everyone. Due to the automated tests, this project would also make a great project for learning DSP and echo cancellation – if you make an error the tests will let you know.

The core echo canceller development is tough and challenging work! As I suspected :-) So after hammering away for the last few weeks I felt a bit stale and took a few days off to go camping with my kids. We went to the Murray River National Park, about 180km from were I live in Adelaide, South Australia. I now feel a little more balanced, amazing what a few days off can do!

As a next step I might do some real time testing, just to make sure I haven’t missed anything obvious with the G168 tests. My first milestone is a “workable” echo can for my home phone (FXO) line, I should be getting close now I think :-)


Thanks to Steve Underwood for all the excellent spandsp code he has written, and to Steve, Jean-Marc Valin, and Ramakrishnan Muthukrishnan for their comments and help with this work.

Reading Further

The Open Source Line Echo Canceller (Oslec) has progressed a great deal since this initial (Part 1) post was written:

Oslec Home Page
Part 1 – Introduction
Part 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Calls
Part 5 – Ready for Beta Testing
Geschichten Interrassisch Sex HahnereiMädchen Russisch Behaarteteen pics ass Kostenlos minderjährigePissing Demütigunghentai Übersetzt Comicsinterrassisch Alexandra nice pornheißen Freunde Meine cee mrs momkostenlos pics Russisch nudeNackt Desi babesOutdoor peeing Verzweifeltenentertainment absolute barringtonringtone to v170 motorola phone addringtones alcatel in fijikyocera ringtones slider remix addtimes amc barrington movietheater barrington amcalexis harringtonorrington s 80 me Mapaccredited loans education distanceloan acoustic homeby consolidation administered loansfor affordable loans studentsmember family agreement loan formloans grants agriculture youngair consolidation debt travel loan tipadvance alabama and loans cash payday Maprich credit american commercial services adamscolorado accreditationcorrespondence colleges accreditedaccreditation center childcarecard offers credit adhesivecapital credit one activateaccreditation of in usa the universitiesaccredited articles health Mapachat mp3 fi chaine hifool mp3 actamp3 brasil ache paranaueachha mp3 jiacting mp3 tipsachhe mp3 lagtemp3 mefaridze achidoar tine activ mp3 cu Mapsample movie lesbianmovies hardcoregirls ebony movies buttsybian clips moviehomemade sex moviesmovie stars nudemovie samples hot xxxhandjob movies free Maptorrent porn bit sitesat work pornsite bitchesbiting pornpirates porn bittorentporn and bittorrentbittorrent search porntrailers bizar pornbizarre adult pornography Map

Open Source Echo Canceller Part 2 – How Echo Cancellers Work

This post explains the basics of how echo cancellers using a very simple C code example.

From Part One of this series here is a block diagram of an echo canceller:

Lets convert this diagram to a model of the echo and echo canceller, and put some sample numbers into the system:

In this case we model the echo as a simple multiplication of the tx signal. So any signal we send down the tx port will be reflected back to us as an echo signal that is 0.1 times the size of the tx signal. The idea of the echo canceller is to work out the value of the echo (which it stores in the variable h). If we estimate h correctly, then our model of the echo (tx times h) will exactly cancel the echo signal.

Echo cancellers adapt to the particular characteristics of the echo in your telephone line. Each phone line is different so the actual amount of echo (in this case 0.1) is unknown. The echo canceller must learn this value somehow, by looking at what goes in (tx) and what comes out (rx) of the hybrid. Many echo cancellers use an adaptive filter to “learn” the echo characteristics.

Here is some C code that shows how it all works:
/* echo.c simple echo canceller demo */

#include <stdio.h>

#define ECHO 0.1
#define N 10
#define BETA 0.3

int main() {
float tx, rx, ec, h;
int i;

tx = 1.0;
h = 0.0;

printf("Step tx rx ec h\n");
for(i=0; i<N; i++) {
rx = ECHO*tx;
ec = rx - h*tx;
h += BETA*ec;
printf("[%d] %3.2f %3.2f %3.2f %3.2f\n",
i, tx, rx, ec, h);

return 0;

Here is the output from a sample run:
Step tx rx ec h
[0] 1.00 0.10 0.10 0.03
[1] 1.00 0.10 0.07 0.05
[2] 1.00 0.10 0.05 0.07
[3] 1.00 0.10 0.03 0.08
[4] 1.00 0.10 0.02 0.08
[5] 1.00 0.10 0.02 0.09
[6] 1.00 0.10 0.01 0.09
[7] 1.00 0.10 0.01 0.09
[8] 1.00 0.10 0.01 0.10
[9] 1.00 0.10 0.00 0.10

To work out the echo (h) we use a simple adaption algorithm. First we use our current guess of the echo (h) to calculate an estimate of the echo (ec). Of course if we don’t have an accurate estimate of h we won’t predict the echo exactly, we will have an error. To converge on the correct value of h we add a little bit of that error onto h and try again. As we get closer and closer the error gets smaller and eventually we converge on the correct answer (h = 0.1).

In practice the echo is a little more complex than a simple constant multiplier. It is usually modelled as a bunch of constants delayed by one sample from each other, for example:
echo_estimate = 0;
for(i=0; i<N; i++)
echo_estimate += h[i] * tx[j-i];
ec[j] = rx[j] - echo_estimate;

The number of samples in the echo model (N in this case) specifies the maximum delay or “tail” the echo canceller can handle. So when an echo canceller is specified as say a 128 ms tail, this means 128 ms * 8 samples/ms = 1024 samples in the echo model. The 8 samples/ms comes from the fact that telephone signals are sampled at 8000 Hz.

The array of h values are sometimes called the echo coefficients or taps. Here is what a typical array of h values looks like when plotted:

This has a rather short tail of only 64 samples (8ms), which would be typical of a FXS port where the phone is connected to the port by a few metres of cable.

In real world echo cancellation we also need to deal with problems like freezing the adaption when both people are talking at once (double talk). In this case the ec signal is made up of the echo plus the “near end” talker’s speech rather than just the echo by itself.

Reading Further

The Open Source Line Echo Canceller (Oslec) has progressed a great deal since this post was written:

Oslec Home Page
Part 1 – Introduction
Part 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Calls
Part 5 – Ready for Beta Testing