Careful with that choke, Eugene!

Yes, the title of this post is a paraphrase of a song’s title from the early Pink Floyd. Judging from the creepy scream coming straight out of hell that is heard about the end of the song, it seems that Eugene wasn’t that careful with his axe after all (that’s “axe” instead of “choke” in the song’s title). I found out many signs of carelessness in my first prototypes, too, but it seems that I have cured all of them. Here are all the nasty details.

To begin with, I am putting down sort of an apology for being so late in writing this new post (if you don’t like apologies or if you don’t care about the reasons I was late, you can safely move on to the next paragraph). As said in Power Games, I had given my laptop for repair when testing the first ten prototype boards. The boards misbehaved in the DC-DC converter part, and working with a different PC led me into the conclusion that this was the fault of the other PC’s USB port or power supply. Well… maybe… The boards now work OK with my (repaired) laptop, but this required a series of fixes to several hardware bugs and issues that I discovered. These issues are discussed in this post, however there were many more reasons why I was so late. To begin with, in the meantime since my last post I lost my job, because of the Greek public sector’s frugality policy (all contracts in the public sector were discontinued and only public servants remained in employment). As a collateral damage, besides losing my income, my lab workspace at work was also gone; thus I had to set up a lab workbench anew, from whatever ingredients were handy. The only candidate place for housing a new lab was  a sort of warehouse that we are renting across the street. There was a slight problem though: this warehouse did not have electricity, telephone and Internet…  My home and the warehouse being in the opposite side of the street, laying cables around was not an option. However, the two sites are in visual contact, so this gave me the following idea: I moved my home wireless router outdoors facing the warehouse and verified this still covers the interior of the house; then I installed an old unused wireless access point at the warehouse and configured it as a wireless bridge; finally, I used a couple of Sipura’s (a 3000 and a 9000) to gateway my home’s PSTN connection to the wireless LAN  and to an IP phone located at the warehouse. Fine, now I had my home phone and Internet connections extended to the warehouse! But how did I power all these at the warehouse? Easy: I installed a 130Wp solar cell on the roof, 230 Ah batteries and a 1000W inverter in the basement, and I now have enough power to satisfy my needs — five to ten hours of 50~100W daily! Of course, during all these installations, I have been — and still am — actively seeking for a job and I have been running a couple of errands that might turn into regular jobs in the future. As you can imagine, all this fuss kept me away from my prototypes for quite some time.

Not forever, though: since last Monday, I got back into debugging my prototypes. And there are quite a few bugs to find. To begin with, my Mouser BOM was once again wrong in one component: I discovered that I had ordered the tantalum capacitor C25 as 1uF/25V instead of the correct 10uF/25V. Still worse, the 1uF caps had been used on all prototypes. Stupid as this might be, it was a hopeful discovery, since replacing that cap with the right-valued one might fix the problem. However, practice proved this was not a big issue. Probably if power came from an unregulated supply, the 1uF cap would also cause problems, but it seems that in a USB supply chain there are plenty of capacitors to compensate for the lost 9uF. As discussed later however, 1uF caps were problematic with larger inductor values that I tested.

After replacing C25 on a couple of boards, I re-tested both fixed and un-fixed yet boards, and they were all now producing a high-frequency noise (a “hiss”). My next mistake was that I attributed this to the same DC-DC converter issue, as before. Although this assumption was wrong, it helped me a lot, in that it gave me incentive to search further and try out a few things.

The first thing I did was some good reading on inductors. Ferrite core inductors like L1 are known to be easily saturated  under high currents (check here for more details). It seemed like saturation was what I was seeing in the scope. To explain that more in depth, let me repeat the schematic of the converter here.

As explained in Silabs’ AN45, the converter works in cycles of loading L1 with energy by switching Q7 on, and then letting L1 discharge so that it pumps current out of C9 via D1, thus resulting in a negative VBAT.

When operating as expected, L1 oscillates at its self-resonant frequency (from my first oscilloscope shots, oscillation is apparent and the self-resonant frequency can be deduced to be in the order of 10 times the frequency of the converter, which yields about 8MHz for the originally-used power chokes — note that this frequency is highly choke-dependent). However, if L1 gets saturated, it does not resonate; it acts like a wire, letting the current through. This has the effect of storing much less energy within the inductor. When Q7 cuts off, the inductor pumps less current through D1, and this eventually is sensed as insufficient power in the VBAT line. Normally, the reaction of the Si3210 in this case would be to elongate the ON period of its PWM signal to charge L1 even more. Halas, this worsens the situation, first by saturating L1 even quicker, and second by heating up the choke’s copper, thus increasing its in-line resistance and worsening even more its characteristics. Eventually, the converter sees an overcurrent condition and cuts off Q7, possibly even for a full cycle or more.

The more inductance L1 has, the more energy it can store. However, more energy means that more voltage and more current are required to make the converter work, and both these supplies are not ample in a USB-powered device. Thus, in my design I had tried to use values of 5V and less than 0.5A, respectively. These values called for a smaller-than-usual inductance value for L1 (100 uH instead of a more common value of 150 uH), and a higher operating frequency (80 kHz instead of a more common frequency of 65-70 kHz).  What would happen if I used a larger inductor, then?

Enough with the theory, now; I had to find something to fix my problematic prototypes. I first replaced L1 on a prototype with a 150 uH inductor. It worked already better than before. From AN45, I knew I had to tweak the values of DRs 93 and 92 to adapt the frequency and the min off time to 150uH.

So my next move was to look again at the wctdm.c code. I used a value of 230 for DR 93 and a value of 25 for DR92 and, suddenly, the 150 uH board worked perfectly. OK! This was a sign that I was on a good track.

Getting back to wctdm.c, I was surprised to find that there were a couple of lines of code that I had neglected so far, which instruct the chip to perform a calibration of the DC-DC converter. The wctdm.c code tries to make sure that the calibration result (a value between 0 and 15) is not too high or too low (i.e., lies between 2 and 13), presumably to ensure that the converter is working within its designed range. Repeating these lines in my driver and testing with a 100 uH board yielded a consistent calibration result of 0. This did not sound very good, so I thought about adjusting DR’s 92 and 93.

I then played a lot with the values of DR’s 92 and 93, to no avail. Then I replaced a 150 uH inductor on a second board, just to find out that the hiss was not gone on that one. This means that the cause was not the inductor.

After that, it took me less than a minute until I found the real cause of the hiss: it was C5 and C6, which were missing on all boards except — by virtue of the most devilish coincidence — the one with the replaced 150 uH inductor! If you remember, C5 and C6 were also wrongly ordered as 220 nF instead of 22. Thus, I had used some stashed C5’s and C6’s on a few boards and had left C5 and C6 unpopulated on the rest of the boards, while placing a new order for 22 nF caps. Due to the long time since my last test, and altough 22 nF caps had arrived, I had totally forgotten about the missing ones. These caps form a sort of a low-pass filter that reduces the digital noise of the converter in the telephony line. I added the missing caps and — voila! — now all prototypes were working fine.

Fine? Not exactly. I had implemented a switch argument (highfreq) on the driver to use different DR 92/93 values for the 150 uH-choke boards. Now I tested the two 150 uH boards again, and one out of them was producing a beeping noise from time to time. Yes, I had not yet fixed C25 to be 10 uF instead of the wrong 1 uF one on that board. Thus, I replaced C25 on all boards and re-tested. Now all boards were working fine.

I now have available some prototypes that can be ordered. I also feel safe to ship DIY kits, in that I (finally!) know that the materials are correct and, if assembled correctly, the boards are likely to work. The prices we have set with Medion 7 are EUR 29.50 for a DIY kit and 42.50 for a tested prototype. You should add P&P and VAT (where applicable) to these prices. Currently, I only have four or five prototypes available, and two of them are 150 uH ones. I am soon going to have more boards assembled and tested. The availability of the boards will be soon announced in the ordering page of this blog. Please use the openusbfxs at gmail dot com address for ordering. Two pages on how to DoItYourself and how to set up the driver are to follow as well, so stay tuned.

On a final note, I am sorry for keeping people waiting for so long, although I guess I had plenty of reasons for that. I hope that all will be back to normal now. I also hope that the boards will behave OK on other people’s PCs and other devices, but I owe to stress once more here that there is no such guarantee.


6 Responses to “Careful with that choke, Eugene!”

  1. micha Says:

    any support to version 2.6.2

  2. Angelos Varvitsiotis Says:

    Hi Micha,

    Please see my latest post you can read a few things about the adaptation to 2.5. Probably 2.6 will work as well, but I have not tested it yet. Can you please provide me with some details? For example, which system (distro/kernel) are you intending to run 2.6 on? Why would you need 2.6 instead of 2.2, 2.3, 2.4 or 2.5?



  3. micha Says:

    I am working on a new project.
    This is why I like to use the latest code for DAHDI.
    I have run into compilation errors.
    /usr/src/dahdi-linux-complete-2.6.2+2.6.2/linux/drivers/dahdi/oufxs/oufxs.c:1651:2: error: ‘struct dahdi_span’ has no member named ‘location’

    the same error for:

    I am using UBUNTU 12.10

  4. Angelos Varvitsiotis Says:

    Hi Micha,

    I will try to check on these errors. In the meanime, I may contact you in private in order to sort out some details regarding your environment.



  5. Mihail Says:

    I patch the problem with terrible noise on some hosts and problem with set_configuration. I use microchip usb_device.c version 2.9i

  6. Angelos Varvitsiotis Says:

    Hi Mihail,

    I wish to thank you very, very much for your contribution! As you can guess
    by the long time it took me to reply, I am not very actively involved in my
    project anymore. I am replying more in-depth to your comment in my post
    entitled “Two old friends”



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: