Astral wars

Tell me the truth: did you really think I was going to sit idle, drinking beer and celebrating my first Asterisk call? Naaahhh, I didn’t think so myself… That first Asterisk call made me so restless that it was impossible to abstain from hacking on the project. So there is lots of news.

Before all else, please let me spend a few words on the title of this post. “Astral weeks” has been the title of an album from Van Morison, which I used to like a lot (that was in the previous century, though). And I guess that everyone knows what “Star wars” refers to. I wanted to use “star wars” as a title to refer to my first combats with the star-named PBX, but I found “astral” much more poetic (yes, the old 60’s and 70’s rock-n-roll songs seem to be a recurring motto in this blog). Why “wars”? Well, I was to fight with the Beast, and although bloodshed was less severe than I expected, every war has its casualties (in this case, just a board, read on for the details). The news from the front are both good and bad. Although I prefer to listen to the bad news first, when it comes to battlefront news, I think it is best to report them in their chronological order. Here they are, then:

Item #1 (good news): As I reported in my previous post, I was able to place an Asterisk call over VMWare using my board. The audio quality was lousy, but I guessed (correctly, as it will follow) that VMWare was the culprit for that. Then I wrote the previous post.

Item #2 (good news): I assembled a dongle board using my version-2 design. The actual assembly was finished before the Asterisk test, but I had not had the time to test the new dongle before my previous post. So, the good news is that the dongle worked fine (at first, as it will follow). The heat problems seem to have vanished and I was able to run all the tests (like ringing the phone, inputting and outputting ulaw samples, dtmf, etc.) without any issues.

Item #3 (good news): I tried installing my new driver and running Asterisk over it on a native Linux installation (Ubuntu/wubi). The sound quality was really good, and there were no clicks or other signs of USB packet loss. Great!

Item #4 (bad news): DTMF works intermittently. At times Asterisk understands the dialed digits, at other times it does not. As David Rowe pointed out to me in a private email of his, this might be due either to distorted/clipped IN audio, or to the lack of an echo canceller (I have not added an echo canceller yet). I think that the most plausible explanation is the second one, because at the absence of an echo cancellation process, the OUT signal may garble the IN tone so that it becomes unrecognizable.

Item #5 (particularly worrysome): The symptom of DTMF not being recognized is board-dependent. My older, large-form board worked fine, however the (hot, version-1) dongle board proved to be problematic. As to my (corrected, version-2) board…

Item #6 (bad news, but not so bad after all): … the second board decided to succumb to its wounds during the Asterisk tests. While initially working (with intermittent and problematic DTMF recognition, but otherwise working), the board suddenly started to refuse to power up the DC-DC converter, the phone did not ring, etc. It now steadily refuses to power up the converter during the first go, it then succeeds on a later try, but VBAT drops very low (-9V) as soon as the linefeed is set to “forward active”. This looks like the converter cannot supply enough current to the circuit or there is a power leak somewhere. News is not so bad after all, since the board has worked for a while, however it makes me worry about design issues. I ‘ll have to either hardware-debug the board, or assemble a new one (I tend to choose the second alternative).

Item #7 (good news): I was able to place a call through an IAX connection to Digium’s server (500 from the main pre-installed demo IVR menu), and the call went perfectly OK (apart from an expected audio quality degradation due to a flaky Internet connection at the place where I work, I was able to hear to the full voice message from Digium’s server).

Item #8 (bad news): My driver is still missing a hook state debouncing algorithm, so funny things happen from time to time, with the funniest one being that Asterisk occasionally interprets back-on-hook as a “flash” event (momentary off-/on-/off-hook transition). Funniest thing, this happened during the IAX call to Digium, which I managed to place into a three-way conferencing state. Yes, Open USB FXS can do three-way conferencing (like any other dahdi hardware)!

Item #9 (good news?): I have placed all the newest driver code, Eagle files, etc. on the project’s Google code site. If you wish to compile the new module, you have to place it into a directory named /usr/src/dahdi-2.2.XXX/drivers/dahdi/oufxs/ and either issue “make” within that directory, or add “oufxs/” (without any other path component) to EXTRADIRS and issue a “make” from the top Dahdi directory (/usr/src/dahdi-2.2.XXX). The plain “make” inside the oufxs directory failed on my Ubuntu tests. In Ubuntu, you need to modify the “dkms.conf” file provided with the dahdi source. I have not yet uploaded a modified dkms.conf, but I will. A word of warning: if you plan to produce your own PCB from the newest (v-2) dongle Eagle files, please take into account that (a) the only such prototype I ‘ve made has failed and (b) the LED and RLED should be swapped to place the LED under the RJ-11 plug. Also, an updated BOM is now in place. Please consider all the upload code and other files as drafts and don’t shoot me if they don’t compile on your system.

Item #9 (good news): After all, if I manage to assemble some working dongle-v2 prototypes and get the DTMF working with them, I think I am going to produce a limited number of dongles (ready-made or DIY kits) at nominal price for interested people to get. I am getting myself organized and will post details soon.

All the above sound like Open USB FXS is slowly conquering the star-land. It may be just ambition, it may be the reality. The next days will show and a soon-to-be post is due as soon as something significant occurs. The next steps are to assemble a couple of dongle-v2 prototypes, to get hook debouncing and to do something with the echo cancellation, then re-test. Expect to have news, sooner or later, and let’s hope it’s going to be exclusively good news this time!

Update, May 2: I am currently looking at the changes I need to make to involve (correctly) an echo canceller. I think that the best way is to work along the following lines. In order to keep a consistent time difference between OUT and IN samples, I need to keep track of the number of samples sent and received. To this, it is vastly more convenient to have the same number of samples (or “packets” in oufxs.c terminology) per URB. Currently, the driver allows module parameters for setting these two independently. This was a great tool for debugging and tuning, but I think the two distinct parameters are not really needed anymore. So, I will merge the two distinct set of module parameters and associated variables into one. After that, I will just need to keep track of an offset between URBs that are sent OUT and the respective IN ones. Normally, this offset should be constant, however the board may delay the receipt of an OUT USB frame, so I need to look carefully at this, using the mirrored sequence numbers to resynchronize in the case of delayed or lost USB frames (note, this was a real issue before I hacked the clock of the ISR to be consistent with the USB SOF frame rate, but normally it should not happen anymore — need to check though). After getting this inter-URB offset, I think that just invoking the echo canceller will be trivial. Basically this is it; however, the devil always lies in the details, so I will report more as I ‘ll be going through my plan. Let’s see.

Update, May 3: In the meantime, I have assembled another two V2 dongle boards. The results — at least for those who see the glass half-full —  are not discouraging: one of the two new boards worked right away, showing no excessive heat issues. The other board failed in an early test stage (problems in communication between the PIC and the 3210, which usually translates into a problem in the PCM bus and especially the FSYNC signal, which in turn means a badly soldered 3210 pin or a totally damaged chip). Both boards might be fixable, but this means time-consuming labwork to diagnose the problem and perform surgery to the failed board. That is, things that I could not possibly do in a production line.

Let me summarize: out of three V2 dongles, one died while on duty (DC-DC converter issue), one worked perfectly well (so far…) and another was found dead in early testing. I don’t know if all this sounds satisfactory to you, however, if I were to read this blog, I would tend to say that the hardware is problematic. I don’t know if this is due to hand-soldering, so that I can expect better rates when I get to mass-produce boards. The experience of readers w.r.t. similar projects would help me there. You see, I am reluctant to go and order a quantity of assembled boards from some assembly factory if rate of dead boards is expected to be 50% or even more… If, on the other hand, hand-soldering delicate SMD materials is known to cause a high rate of damaged boards compared to what one can expect from an industrial grade assembly facility, then I am probably OK to go on (OK, after trying and possibly incorporating the patch proposed by Gabor). Moreover, this means that a DIY kit will have high chances of resulting into a brick circuit, a situation that will eventually kick back to me for providing the DIY option to the blog readers, even at a not-for-profit price. What do you, blog readers, think about this?

On a different course now: I am progressing with the driver. I have implemented hook debouncing and am going to test it soon. And, I have put some more thought into the echo cancellation issue. Fortunately enough, I already have sequence numbers in my USB packet headers. I can use these to deduce the actual OUT sample that is being acknowledged by each IN sample, so that I can match the two when calling the echo canceller. In addtion, I think I can fix this mapping between sequence numbers and samples to be static, so I won’t need to update it (thus, I will need no complex structures and locking).

I will report more on this a bit later; for the time, what I would appreciate very much would be to receive some comments on the dead boards issue, in particular from people who have experience in similar projects.


10 Responses to “Astral wars”

  1. Robert Boerner Says:

    Congratulations on your success. Please let the world know when you have the kits/ready-made units for testing. I would be very interested in buying one.

  2. Angelos Varvitsiotis Says:

    Hi Robert,

    Many thanks for your comment and your encouragement. I am already looking around for a local partnership to help me in production and shipment of a first “wave” of boards/diy kits. Soon I am going to post some news w.r.t. planned activities and maybe some availability dates.



  3. sean Says:

    forgive me if this is a stupid question, i’m a programmer not a EE.
    i know the 3210/3201 combo can do either fxs/fxo and i’ve looked at the
    schematic. but, i since i’m not a EE i don’t really understand what’s going
    on with all the discrete analog components outside of the si 32xx chips.

    is there any *hardware* reason this unit couldn’t be repurposed as an FXO device
    as long as the proper firmware and driver changes were made?

    in the faq there’s a discussion of adding an fxo to the device in addition to
    the existing fxs which would obviously be less expensive if you want both since
    the fxs & fxo could share a single usb port(assuming the pic is fast enough
    to handle both). but, the faq talks about needing a bi-stable relay.
    what is the bi-stable relay needed for?

    anyway, thanks for developing this, and i’m looking forward to being able to
    buy a kit.


  4. Angelos Varvitsiotis Says:

    Hi Sean,

    Thanks for your comment. I am not an EE either: my Diploma degree is in Computer Engineering (and I have a PhD in EE, but in a totally different area, protocol testing). From just reading the data sheets, however, I think that the 3210 cannot act as an FXO subscriber line controller. It is the 3211 that is designed for that purpose. Both chips, 3210 and 3211 are described in the same data sheet, however there are vast differences between the two. The line driver chip, 3201, is common in both applications (FXS/FXO). So, to answer your other questions: in order to have dual FXO/FXS functionality in parallel, one should use one 3201, one 3211 and two 3201’s, and lots of PIC assembly magic to squeeze servicing two PCM bus slots within the computing limits of the PIC. The design with the bistable referenced in NQ-FAQ is a proposed alternative that does not include or involve an FXO port. In this design, the bistable would switch the phone between the PTT line and the FXS port. Its usefulness would be the sharing of a single phone set between two lines, one provided by the PTT, and the other being the Open USB FXS port, e.g. on a VoIP subscription. However, with such an application, one could not, for example, have Asterisk receive a voice message from the PTT line while simultaneously making a VoIP call. At best, such a circuit could simulate a loop close condition and thus trick the PTT into returning a busy signal to any callers while the phone set is engaged in a VoIP call. I hope this clarifies the situation a bit?

    W.r.t. kits and boards, I am going to announce some news soon. BTW, I wish to thank you — and everyone else, indeed — for their patience until now.



  5. vlaero Says:

    what are your thoughts on connecting your dongle to routers running linux? There are a number of cheap devices with USB such as the Asus wl-520gu that could be used to locate a VOIP phone somewhere around the place by configuring the router to be a wireless client.
    The wl-520gu is getting expensive these days so a more capable device like the tp-link TL-WR941ND is available at a similar price.
    I’d imagine that the router would need to run something like dd-wrt or openwrt.
    Obviously your focus has been an asterisk driver but in the scenario above if you wanted to have some software on the router to connect to SIP voip provider what would you use? I understand asterisk can be put onto the better specced routers but in the case like I just mentioned I don’t think full PABX software is required.
    What are your thoughts?

  6. Angelos Varvitsiotis Says:

    Hi vlaero,

    I have not been able to find any support for USB on the TL-WR941ND, however your argument is valid for many other similar devices. Asterisk may indeed prove to be an overkill for platforms like that. An alternative might be to try combining Open USB FXS with a simple SIP client. Probably beyond my capabilities and for sure beyond my current time budget for this project. If however you are — or anyone else is — interested in exploring this direction, I ‘ll try to provide all the help that I can.



  7. vlaero Says:

    Angelos, from what I have been reading the TL-WR941ND v4 appears to have usb on board but no connector is present on the device. I have a TL-WR1043ND and it does have USB on board – in addition to gigE.
    I have just loaded a dd-wrt build on it and it appears to be working OK.
    The device can run asterisk OK – there are openwrt opkg packages available. Might be an interesting platform for you to test on?
    I’ve had a look for some simple sip cleints that might run on a router but am coming up empty.
    Keep up the good work.

  8. Angelos Varvitsiotis Says:

    Hi vlaero,

    Thanks for the update! Yes, sure, it is an interesting platform for testing the performance of Asterisk with Open USB FXS. My feeling is that it is going to do fine; maybe some IRQ tuning will be required. I don’t have such a device, and I don’t really know if I am going to buy one just to do this testing myself, but if you ‘d like to volunteer, please let me know and I ‘ll contact you in private to discuss what can be done to help you.

    As to SIP clients, most are softphones that use some graphics front-end (GTK, for instance) and a PC’s sound card to provide functionality similar to that of a phone set. I don’t know if openwrt provides any graphics support, but my first guess is that graphics toolkits are a bit out of scope for a router. Nevertheless, all these SIP softphones use a SIP stack and, in principle, one could remove all graphics calls and use the native Linux driver that I have initially written (“openusbfxs”, not “oufxs” — the latter is the Dahdi/Asterisk-specific driver, while the former is a generic driver) to hook the SIP functionality in. Not a trivial task, definitely, and not anything that you could expect to find ready out-of-the-box and plug into your router. One might also contact some softphone authors to see if they would be willing to hook their softphone to a hardware FXS port on their own. I guess that some might find it a good idea.



  9. vlaero Says:

    The latest openwrt does actually have xorg working. See the release notes:
    I’m not sure what you are getting at with this though. Are you suggesting X redirection to bring up the gui on a remote workstation or something?
    I was thinking more along the lines of providing functionality like the Billion VOIP routers have. They provide an fxs port on board and you just use the web interface to the router to configure the inbuilt sip client.

    I think the mesh potato project guys are using this:

    I’m happy to put another firmware on one of my devices to test some things. I have an Asus wl-500gpv2 and a wl-520gu in addition to the new tp-link router. Feel free to contact me.

    I’ve just had a look at the package lists for the latest openwrt. asterisk14-mini is there as is miax – which is described as:
    miax is a console iax (asterisk) client

  10. Angelos Varvitsiotis Says:

    Hi vlaero,

    Thanks for the update on openwrt. Probably there is some sort of misunderstanding in this discussion. What I tried to say was that if one does not need the full PBX functionality of Asterisk (or Asterisk proves to be too heavy for the CPU of some cheap-n-small wireless router), one could in principle get rid of Asterisk altogether and use instead some SIP soft phone software, which would then need to be modified into a “hard phone”. On a desktop or laptop, soft phones use the keyboard, the mouse, the sound card and the graphics system. On a small device, like a <$100-cost router, these devices simply do not exist (no keyboard, no mouse, no sound card and no screen), but as you say, an Open USB FXS dongle board could be fitted on, so the router might obtain a “native” FXS port. The soft phone code would thus have to be modified in order to use a Open USB FXS card instead of the screen/mouse/audio/graphics. As I already said, not an easy job.

    Please note that the web-based GUI tool like mini-asterisk, used for configuring a box, is a totally different story (you would need that sort of tool anyway to remote-configure a box, but it has nothing to do with the operation of the box after it has been configured). Moreover, the availability of in openwrt does not contribute too much here, since it does not change the fact that the devices we are discussing about do not have a screen. I don’t know if my argument has become any clearer now (or if it makes much sense anyway), however I ‘ll contact you in private in case you would be interested in discussing the issue more in detail, as well as w.r.t. testing (btw, many-many thanks for volunteering to test on your boxes!).



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: