CallerID-compatible distinctive ring decoder firmware available

[*com (Dan Lanciani)]

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
***@danlan.*com

[Marc_F_Hult]

Post by *com (Dan Lanciani)
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
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

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

[*com (Dan Lanciani)]

In article <***@4ax.com>, ***@nothydrologistnot.com (Marc_F_Hult) writes:
| On 12 Jan 2009 06:11:24 GMT, ***@danlan.*com (Dan Lanciani) wrote in message
| <***@news1.IPSWITCHS.CMM>:
|
| >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
| > ***@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
***@danlan.*com

[Marc_F_Hult]

Post by *com (Dan Lanciani)
| 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

[msg]

Dan Lanciani wrote:

<snip>

Post by *com (Dan Lanciani)
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>

Post by *com (Dan Lanciani)
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

[*com (Dan Lanciani)]

My new SR3 arrived and I'm pleased to report that the design hasn't
changed and my firmware runs fine on it.

I've slightly updated the code to reduce some delays and add one feature.

If trunc3 is defined the trailing short ring of pattern 3 will be deleted.
This means that the first ring seen by any port will be a single burst of
between about 1/2 and 1 second. This is useful for me because the FXO
ports I'm feeding (Cisco NM-HDA) need to be told after which ring to
expect the caller ID information. If you get it wrong they either miss
the information or delay the call. The NM-HDA sometimes sees the trailing
short ring of pattern 3 as a separate ring and sometimes not, so there is
no correct setting. Deleting that ring allows the port to work reliably.

Dan Lanciani
***@danlan.*com