CallerID-compatible distinctive ring decoder firmware available
|
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||
|
Posted by Dan Lanciani on January 12, 2009, 1:11 am
Please log in for more thread options
distinctive ring services. Distinctive ring call routers normally do not connect quickly enough to pass the original caller ID signal (though some do for some ports some of the time). Recently I wanted a front-end for some Voip FXO ports that would route on distinctive ring and pass CallerID all of the time. I tried Command Communications latest product which buffers and resends the CallerID information after the second ring. It works, but the extra ring delay is noticeable and it also does a double- click of the relay when the port answers. This requires additional delay to avoid cutting off the beginning of the voice-mail greeting and the click is heard by the caller. Looking at the ring patterns used here (typical for a 5ESS I think) it seemed to me that it should be possible to make the routing decision during the first ring cycle and connect the line such that it sees at least half of that ring and the CallerID information. To test this theory I wrote replacement PIC firmware for the Multi-Link SR3. I used this device because I had one handy, the PIC was in a socket, and it was relatively simple to understand the device's operation. (My SR3--actually a modified SR2--is pretty old. I've ordered a new one to be sure they are compatible.) The result of my effort is replacement firmware that supports most of the normal features of the device (I do not generate the busy tones yet) and routes calls as described above. I've just put this into service and it appears to work so far. If anyone else is interested the firmware source is available on my home automation page: http://www.danlan.com/homeauto.html I used a PIC16F628 because that's what I stock, but the program is trivial and could run in a much simpler device. Dan Lanciani ddl@danlan.*com | ||||||||||
|
Posted by Marc_F_Hult on January 12, 2009, 12:57 pm
Please log in for more thread options  The problem that Dan identifies above is a principal reason for why I stopped using my SR3. Dan: If you'd like to test an older SR3 (serial # 3277xx), let me know and I'd be glad to send you mine along with return postage. Else, could you provide a PIC if I send you $10 and self-addressed stamped envelope? (I do AVR, not PIC). ... Marc Marc_F_Hult www.ECOntrol.org Visit my home automation and electronics Internet Porch Sale at www.ECOntrol.org/porch_sale | ||||||||||
|
Posted by Dan Lanciani on January 12, 2009, 5:04 pm
Please log in for more thread options MFHult@nothydrologistnot.com (Marc_F_Hult) writes:| On 12 Jan 2009 06:11:24 GMT, ddl@danlan.*com (Dan Lanciani) wrote in message | | >For some years I've used various work-arounds to combine CallerID and | >distinctive ring services. Distinctive ring call routers normally do | >not connect quickly enough to pass the original caller ID signal (though | >some do for some ports some of the time). Recently I wanted a front-end | >for some Voip FXO ports that would route on distinctive ring and pass | >CallerID all of the time. I tried Command Communications latest product | >which buffers and resends the CallerID information after the second ring. | >It works, but the extra ring delay is noticeable and it also does a double- | >click of the relay when the port answers. This requires additional delay | >to avoid cutting off the beginning of the voice-mail greeting and the click | >is heard by the caller. | > | >Looking at the ring patterns used here (typical for a 5ESS I think) it | >seemed to me that it should be possible to make the routing decision | >during the first ring cycle and connect the line such that it sees at | >least half of that ring and the CallerID information. To test this theory | >I wrote replacement PIC firmware for the Multi-Link SR3. I used this | >device because I had one handy, the PIC was in a socket, and it was | relatively | >simple to understand the device's operation. (My SR3--actually a modified | >SR2--is pretty old. I've ordered a new one to be sure they are compatible.) | > | >The result of my effort is replacement firmware that supports most of the | >normal features of the device (I do not generate the busy tones yet) and | >routes calls as described above. I've just put this into service and it | >appears to work so far. If anyone else is interested the firmware source | >is available on my home automation page: | > | >http://www.danlan.com/homeauto.html | > | >I used a PIC16F628 because that's what I stock, but the program is trivial | >and could run in a much simpler device. | > | > Dan Lanciani | > ddl@danlan.*com | | The problem that Dan identifies above is a principal reason for why I stopped | using my SR3. The funny thing is the SR2/3 comes closer than most. In two-port mode after one "learning" cycle it usually works. But in three-port mode in clicks the relays several times after guessing right, almost as if to ditch the CID data and/or delay the call. Were there any other reasons you didn't like it that I might be able to fix in firmware? One problem I had years ago was that the 48V charge pump was a little weak but I added some capacitors. | Dan: If you'd like to test an older SR3 (serial # 3277xx), let me know and | I'd be glad to send you mine along with return postage. Mine is from 1992 (S216779), so I'm really more worried that the new ones won't be compatible, but sure... | Else, could you | provide a PIC if I send you $10 and self-addressed stamped envelope? (I do | AVR, not PIC). I have to check something. The 16F628 that I use seems to be being replaced by the 16F628A and I don't know if I have to update the programmer or such. If there are issues I'd rather not deplete my supply of parts, so sending a PIC would be better. Dan Lanciani ddl@danlan.*com | ||||||||||
|
Posted by Marc_F_Hult on January 12, 2009, 7:51 pm
Please log in for more thread options On 12 Jan 2009 22:04:49 GMT, ddl@danlan.*com (Dan Lanciani) wrote in messageMFHult@nothydrologistnot.com (Marc_F_Hult) writes: It was the extra extra rings and noise experienced by the caller. Sometimes sounded like the CIA was checking in. </joke> The SR3 functionality for the fax line was replaced by a fax machine hooked up to the POTS line that itself recognizes distinctive ring. The third line is now VOIP. I no longer have the fourth line (cell phone) connected to the four-line Panasonic system. Putting the SR3 back in operation would eliminate having to listen to most of the irritating ringing from spam faxes and other illegal calls to the fax number. (FWIW, the Cell Socket Model 61622 from WHP Wireless Inc that I used for the cell phone connection is for sale through my Internet Porch Sale of excess personal gear at www.econtrol.org/porch_sale.htm .) ... Marc Marc_F_Hult www.ECOntrol.org | ||||||||||
|
Posted by msg on January 12, 2009, 6:56 pm
Please log in for more thread options Dan Lanciani wrote:<snip> > I tried Command Communications latest product <snip> <snip> Very nice! Have you ever looked at the TF series' firmware? I have made a point of stocking as many TF505, TF555, etc. boxes as I can find at Goodwill, rummage sales, etc. as they have been the most useful to me. They don't store and forward caller ID and I have had to use a modem or other caller id peripheral on the FXO port as a workaround. Since these devices detect call progress and fax tones I would hope that they could demodulate caller ID, but I never thought to R.E. them. Kudos on your approach; would that more folks publish hardware hacking efforts; seems to be on the decline these days. Regards, Michael | ||||||||||
|
Home Cabling Guide
Finally, an instantly downloadable book that saves you thousands in home improvement dollars! Enjoy living in 21st century technology-advanced home while increasing its selling value and competitive advantage on the real estate market. Whether your cabling is for home office or high-tech leisure, you can wire your home yourself or learn "wirish" to speak with your cabling contractors in their language! Click Here to learn more |
>distinctive ring services. Distinctive ring call routers normally do
>not connect quickly enough to pass the original caller ID signal (though
>some do for some ports some of the time). Recently I wanted a front-end
>for some Voip FXO ports that would route on distinctive ring and pass
>CallerID all of the time. I tried Command Communications latest product
>which buffers and resends the CallerID information after the second ring.
>It works, but the extra ring delay is noticeable and it also does a double-
>click of the relay when the port answers. This requires additional delay
>to avoid cutting off the beginning of the voice-mail greeting and the click
>is heard by the caller.
>Looking at the ring patterns used here (typical for a 5ESS I think) it
>seemed to me that it should be possible to make the routing decision
>during the first ring cycle and connect the line such that it sees at
>least half of that ring and the CallerID information. To test this theory
>I wrote replacement PIC firmware for the Multi-Link SR3. I used this
>device because I had one handy, the PIC was in a socket, and it was