CallerID-compatible distinctive ring decoder firmware available

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:

formatting link
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

Reply to
Dan Lanciani
Loading thread data ...

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

formatting link

Visit my home automation and electronics Internet Porch Sale at

formatting link

Reply to
Marc_F_Hult

| >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: | >

| >

formatting link
| >

| >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

Reply to
Dan Lanciani

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

Reply to
msg

It was the extra extra rings and noise experienced by the caller. Sometimes sounded like the CIA was checking in.

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

formatting link
.)

... Marc Marc_F_Hult

formatting link

Reply to
Marc_F_Hult

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

Reply to
Dan Lanciani

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.