Prototype IP08

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

Features include:

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

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

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

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

Some work remains:

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

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

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

Links

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

Asterisk Appliance Survey

In a few weeks I will be attending the GK3 conference in Malaysia on ICT for the developing world (ICT4D) with Louise and Alberto from IT 46. Part of our preparation was writing a document describing how the IP04 can be used in developing world scenarios.

Anyway, Alberto and I put together this table comparing Asterisk “Appliance” class products.

The IP04 is a leading edge embedded IP-PBX, equivalent to anything developed by traditional (closed development) commercial companies. The open hardware pedigree means that the hardware has been reviewed by “many eyes”. This means (just like open software) that the IP04 is likely to be more stable and have higher quality comparable “closed” products.

Note that the IP04 is one of first embedded Asterisk “Appliance” type devices to be offered for commercial sale (production status in the survey) – community based development (open hardware and software) gave the development team a time-to-market edge!

Links

The IP04: Open Hardware for Developing Regions
IP04 and the Asterisk Appliance
IP04 Open Hardware IP-PBX
deep movie thenh in movie theatersmovie xxx freepantyhose mature movies ladies of inmovies men sample xxx muscle ebonynaked movie beachnatsuko tohno movienikki movies fritzmovie ninja download scrollmovies women nudecredit military bad all loans personalonline accredited course organic chemistryunsecured bad loan credit $3000report preparer credit 1 in 3texas merchant account card accepting credithomes nursing of accreditationaustin federal union plus credit a0 cards credit transfer balance interest Mapmovies free scatsample clips movie sexsex movie clipsexpress polar movieporn classic moviesadult japanese moviesmovie mtv awardstheater movie amc Mapgreen jaidon codrington allanallblacks haka ringtone555 ave leveringtonleverington ave philadelphia 100north 1601 corrington city mo kansaspa fold warrington klear agird wa 83516 west harrington richlandcarrington pictures amerlink 1 Mapmovie deep throatloan sfas definition impairment 114house hr loans 40misused 11 recovery loan 9403b loans 403katv s 4×4 motorcycle loangreenlight loans 295loans 120 day Map

Asterisk on a FPGA

Over the past couple of years a few people have suggested running Asterisk on an FPGA using an embedded processor core. I must admit I had always assumed that the processor would be too slow to be useful, certainly much slower than a regular embedded processor at the same price.

However my friend Stelios Koroneos and the team at Digital OPSiS have proved me wrong! They have managed to implement Asterisk on a Xilinx Virtex 4 FPGA, running a 300MHz Power PC core. These FPGAs cost about the same as an embedded processor, e.g. around $12 in Qty 1000.

They have the whole system running on a Xilinx development board:

Many clever tricks are possible with a FPGA, for example you can just “compile in” a floating point unit, include all your system glue logic on the same FPGA, or provide hardware acceleration for application specific tasks. In this case, FIR filters used for echo cancellation have been sped up by a factor of 300, using a little custom hardware implemented on the FPGA.

The build process is interesting, you first “build” (synthesise) the actual CPU (!), then build the kernel, applications etc to suit. Booting is also interesting. On power up the first step is to configure the RAM-based FPGA, then like magic it turns into a CPU and the regular boot loader plus Linux boot process can commence. Both the FPGA configuration data and Linux can be stored on a SD card (and presumably be updated by Linux at run time).

This is pretty amazing stuff, and opens up some really interesting possibilities. For example you could include an E1 framer on the FPGA and possibly even the DSP side of analog interfaces. The Bill of Materials BOM can also be reduced by absorbing system functions into the FPGA. Stelios and team are also working on hardware-acceleration for codecs like G729.

CPU cores embedded on an FPGA represents a “third way” to build embedded IP-PBX systems. Earlier designs used a host processor + specialised DSP architecture, later systems (like Asterisk on an x86 or the IP04) use a host-processing approach where a single CPU with DSP capabilities is employed.

I really like the Digital OPSiS guys think – they are digging into the key issues of Asterisk (like the drawbacks of it’s threaded design and bottlenecks like echo cancellation) and coming up with fascinating new ways to optimise the system.

Nice work Digital OPSiS!

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.

Links

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

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.

Conclusion

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

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:
#!/bin/sh
# lotsofcalls.sh
# David Rowe 3 April 2007

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

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.

Credits

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.

Links

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.

Risks

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.

Links

$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