Building an Embedded Asterisk PBX Part 2

Here is the next installment in my adventures of building an embedded IP-PBX around the Blackfin-Asterisk. The big news is that we now have a working 4-port embedded IP-PBX and low cost hardware for sale!

DTMF Fixed Point Port

I spent a few days converting the Asterisk floating point DTMF detection code (dsp.c) to fixed point. You see the Blackfin doesn’t have a FPU so any significant floating point work (like DSP) needs to run in fixed point. This work brought the MIPs per channel down from about 200 to 5 (The Blackfin has about 500 MIPs available). It could run much faster if I ported the inner loop code to assembler however I think it’s fast enough for now.

To test the Asterisk DTMF detector I used Steve Underwood’s dtmf_rx_tests.c program from his very well written spandsp library. I moved from floating point to fixed point in a series of very small steps. After each step I ran Steve’s unit test to make sure I hadn’t screwed anything up. This is really the only way to test DSP code, you can’t just hack real time code then push a few buttons on the phone and hope it dials OK!

Here is some typical output from the unit test:
Test 4: Acceptable amplitude ratio (twist)
1 normal twist = 8.00dB
1 reverse twist = 4.20dB
5 normal twist = 8.40dB
5 reverse twist = 4.60dB
9 normal twist = 8.40dB
9 reverse twist = 4.60dB
D normal twist = 8.70dB
D reverse twist = 4.30dB
Passed
Test 5: Dynamic range
Dynamic range = 41dB
Passed
Test 6: Guard time
Guard time = 25ms
Passed
Test 7: Acceptable signal to noise ratio
Acceptable S/N ratio is 10dB
Passed
Test: Dial tone tolerance.
Acceptable signal to dial tone ratio is 15dB
Failed

Note the last test failed. This test also fails on the floating point code (i.e. running on a PC, before I ported it to the Blackfin). I am not sure why. Could be a switch I forgot to turn on or a bug in the dsp.c code. Need to look into that some day.

Echo Canceller Optimisation

I also spent some time looking at the mec2.h echo canceller in the zaptel package with a view to speeding up code execution. You see if we are running 4-8 analog channels we need to make sure the echo canceller is fairly efficient. In fact, the echo canceller is likely to dominate the CPU load of the PBX; Asterisk and the other DSP code uses a relatively small amount of MIPs in comparison.

I have identified a few areas where mec2.h could be optimised. One example is in the tap update code:
for (k=0; k<ec->N_d; k ) {
grad2 = CONVOLVE2(yada yada);
ec->a_i[k] = grad2 / two_beta_i;
ec->a_s[k] = ec->a_i[k] >> 16;
}

BTW I have deleted a lot of code for clarity. On the Blackfin the divide is a function call which is a no-no for real time DSP code. In fact divides are generally a bad idea for real time DSP, you want everything to be expressed in terms of multiplies and adds.

However, we are in luck. As we are dividing by a constant the divide can be pulled out of the inner loop:
inv_two_beta_i = 1/two_beta_i;
for (k=0; k<ec->N_d; k ) {
grad2 = CONVOLVE2(yada yada);
ec->a_i[k] = grad2 * inv_two_beta_i;
ec->a_s[k] = ec->a_i[k] >> 16;
}

There are also several other places where the echo canceller could be optimised. This would also help performance on x86 platforms, for example there is no reason why much larger tails (or larger spans) couldn’t be handled on a PC with a little more optimisation.

Multiple Analog Ports

Once I had the DSP code moving along nicely it was time to port the driver to handle multiple analog ports. Here is the output from the driver as it boots and auto detects 4 modules:
root:/var/tmp> insmod wcfxs.ko debug=1
Using wcfxs.ko

Registered Span 1 ('WCTDM/0') with 8 channels
Span ('WCTDM/0') is new master
iRxBuffer1 = 0xff803e58
iTxBuffer1 = 0xff803ed8
ISR installed OK
port: 1 port_type: O
port: 2 port_type: O
port: 3 port_type: S
port: 4 port_type: S
port: 5 port_type: -
port: 6 port_type: -
port: 7 port_type: -
port: 8 port_type: -

O means an FXO port was detected, S means an FXS port. In this case just four ports are loaded, out of a possible 8. You know I really should have added the letters “FX” in front of those strings. Hmmmmm. Maybe when I finish this blog post.

Here is what it all looks like when configured for four ports:

A pretty red light means an FXO port, green means FXS. The whole thing isn’t very big, about the size of a phone handset:

Want more than 4 ports? No problem. Just stack another board on top:

In this example I didn’t populate all the ports as I hadn’t soldered up enough modules at the time. Can you guess from the lights how each port is configured?

It might be useful to introduce a few terms:

  1. The mother board is the Blackfin STAMP card on the bottom. These are made by Analog Devices and are available off the shelf for about $200. They run uClinux and also support way-fast DSP work.
  2. On top of that I plug in a daughter board (why are boards always girls?). This puppy holds some glue logic and sockets for the modules and SD card.
  3. The modules are the little boards that plug into the daughter board. There are two types of modules, FXS and FXO. The daughter board holds four modules.

So the whole thing is very similar to the Digium TDM400 design (and other companies who use modular approaches I guess), except that here the mother board is an embedded system and the daughter board uses a serial bus rather than PCI.

Stack Overflow

I am pretty happy with the hardware stacking architecture, here are some other cool things it can do:

  1. Although I haven’t tried it you might be able to stack more boards on top, to give a total of 12, 16 ports etc.
  2. It would be easy to design a daughter card with sockets for 8 or even 12 modules, that way you wouldn’t have to stack it so high. You could then make an IP-PBX in the shape of a channel-bank.
  3. It’s possible to combine analog and other interfaces in one stack. For example you could combine analog ports and say BRI-ISDN using the fourfin board.
  4. If the Blackfin DSP starts to glow cherry red we can always add a DSP daughter card to handle say echo cancellation.

Status

So how well does it work? Well it’s early days but so far so good:

  1. It works (really) and stays up until I bring it down, i.e. as far as I can tell it’s stable.
  2. I can make calls between ports and have run calls on 3 out of 4 ports at the same time. I ran out of phones and phone lines at that point!
  3. I can play the “Congratulations, you have successfully installed….” demo and even call Digium via the IAX2 demo.
  4. It makes and receives IAX2 & SIP calls OK.

Getting Involved

There are still plenty of things to do. If you would like to work on a leading-edge project with open hardware and software, you are very welcome to join our community and get involved.

Corporate sponsorship is welcome, however please don’t ask me to close the hardware designs (I get a lot of that). Some thoughts on the business and social possibilities are here. Some ways to contribute are engineering time, donation of test equipment, and direct financial support. In return you get high quality, well tested, open hardware designs and quality open DSP software.

We already have people working on software, hardware, and some companies donating test equipment and engineering time.

Next Steps

  1. Lots of testing. I would like to give the platform a good hammering using automated tests, for example have FXS ports call FXO ports continually and pass a few tones back and forth while measuring signal quality automatically.
  2. I would like to improve the echo canceller algorithm. I have a bunch of ideas and a “brains trust” of strong DSP guys who I am in email contact with to help on this one. I don’t see any reason why an open echo canceller can’t be made just as good at the proprietary echo cancellers being used in “hardware” echo cancellers today. After all, they are just software running on DSP chip. I am not saying it is a trivial problem (echo cancellation is tough DSP voodoo), but I am saying is is do-able. Any echo cancellation gurus out there – please email me if you would like to help with effort or even just advice.
  3. Implement booting via the SD-card.
  4. Complete the port to a late model Asterisk.
  5. Compliance Testing. I have booked the first set of compliance tests and will be aiming at approvals for the US, Canada, Australia and New Zealand. Once testing is complete you will be able to build and deploy real world products that are approved for connection to the telephone networks in these countries.
  6. The ultimate test. I will install one at my Mums house. If she can’t break it no one can. She is death to anything with IT in it. She doesn’t need a GUI, rather a RPI (rotary phone interface).

Hardware for Sale

I have started manufacture of 20 Beta units, they are due to ship in mid October. The price for a kit consisting of 1 daughter card and a total of 4 FXS/FXO modules (see photo below) is US$299 plus shipping (McDonalds ruler not included unless you really want one).

Combined with a US$226 BF537 STAMP card from Digikey (enter ADDS-BF537-STAMP-ND in the search box) you can start experimenting with your very own embedded Asterisk PBX with 4 analog ports for around US$500. Please email me if you are interested.

Buy purchasing my products you directly support open telephony hardware development.

Links

  • Building an Embedded Asterisk PBX Part 1
  • Building an Embedded Asterisk PBX Part 3
  • loan 13 payday 19 online arizona6 city payday 4 central loan6 advance 4 loan payday paydayadvance6 8 loan payday vapayday loan bad credit 8direct consolidation 9 loancredit loans personal bad 90 daytax for loans abandoment purposes Mappornos bondagesubmission bondage pornsites porn bondeprone porn bonebonnie british pornstar porn bonniefucking boob porngame boob porn Mapporn pimp 50centsoldr 6and porn95991 tattoo closet artists pornmag a3 pornadept porn aaslincoln porn abeabuelas y porn sexo madresporn accept creditporn accion enny porn accord Map

    Building an Embedded Asterisk PBX Part 1

    Over the last few days I have been bringing some telephony hardware to life. I have finally obtained all the parts I need and am assembling, testing, and blogging as I go!

    This work is part of a project to develop and build “open” IP-PBX hardware. Now by building I mean really building. Like designing the circuits and Printed Circuit Boards (PCBs) and then hand-loading the PCBs with a soldering iron. The PBX is an embedded Asterisk design running on a Blackfin STAMP platform. This work is part of the Free Telephony Project.

    Now the first priority is to start with a clean, tidy, professional work area:

    Mmmmmmmmm. Oh well, I will tidy it up one day.

    Lets start with the 4fx board. The 4fx board interfaces the Blackfin STAMP to the FXS & FXO modules. It has a little Xilinx XC9536 programmable logic chip (or CPLD). I had previously designed and simulated the Verilog code for this CPLD so all I had to do was program the chip using a JTAG cable that connects between my PC and a header on the 4fx card:

    It actually took me a few hours of head scratching to get the chip to program. The problem was I has accidentally selected the wrong chip type when I synthesised the CPLD code. DOH! Anyway once I worked that out it programmed straight away which was a relief – you never know with a new design if you have messed up something fundamental like connecting power in reverse. So the first “sign of life” you get from a new board is always a big relief.

    I then poked around with the scope while running a unit test program on the Blackfin that put the CPLD through a few tests. Just like software, it is very important to make sure the components of a hardware design a working before integrating the components into a larger design. The typical trap is that we get excited and try to move forward too fast, for example testing several new and unknown parts of the design all at once. Simple errors compound to tough bugs when combined with other untested hardware and software.

    So I always try to test thoroughly at the earliest possible stage. In fact I often organise my designs so they can be broken apart into little chunks and tested, rather than thinking about testing as an after thought. In the case of the CPLD I ran many simulations using the Icarus Verilog simulation tools before even going near the hardware. Experience (OK plenty of screw-ups) has taught me that it takes much less effort to test carefully earlier than to debug later.

    Anyway, back to the story. On the CPLD I messed up one pin’s position in the pin-locking file (easily fixed by recompiling the CPLD image), but apart from that the CPLD appears to be working fine. All the chip select signals are being generated in response to the commands from my test software.

    OK, the next step is to see if I can make some LEDs on the board light under software control. The LEDs are connected to the CPLD and will be used to show the status of each telephony port. So if we can make the LEDs do their thing this will prove another chunk of the CPLD code is OK.

    I modified the unit test program to write to the register that controls the LEDS:
    bfsi_spi_init(baud, (1<<NCS_A) | (1<<NCS_B));

    for(i=0; i<tests; i ) {
    bfsi_spi_write_8_bits(NCS_B, select);
    bfsi_spi_write_8_bits(NCS_A, data);
    }

    In the for loop, the first write sets the “destination” of the data (which SPI device we wish to write to). The second write sets the actual value. The way the LED is wired up if we write a 01 (binary) we should get the LED to glow red, and 10 (binary) to make it glow green. The for loop makes it repeat many times, just so I can see what is going on with my ancient analog scope. Only one write is actually neeeded.

    I peer at the LED. It stares back, blank and just daring me to try:

    I hit the magic command line:
    root:~> insmod tspi_4fx.ko data=0x1

    Hey – it worked! Thats not meant to happen! Not first time! WHOO-HOO! OK, lets try making it green:
    root:~> insmod tspi_4fx.ko data=0x2

    Coooooooool……..

    It is hard to explain feeling of achievement you can get from just making a LED light. You never really understand how much complex technology is between the vision and reality of making a simple LED come on – until you start to build chunks of that technology, solder the LED yourself, write the driver etc. Then you realise, and a simple LED turning on when you tell it to seems like an unlikely miracle! Anyone who has ever worked on making computers talk to hardware will understand what I mean.

    Especially if you have had your share of times when that LED wouldn’t turn on. For like days or weeks.

    OK so the next step was to test the FXO and FXS modules. Here they are all soldered and ready to smoke up, errr I mean test. The large, ugly resistors hanging off them are because I couldn’t easily source some very high (15M) and very low (0.5 ohm) resistors I needed in 0603/0805 packages. Can anyone send me a few please?

    First I wanted to test the FXO module. I connected it directly to the Blackfin STAMP card, rather than using the 4fx card just yet. Golden rule – always test the minimum possible:

    I already had some Asterisk software for the Blackfin running and tested (using other hardware). That meant I had tested and working software to test the unknown hardware. So it was just a matter of firing that up and seeing if it detected the card:
    Welcome to:
    ____ _ _
    / __| ||_| _ _
    _ _| | | | _ ____ _ _ \ \/ /
    | | | | | | || | _ \| | | | \ /
    | |_| | |__| || | | | | |_| | / \
    | ___\____|_||_|_| |_|\____|/_/\_\
    |_|

    For further information see:
    http://www.uclinux.org/
    http://blackfin.uclinux.org/

    BusyBox v1.00 (2006.08.25-23:13 0000) Built-in shell (msh)
    Enter 'help' for a list of built-in commands.

    root:~> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
    Zapata Telephony Interface Registered on major 196
    Registered Span 1 ('WCTDM/0') with 1 channels
    Span ('WCTDM/0') is new master
    iRxBuffer1 = 0xff800000
    iTxBuffer1 = 0xff800080
    ISR installed OK
    Testing for ProSLIC
    ProSLIC not loaded...
    Testing for DAA...
    VoiceDAA System: 04
    ISO-Cap is now up, line side: 03 rev 06
    Module 0: Installed -- AUTO FXO (FCC mode)
    Found: Blackfin STAMP (1 modules)
    Registered tone zone 0 (United States / North America)
    4294895942 Polarity reversed (0 -> 1)

    root:~> /var/tmp/asterisk -vc

    Thats a pretty good result – the FXO port was detected OK. So then I started Asterisk and put a few calls through it. I placed a call into the PBX (using another Asterisk PBX running on an x86 box) and it detected the ring signal and went off hook OK:
    *CLI> RING on 1/1!
    NO RING on 1/1!
    RING on 1/1!
    NO RING on 1/1!
    Jan 1 02:51:59 NOTICE[96]: chan_zap.c:5406 ss_thread: Got event 2 (Ring/Answer)

    However the audio had lots of sharp clicks and pops. Crack-Crack-Crack every few seconds. Damn.

    I spent half a day chasing this bug. I puzzled me a bit as I knew the circuit was straight out of the Silicon Labs data sheet and that I (and a few others) had carefully checked it. So I figured it must have been an assembly error like a wrong component or bad solder joint. Actually I wasn’t quite that logical: in the real world bugs tend to get your emotions involved. You really want it to work so you get a little stressed and start doing and thinking stupid things. So you end up checking a bunch of things you don’t need to (like the schematic five times) and perhaps missing some other more sensible checks – you don’t always think straight when your emotions are in play. Such is the psychology of bug hunts.

    I started checking signals on the header and had trouble getting a good contact with my scope probe. I looked at the pin and there was some flux residue stuck to it. So I gave that part of the board a scrub with a fine brush and some solvent and then fired it up again to check that signal. Huh – now the audio is OK – clicks gone! WTF? I am still now sure what happened here – perhaps the brush dislodged a small short or the flux was conducting a little.

    So anyway the FXO module (fxomod) seems to work OK now.

    I then tried the FXS module and it worked on the first try. I was really happy about that – I was placing calls over it 5 minutes after the first time I applied power. Hardware development isn’t meant to work like that! Anyway I guess I will get my fair share of bugs later (it’s the conservation of bugs law), there is still plenty of development to go.

    My next step is to integrate the FXS and FXO modules with the 4fx board. More on that in a later post.

    This is what the whole thing looks like when put together with the STAMP, 4fx, and (for now) a single FXO module:

    The idea is that you can stack more 4fx boards to get multiples of 4 ports. You could also stack other cards, for example BRI-ISDN, E1/T1, or cards that give you additional DSP horsepower.

    You might have also noticed the SD-card. The driver for that was developed by Hans Eklund and the team at Rubico. They have done a fantastic job. I compiled the latest uClinux version with SD/MMC card support and it worked perfectly first time. It is really cool to read and write files to a SD card on the Blackfin, then transfer the card to a PC and find the files all there and readable. Such a simple hardware interface too (just a few wires).

    Geekiness is contagious. Just last week I convinced my wife Rosemary to help me with some board stuffing. I started here off on a simple thru-hole kit to teach here soldering. A few days later here she is soldering tiny 0603 resistors and doing a fine job:

    Thats all for now. I’ll might blog some more later as I work through the steps to bring up the rest of the board.

    Links

    1. Building an Embedded Asterisk PBX Part 2
    2. Building an Embedded Asterisk PBX Part 3
    3. More information on the Free Telephony Project here.
    4. Blackfin MMC/SD card how-to.
    5. More information on the design I am building here.
    6. Here is the (current) 4fx schematic in PDF form. It will probably change as the bugs are found and fixed.
    7. You can download source files for the schematics, PCB design, CPLD code here. Grab the latest hardware-x.y.tar.gz file. In the cpld directory there is a README that explains the CPLD code as well as “test benches” – Verilog code that tests other Verilog code.

    mortgage calculator rate loan 2ndremortgage http home advice uk loanloan abacuspayday loans 30 dayhour faxing loans no 1loan physician bank america$3000 loan credit with badloan education acsa bad loan with personal creditloan 1003 applicationdaphne pornporn daphnyporn vain star darienangel bio dark pornbbs porn darkporn collection dark bbsporn dark girlporn dark portal Map