Chuck, I'm sorry for the timesink I'm about to introduce you to:
http://www.bitsavers.org/components/motorola/_dataBooks/ http://www.bitsavers.org/components/ti/_dataBooks/ http://www.bitsavers.org/components/national/_dataBooks/ Or you can just go to www.bitsavers.org for even more time consumption. On Thu, Nov 9, 2017 at 9:44 PM, Chuck McCown <[email protected]> wrote: > Back in the day, I was a bona-fide SLIC expert. Subscriber Line Interface > Circuit. I designed and built crap that interfaced with POTS lines. So I > knew just about everything having to do with dial tone circuits. Much of > the stuff was learned by reading data manuals. I had hundreds of them > Blue and brown from Motorola. Yellow from Texas Instruments. Gray from > Maxim. Navy blue from National. etc etc Good bed time readin’ > > *From:* Steve Jones > *Sent:* Thursday, November 09, 2017 9:19 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] ATA CallerID question > > Out of curiousity, i learn this nonsense from folks in the know. Where do > folks in the know learn this shit? Is it that they were involved in the day > when people in the service industry knew what they were doing, or prior to > mailing lists was there some analog solution center? Like did you old folks > hang out near your telegraph listening to everybodies conversations? Does > it boil down to some old chinese guy sending out coded messages or what? > Was at a customers joint the other day, an issue with ms rdp, end of the > day, it boiled down to remote connectivity, had to disable a tertiary > networks gpo printer and disable bitmap caching. I got this from google. > Seperate threads and a brain connection that this was the second remote > joint via vpn, and the two remote joints couldnt communicate. > Customer noted the google use, i told him its cause we dont have manuals > now. > Is the truth that some chinese guy just answers all our google queries now > and we are just corporate puppets? > > Is there only one really old rice eating fellow that actually knows the > answers? What if he dies? > Are we fucked if the chinaman dies? > > On Nov 9, 2017 4:46 PM, "Forrest Christian (List Account)" < > [email protected]> wrote: > > If you have call waiting, you'll often hear the caller id 'data burp' > after the first 'call is waiting' beep... > > On Thu, Nov 9, 2017 at 2:52 PM, Lewis Bergman <[email protected]> > wrote: > >> Remember, the signal comes between rings. Unless you are listening on a >> butt set in line or watching the info pass through a switch you wouldn't >> see or hear it. The only reason I remembered between first and second is >> sitting at a class 5 switch trying to figure out why caller ID was failing >> on a feature group D trunk group and seeing them come through after one >> ringy dingy. >> >> On Thu, Nov 9, 2017 at 3:46 PM Adam Moffett <[email protected]> wrote: >> >>> Is it at an inaudible frequency? If so, then it wouldn't make it >>> through 2600hz bandpass filters would it? Or maybe it's audible, but so >>> short you don't notice it? I'm fuzzy on this. >>> >>> I probably shouldn't ask. I don't need to know that much about POTS >>> anymore. >>> >>> >>> ------ Original Message ------ >>> From: "Lewis Bergman" <[email protected]> >>> To: [email protected] >>> Sent: 11/9/2017 4:40:57 PM >>> Subject: Re: [AFMUG] ATA CallerID question >>> >>> >>> More info than anyone probably wants to know. I found this about the >>> original question: >>> Caller-ID Signaling >>> >>> According to Telcordia specifications, CND signaling starts as early as >>> 300 mS after the first ring burst and ends at least 475 mS before the >>> second ring burst >>> >>> From here: http://www.tech-faq.com/caller-id.html >>> >>> On Tue, Nov 7, 2017 at 9:29 PM Adam Moffett <[email protected]> wrote: >>> >>> I did not know that tone contained modulated data. I just thought it >>>> was a noise you wouldn't ignore. >>>> >>>> That's a fun fact to have. >>>> >>>> >>>> ------ Original Message ------ >>>> From: [email protected] >>>> To: [email protected] >>>> Sent: 11/7/2017 4:39:27 PM >>>> Subject: Re: [AFMUG] ATA CallerID question >>>> >>>> >Monitor the line for the data burst. It is the exact same modulation >>>> >method as the emergency alert system you hear squawking on the TV >>>> >before the beep and thunderstorm warning. >>>> > >>>> >I think it comes before the first ring or right after the first ring. >>>> >Some of the original display units rectified and stored ring voltage >>>> >for power so it may need the ring first to power the display box then >>>> >the data. >>>> > >>>> >In any event, you can hear it if you have a butt sett with line monitor >>>> >mode. >>>> >Bell 202 is correct. >>>> > >>>> >-----Original Message----- From: Nate Burke >>>> >Sent: Tuesday, November 7, 2017 1:58 PM >>>> >To: Animal Farm >>>> >Subject: [AFMUG] ATA CallerID question >>>> > >>>> >At a customer, I just hooked up a Cisco SPA122 into an Ancient Lucent >>>> >PBX system. The customer says that caller ID is not coming through, >>>> >but >>>> >it used to work with his old AT&T Lines, and it appears to be hitting >>>> >the ATA Properly. Is there a setting on the ATA that needs to be set >>>> >that older systems may be looking for? >>>> > >>>> >The only settings I see for Caller ID in the ATA are Caller ID Method, >>>> >currently set to 'Bellcore(N.Amer,China)' and Caller ID FSK Standard, >>>> >set to 'Bell 202' I've never had to mess with those settings before. >>>> > >>>> >Nate >>>> >>>> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> > [email protected] | http://www.packetflux.com > <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> > <http://twitter.com/@packetflux> > > > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
