This post is being typed on my mobile phone, thus it will be shorter than I intended. However, my laptop, on which I have done all the work so far, is off to the repair shop. In the meantime, I have worked for a few days on a desktop owned by my employer.
By the time my laptop decided to die on me, I had already received all the required materials for 50 prototype Open USB FXS boards. I could just as well start shipping DIY kits right away. However, I thought it would be wiser to first verify the newly-ordered parts and PCBs by assembling about a dozen boards. So (a bit reluctantly, to tell the truth), I re-created an elementary development environment on the desktop: Eagle, then Microchip PICDEM environment, then Wubi and finally Dahdi, svn-get the driver and compilation. All went fine.
Then, I started getting busy with assembling the boards. The first two annoying things that I noticed were that I had ordered wrong C5 and C6 (220nF instead of 22) and that, although I had ordered correctly the part number for Cusb (220nF), the little plastic bug from Mouser contained some unknown SMD part with eight contacts (“pins” would not be appropriate here, since contacts were pin-less, just like in QFN packages). I decided to proceed without C5/6 — since these are just an HF filter, I could add them afterwards — and to use the wrong C5s (220nF) as Cusb.
Then the Judgement Day arrived, when testing would tell apart good boards from bad ones.
First thing, I had to bring up the pre-programmed boot loader by switching on S2. This gave me the first creeps: six boards refused to work. Checked better and, false alarm, it was one of the S2 pins that had been left unsoldered. So I corrected that and flashed the latest firmware on all ten boards. Then, elementary testing gave the following results: one perfectly good board, one that refused to pass the Q6 calibration step, and eight boards with more or less severe audio issues — clicks and buzzes right after tranition to off-hook, that were mostly disappearing after a few seconds of operation.
This was unheard of; 90% failure rate meant that the prototypes business would not work and, besides that, it also meant that a serious issue existed, most probably a design glitch. Debugging again was the only way to go.
First I focused on the board with the Q6 issue. That one proved easy to solve: a short between R1 and R2 was relatively easy to spot and remove, and after that, the board initialized OK, but then presented audio problems, just like the rest of the problematic ones. The failure rate was still 90%. This felt really despairing, so I decided to resort to the oscilloscope again — with help from some colleagues whom I ‘ll remember to thank publicly some day.
First thing we noticed was that Q7 was getting very hot (70-90°C) when the phone set was off-hook or when the phone was rung. This told me something about power, since in the ringing and off-hook states the DC-DC converter must provide more power than in a standby state.
What the oscilloscope revealed was truly interesting. If you consult my early post “Chasing an elusive bug around”, you ‘ll see a shot of what happens at inductor L1: just as the power transistor Q7 is switched off, the inductor starts discharging in an oscillating manner. This was more or less the same image on all boards. However, in off-hook or ringing mode, the picture changed: there was no oscillation at all, just the on-off square waveform as Q7 was switching on and off. More descriptively, L1 was discharging very quickly and Q7 was pumping too much current into L1 in order to charge it again, thus it was heating up too much.
So now we tested with a simpler tool: a digital multimeter. Measuring the voltage right before F1 yielded a mere 4.8V. When in off-hook state, however, the voltage was dropping down to 4.2V! For the current settings and components used in Open USB FXS, Silabs’ spreadsheet mentions 4.2V as the absolute minimum Vunreg, in that below that voltage, the DC-DC converter does not work at all!
By using a Type-A to Type-A USB extension cable and interpolating the multimeter in mA mode, we measured 400 mA in the idle state and 440mA in the off-hook state. This ruled out the overcurrent case. Thus, it became obvious that the desktop’s USB ports were unable to supply the required 500mA at 5V that my board required (lawfully, as per the USB standard). With the overhead of the extension cable and the amp-meter, sometimes the voltage was dropping that much that the board was rebooting!
But why would this result in audible clicks? It is simple: the 3210, seeing that the converter is not performing as it should, attempts to restart it from time to time. This results in a “click”, as the voltage on the line drops momentarily. The restarting frequency changes as the line conditions change (e.g., as capacitors inside the phone set get charged), so clicks may eventually disappear. Anyway, under these conditions, the circuitry does not operate as it should.
What’s the bottom line of all this? There are two answers. The first one is that the USB ports (or, most probably) the power supply of the desktop that I used were inadequate for the power requirements of the board. However, this is the easy answer. The difficult one is the circuit’s design parameters could after all be a bit marginal and this may cause failures on situations like this one. This must me remedied in a way or another. Until I get my laptop back I cannot do much (typing all this on my mobile is already an overkill), but I would be delightful to receive suggestions from you, the readers.