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

Building a BlackfinOne

Over the past week I have been assembling, debugging and testing my own BlackfinOne board:

During this time I have had a lot of help from the BlackfinOne community, in particular via ongoing chat sessions with Wojtek (pronounced Voycheck) Tryc. Yesterday, I booted uClinux on hardware that I had helped design, soldered and debugged myself. A tremendously satisfying experience.

Building hardware is a bit like software – you go quickly through stages of construction; get stuck for a day or so on a tough bug; then rapidly scream through construction again until you hit the next bug. By documenting some of my experiences I hope I can help other people with similar projects.

The BlackfinOne

The BlackfinOne is a uClinux board based on the Blackfin DSP/RISC processor. There are several features of the BlackfinOne project that make it a great project for hackers:

  1. The design is open as in GPL. Free as in freedom/libre. Anyone can use, re-use, and modify the design, just like open source software.
  2. The BlackfinOne has been designed using the gEDA open source CAD tools. This means the design can be edited without needing expensive proprietary CAD software.
  3. Quite remarkably, it is implemented (and runs well) on a two layer PCB. To run a high speed digital design (it has a 400MHz clock and 133MHz bus) on a two layer board is generally regarded as impossible. Standard engineering practice says that you must have ground plane layers to ensure signal integrity and to make routing the PCB possible. For example the Blackfin STAMP designs uses 8 layers. The trick that the original designers (Ivan Danov and Dimitar Penev) used was to place the high speed SDRAM immediately behind the Blackfin chip, on the opposite side of the PCB. This minimises the length of the nets, ensuring signal integrity despite the absence of a continuous ground plane. Using two layers makes low quantity fabrication of the PCB cheap and easy for hackers compared to a multilayer PCB.
  4. A non-BGA version of the Blackfin was used to make soldering easy for hackers.
  5. It is based around the Blackfin community (sponsored by Analog Devices, the makers of the Blackfin chip) which has very good uClinux support and a range of open hardware building blocks (such as USB and other interfaces) for the Blackfin.

The initial BlackfinOne V1.0 design (by Ivan and Dimitar) first appeared in mid 2006. This design had SDRAM, Flash, and serial support. I was interested in using it as a DSP motherboard for my telephony work so I (along with several other people) helped add dual Ethernet ports and a USB port to create the BlackfinOne V2.0. Many other people (both commercial companies and private developers) have also contributed to the hardware and software side.

Several BlackfinOne V2.0 boards have now been made and brought to life by people all over the world. For the remainder of this post, when I say BlackfinOne (or bf1 for short) I mean BlackfinOne V2.0.

The schematics for the bf1 are useful to understand the rest of this post.

Building an Igloo JTAG cable

To bring up the BlackfinOne (for example to flash the boot loader) a JTAG cable is required. I built mine using some spare parts and a spare PCB I had laying around. I built a copy of the Igloo JTAG cable. My Igloo is not a shining example of hardware construction:

By the way I obtain the 3.3V power for the cable from the board being tested/flashed, rather than using the 5V to 3.3V regulator suggested in the Igloo design. A nicer version of the same Igloo circuit was constructed by Wojtek (pronounced Voycheck) Tryc:

I tested my Igloo using a BF533 STAMP board. The idea was to test the unknown hardware (my JTAG cable) using known working hardware (the STAMP). To drive the cable I used a version of the jtagprog software that has been modified slightly for the BF532 processor and BlackfinOne platforms.

It is important to use the CVS version of the jtagprog software as this has been modified to work with the latest versions of the BF532 chip. If you use the non-CVS version you may get a “stepping error”, which means the software doesn’t recognise this version of the BF532 silicon.

OK, so I tested the cable on a BF533 STAMP board and it seemed to work OK:
jtag> cable parallel 0x378 IGLOO
Initializing Excelpoint IGLOO JTAG Cable on parallel port at 0x378
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00110010011110100101000011001011
Manufacturer: Analog Devices
Part: BF533
Stepping: 3
Filename: /usr/local/share/jtag/analog/bf533/bf533
jtag> initbus bf533_stamp
jtag> detectflash 0x2000000

The last command “detectflash” gave me lots of information on the STAMPs flash chip. As a further test I also used the cable to re-flash a BF533 STAMP with a new version of u-boot. This proved that despite the rough construction my cable was OK (thanks Wojtek for this suggestion).

Other JTAG cables can be used as well, for example other developers have successfully used the JTAGblue cable which emulates very popular Xilinx Parallel – III.

For reference here is an example of a jtag session from a working BlackfinOne. However it took me a while to get that far, as described below!

Tools and Tips for Surface Mount Assembly

The BlackfinOne uses some fine pitch surface mount chips and resistors and capacitors in the 0603 size range. So you need to think a little bit about assembly.

To load my BlackfinOne I used a stereo microscope like this one in this picture (being used by my wife Rosemary whose brief geeky phase is regretfully now over):

I bought mine new for about $700 but there are very nice ones available on e-bay for about $100 up. A much cheaper alternative is an illuminated magnifier:

But trust me – a stereo microscope will change your (soldering) life once your buy one, it really is worth the investment. My eyes aren’t that great but I can work all day under the microscope with no problems or eyestrain. Mine is variable zoom 10 to 40x but I find even 10 x is just a bit too much and I never use the variable zoom. So I suggest fixed magnification in the 5 – 7x range is just right, however it’s a personal choice.

Wojtek bought this microscope for around US$100. He finds the fixed 15x magnification perfect for him:

If you can, get a microscope that has circular illumination all around the objective lens. Mine just illuminates from one direction which gives me shadows so I have to rotate the work a lot. For US$45 Wojtek found this great LED based circular light that clamps onto his microscope:

Here is a view through the microscope of one edge of the Blackfin chip. A sewing needle is in the picture for comparison.

Here is a similar image from Wojtek, through his microscope. You can just see how much fun we are having with the toys we bought for this project!

I found Darrell Harmon’s notes on surface mount soldering very useful. I bought the tweezers and flux that he recommends from Digikey and also strongly recommend them. The flux makes a very big difference in surface mount work, I have never really needed flux previously in through hole work. The flux really makes the solder “leap” onto the parts being soldered.

I also use and recommend the same procedure Darrel suggests for soldering 0603 parts; blob of solder on one pad, then slide the part in with the tweezers. Thanks Darrell.

Wojtek has also done some research on soldering irons, from a recent email:

There is 2 leaders: the Hako 936 and Metcal PS-800. The Metcal is very small, light (!) and reliable. The tips are hot in just few seconds, and are available in variety of sizes and temperatures. For most I use 650 tips, which are designated for non-RoHS components, for ground planes and headers, I use 750 – 1.5mm tip which makes it much easier (750 is RoHS temperature). The Metcal does not have a dial to change a temperature, you change it by replacing tips (2 seconds, pull and push operation). The Metcal is available from DigiKey at very competitive price.

Flux Removal is Very Important

As Darrell notes that Digikey flux is conductive, so you really need to get it all off ASAP after soldering or it will cause problems. For example I added some flux before soldering a 10M resistor (part of the bf1 clock circuit). After soldering, the resistance across the resistor measured only 340k! Some vigorous scrubbing with the flux remover and brush fixed it, and the 10M resistor once again measured as 10M. In one or two cases I have even had to remove parts as the flux was trapped underneath and not easily removed.

I use a spray can of solvent with a little brush attached to the nozzle for flux removal. Wojtek actually gave his BlackfinOne a bath (full immersion in water) with good results. Wojtek also uses this flux remover:

Both Wojtek and I have fixed many problems that were caused by flux left on the board. So Scrub-Scrub-Scrub that flux away!

From Wojtek:

It is critical to remove flux as soon as soldering is finished. Different methods could be used, solvents and a water bath both work great. But leaving flux on PCB for hours or days could potentially affect a board in a very negative way (possible even ruining it) – this stuff contains acid and is corrosive!

Initial Assembly and Smoke Test

I started with a bare PCB board, kindly supplied by Jeff Knighton:

I first loaded all the surface mount passives, then Blackfin chip, SDRAM, Flash and other chips. By loading the surface mount parts first the board was nice and flat and so easy to work with, especially under the microscope I use for surface mount parts. I loaded the large and bulky through hole passives last, as they prevent the board from sitting flat, hindering surface mount work a little.

My approach was to load various sections of the board progressively. For example I first started with the CPU and memory but left the Ethernet and USB ports unloaded for the initial tests. In hindsight I am not sure if this is a good idea, it is easy to miss something this way (like a pull up resistor you didn’t think you needed at this stage of construction).

If you are loading a V2.0.0 PCB it is important to read and fix BlackfinOne PCB Errors, this only takes about 10 minutes. These problems will be fixed on later PCBs.

After loading the CPU/memory section of the board here are the initial “smoke test” steps I when through:

  1. I checked my parts orientation against the reference photos of the BlackfinOne, for example I made sure that the writing on my chips faced the same way as the photos. Especially that damn expensive 64M SD-RAM chip.
  2. Before powering up I checked the resistance between the 3.3V rail and ground. About 300 ohms, which seemed OK. I would have been worried about a dead short.
  3. The next step was to apply power and sniff for that familiar smell of molten silicon. I used a variable power supply first with the current limit set to 100mA. Just in case I had done something stupid (a common occurrence). Mmm, no smell. Feel the top of all chips, no burnt fingers. Excellent. A better start than most projects.
  4. I measured the 3.3V rail to make sure the switching power supply came up OK. Check.
  5. Measured the 1.2V rail – this was present which proved that the Blackfin chip was doing something, as the Blackfin contains the switching power supply circuit for the 1.2V rail.
  6. With the scope I checked that the 10MHz system clock was present. Check, another sign of Blackfin life.
  7. Check reset line is H. Ooops, it’s stuck L. That means the system will be held in reset forever!

I took me a couple of hours to find the reset problem. The capacitor C53 that sets the duration of the reset pulse wasn’t fully charging due to some residual flux on the board. I gave the reset part of the board a good scrub with the solvent and reset started working OK.

Programming the CPLD was fairly straight forward – I used the Verilog file bf1_cpld.vl from the hw-0.1 CVS repository. This needed to be renamed to bf1_cpld.v for my Xilinx synthesis tools to understand it and don’t forget to include the pin locking file bf1_cpld.ucf when you synthesise the design. Free (but not open) synthesis tools are available from Xilinx for Windows or Linux. I used an ancient Windows version and a serial JTAG cable to program the CPLD.

To save time, you are welcome to use my xlinx_bf1.jed file, just program the CPLD using your Xilinx JTAG cable.

Flash Problems

The next step was to connect the JTAG cable to my BF532 and try to flash the board. This is a “nervous” step – it’s the first time you actually get to see if the Blackfin chip is responding via the JTAG port. It’s also where you find out if you have soldered any memory chips on backwards.

The jtag tools detected the BF532 OK:
jtag> detect
IR length: 5
Chain length: 1
Device Id: 01010010011110100101000011001011
Manufacturer: Analog Devices
Part: BF533
Stepping: 5
Filename: /usr/local/share/jtag/analog/bf533/bf533

Note that the BF532 is detected as a BF533. This doesn’t seem to matter in practice.

However when I tried the next few steps:
jtag> initbus bf532_bf1
jtag> detectflash 0x2000000

It couldn’t find the flash chip.

My first suspicion was the CPLD, maybe I had messed up something like the pin locking and the control signals like AOE and FLASH_CS weren’t getting through to the flash chip. So I checked the control signals by watching them on the scope while I tried to read words to the flash:
jtag> peek 0x20000000
The signals were asserted when I did the read which suggested the CPLD was OK.

I then checked out the flash data sheet to work out how it should be responding. The flash chips have state machines built in, you can send commands to them and they respond in certain ways. One of the commands can tell you all about the flash chip. This is what JTAG tries to send when you run the “detectflash” command.

You can generate these commands and read response to the flash chip using the jtag peek/poke commands. For example on the BF533:
jtag> poke 0x20000055 0x98
jtag> peek 0x20000020
bus_read(0x20000020) = 0x00000051 (81)

Writing 0x98 to 0x55 on the chip (mapped to 0x20000050 on the bf1) puts the chip into “common flash interface” mode. In this mode, address 0x20 should always return 0x51 (the letter Q in ASCII). This is a good way to test if the Blackfin is talking to the Flash chip OK.

The same flash command/response on the bf1 showed just 0xff responses, which suggested either the command wasn’t getting through, or something was wrong with reading the response. I had already checked the control signals, so the next step was to check the address and data bus. Damn. This meant 32 nets to manually check.

To check the electrical connections of each net I used two methods:

  1. Under the microscope, I applied gentle pressure to each pin with a sewing needle. If the pin moved when I applied pressure, it would indicate a bad solder joint. This check didn’t find any problems.
  2. I then tested the continuity of every solder joint on the major chips using my multimeter. I placed one probe on the top of each pin, and the other on the pad it was soldered too. This is tricky to do on fine pitched pins, so I improvised some fine tipped probes (see below)!

While I was checking some pins on the SDRAM I accidentally touched two adjacent pins (pins 1 and 2) and my multimeter went “beep”, indicating a short. Hmmm, that doesn’t look right. Turns out that the D0 net was shorted to VCC, which was why the flash chip wasn’t responding. Any commands were being mangled as D0 was stuck H.

I spent an hour trying to work out why. It could be a soldering error or a PCB fault. However the track in question lives mainly under the the Blackfin and SDRAM so there was no way to check it visually without removing these chips, something I don’t have the tools for.

I used my multimeter to measure the resistance of the short. It was 0.4 ohms between VCC and D0 near the SDRAM, but 0.8 ohms between VCC and D0 on the flash chip. This suggests the short was nearer the SDRAM, right where I couldn’t get to it.

Fun with Burning Out Shorts

One fun technique I tried was to burn out the short. I have used this technique before on production PCBs that have shorts. You apply a high current (Amps), low voltage (say 0.5-1V) across the short and try to burn it out. Literally. You sometimes even hear a nice crack. It is safe for the logic chips as the low voltage means they won’t conduct any significant currents. It works best with shorts that measure a few ohms. Small enough to pass lots of current so they get hot, but larger than the parts of the track you want to keep. Too small and you risk burning out the wanted part of the track. To large and it won’t get hot enough.

Anyway, it didn’t work this time, the short passed 3A happily and I wasn’t going to risk going higher in case I vaporised the whole D0 net! So I cut out the offending parts of the D0 net and replaced them with some fine wire. Ugly, but when I fired up jtag again and there was my flash chip! Whew. Problem fixed after a day bug hunting. On to the next one.

Bug Hunts and the Geeky Mindset

If all the above sounds very cool and logical rest assured it wasn’t.

When you are in the middle of a bug hunt two things happen.

The first: the logic centres of your brain shut down. You don’t think straight. You bounce from one theory to another.

The second: you don’t want to work on anything else. You get obsessed and can’t leave it alone. Worse, doing anything else is impossible. Intense bug hunts lead to late nights, neglect of significant others, no exercise, fatigue and a further dip in intellect.

Despite all that, I really enjoy a good bug hunt. When you come through at the end, the satisfaction is supreme. And you always end up learning lots along the way that comes in useful later. Call me a geek, call me a nerd, or call my wife and commiserate with her.

Flashing problems

This was an strange one. Now that jtag could actually see my flash chip I tried to flash the chip:
jtag> cable parallel 0x378 IGLOO
jtag> detect
Jtag> initbus bf532_bf1
jtag> detectflash 0x20000000
jtag> flashmem 0x20000000 /path/to/u-boot.bin

However I kept getting verify errors. Whole sectors of the flash (each sector is 64k long) were not being written. I tried a few things like checking the JTAG signals for ringing (they were OK) and shortening the JTAG cables just in case I has signal integrity problems like ringing on the JTAG clock signal. Still verify errors.

Each attempt was very time consuming as flashing via the JTAG is slow, it takes about 20 minutes to flash the 128k u-boot program.

I was in chat contact with Wojtek at this time and he suggested I try the Igloo JTAG cable on a STAMP board. So I tried flashing u-boot onto a BF533 STAMP and it worked fine. U-boot even ran OK on the STAMP. This was a good test as it confirmed my Igloo was OK. One variable removed from the bug hunt.

So then back to the bf1 board. Suddenly it is now flashing OK! Despite nothing changing. So I tried it three more times and each time it flashed and verified OK. So I don’t know. It doesn’t always boil down to logical cause and effect. Sometimes stuff just happens. So I “declared victory” and moved on.

Now I had u-boot starting up OK when I powered up – I could interact via the serial port. This was pretty exciting, as it proved that all the major components – Blackfin, flash, SDRAM, and CPLD were working fine. The bf1 was talking to me. So I powered down and soldered on all the parts for one Ethernet port. The idea was to use Ethernet and tftp to download a uClinux image.

Torpedoed by U-Boot and Ethernet

After loading the Ethernet parts I booted into u-boot and tried to tftp. Something was happening, but there were lots of tftp time out “T” symbols and only the occasional OK packet. Ping worked OK from u-boot, but not tftp or dhcp.

I did some packet sniffing on my host and found out that packets were being received OK from the bf1, but it looked like anything the host sent back was being ignored by the bf1. So I checked the rx side wiring of the Ethernet port but couldn’t find any problems. During tftp attempts I could also see what looked like valid Ethernet signals (1Vpp nice looking data signals) on the tx and rx nets at the RJ45 connector.

I was using a binary u-boot image that I found on the bf1 site. I wanted a way to inspect packets being received and that meant I needed to compile u-boot from source. So I checked out the CVS version of u-boot for the BlackfinOne and tried to compile. However I kept getting linker errors. This is very frustrating, you are trying to fix one bug and keep getting caught by others! Such is life.

Eventually a post to the bf1 forum solved the linker problem – there was a recent bf1 u-boot fix just checked into CVS. Now I could compile u-boot and start inserting some test code. So I flashed the CVS version of u-boot and hit another problem – now Ethernet wouldn’t work at all (not even ping) and the MAC address was always a string of 0x00s. This was a step backwards from the previous binary where the MAC was set up OK and at least ping worked!

One other problem was slowing me down – that 20 minute time it took to flash u-boot every time I wanted to add a printf to test something. This made debugging very tedious and frustrating. It felt like I was getting no where fast.

One thing I did discover is that it is a good idea to erase the flash sectors before flashing using jtag, just to make sure:
jtag> eraseflash 0x20000000 2
When I didn’t perform this step I sometimes found I was booting a previous version of u-boot, not the one I had just flashed!

After a break I thought of another idea to help speed up debugging. I used a trick I read about in the Blackfin u-boot documentation – you can download a new u-boot image into SDRAM using u-boot, then execute the new u-boot image using the “go” command. As I didn’t have Ethernet working I used ymodem to download u-boot images to SDRAM. This worked really well and enabled me to test and debug in 2 minute cycles – much faster.

Note that this technique doesn’t work for all u-boot images, for example when I tried to run a u-boot image configured for 64M RAM with a 32M u-boot it failed and I needed to reflash instead. Some people have reported that ymodem doesn’t work for them, they use the kermit protocol instead.

Two iterations later I had the bug nailed. The problem was that u-boot was trying to read the MAC from the little serial EEPROM used by the Ethernet chip. However I hadn’t loaded this chip, and even if I had it would be un-programmed and the MAC would be all 0xff’s. So after some reading and grepping of the u-boot source I changed this line in include/configs/bf1.h from:
This allows the MAC to be set by the values compiled into bf1.h, or the environment variables used by u-boot. If this option is defined then the eeprom contents always overrides the MAC from the environment.

Suddenly my u-boot Ethernet was up and downloading images via tftp just fine. Cool. After 1.5 days of chasing this bug it never looked so good to see those tftp “*” symbols flashing across the screen as an image was downloaded. I also learnt a lot about u-boot and how Ethernet drivers work which was interesting.

So now we are getting real close – time to build a uClinux image!

Building uClinux for the BlackfinOne

To create a uClinux-dist for the BlackfinOne I copied all of the files in
on top of a fresh 2006R2 Rc5 uClinux-dist using “cp -R”.

This was set up for the jffs2 file system, however I wanted to try a ramfs config as I was more familiar with that from my STAMP work. This was probably a mistake, as I spent several hours working out how to get this working. uClinux was starting OK but kernel panicking when it couldn’t mount root. I was using the u-boot command:
bf1> tftp 0x1000000 uImage
bf1> bootm 0x1000000

To download and boot the uImage. The uImage file combines the kernel and the root files system in one compressed image.

At Wojtek’s suggestion (again via chat) I compared the boot sequence of the bf1 to my STAMPs. I noticed something odd about the Memory Map section of the boot sequence. When I booted the STAMP I was getting something like this.
Memory map:
text = 0x00001000-0x00107f94
init = 0x00108000-0x00115508
data = 0x00115b4c-0x00145e60
stack = 0x00116000-0x00118000
bss = 0x00145e60-0x00153394
available = 0x00153394-0x03800000
rootfs = 0x07700000-0x07f00000
DMA Zone = 0x07f00000-0x08000000

Note the “rootfs” line. This says that 8M is allocated to the rootfs. This was the BF533 STAMP, which has 128M available, which means the top address is 0x8000 0000. Note that the “available” memory is about 57M. Now when I compared the rootfs line for the bf1, I saw:
rootfs = 0x00600000-0x001f00000
Which is 25M allocated for rootfs. Now at this stage I only had my bf1 configured for 32M, so that rootfs was consuming most of the available memory. In fact when I checked the available line, only 416k was free for the entire operating system! I traced the problem to the vendors/IvanDanov/BLACKFINONEV2/Makefile. The BLOCKS line that controls the size of the rootfs was set to 25600 rather than 8000. As I mentioned earlier, this is only really a problem if you are using ramfs.

I changed the line back to BLOCKS=8000, rebuilt the uImage and managed to (finally) boot uClinux. So I ran around the house telling everyone but nobody cared much (except my baby son, as discussed below). Oh well, it still made my day!

A little more work to u-boot and kernel configuration and I had a 64M BlackfinOne booting OK. Wojtek showed me how to configure u-boot for 64M:

  1. In board/bf1/ make TEXT_BASE = 0x03fe0000.
  2. In include/configs/bf1.h set the #define CONFIG_MEM_SIZE to 64.
  3. make mclean;make mrproper; make bf1_config;make.

To configure uClinux for 64M “make linux_menuconfig and set “Blackfin Processor Options – Use SDRAM chip” to your memory chip, then rebuild uClinux-dist with the usual “make”.

If you have built a 64M BlackfinOne you are welcome to try my u-boot and uClinux uImages. They might be useful for initial testing and save you the steps of compiling your own. Once you have flashed u-boot-bf1v2-64M.bin, place uImagebf1v2-64M on your tftp server and on the bf1 console:
bf1> tftp 0x1000000 uImagebf1v2-64M
bf1> tftp 0x1000000

Note that this uImage uses ramfs not jffs2, and I used the -75 memory chip. This should work OK with the slightly faster -7E chips.

While experimenting I noticed that you need a u-boot configured for 64M to boot a 64M uClinux, otherwise uClinux bombed for me shortly after the uImage was uncompressed. However you can boot a 32M linux using a 64M u-boot.

I set the Ethernet MAC and IP for uClinux using environment variables in u-boot that are passed to uClinux, using the addnet script:
bootargs=root=/dev/mtdblock0 rw
addnet=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:off
flashboot=run addnet;bootm 0x20040000

Flashboot is called when the bf1 starts, which calls the addnet script, and boots uClinux. I would rather have u-boot set just the MAC and let uClinux set the IP through /etc/rc, however I haven’t worked out how to do this just yet.

Open Hardware

The BlackfinOne project is a great example of open hardware development. There is a growing community of developers that have contributed to hardware, software, and even tracking down problem parts for each other. There are parts being air-mailed all over the world as one person helps another get parts that are tough to find in their country. An interesting example of open/community development being applied to hardware – obtaining parts is not a problem for open software development!

Web-based parts supply companies like Digikey have helped make this sort of project possible. You can now easily buy many obscure parts and get them delivered anywhere in the world in a week or so. The web has helped hardware hacking get easier, and made it possible to build complex, sophisticated designs like the bf1.

Chat and mailing lists proved invaluable. Wojtek and I were in constant chat contact, and we used the bf1 forums to help us when we got stuck. Even though at this time of year we are about 12 hours apart in time (and about 40 degrees C in temperature). Just being able to explain each our problems was very useful – it made the problem clear in your own head when you have to express it to another person. I have been developing hardware for about 20 years and this as truly a new way of working for me. Nothing new for software development I guess, but very different for hardware (at least for me). In my experience (mainly in smaller companies), the hardware guy has often worked more or less alone.


This has been a really great experience. I assembled my very own uClinux hardware, then brought it up through various stages until it booted. I still can’t believe that I actually soldered together my very own Linux machine! If you are interested in trying out a hardware project, I thoroughly recommend this project. Great design, great community. Open hardware in action.

When I told my baby son about my working BlackfinOne, this was his reaction:

I know exactly how he feels!


Wojtek for your review of this post and photos.

amount interest negative loan of capitalizationloans 10 dollar paydaypayday law 10 new 15 loan100 payday loan faxemergency 1000 loan1000 loan business opploan no check credit 10000il equity 125 value home loan Mappanasonic ringtone 55 gdmobile ringtone t 6010ringtone ppc sprint 6700ringtone nextel 7100ito how ringtone 8125911 ringtone 69999a 670 ringtonesyour a900 make ringtones Mapringtones chocolate to lg convertcool metallica ringtonescountry ringtoneringtones crazy freecreate ringtones free share andcreate ringtone my owncreate cellular us for ringtonesmidi ringtone creating Map

EMI Testing 101


Electromagnetic Interference (EMI) testing measures the amount of energy your electronic product radiates. If it radiates too much EMI, it might interfere with other products, for example a PC with bad EMI might make it hard to use your radio or cell phone.

EMI is a growing problem, as most devices contains some sort of computer, and the frequencies of clock signals are rising all the time. All those fast signals can potentially create lots of EMI.

EMI tests can be a stressful time in the product development cycle. These tests are usually occur right at the end, when the budget is blown, you are overdue and you need to get that product out the door “or else”. They are expensive (especially for small companies) and are “make or break” – a failure could send you back to the drawing board to redesign the printed circuit board costing months of development time.

My EMI Testing Experience

There are certain standards that you need to meet for EMI. In October 2006 I attempted to obtain US/Australian/European EMI compliance for the following system (the 4fx telephony boards combined with a BF537 STAMP):

The tests were performed by Austest, in their Adelaide Labs. The US standard for EMI is known as FCC-15. The Australian/European standards overlap in most areas so can be performed at the same time.

The idea was to use the STAMP (an off the shelf development board from Analog Devices) plus my 4fx daughter board to get a first pass product “to market” quickly, without the engineering effort required to develop our own Blackfin motherboard. This would be a a good way to get the technology into real world use quickly. We could then follow up with a lower cost/volume manufactured custom motherboard.

Unfortunately, I flunked part of the tests. Below I describe why I flunked and how I traced the problem. I have got to admit that this hurts – these tests cost me around US$3,000 out of my own pocket! However maybe by blogging on it I can share some of the experience I gained and help share some of the value from the tests.

This means that we can’t use the STAMP/4fx combination for a real-world, volume manufactured product, although it’s OK for “test and evaluation” (the EMI standards generally have exemptions for development work).

The good news is the telephony daughter board looks good from an EMI point of view – it was the STAMP board that was radiating too strongly to meet the requirements of FCC-15. So with a Blackfin DSP motherboard designed to minimise EMI we should be able to eventually pass the EMI tests OK.

The EMI Test Procedure

The EMI tests are designed to accurately measure radiation from your product, called the Equipment Under Test or EUT. Radiation can come from a variety of sources:

  1. Any cable connected to your device can act as an effective antenna under the right circumstances. For example power cables, Ethernet, and phone cables.
  2. The Printed Circuit Board (PCB) can also radiate directly. High frequency currents can flow around the board, for example from a clock oscillator through the power supply rails. If the loop area of the current is large (say due to the PCB layout), it may radiate EMI.

The FCC-15 tests are divided into two sorts of tests, designed to pick up EMI in different parts of the spectrum:

  1. Conducted tests, where voltages conducted down the cables are sampled.
  2. Radiated tests, where the actual radiation of the EUT is measured using an antenna.

Conducted tests

Conducted tests are used for lower frequencies (150kHz to 30MHz). Low frequency signals have long wavelengths. At these frequencies it’s easier to determine if the EUT is likely to radiate by sampling the voltages on the cables connected to the EUT, rather than say using an antenna. Otherwise you might need very large antennas (like several km long) to be sensitive to radiations at low frequencies. Common problem at these frequencies are switching power supply noise. For example those big lumps in your power supply cables are ferrites that are designed to block power supply noise travelling down the power supply cable.

The conducted tests were performed inside a shielded room. Note the careful arrangement of the EUT, wires were connected to all ports to simulate real world operation. Any little change in this configuration could change the EMI signature.

To sample the signals special boxes are used that are carefully calibrated to sample any EMI signals on the Ethernet/telephone/power cables without affecting normal operation:

The signals detected by these boxes are fed to a spectrum analyser – a device that can measure the EMI energy in various parts of the spectrum and determine if it is above or beneath the required levels.

The levels for the conducted tests were sampled from the power, Ethernet, RS232 serial, FXS and FXO ports and found to meet the requirements. All well and good, so on to the radiated tests.

Radiated Tests

For higher frequencies (30MHz to 1.5GHz in this case), an antenna is used to directly sense EMI from the EUT. The test lab I used have an outdoor test site:

Outdoor test sites tend to be in relatively remote locations, away from any ambient sources of radio waves that might interfere with the tests. You can see that this site is in a valley, with only a few houses in sight. The sites are carefully calibrated each time they are used to make sure there are no new sources of “ambients”.

The EUT is placed on a rotating table, so its EMI radiation can be measured at different angles:

A very special (and very expensive) antenna is used to sense the EMI radiation. This is carefully calibrated and has a known response across the frequencies of interest:

Below is an example of the typical test results. This graph measures the level of EMI energy between 30MHz and 1500MHz. Click on the image to get a larger, more legible version.

The green line shows the background (or ambient) radio signals at the site, the black line shows the combination of ambient plus the EUT. The red and blue lines show the permissible limits.

During the tests the antenna is moved up and down, and the EUT table rotated to maximise the signals from the EUT at various frequencies. The EMI signature tends to vary a lot with orientation and antenna height.

It was here that we hit some problems – the EUT was radiating a very strong signal at 300MHz – far exceeding the level allowable by the standard. The 300MHz signal was about as strong as a small radio transmitter (for example like one used to open your car doors)!

By a process of elimination we tracked the problem down to STAMP board itself. When all the cables (except power) and the telephony daughter boards were removed the STAMP sat there radiating approximately the same signal at 300MHz.

After a few hours of attempting to reduce the EMI level at 300MHz (for example shielded boxes, and metal plates under the STAMP board) we called it a day – the signal was just too strong to be easily fixed.

I guess the good news was that my telephony boards were fairly clean – telephony boards often have problems with radiation from phone cables (they make good antennas for EMI). However adding and removing the daughter boards and phone cables didn’t have much effect on the EMI levels.

Somewhat (OK very) disappointed, I retired to home base to think about the problem and do some tests.

Now I should emphasise that the BF537 STAMP board was not designed for EMI compliance, rather it was optimised for development purposes. These two requirements are at odds, for example on the STAMP all of the high speed address/data bus nets are routed to headers, which means lots of extra high speed nets on the board, all potential EMI radiators. In a commercial, FCC-15 compliant design, the number and length of high speed nets would be minimised. I was just hoping that the STAMP would be FCC-15 compliant and therefore suitable for early deployment of my telephony systems. So I took a chance and messed up. My mistake.

However I learnt a lot and had fun tracing the source of the EMI, as described below.

The Elusive EMI Bug Hunt

To track the problem I built a little sniffer probe: two turns of wire connected to 50 ohm coax. I viewed the signal from the sniffer using a 500MHz scope with the input set for 50 ohm termination. One handy feature of my scope was a FFT function – this let me see the 300 MHz signal on a frequency scale. I could also see the signal on the regular time domain display when the sniffer probe was close to the STAMP.

When placed near the STAMP PCB a very clear 300MHz signal can be seen. The level of the signal varies as the probe is moved over different parts of the board.

Here is a picture of the sniffer probe in action. It is like a poor antenna, that picks up EMI from just a few cm away – useful for localising the source of the EMI on the PCB.

Here are the initial results:

  1. I found that the 300MHz noise was all over the ground plane, but is not present in the power cable. This suggests that the noise is not being radiated by the power cable.
  2. I found peaks in the signal level over the SDRAM chips. This is expected, as there is a 100MHz bus connecting the SDRAM chips to the CPU, which means lots of digital noise.
  3. Curiously, I found another big peak over the “Blackfin” graphic (see photo above). This peak was not expected, as there were no parts loaded on this part of the PCB (on the upper or lower side).

Now 300MHz is the 3rd harmonic of the 100MHz bus frequency. Digital signals are square waves which are made up of odd-harmonics of the square wave frequency, so from a 100MHz bus we would expect to see energy at 100MHz, 300MHz, 500MHz, etc.

I guessed that the 300MHz signal was a harmonic of the 100MHz bus that for some reason was radiating effectively from the PCB. To test this theory I changed the bus frequency to 125MHz, and saw the strong signal at 300MHz shift up to 375MHz. So it looks like the source of the EMI is the bus.

Now to radiate EMI you need a signal source (the bus in this case) and an effective antenna (for example a cable around one quarter of the wavelength or a current loop of similar size).

I suspect the PCB has a resonance at around 300MHz. This would explain why the signal is so strong at 300MHz but the fundamental (100MHz) and 5th harmonic (500MHz) are not visible on the scope.

At 300MHz, a good 1/4 wave antenna would be 25cm long – close to the length of the board. There could be AC currents travelling over tracks of that length of the PCB board.

Splits in PCB Power Plane

Fortunately the STAMP designs are all open. I therefore inspected the BF537 STAMP Gerber files, which are available from the Blackfin site. Gerber files are the graphics files that define the Printed Circuit Board (PCB) layout. They are the files you send to the PCB house to get your boards made. The BF537 STAMP board is an 8 layer design.

There is a very nice Linux Gerber viewer program called gerbv that comes with the gEDA tools that I have used to design the 4fx hardware. To view the Gerber files I unzipped the STAMP Gerbers then ran gerbv:
$gerbv *.pho&

I took a look at the PCB in the area of the Blackfin logo:

The image above has the layer 0 (a signal layer) and layer 1 (VCC power plane) displayed. Layer 0 has some wiring for high speed signals. Layer 1 is the VCC plane and is split into areas for each VCC rail (5V, 3V3, 1V2 etc).

Now remember that my sniffer found a peak over the Blackfin logo – this area is the rectangular box in the image above. Curiously, this area corresponds to a split in layer 1, the VCC plane.

High speed digital signals like to take the path of least impedance, i.e. the most direct path (Note: see comment below by Icarus75 on this). They tend to flow out of a pin, along a net, then back through the ground or power plane to the ground pin of the chip generating the signal.

A split in power or ground plane causes the signal to take a longer path (it must flow around the split), causing the total loop area to increase. Signals flowing through large loop areas make good antennas for EMI.

If layer 1 is placed directly under Layer 0 it will not be doing a good job as an signal return path – the splits will cause signals to take big detours, with large loop areas, and generate lots of EMI (plus possibly other high speed digital issues).

To minimise loop area (and hence EMI) you really want a continuous plane (VCC or GND) under any high speed nets.

So my theory is that the EMI is being caused by having a split power plane directly beneath a high speed signal layer, i.e. the problem may be the PCB layout, or more correctly the ordering of the layers in the PCB. This theory is supported by the high level of the problem 300MHz signal found over a split in the VCC plane.

Next Steps

The next step is to design a new DSP motherboard that is FCC-15 compliant. As a first step I have been working with a team of open developers on the BlackfinOne project. This is Blackfin DSP motherboard, designed using the gEDA open CAD tools by a community of developers. This design has been customised a little for telephony work and some steps have been taken at the design stage to minimise EMI. Several people in the BlackfinOne community now have this design up and running.

When I have loaded my BlackfinOne, I will do some preliminary in-house testing of the design before determining if the board will be submitted for FCC-15 testing. It is possible to construct some test jigs to do preliminary EMI testing outside of the EMI labs. Although uncalibrated, it should be possible to determine if there are any serious problems. More on this in another post!


Thanks to Paul Kay at Austest for patiently explaining to me the issues involved with EMI. Despite the poor results, he made the two days we spent testing enjoyable and a fascinating learning experience!
movies gay boyinteracial samples moviesexy movie scenesteen movies nudevintage movies sexxxx movie clip sampleselectra movies sex carmensapphic exclusive movies Mapabet universities crediteds crisis farm credit 1980rental laptop addwords apr creditcredits 50 music dates first200 child credit ontario50 first dates music credits2b whiskey credit lullaby videoloans balloon 2 28 Map

Open Source Echo Canceller Part 1


For the Free Telephony Project I have an embedded version of Asterisk running on hardware that supports several FXO and FXS ports. I need a line echo canceller that can handle echo on typical FXO and FXS ports. As a starting point I am using the echo canceller software included in the Zaptel device driver package.

However on my FXS and especially FXO ports, this echo canceller is not working too well. This seems to be a common problem with Asterisk using the the Zaptel echo canceller, and there is quite a lot of content on the web dealing with how to optimise the Zaptel echo canceller using various tweaks.

The Myth of Hardware Echo Cancellation

Currently, the best solution to echo is to use a “hardware” echo cancellation rather than the Zaptel “software” approach. Hardware echo cancellation uses DSP chips from companies like Octasic which contain embedded echo cancellation firmware. Several board manufacturers have added hardware echo cancellation as an extra price option. Of course, this “hardware” solution is really just proprietary DSP software that works better than the current Zaptel software.

One distinguishing feature of hardware echo cancellation is that it “just works”. When enabled, echo just goes away, apart from perhaps a second or two at the start of a call. Contrast this to the current Zaptel software echo canceller which often requires experimentation with many options, and in some cases cannot be made to work at all.

There is no fundamental reason why an echo canceller running in software cannot perform as well as a “hardware” echo canceller on a DSP chip. In fact, there are several advantages to a pure software approach such as simpler interfacing and lower cost. Why pay $400 – or thousands – (in the case of a few of the high end products) extra for “hardware” echo cancellation if your current PC can cancel echo at no extra cost? To prove this point Pika Technologies have implemented host based echo cancellers purely in software that work very well.

The real reason behind the myth of hardware based echo cancellers is the lack of an open source echo canceller that “just works”.


I must admit that I am no stranger to echo cancellation problems. I have worked on line echo cancellation several times over the past 15 years and have never really developed a canceller I was happy with. Like the Zaptel guys, I ended up with code that worked some of the time and needed a variety of tweaks and tricks like manual adjustment of gain parameters.

It’s a tough problem to develop a canceller that “just works” without lots of tweaking. I have a great deal of respect for the people who have worked on the Zaptel echo canceller, as I understand how hard it is to write this sort of software.

I would like to try a new approach. I want to get the open source community to help, rather than trying to solve the problem by myself. You can help by sampling your nasty echo problems and sending them to me. We can build a database of echo problems and use this to develop an improved algorithm.

I am also in contact with a few very bright DSP guys who are interested in helping. Unlike me, they have implemented successful line and acoustic echo cancellers in the past. So together I think we can develop an improved open source line echo canceller.

Getting under the Hood

To debug a program we need to look at it’s inputs and outputs. This is a little tricky with a real time echo canceller, as all the signals are processed in continuous streams. It’s not always possible to set a break point and look at the variables. So I have hacked the zaptel.c driver to sample the echo canceller signals and dump them to files. The idea is we can then look at the signals in the files and figure out what’s going on.

Here is the test set up:

The hybrid is an electronic gizmo that is part of your analog line interface hardware. It combines the separate transmit (tx) and receive (rx) signals onto one two-wire pair. In the receive direction, it’s job is to separate the combined tx rx signals and extract just the receive signal.

Lets say you transmit (tx signal) the words “ONE..TWO..THREE”. This gets sent down the phone line by the hybrid but a little bit gets reflected back “one..two..three” in the rx signal. This is the echo. In an ideal world no tx signal would get reflected back but due to real-world imperfections you always get a little (or a lot) of echo. The idea is that the echo canceller then cancels out the echo, leaving………silence (the ec signal).

So we have three signals going to/from the echo canceller:

  1. tx: the transmitted speech we are sending down the line (listen).
  2. rx: the received signal, which will contain the echo (listen).
  3. ec: the (hopefully) echo cancelled signal (listen).

If you listen carefully to the ec sample above you can hear the echo canceller slowly converging, by the time we get to “four” the echo level is significantly reduced.

So lets take a graphical look at the Zaptel echo canceller in action. Here is a plot of the words “one….two” from a FXO port connected to an Australian PSTN line. On the call I could clearly hear the echo of my own voice. Click on the image for a larger version.

You can get a feel for the performance of the echo canceller from this plot:

  1. The echo signal (rx) is quite a bit smaller than the transmit signal (tx). This is usually the case, unless your hybrid is way out.
  2. However look at the echo canceller output (ec). On the first word the level of this signal is about the same as rx (as the blue (ec) completely covers the green (rx)), which indicated not very much echo is being cancelled.
  3. It gets a little better on the second word, now the echo canceller has adapted to the echo a little, and the ec signal is at a slightly lower level than the rx signal. However this suggests the convergence of the echo canceller is slow, as it has not completely cancelled the echo yet.
  4. What we would like to see is the blue ec line to be completely flat – this would indicate that all the echo has been cancelled at the echo canceller output.

Sampling Echo Signals

The software to perform the sampling is called sample. Sample captures the real time echo canceller signals from a running Asterisk/Zaptel system to disk files. You can sample echo on an Asterisk system equipped with any zaptel compatible hardware. It works like this:

  1. Patch the zaptel driver as described in the README and start Asterisk.
  2. Using Asterisk set up a call through the FXO or FXS port you wish to sample. For example I set up a SIP-FXO call.
  3. Make sure there is no other receive signal on the line apart from the echo. For the FXO port I set up a dialplan to simply get an outside line “exten => 9,1,Dial(Zap/1)”, I then hit a DTMF key like 5 which causes the CO to stop the dial tone. For a SIP-FXS call I mute the phone on the FXS side.

When you are ready to start sampling:
[root@homework zaptel]# ./sample /xhome1/tmp/fxs 1 5
sampling Zap/1...
[root@homework zaptel]#

In this case it samples 5 seconds from Zap/1. While it is sampling I said “one..two..three….” into the SIP handset to generate the tx and rx signals. I could clearly hear echo coming back. Running sample generates the three sample files:
[root@homework zaptel]# ls /xhome1/tmp/fxs*
fxs_ec.raw fxs_rx.raw fxs_tx.raw

The files are in 16 bit signed short format, sampled at 8 kHz. You can listen to the samples on your sound card using the sox utility play:
# play -f s -r 8000 -s w fxs_tx.raw
If all is well the rx file should be quieter than the tx file. The ec file will be silent if your echo canceller is working, otherwise you will hear the uncancelled echo. You can plot your results you can using GNU Octave and the pl.m script:
octave:1> pl("/xhome1/tmp/fxs")
You can zoom in on certain parts of the waveform:
octave:6> pl("/xhome1/tmp/fxs",16000,20000)
which produced the plot below (again click on the image for a larger version):

In this case you can see the echo canceller is doing a better job. In the second half of the word the blue (ec) line is very thin, showing that the echo has been cancelled. The first half is not so good, once again the blue ec is overwriting the green rx indicating poor cancellation. The first half of this word (the “t” sound in “two”) consists of a noisy waveform, this has significant high frequency content. This suggests the echo canceller hasn’t converged as well for high frequencies as it has for low frequencies.

The cool thing about sampling this way is that it doesn’t interfere with your running Asterisk system. If you hear echo at any time you can fire up a console and run “sample” to capture real-time data from the Zaptel port.

Next Steps

Next I would like to write a command line program to run the Zaptel echo canceller in non-real time, using the sampled tx & rx files as inputs. This simulation version of the echo canceller will be easier to work with compared to running the same code in real time. For example we can set breakpoints, stop/start at will, and dump internal states to files for further analysis.

If you would like to help develop an open source echo canceller, please collect some samples and send me you echo samples! I would welcome any samples of your echo signals, for example where the echo canceller isn’t working well, and also cases where it does work well. By comparing the two cases we can learn a lot about the strengths and weaknesses of the algorithm.

Please name the sample files in a way that is unique, for example if your name is Charlie Brown “fxs_charlie_brown_line_1_tx.raw” and email the files to me.

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 2 – How Echo Cancellers Work
Part 3 – Two Prototypes
Part 4 – First Calls
Part 5 – Ready for Beta Testing


Thanks Mike Taht and Wojciech Tryc for helping me with this work and blog post.
auto after loan bankruptcyloan ahard moneyloan mortgage alabama secondhome loans mortgage alaskaloan american dream homereport $1000 loanloan personal 000 10100 rv loans Maptorrent porn sites bitwork pornsite at bitchesporn bitingpirates porn bittorentporn bittorrent andporn search bittorrentbizar porn trailersadult pornography bizarre Mapbest rates loan constructionbest loan home interest equity rateshome washington rates best loanfor best home rate loans interestpoor places with loan credit bestlowest best rates possile loan autofor loan best car rateroadloans business bureau better Mapvideo devon pornporn free devon vidsvideo free devon pornstarporn dhakadhild images pornagraphydia star pornblack porn star diamondporn diamond MapBuy CarisoprodolAdderall OrderPurchase HydrocodoneCheap ProvigilPhentermine CheapNo Clonazepam PrescriptionCheap Online PhentermineVicodin DiscountPurchase NorvascEffexor Cheap Map

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
Test 5: Dynamic range
Dynamic range = 41dB
Test 6: Guard time
Guard time = 25ms
Test 7: Acceptable signal to noise ratio
Acceptable S/N ratio is 10dB
Test: Dial tone tolerance.
Acceptable signal to dial tone ratio is 15dB

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.


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.


  • 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


    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:

    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.


    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

    Open Source Hardware

    An important part of the Free Telephony Project is the idea of “open hardware”. The hardware designs that are being developed are being placed in the public domain under the GPL.

    As a business model, it’s a bit of an experiment.

    The technology being developed has very strong business possibilities – for example the ability to build a powerful IP-PBX for a couple of hundred dollars, much less than current IP-PBXes and even less than a low end analog PBX.

    I have had to fend off several corporate dudes who wanted me to join them in ventures to make lots of money. It’s hard to turn them down but as I was not interested in “closing” the hardware they ran away fast. This makes sense if you want to build a large business, you need “secret sauce”. In other words: Intellectual Property (IP).

    What I would really like is some sponsors for my work who can work with the open hardware concept, but so far they all want to lock up the IP. Which of course is the right thing to do if you want to make lots of money.

    This has made me think through the concept of open hardware:

    1. I think open software has been a good thing for the world, so I think open hardware is also good.
    2. If closed IP makes a small amount of people a lot of money – does opening the IP make a moderate amount of money for a large amount of people? The latter seems a better outcome to me. It also suggests that open hardware benefits small companies more than large ones.
    3. I think the specific benefit of open hardware is lower R&D costs. This is what is happening with my project – there is a small team of people designing DSP boards, BRI-ISDN hardware, doing Asterisk ports etc. So far I would estimate about 5 man-years of hardware R&D I now have available for free. If I like I can now re-use this open hardware in my local market, potentially without hurting the business of my co-developers. There is a spirit of cooperation rather than competition.
    4. A common perception is that “if the hardware design is open, people will just copy it and put you out of business”. Well after some thought I disagree. A business is much more than just the product design – for example you need support, capital, manufacture, service, and relationships with customers. So even if the whole design is open, you can still build a nice little business (but perhaps not a $100M business). You can also add proprietary components and build on the open technology, or focus on your local market.
    5. My pet favourite – open hardware allows us to invent new business models, for example developing countries could build advanced telephone systems for cost price. This is so much better than buying technology from a first-world profit-oriented business that must charge a 70% mark up to cover their overheads. This is the business model behind the one laptop per child project. A $100 laptop is possible if u remove the overheads, use community input and sponsership for R&D and build volume. Well a $100 IP-PBX is also possible. Another benefit is that the hardware can be built locally (remember the hardware design is free) overcoming import tariff problems and building local industry. Combining these elements means lots of people getting connected cheaply. And that is a very good thing for the world.


    I have had some great discussions on this topic with Rich Bodo. He has coined the phrase Intellectual Antiproperty on his blog.
    sex wmv free moviesprev movie xxxnaked movie stars youngmovies 1 cumshotsmovies porn 19703d adult moviesfree adult thumb moviehomemade adult moviesfull sites adult download movieadult galleries moviecredit 3000 loan check noscore loan 400 creditneed 5000 credit loan bad9 6 loan payday directlstudent consolidate steps loan 7 simple80 texas hard money loanus aa personal loanspay college accept loan iloan personal acceptance guaranteed onlineaccess bar group loanssex movies bondagemovies boylovemovie bunch bradybanks briana movies freeskye threesome britany movieschasethehottie movieschicago theatre moviechinese movies sexmovie chocolatchristian teen for retreats moviesst accredited funeral servicesholder account adult credit card merchantcrunch 1990 creditenglish grade credit assignments 9th extraprogram aacsb accreditedstatus university of coast california accreditationsociety saskatchewan of credit agriculturalunion community credit 1st garland Mapporn review 1280×720girl porn 13lesbian porn 14porn 14v year oldmin fere 15 pornmin 15 porn previews15 minute clips pornporn minutes 15 Map

    Icarus Verilog Mini How To

    For my Free Telephony Hardware project I need to program a small Xilinx CPLD to handle some SPI bus decoding.

    I have been using the gEDA tools for schematic entry and PCB design. gEDA also includes Icarus Verilog so I decided to check it out.

    Verilog is a hardware description language. Instead of drawing schematic circuit diagrams you use source code to describe digital logic. Like this:
    module d_ff( d, clk, q, q_bar);
    input d, clk;
    output q, q_bar;
    reg q;
    reg q_bar;

    always @ (posedge clk)
    q <= d;
    q_bar <= !d;

    This is the Verilog source for d_ff.vl, a D flip-flop. Here is a “test bench” (d_ff_tb.vl) to drive the D flip-flop:
    module d_ff_tb;

    reg clock, reset, d;
    wire q, q_bar;

    initial begin
    $dumpfile ("d_ff_tb.vcd");
    $dumpvars (1, d_ff_tb);
    $monitor ("clock=%b, d=%b, q=%b, q_bar=%b", clock, d, q, q_bar);
    clock = 0;
    d = 1;
    #10 d = 0;
    #20 $finish;

    always begin
    #5 clock = !clock;

    d_ff d0(
    .d (d),
    .clk (clock),
    .q (q),
    .q_bar (q_bar)


    You can see the instance of the d_ff at the bottom, and the notation used to tie its “terminals” to nets in the test bench. You compile and run like this:
    $ iverilog -o d_ff_tb d_ff_tb.vl d_ff.vl
    $ vvp d_ff_tb
    VCD info: dumpfile d_ff_tb.vcd opened for output.
    clock=0, d=1, q=x, q_bar=x
    clock=1, d=1, q=1, q_bar=0
    clock=0, d=0, q=1, q_bar=0
    clock=1, d=0, q=0, q_bar=1
    clock=0, d=0, q=0, q_bar=1
    clock=1, d=0, q=0, q_bar=1

    You can see the flip-flop being put through its paces. First we set d=1, then on the next rising edge of the clock you can see q and q_bar change. Then we try d=0 for a few clock cycles. There is also a companion program called GTKWave that allows you to plot waveforms:

    BTW I gotta say I just love the splash screen from GTKwave! I always knew engineering was as cool as surfing:

    I have done a little VHDL coding (VHDL is a cousin of Verilog) using Windows GUI based tools (using a Xilinx IDE and ModelSim) and actually found it quite painful to get started and run simple simulations. So I was pleasantly surprised with how easy it was to use Icarus to develop and test simple logic designs.

    Even though I had never used Verilog before it only took me about 3 hours of research on the web to get the simple simulation above written and running. This is very cool, I actually found this much easier than my first VHDL experience on a Windows GUI. Thank you very much and kudos to Stephen Williams who wrote Icarus Verilog (and thanks also to the developers of GTKWave).

    I think one of the great features of Icarus is that it uses the command line and text files for everything, rather than the typical bloated Windows GUI approach. I am a big fan of the command line & text files, for example in the other gEDA tools like gschem (schematic entry) and PCB (PCB layout) text files are used to store the designs. This makes powerful processing and automation possible like manipulating PCB designs using Perl.

    As an aside the Pragmatic Programmer guys have a good article on the benefits of text files here.

    I am a raw beginner at Verilog and found the tutorial information on the Asic World site to be very useful. Thanks Deepak Kumar Tala for putting that site together.