So what’s happening with Open USB FXS these days? I know I ‘ve been silent lately, so you might expect me to come up and announce some really-big-next-thing. The truth is that there’s nothing tremendous to announce. However, there are a few new things to report.
I am finishing with the assembly of the “dongle” board. The construction revealed no big mistakes (yet), except one really stupid glitch: in creating the board-edge ICSP “connector” (consists of 2 sets of three stripes of copper at the edge of the board, I have placed the axes of the stripes 2 mm apart, whereas conventional board-edge connectors have a distance of 2.54 mm. Shoot… This is not the end of the world, since I can always solder wires on the “connector”‘s stripes and then remove them after I program the PIC, however it’s not really elegant. So I ‘ll have to correct that before I release the Eagle files (see why I haven’t done so yet?).
I plan to upload a few shots of the assembled dongle here. Here are two shots of the assembled dongle board.
On the top side, left to right, one can see the mounted type A USB plug, the DIP switches, the DC-DC converter circuitry (partially hidden behind the shielded choke L1), the PIC’s crystal, the Si3210 and its army of resistors and capacitors around it, the DC decoupling capacitor CDC1 and, behind that, the RJ11 plug. Notice that the top-side contacts of KICSP are hidden behind the RJ11 plug.
On the bottom side, one can see (left to right) the output circuitry of the Si3201, the 3201 itself, he PIC, the crystal oscillator capacitors (front), the PIC (middle) and its pull-up/pull-down resistors (back) and the Si3210 overvoltage protection circuitry.
I still owe to report on how the dongle will work. Even if it doesn’t work at all, I find it’s a beautiful construction, so I won’t complain — at least, not too much. Don’t you agree? Isn’t it very elegant? Anyway, enough with bragging, let’s get back to actual progress.
In the Asterisk channel driver front, I am making some slow progress. I have managed to understand the basics of a channel driver module file and the necessary structures and functions. Plus, I have taken a good look at a couple of channels (mostly chan_oss, chan_sip and chan_dahdi — the latter, excluding all about PRI, SS7 and the like). Basically, the channel driver module consists of three “interface” functions (load, unload and reload) which are called by the Asterisk core. Then, the load (and most similar, the reload) function initializes just about everything, reads in the configuration from the respective file and fires off a “monitor” thread. That thread is responsible for well, all the monitoring work in active channel instances. In simple channel drivers (like mine), the monitor thread might also do the audio data I/O, whereas in more advanced ones, the I/O can be “bridged” directly with some other channel.
Then, there are functions to create a new instance of the channel (e.g., when a new call arrives) and deleting an instance (when a call finishes off and the respective interface should go idle). Remember that a channel driver handles many instances of the same “class” of interface (in my case, say, many dongles connected to the same computer), and an instance exists only when an interface is active (is engaged in a call).
This is roughly it, however I have still lots to study and lots to learn.
As I ‘ve done in the past, I ‘ll be updating this post as I progress with the channel driver. Hopefully it won’t be long until I report some good results.
Update, March 2: some good and some bad news: the dongle worked its dc-dc converter right away! It also rings the phone with no problem and its output audio quality is perfect. However, for some reason, the input audio (recording) is distorted. This is a bug I have seen on some other prototypes of mine as well. Until now, I thought that it was due to bad quality materials, like unrated voltage capacitors. As a matter of fact, replacing the caps in one of my prototypes fixed that. However, the dongle had the rightly-rated caps from the start, so this should not be it. Having more than one prototypes that present the same issue means that the cause might be not in the materials, but somewhere in the design (although it shouldn’t, because this is very close to the manufacturer’s reference design). Another possible cause might be a bug in my Si3210 register settings or calibration procedure. All this means that I have to return (again) to an unpleasant session of hardware debugging in order to spot and fix the issue. Nevertheless, I am quite optimistic on this. If need be, I ‘ll consult some fellows I know who happen to have more expertise on electronics than I do. On the other hand, if, among all you readers (see how I make it sound as if this blog had a few thousands of readers, heh?) anyone can suggest some possible cause or some debugging methodology that will help spot the problem, I would be delighted to hear from you.