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.

    How To Make Your Kids Rich

    This page describes a simple plan to generate $150,000 for your child by the time they turn 21.

    The Plan

    What you need to supply is:

    • Time: About 20 years is great, more or less time can work if you adjust the plan. The plan works very well if you start when your child is born.
    • Saving. You need to save $8 each work-day. You get weekends off so thats $40 a week. This is the tough bit. Most people can spare $8/day but very few can save it over the long term.

    It works like this:

    1. You save $8 a day, $40 a week, or around $2000 a year.
    2. You invest this in a managed share fund that is indexed to the share market. Based on historical performance this will mean an average of around 10% appreciation every year. The share market has many ups and downs, but over the long term, 10% is about right if you reinvest dividends. You are interested in the long term, so all the swings will average out. If you don’t like the share market you could choose some other investment with similar returns like a property fund.
    3. You increase your savings each year based on inflation. For example if the average inflation is 3%, you increase your savings from $40/week in the first year to $41.20 a week in the second year.
    4. You keep this up for 20 years. Your saving and the magic of compound interest means your child now has over $150,000 at age 21. Even with inflation, that still a lot of money, just when they need it the most. Invested wisely, it could make a big difference to your childs life. The cool thing is that unlike you and me kids have a pretty long time horizon, which lets compound interest go to work with a vengeance.

    The Spreadsheet

    Here is an Excel spreadsheet that shows you how it all works. Here is the same table in PDF form. I wanted to put the table directly in this post but couldn’t work out a nice way of getting a formatted spreadsheet table into WordPress.

    BTW I find Excel (or the spreadsheet of your choice) really cool for basic financial modelling like this. It’s a lot of fun to experiment with. If you think part of my model is wrong, try entering your own parameters and see what develops. What is the effect of 5% inflation, or putting $80/week into the plan?

    The Results

    Does it work? I think so. I started it about 8 years ago (when my first son was born and my daughter was 2) and while not exactly matching the model results both of them could now buy a (small) new car outright. My 8 year old probably has more savings than many 28 year olds. Still, my kids are a few years behind the curves in the spreadsheet which makes me wish I had put in more money earlier. Doh!

    On problem is that I am struggling to put the $40/week in. I like to do it in lump sums of a couple of $k a year and my wife often objects when I suggest it. It’s kind of hard to visualise the compounded effect $2k can have over 20 years for many people, especially if you are focussed on paying down a mortgage or have bills to pay. However I can’t think of a better use for my money that my kids future. Can you?

    In Australia the government is giving $4,000 to the parents of every new baby born. So when our 3rd child was born last year I invested this baby bonus it in my newborn sons name. I am not sure what most parents do with their baby bonus however I suspect a lot of it ends up being used for flat screen TVs. Now my 11 month old son needs to file a tax return as he made a few hundred dollars in dividends! As my daughter says “he can’t even talk and he is making money”!

    capitalization of loan rate interest amountcompanies 100 top loan direct worldstafford 2008 rules loan texasadrienne sloanealberta legal default student loans courtaba loan calculator autoloan bad auto for credit $9,000payday collection loan ambassadorarticles loan adjustable postcard clients rateamerican microloan3 g ringtonetime 1 ringtones purchase100 free downloads ringtone100 free download ringtonetv ringtone 24 seriesmobile to phone ringtones add24 mp3 ringtoneg ringtone for free 3 Mappayoffs loanporthole loanmissouri quarters loanag loans minnesota loan on ratesrepayment formula loanrescue loanuk search loanloan industry servicing Map

    Roads and Wealth Creation

    For years I have been interested in travel to some of the more remote areas of Australia. Recently I bought an old (but tough) 4WD, and with my children Amy and William we set out for the Flinders Ranges, about 500km north of our home in Adelaide, to spend a few days camping and doing a little off road driving.

    One day we visited Arkaba Station, a private property where for $35 we could spend a few hours on a self guided 4WD tour through the station. There was a mixture of terrains; creeks, some very steep (at least for me) and very rough roads. I was really an ideal trip for me, just right for my (very basic) 4WD skill level. We were the only ones on the track for the entire time, and the scenery was very nice, although I was focused mostly on the road. The kids really liked the steep bits and being shaken to pieces on some of the rough roads. They also spotted lots of wild life (Emus and Kangaroos, as well as sheep that are run on the station).

    One section was covered with large rocks sticking out at all angles. Our speed was limited to about 5km/hr, and inside the car we were shaking and bouncing all over the place. We could have got out and walked faster. It occurred to me that this was probably a typical road for 99% of history, and that travel at walking pace (and being shaken to pieces if in a vehicle) was probably the norm. This must have made communications very difficult, expensive and therefore very rare.

    Driving off road made me appreciate that a simple flat ribbon of bitumen that enables us to travel at highway speeds really is a miracle. The distances we can cover in a few hours on a modern road must have taken days 100 years ago using the poor roads and horse and carts of the time.

    Roads as a creater of wealth

    One question I have been thinking about lately is “where does wealth come from”. I mean, we all talk about economic growth, which to me means more money in a country/region as a whole, but if an economy grows, we all get richer, so where does the wealth come from? Who is pumping the money in? If we are getting richer, is some one else getting poorer?

    Thinking about roads gave me a good example of wealth creation.

    Roads allow us to move more efficiently, less effort is required than without them. The government took our taxes and invested them in this infrastructure, now it costs much less to get from A to B. The cost of travel has been reduced.

    Lets look at an example. In 1850 Farmer Joe needs to travel a round trip of 100km. He uses his horse and cart and spends two days to travel. In those two days he cannot be doing any other work. Now in 2006 Farmer Joe jumps in his car and travels the 100km in 1 hour. He returns to the farm and can work for 2 full days (minus the 1 hour). That 2 days of extra work that Joe earns income from. This is additional wealth that has been created by the road.

    The interesting thing is that no one else had lost anything to make Joe richer. It is a win-win situation. Communications infrastructure (the road) has created wealth, and no one loses.

    What about the cost of the road? Well I am assuming that the government paid for this out of the same taxes Joe would have paid anyway. They just decided to spend the taxes on a road rather than a warship or new town hall or something. I am also guessing that the cost of the road is far less than it’s economic benefit to those who use it over the years.

    Wealth Creation

    Looking around at the people around me I notice that most of are much better off in a material sense that we were say 20 years ago. Much of the stuff we buy (especially consumer goods) is also much cheaper than it was 20 years ago. For example in 1989 I bought a VCR for $1100, I just bought a combined VCR/DVD player in 2006 for $150. Adjusting for inflation thats a cost reduction of about 15 times! Fifteen VCRs for the price on one.

    Somehow, wealth has been created. We all have a lot more money. My mother tells my stories about “stretching” the food money to last until pay day in the early 70’s. Now our biggest problem is when are we going to get a flat screen LCD TV?

    The only exception to this rule seems to be real estate. My theory here is that real estate prices have been pushed up by demand as people have enough discretionary money now to cover huge interest repayments. Real estate has soaked up excess wealth through the laws of supply and demand.

    But I digress. The question I was looking into is “how is wealth created”?

    The best answer I have worked out so far (worked out in discussions with several friends) is that: we all get richer as the cost of producing stuff is reduced.

    So I think it works like this:

    • Technology is developed that allows something to be produced cheaper than before. For example fertilisers make food production more efficient. Silicon chips lower the cost of electronics.
    • This makes some product or service cheaper to deliver.
    • So we spend less to obtain a given product or service, and have more money free for other things. Like flat screen TVs, or huge interest payments on your mortgage. Or sending our kids to expensive private schools.

    Advancing technology is not good for everybody. Some industries get displaced. The development or roads and cars probably put a lot of the horse and cart industry out of business. This must have caused a small group of people a lot of distress, despite the huge benefit to a large number of other people. And yet the world is clearly a better place for having efficient transport.

    It is also interesting to see what we do with our increased material wealth. Somehow soaking it up in big interest payments or mobile phone bills doesn’t seem right when there are 10,000 children dying each day from preventable disease. But thats another story. I am currently reading a couple of books on these subjects, and recommend them to you:

    Communications Technology for Wealth Creation

    I see a lot of parallels in physical communications assets like roads and communications technologies like VOIP and the Internet. They all let us communicate faster and better.

    They are engines for wealth creation.

    So reducing the cost of communications is a good thing. It lets us communicate faster and cheaper. Reduce the cost enough and maybe some kid in a disadvantaged country can make his first telephone call or obtain an education over the web.


    So on balance I think “decreasing the cost of stuff” is a good thing. It is a mechanism for creating wealth. Like the example of roads, it can be win-win – wealth can be created like magic without disadvantaging a large group of others.

    I must admit I find this pretty cool. It suggests that we can actually increase wealth (and the material well being of everyone on the planet) in a win-win situation. For us fortunate people in the 1st world this means more gadgets or a nicer house. For the less fortunate it means hope that one day they will be able to eat 3 meals a day and not die of Malaria.
    ringtone para nokia 11083589i ringtone nokiasprint free sanyo 4900 ringtonefree sanyo ringtone sprint pcs 8200ringtones vx3200 lg alltelalex etheringtonalltel ringtones lg vx3200composable free ringtone motorola 120e Mapfamosas actrices pornoadvantages analysis gravimetric ofteen porn videos amatuarsex photos amputeesex adora35p phone sexalicia machado porn3movies porn Mapfree porn cartoon moviesmovies porn privatesexy stars moviefree movie horse sexaebn streaming moviesporn movies cartoon freeasian free movies sexjob movie hand Mapnipples youngshemale analpussy bareflintstones hentaiphotos peniscock cummingunderage preteenmature wives Map

    A Bit Exact DSP Fairy Tale

    Once upon a time in a far off land there was an underpaid pale skinny guy working in an impoverished start up who wanted to build products with fixed point DSP chips in them. The problem was he had just about killed himself doing the same thing many times in the past.

    In particular, he seemed to spend a zillion hours debugging intricate fixed point DSP assembler to get products working. All while some project manager who hadn’t written a line of code for 10 years was hovering behind him asking questions like “is it ready” and mumbling something about milestone dates that were ridiculous when proposed, and soon became hilarious after the project started.

    So, our hero wondered, “is there a better way”.

    How to Build a DSP Based Product

    Many DSP products are developed like this:

    The academics “brains trust” guys work out a clever new algorithm. Now these guys are way-smart, but tend to express themselves in algebra with lots of Greek letters. They usually have PhDs, and cost a lot, and there aren’t many of them. They might test their brain-child in a simulation algorithm like Matlab:

    x = [1.1 2.0 3.0];
    y = [2.5 3.0 4.0];
    dot = x * y’;

    Now this lets them test the algorithm quickly (dot = 20.75), but you can’t run code like this on a real world product due to (a) it runs 10 million times slower than real time and (b) Matlab licences cost $5,000 each and only run on $3000 PCs. Which is a shame when u are building a $99 product.

    So some poor engineer then has to make the DSP algorithm work in real time (i.e. fast) on the “target” hardware, a $10 DSP chip. Actually, in general, these guys actually like the detail work this involves. The first step they might do is convert to floating point C:
    float x = {1.1,2.0,3.0};
    float y = {2.5,3.0,4.0};

    float dot(float x[], float y[], int n) {
    float d = 0.0;
    int i;

    for(i=0; i<n; i )
    d = x[i]*y[i];

    return d;

    But the guys & gals in Marketing (they are a breed closely related to Managers, but tend to be more attractive and use airports more) have decided that this must be a low cost product, so a $10 fixed point DSP is chosen.

    Now a fixed point DSP is a chip that can perform multiplies and adds quickly, as long as you only use integers. They don’t do floats. So the engineer converts the algorithm to fixed point:
    short x = {11,20,30}; /* x*10 */
    short y = {25,30,40}; /* x*10 */

    int dot(short x[], short y[], int n) {
    int d = 0; int i;

    for(i=0; i<n; i ) d = x[i]*y[i];

    return d; /* returns dot*100 */

    Now look what has happened to the x[] and y[] arrays. We have multiplied each number by 10 so we can use an integer to hold the value. If we didn’t scale each number then we would lose information (for example converting the 1.1 to 1) which on certain algorithms would cause problems.

    However because each input value is multiplied by 10, that means the result is multiplied by 100 ( 10x * 10y = 100xy ). So we need to take this output scaling into account in any other stages of the algorithm. One more piece of information we need carry around with us as we code. One more source of bugs.

    This is a very simple scaling example. In practice it gets much scarier and means you need to hold a lot more information in your head when you program in fixed point (see complex sample below).

    There is also the potential of overflow problems. As the output is scaled up by 100, it is easy to overflow the 32 bit range of the integer output, for example if we used x[] and y[] arrays with larger numbers.

    I Feel the Need for Speed

    The product requires that this routine must run as fast as possible on the DSP chips. So we need to code an optimised version of this routine in assembler:
    int dot(short *x, short *y, int len)
    int d;

    "I0 = %3;\n\t"
    "I1 = %4;\n\t"
    "A1 = A0 = 0;\n\t"
    "R0 = [I0 ] || R1 = [I1 ];\n\t"
    "LOOP dot%= LC0 = %5 >> 1;\n\t"
    "LOOP_BEGIN dot%=;\n\t"
    "A1 = R0.H * R1.H, A0 = R0.L * R1.L
    || R0 = [I0 ]
    || R1 = [I1 ];\n\t"
    "LOOP_END dot%=;\n\t"
    "R0 = (A0 = A1);\n\t"
    "%0 = R0 >> 1;\n\t"
    : "=&d" (d), "=&d" (before), "=&d" (after)
    : "a" (x), "a" (y), "a" (len)
    : "I0", "I1", "A1", "A0", "R0", "R1"

    return d;

    This is assembler for the Blackfin DSP, the actual code will of course vary for different DSP chips. The important bit is this:
    A1 = R0.H * R1.H, A0 = R0.L * R1.L
    || R0 = [I0 ]
    || R1 = [I1 ]

    In a single clock cycle, our intrepid DSP performs two parallel 16-bit multiplies, two 16-bit adds, and fetches 2 32 bit words from memory, post incrementing the pointers after each fetch. It does all this 500 million times a second, and sometimes it even gives you the right answer.

    But not often. First you need to spend a lot of time getting it all to work right. The assembler is much harder to grok than the previous versions of the algorithm, and you use up a lot of brain power on a myriad of fine details. Get any one of the details wrong and the product is a dud.

    The target development environment is also tough. In many cases the feedback you use to debug might be an analogue signal flowing into or out of the product (that is processed internally by the DSP). Or a blinking LED. Sometimes you don’t even know when its really working, bugs can simply slip through. You can’t always stop the code and single step using a debugger as parts of the algorithm depend on real-time activity.

    It’s a development/testing/maintenance nightmare.

    Bit Exact Assembler

    There is a way to ease the pain a little. Lets say there is a bug in the assembler version. The problem is that to debug the algorithm you may need to understand both the assembler and the DSP algorithm, I mean to debug something you need to know how it works, right?

    This is OK for a simple algorithm, but what if it is even moderately complex? Then you are dealing with (i) a very complex algorithm and (ii) very complex assembler all at the same time. This is usually too much for mere mortals (and even minor deities). The result is long, painful development, failed projects, late nights, angry spouses, and lots of pizza (well its not all bad I guess).

    The trick is to divide and conquer. Make sure we are only hitting one tough problem at any given time.

    One approach I have found very useful is bit exact porting to assembler. There are two important steps:

    1. At the fixed point C stage, you test very very carefully. Run batteries of tests and simulations. These can be performed on a regular PC in non real time, using powerful debuggers. The idea is to verify that (i) the algorithm is OK and (ii) the fixed point port works OK. In particular (ii) is very tough, so its nice to handle this in a relatively benign environment like a PC or workstation.

    2. Port each function to real time assembler one by one. Test each function against the fixed point C reference. Make sure the functions give IDENTICAL output – right down to the last bit. This takes a lot of discipline – near enough is NOT good enough.

    The benefits of bit exact coding are:

    1. When coding assembler, you don’t have to worry or even understand the algorithm. You just have to make sure that the C version matches the assembler version. When they do, you know that the overall system will perform as expected. This lightens the load on your brain, leading to less bugs.

    2. As you integrate modules of code together, problems are easy to spot, just look for where the output doesn’t match the fixed point C simulation. This is much simpler that performing batteries of tests in a real time environment.

    3. A less senior engineer can be used to perform the assembly coding, as they don’t need algorithm knowledge. This makes it easier to find people for the project, lowering costs. Adding people to the project is less of an issue, as they can get up to speed and be productive quickly.

    4. Any bugs are exposed early (while unit testing), rather than late (after integration). You get an honest measure of progress, rather than nasty surprises late in the project.

    Where it fails:

    1. It takes a lot of discipline to perform (1) CAREFULLY. There is a lot of pressure from managers (and engineers) to jump onto the sexy real time/hardware integration stage. If you are part way through (1), and there is a milestone due, it is very tempting to “declare victory” and move onto the next stage, WAY before you are ready. The results are predictable…

    2. It takes discipline to make the assembler bit exact. I mean, look, it’s nearly the same, just a few bits are different? The problem is these little errors may lead to much bigger flaws in performance later on. Try changing a single bit in your operating system binary image and see how well it runs. In some (most) cases bit-exactness matters!

    3. It is honest. It gives you a black and white go/no-go indication at various stages of the project. For example the fixed point C stage is not complete until it has shown perfect performance against the spec. This reduces the “room to move” managers have, you can’t declare a phase “complete” just to suit a milestone date. It really has to work. This sort of honesty doesn’t sit well with some managers, for example they may have to admit problems to a customer early on in a project.

    Case Study – Non Bit Exact

    Now here is what typically happens. Our hero is under pressure from his manager to progress, so he short circuits the fixed point C simulation stage and codes straight into assembler. The C simulation and bit exact assembler have results that are “close” but not really the same. No effort is made to synchronise the results, there isn’t enough time!

    Time is also short so he can’t “waste time” on unit testing, there is a milestone with a big fat cash payment attached.

    The assembly code is loaded into flash on some brand-new, untested hardware, power is applied, and some basic tests performed.

    Damn. It doesn’t work.

    So our hero and his team start trying to debug the real time assembler code. However debugging in real time is very time consuming. The best brains in the company spend months tracking down bugs that end up being simple one line fixes. Bugs constantly interact with each other, leading the team off in false directions.

    He doesn’t go back to the C simulation as it now gives different results to the assembler and “we don’t have enough time” to make them match.

    As the project falls behind, there is no one who can be added, as only people who understand both the algorithms and the assembler can be used. The team is debugging leading edge algorithms in assembler.

    A year passes. Senior management is fuming. They keep getting told “real soon now”. However no-one really knows how long it will be, because no one really knows just how many bugs there are. Frustration and stress is very high all around.

    Eventually the company runs out of funds and the project is cancelled. There are mass departures of some of the best and most capable people from the company. Our hero leaves to join another start up where he repeats the same process.

    Case Study – Bit Exact

    Our hero and some members of the brains trust spend many months carefully porting the algorithm to fixed point and testing the entire product in a robust simulation. This apparent lack of progress is tough for the managers to handle, but they understand the benefits and bravely support the team.

    Lots of complex bugs are thrown up, and the team works through them one by one. They don’t take too long to fix because these tough problems are at least occurring in a PC environment, where it easy to track them down.

    In parallel, the fixed point C modules are passed to a team to perform the assembler coding. This team is made of up many junior engineers, who are instructed to make sure each module is bit exact with the reference C simulation. A few of them don’t like this, but the more senior members keep them on track. The junior members do a good job, as all they need to focus on is the assembler, not the algorithm details.

    A few bugs slip through unit testing to integration. A senior member who is a veteran of previous “death march” DSP projects is assigned to fix the bug. She discovers that the the problem was due to an exceptional case not covered in the unit test and sure enough the assembler module wasn’t bit-exact under that case. She had previously been a critic of the extra effort required for bit exactness but the speed in which this bug was found and fixed impresses her.

    Early in the project some unforeseen problems are discovered during the work on the fixed point C simulation. Some parts are running slower than expected which means more assembler may be required in the final product. This throws up an early indication that the project is at risk of falling behind.

    This critical management information is flagged early, while there was time to do something about it. It is decided to add some extra engineers to the assembler side. As soon as they learn the DSP instruction set they quickly come up to speed. They don’t need to know or understand the algorithm details.

    The schedule still slips by a few weeks, but all the stakeholders understand that this is a better outcome than delivering a lemon on time. No further slips occur, and the project manager earns a great deal of trust and respect by delivering “bad news early” rather than trying to hit arbitrary milestone dates and risking the entire project.

    When the real-time DSP software is integrated with the hardware there are still a few bugs to find. However by this stage the real time software is at a very high quality level so the bug count is low. Integration actually proceeds on schedule, amazing everybody, especially veterans of past projects.

    The product is a success, the start up has a great IPO, and the pale skinny guy retires at 28 years old.

    Complex Example

    Here is a rather more complex example of fixed point C code from the Speex project:
    static inline spx_word32_t cheb_poly_eva(
    spx_word16_t *coef,
    spx_word16_t x,
    int m,
    char *stack
    int i;
    spx_word16_t b0, b1;
    spx_word32_t sum;

    /*Prevents overflows*/
    if (x>16383)
    x = 16383;
    if (x<-16383)
    x = -16383;

    /* Initialise values */

    /* Evaluate Chebyshev series formulation
    using an iterative approach */
    sum = ADD32(EXTEND32(coef[m]),
    for(i=2;i<=m;i )
    spx_word16_t tmp=b0;
    b0 = SUB16(MULT16_16_Q13(x,b0), b1);
    b1 = tmp;
    sum = ADD32(sum,

    return sum;

    In English (sort of), this function works the value of a polynomial at various points around a circle. Don’t ask me why. DSP engineers just like doing things like that. For more information/punishment see the file lsp.c from the Speex project.

    Macros like ADD32() simulate the instruction set of the DSP chip in the simulation code, which makes porting this function actual DSP assembler a simpler step. However they also make the code much harder to read.

    Renumbering components using Perl

    I am designing a telephony version of the BlackfinOne DSP/uClinux board. To develop the design I am using the gEDA CAD tools. This board runs uClinux on a Blackfin BF532 processor, and has been designed using the open source gEDA tools which makes it really easy for anyone to re-use the design. Thank you very much to Dimitar Penev and Ivan Danov who designed and published this board. They have done an excellent job.

    The first stage in any electronic design is usually to enter the schematic. The schematic shows the components and their wiring in a form that is easy to follow:

    I wanted to add two Ethernet ports to the BlackfinOne design, so I found a reference design and entered the schematic using the gschem program.

    After I entered some sheets for the Ethernet chips, I had a little problem. In the schematic above you can see that every component has a letter & number next to it, for example, C1, C2 for capacitors, or U1, U2 etc for chips. This is a unique ID for each part. The letter generally indicates what sort of part is is (capacitor, resistor, chip etc). These IDs are know as reference designators or as a “refdes”.

    Now I wanted the refdes on my new Ethernet sheets to merge nicely with those on the existing BlackfinOne design. For example if the last capacitors refdes on the BlackfinOne design stopped at C51, then my C’s should start at C52.

    There is a program to do this (refdes_renum described here in the gEDA tutorial) but unfortunately it renumbers all of the refdes in the design, and I only wanted to renumber the new parts that I had added. I didn’t want to mess up anything in the existing design. Please also see the Links section below for a new alternative – grenum.

    Now of course it is possible to number the components manually in gschem via the GUI, but if you know a little Perl then its much more fun to hack out a solution! Now fortunately gschem uses text files to store the schematic. The refdes are stored in the schematic file like this:
    C 7000 87800 1 0 0 bf-93LC46.sym
    T 8200 89100 5 10 1 1 0 0 1

    I think this means that the component (leading C) that is drawn using the bf-93LC46.sym symbol file has a refdes called U19. The line starting with T tells gschem where to place the refdes text on the sheet. Anyway all I am really interested in is reading and changing the refdes lines.

    So the Perl script num_refdes.pl first scans all of the existing schematic files for lines that have the text /refdes=/. The number of the refdes is then extracted, and stored in a hash if it is the largest refdes so far. On the new schematics, I initially enter each refdes as C?, U? etc. The script scans these, and wherever it finds a ? it replaces it with the next refdes in that series.

    Improvements and Reflections

    There is one obvious improvement. The current script isn’t smart enough to use a refdes that hasn’t been used yet, for example if C1,C2,C4 are currently used it isn’t smart enough to use C3, it will use C5 instead.

    This script took me about 70 minutes to write and it worked perfectly the first time. To be honest it didn’t really save me any time (I could have manually entered the refdes in less time) but it was lots more fun to do it this way. And I guess it will be useful the next time I have this problem. Perhaps now that I have posted on it some one else might also find it useful. Come to think of it writing this blog post took longer than writing the script! DOH!

    BTW every time I work with Perl (which is maybe once every two months) I spend the first 20 minutes looking up web sites to work out which regexp to use, how to iterate through a hash, etc. If I don’t work on Perl and regexps constantly it all looks like line noise to me after a few weeks:
    if ($line =~ /refdes=(\w)(\?)/) {

    But hey, its no big deal to refresh my memory every few months.

    Solving little problems like this with Perl is fun. You almost hope there isn’t a solution out there already, just so you have an excuse to write one!


    I have also written a few Perl scripts for PCB (the PCB design application in the gEDA suite) here.

    After I posted the above, Levente Kovacs kindly pointed out his grenum utility which is now included with gEDA! This has been recently added to gEDA and performs the same job as the Perl script above, but can also spot gaps in refdes sequences. As grenum is now part of the official gEDA distribution I would recommend using it rather than num_refdes.pl. I share a trait common among engineers – a strong desire to “do it myself” rather than checking carefully for existing solutions! Thanks Levente!
    14 payday 20 loan directory2500 cash quick loansquick 26 loan 37 paydaycredit bad loan 2b personal45 loan payday 31 advance uksites 37 payday loan 53loan cash payday advance 5 5006 loan online kentucky payday 8loan 6 cost 20,8 payday lowlink 60 payday loanmovies hentaimovie lesbiansex moviesmovies adultfree hentai moviesporn moviesmovie clips porn freemovies gay free Mapmp3 achha ji1990 mp3 temptationsnation acumen mp3drame mp3 adamatecktonik mp3 tepr acdgmp3 ackermann sucheachhe mp3 lagtemp3 blog 1990s Mapfree naked moviesdildo movies hugehardcore clips moviemovies dans pornblow free movies job bestwomen movies nakedgirls free teen moviesdouble penetration free movies Mapporn cliphunterporn clipmasterclips free pornporn anal of clipsof girl porn clipsporn clipsporno clips gratuitclipsporn Map