People seem to have liked a lot the dongle form of the board — thanks, folks! This blog keeps its promises (well, at least to a certain extent) and thus I have corrected a few things here and there in the board’s layout and I have uploaded the Cadsoft Eagle files to the project’s google code svn (here). Besides the .sch and the .brd file, you can find also a BOM Excel sheet (with Farnell product codes for many of the parts — but, depending on the part of the world where you live, you might prefer looking these up at Digikey, Mouser, etc.) and two .lbr files. One contains the Eagle device for the shielded choke L1 and the other one contains the Eagle devices for the 3210 and the 3201. I have not found TSSOP-38 packages available elsewhere, so people may find these useful.
Among the corrections I have made were many text moves in the tNames layer, so now most parts’ names don’t coincide with vias as they used to and should be printed OK on the board’s silk-screen. One other change I made was that I changed the board-edge connector with a 2×3 pinhead, which is much easier to work with. Parts on the bottom-side of the board were moved slightly to make room for the new, larger connector, however other than that, no significant changes have been made.
One word of warning: although the changes I made were minimal, the new board is yet untested. There is still one medium-importance issue with the dongle board that I have tested, and this is that the 3210 gets hot over time (it reaches something like 60o C, and I have not left the board plugged-in for too long to see if it will eventually burn). Maybe this is due to the placement of components, so if my next dongle board gets hot too, I will have to either take the 3210 away from the PIC (they both dissipate heat, and them two being one atop the other is probably what gives the poor 3210 a hard time) or somehow add a heat sink. With this caveat, the dongle design is OK, so I have uploaded all the relevant material.
So far, I have been working alone in this project. However, there are a few signs of interest from people occasionally volunteering to help in one way or another. This gave me the idea of creating a poll to see if you, the readers of this blog, would like to get your hands on a board and try for yourselves how things work. So, if you ‘d like to participate in the project and help out with further development, please fill in the questionnaire below.
The poll is anonymous and will serve just to help me in ordering an appropriate quantity of materials to be able to make/send a board to those who would like to help (should I finally choose to do it, something that I am not promising to do). You will not assume any obligation by replying in the poll. You will not order anything online, nor will you pay anything. You will not even need to promise anything, like that you will help. You will just express a wish, and even that will be anonymously. On my part of the deal now, I am not obliged anyhow to fulfill your wish. I am just trying to see if people would like to help the project and what I can do to help them help it. That’s all.
Please do note that I am not trying to make any money out of this. At its current stage, Open USB FXS is not a useful product and will definitely not serve any purpose other than experimentation and further development. It would be unethical for me to promise otherwise and try to make profit out of this. This means that, provided that readers show some interest in getting their hands on a board and assuming I choose to send over some boards after the poll results, I am going to publicize (my) cost of materials and ask interested readers to cover exactly that cost, not a single penny above. All that said, here is the poll.
Back on the code front, I am now working to resolve some firmware bugs that I have found. I will report on these in my next post. Besides firmware issues, I have been trying to come up with the Asterisk channel driver, doing dutifully my daily reading and digesting screenful after of screenful all the Asterisk channel driver code I could. While reading on, I started again to hesitate between writing my own very simple channel driver on the one hand, and trying to go back to the Linux driver and produce a Dahdi/Zaptel-compatible driver on the other [note: I am using D/Z to refer to Dahdi/Zaptel in this post].
You see, in Asterisk, an awful lot of functionality available for D/Z devices has to be (also) implemented in the channel driver: call waiting, call transfer, multi-way voice conferencing, caller id, and many other “smart” PBX functions have to be supported by the channel driver or else they won’t work at all. So, was I really in the right track trying to rewrite all of this on my own? On the other hand, trying to make my driver D/Z compatible looks daunting as well, since I have come to master at least the elementaries of a D/Z channel driver, but I am quite ignorant of the structure of a kernel D/Z-compatible driver. But it looks there is a structure, and eventually it should not be extremely hard to follow that.
More on that in my next post. It should not take to long!