|
Technical Telecom Forum - Telecom Technician - Hardware and Techniques, Help Requests, News and Discussions
|
|
|
|
If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by Dan Lanciani on January 12, 2009, 1:11 am
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
|
|
Posted by Marc_F_Hult on January 12, 2009, 12:57 pm
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.
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
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
On 12 Jan 2009 22:04:49 GMT, ddl@danlan.*com (Dan Lanciani) wrote in message
MFHult@nothydrologistnot.com (Marc_F_Hult) writes:
>| 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.
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
Dan Lanciani wrote:
<snip>
> 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.
<snip>
> 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.
<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
|
| Similar Threads | Posted | | Panasonic Door phone distinctive ring question | October 29, 2009, 9:01 pm |
| Why does verizon cellphone voicemail pick up after the 5th ring, other times at the 1st ring. | October 14, 2008, 5:20 pm |
| WebRamp 200i firmware | April 8, 2005, 5:04 am |
| firmware download problems Avaya 2420 telephone | January 27, 2006, 12:26 pm |
| "Ring-master" in CA | March 28, 2005, 7:39 pm |
| First Ring Supression? | January 5, 2006, 10:23 pm |
| Looking For Used 016 Module With Ring Gen For Merlin System | April 14, 2008, 10:17 am |
| answering machine on partner plus system doesn't ring | May 21, 2008, 2:11 pm |
| Making incoming calls also ring a phone line in remote office? | April 23, 2006, 6:53 pm |
|
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map
>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