Dongle and channel driver: a quick update

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.


7 Responses to “Dongle and channel driver: a quick update”

  1. Alok Says:

    Thats awesome work.small portable ,hope u get success soon in channel driver.Any help i can provide will be my pleasure.

  2. Angelos Varvitsiotis Says:

    Hi Alok,

    Thanks a lot for your kind words. I hope too I will get the channel driver working soon.

    I can use a lot of help from volunteers! Practice however has shown that it is not easy for someone to help at this stage. In order to help, one needs to have access to a working prototype board, and I only have three of them, out of which at the moment there is only one that works perfectly OK — the others show major or minor signs of misbehavior.

    So I cannot really send you a prototype — unless you would be happy to receive a problematic one and fix it on your own (in this case, pls. let me know). Otherwise, in order to help (e.g., contribute to the channel driver work), you ‘d have to construct your own board . If you indeed choose to do so, you are very welcome (in this case, please note that the older, large-size-form PCB is far better than the dongle for prototyping purposes). Otherwise, I ‘m afraid we will both have to wait until I build or order a number of working prototypes that I can distribute around.

    Please believe me that the lack of an adequate number of working prototypes is pissing me off too, exactly because it keeps me and volunteers like yourself from building up the elementary community that the Open USB FXS project really needs. Thus, I think that sooner or later I ‘ll order me a small stash of boards for this purpose (and when I do that, rest assured that I ‘ll post on it).



  3. Alok Says:

    Hi Angelos,
    Thanks for the Reply.I would really to want contribute with my knowledge whatever
    i have on this front . but surely will need prototype.

    Problem is making the PCB here(India) don’t have services like Elektor magazine,
    so probably have to build it on General Purpose PCB(SMD will be pain in the neck though)

    Another problem is getting in getting the SLICs but think it will not a hard find.
    Regarding controller I initially thought of AVR controllers as they are more readily
    available but will see one with USB.

    Regarding prototype I also could fix the one you have,but it will difficult for you to ship here , but If possible let me know how to send shipping & other charges to you.

    Also Are you in google code or sourceforge

  4. Angelos Varvitsiotis Says:

    Hi Alok,

    I will contact you with a private mail for the details on the prototype.

    I am not sure why you mention the AVR; it doesn’t have anything to do with the Open USB FXS circuit. Even at the design phase, I chose the PIC because it had a unique feature that wouldn’t let me replace it with any other microprocessor: it ticks a predictable number of machine cycles from the time an interrupt fires in h/w until the CPU jumps to the respective interrupt vector. This allows building very tight timing schedules using plain timers and interrupts, with no external hardware, which was precisely what I needed to do in this design. I am not saying that the AVR won’t do this, however I am quite unsure if it does. Anyway, probably the time for this discussion would be one and a half year earlier. Now the circuit uses a PIC, and this cannot change unless someone does a complete redesign, including hardware.

    The latest version of the code is on google code. Sourceforge contains a very old version, but the nice fellows there won’t let me delete the code, since they have a policy stating that, once a piece of code is posted on their site, it should remain there eternally. I found google code easier to manage, so I decided to move my code there, and then I found it was impossible to remove the code from Sourceforge. So I have placed a redirection reference from sourceforge to google code. If you look carefully, you ‘ll see it.



  5. Alok Says:

    Thanks Angelos ,
    You are right decision has to be made long back on that.Prob my working affinity on AVR made me said that.
    Got in google code.

    Now looking into that.


  6. Alok Says:

    Seems.No file has been added

  7. Angelos Varvitsiotis Says:


    You either have to svn checkout the code, or browse through it via and subdirs.



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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: