Gary, Your comment is a valid one at the copper interface. However, the telephone call set-up, content and tear-down have also to be considered. There is a trend with PC modem cards, to transfer most of intelligence back to the host CPU. There is now software that will permit the PC user, via a modem card, to talk to someone else on a normal POTS phone. Several sections of FCC part 68 are there to ensure that the person at the other end of the call does not have their eardrums damaged. Also, if the software controlling the phone line interface "forgets" that it is in a call, you could still be incurring call charges, even though the original application program has terminated.
So, if you take this to a logical conclusion, the motherboard, BIOS, operating system, drivers and even a screensaver application could be telephone network affecting. It is very difficult to know where to draw the line. The hardware part of the full signal path is usually well defined, but the complex interaction of software generates the headaches. It would be nice to have a simple solution to Ilan's problem, but unfortunately I must leave it to those wiser and more knowledgeable than myself. Regards, Geoff Lister Senior Engineer Motion Media Technology Ltd., Bristol, UK. http://www.motion-media.com -----Original Message----- From: Gary McInturff [mailto:gary.mcintu...@worldwidepackets.com] Sent: 14 November 2000 20:30 To: 'Maxwell, Chris'; emc-p...@ieee.org Subject: RE: FW: Compliance of a USB telephone Chris, Chris, Chris. How can I get the flames of discontent spreading around the globe if you are always mediating things - heavy sigh! Richard made a very similar point this morning and I don't have a problem with testing to the EMC and Safety standards. Do it all ready - I just do it as ITE equipment. We make things that can have a real phone input, but we don't make the phone- and it only has a fiber optic output. The real problem not the tests because they quickly get thrown out once the product is analyzed in detail. The problem is the TCB's CABS, customs agents, and the lot wanting to see additional tests - like lightning surge tests that are called out by a standard that doesn't apply. I could send the equipment off to have them verify it under the RTT & E directive or and FCC part 68 all they can really say is that some tests don't apply because it lacks the copper interface - USB phones have no copper leaving the premise so the lightning surge doesn't apply for example. If you drop all of those tests in the RTT & E that don't apply what you end up with just the safety and ITE tests. I knew that before we started so all that has been accomplished is that we have just gone full circle, spending time and money just because a directive "seems" or "wants" it to apply. I already have these arguments with the safety guys who want to apply lots of things out of section 6 of the EN 60950 or UL 60950 standards that are there only to protect the copper connected interface - snort! So my objection is not tests required for RTT&E, if it is actually some sort of terminal then I would jump through all of the appropriate hoops, but when it's not a terminal I don't want to waste my resources. Gary By the way there is a secret hidden advantage to fiber underwear that you just don't get with plastic. -----Original Message----- From: Maxwell, Chris [mailto:chr...@gnlp.com] Sent: Tuesday, November 14, 2000 8:34 AM To: emc-p...@ieee.org Subject: RE: FW: Compliance of a USB telephone My company doesn't have any USB products (yet), so I'm just an innocent bystander. But sometimes a bystander can provide a "mediating" point of view. (or maybe stir things up a little) What if I were to play devil's advocate? What if we assume that the R&TTE directive did apply? What if we also assume that the product has been EMC tested in accordance with ITE EMC standards and meets EN 60950 for safety? What more could the R&TTE directive want? Since the USB connection is so indirect, I can't see where there will be any problems with isolation from TNV circuits, or with ringer equivalence ratings, or with power cross , power induction, surge ... The modem card would take all of this responsibility. Actually, in modern times we have to assume that there is any electrical connection between the PC and the network. It's very possible that this USB device could be connected to a computer with a wireless or cellular modem. It doesn't sound like the product is an intentional radiator, so I can't see any reason to consider the "radio" portions of the R&TTE directive. Even in the cellular case mentioned above. All of the radio requirements would be taken care of by the cellular modem's approval. So, if we assume that the device already meets ITE standards for EMC and Safety? What more testing would the R&TTE directive require? I'm just wondering if the device would be subjected to the same technical standards and tests no matter which compliance path is chosen. I'm also wondering how the term "indirectly" is interpreted. For instance, my electric table saw uses the same Earth ground as my phone. Are they indirectly connected? A computer monitor displays the information that is transmitted over the internet to the computer. Does this mean that the monitor is indirectly connected? It's just as connected as the USB phone, isn't it? What about the computer's speakers that can play sound bites that are delivered over the internet? There has to be a cutoff somewhere. I'm sure that there must be a "guideline" document that defines this some more. If there isn't, there should be. By the way, Gary, what is the UL flame rating of asbestos underwear? I think maybe Nomex would be more comfortable :-) The opinions expressed in this email are the result of my genetic background combined with the environment in which I grew up. My employer (and my parents) cannot be held liable. Chris Maxwell, Design Engineer GN Nettest Optical Division 6 Rhoads Drive, Building 4 Utica, NY 13502 PH: 315-797-4449 FAX: 315-797-8024 EMAIL: chr...@gnlp.com > -----Original Message----- > From: wo...@sensormatic.com [SMTP:wo...@sensormatic.com] > Sent: Tuesday, November 14, 2000 8:23 AM > To: emc-p...@ieee.org > Subject: RE: FW: Compliance of a USB telephone > > > Let's think about this logically. I have a PC with a microphone and > speakers > that allows me to speak with persons using the internet. Does that mean > that > my PC, monitor, keyboard, microphone and/or speakers form part of a > telecommuncations terminal. I don't think so. Now I get smart and replace > my speaker and microphone with a headset. Has anything changed? I don't > think so. Now I decide to change out my headset for a handheld device that > includes a microphone and earphone. Has anything changed? I don't think > so. > > Richard Woods > > ---------- > From: H.T. Hildering [SMTP:h.t.hilder...@ktl.com] > Sent: Tuesday, November 14, 2000 4:07 AM > To: Gary McInturff; 'Allan G. Carr'; emc-p...@ieee.org > Subject: RE: FW: Compliance of a USB telephone > > > Dear all, > The R&TTE is meant for terminals. If my message was not clear enough I > repeat here once again the R&TTE scope (see below). I disagree with Gary > regarding his statement that an USB telephone, computers and other > indirectly connected stuff are not falling under the R&TTE scope > (connected directly or indirectly by any means whatsoever whatsoever to > interfaces of public telecommunications networks). > > Just read for yourselves what is stated in the R&TTE and conclude for > yourselves. > > > > >"telecommunications terminal equipment" means a product enabling > >communication or a relevant component thereof which is intended to be > >connected directly or indirectly by any means whatsoever to interfaces of > >public telecommunications networks (that is to say, telecommunications > >networks used wholly or partly for the provision of publicly available > >telecommunications services); > > > Perhaps you were confused by the former TTE directive. Indirectly > connected > equipment was excluded under that directive, but that's history now. > > > > Best regards > > Theo Hildering > KTL > > -----Original Message----- > From: owner-emc-p...@ieee.org [mailto:owner-emc-p...@ieee.org] On Behalf > Of > Gary McInturff > Sent: 14 November 2000 00:01 > To: 'Allan G. Carr'; emc-p...@ieee.org > Cc: H.T. Hildering > Subject: RE: FW: Compliance of a USB telephone > > > Allen, > I agree fully with you. The response below, and in particular "Only > when it is IMPOSSIBLE to reach a public network, ..." is wrong for a > couple > of reasons, but principally ignores the obvious. The USB (and IP) phone is > nothing more than a computer peripheral just like a printer or monitor and > cannot reach the public phone system. Even if the signals did exit first > the > phone, then the computer, and then some IP switching system and if, and > that > is not a certainty, the signal is then sent through a metallic contact to > the public phone system it is that interface that must meet the RTT&E > directive. The phone is at least two devices removed from metallic access. > More explicitly using the USB phone example. A USB interface doesn't > connect to any public phone system, it can't. At a minimum it doesn't have > the right connector. The device it plugs into, the computer itself, is > also > incapable, again as a minimum it doesn't have the right connector. In the > best case an internally installed modem would be the first point at which > the RTT & E directive can be applied. Even then one should not confuse > what > is actually being certified. It is the modem not the computer that is > powering the modem that has to meet the requirements. Modem manufactures > attest to the RTT & E regulations by using a computer in a type test but > they sure don't test one of each type of computer that is manufactured in > the world that happens to have a bus that will accept the modem. > Following the "Only when it is IMPOSSIBLE...." dictum would say that > all computers should meet the RTT&E directive because somebody MIGHT put a > modem in them. Good for test labs, not so good for product prices. > Nor should there be any concern that the public phone system is > being left vulnerable. There indeed is a point at which all of these > devices, USB, IP or whichever, MAY be routed to the public phone system > through some metallic contact, but those devices at which that actually > happens are subject not only to the RTT&E but FCC part 68 among others. > If it doesn't look like a duck, and it can't quack then it probably > isn't a duck. > I have my asbestos underwear on - fire away. > > Gary > -----Original Message----- > From: Allan G. Carr [mailto:e...@agctel.co.uk] > Sent: Monday, November 13, 2000 7:07 AM > To: emc-p...@ieee.org > Cc: H.T. Hildering > Subject: Re: FW: Compliance of a USB telephone > > > > Theo > > I thought I should post the consensus of our discussion on the > applicability of the R&TTE Directive for the avoidance of doubt by other > readers of this newsgroup. > > The R&TTE applies to TERMINAL equipment - that is equipment connected on > the subscribers side of the NTTP (Network Test and Terminal Point). > Therefore a modem in a users home is covered by the R&TTE as would a > modem used by a company that does not have a telecommunications > operators licence. > > It does not apply to NETWORK equipment - that is equipment on the > network side of the NTTP which is owned by the PTO (licensed Public > Telecommunications Operator). Therefore an ISP's (Internet Service > Provider's) modem, typically rack mounted and sited in the local > exchange, is Network equipment and is not within the scope of the R&TTE. > > This difference may seem academic as there are no Telecommunications > Terminal Equipment specifications designated under the R&TTE Directive > and safety to EN 60 950 applies on both sides of the NTTP but the EMC > specifications are slightly different. > > EN 300 386-2 "Electromagnetic compatibility and Radio spectrum Matters > (ERM); Telecommunication network equipment; Electro-Magnetic > Compatibility (EMC) requirements; Part 2: Product family standard" > applies to Network equipment but not to Terminal equipment. > > > Hope this helps > > > Allan > __________________ > > In article <EDFA411E5E4AD2118D6F00A0C99E4BAC01DF752E@FLBOCEXU02>, > wo...@sensormatic.com writes > > > >Forwarding a reply > > > >---------- > >From: H.T. Hildering [SMTP:h.t.hilder...@ktl.com] > ><mailto:[SMTP:h.t.hilder...@ktl.com]> > >Sent: Friday, November 10, 2000 11:49 AM > >To: wo...@sensormatic.com <mailto:wo...@sensormatic.com> > >Subject: RE: Compliance of a USB telephone > > > >Sorry for my late reply. > >For applying the R&TTE directive, the intended use is the crux. I wander > or > >it is possible nowadays - if computers are connected to the internet- , > to > >deny that it is not intended for communication using the internet; for > >example using Voice over IP! > >I would say that every computer (and connected equipment), that can > >communicate to the internet is falling under the scope of the R&TTE. > >Consider for yourself what is stated in the R&TTE directive: > >"telecommunications terminal equipment" means a product enabling > >communication or a relevant component thereof which is intended to be > >connected directly or indirectly by any means whatsoever to interfaces of > >public telecommunications networks (that is to say, telecommunications > >networks used wholly or partly for the provision of publicly available > >telecommunications services); > >Only when it is IMPOSSIBLE to reach a public network, the R&TTE is not > >applicable. > >The consequence for the USB telephone is that there are no restrictions > on > >the power voltage (as stated in the LVD), so the telephone must fully > comply > >with all the requirements as mentioned in the safety directive(for > example > >acoustical shock) > > > >Best regards, > >Theo Hildering > >KTL > > > > > > > >-----Original Message----- > >From: owner-emc-p...@ieee.org <mailto:owner-emc-p...@ieee.org> > >[mailto:owner-emc-p...@ieee.org] > <mailto:[mailto:owner-emc-p...@ieee.org]> > >On Behalf Of > >wo...@sensormatic.com <mailto:wo...@sensormatic.com> > >Sent: 02 November 2000 19:29 > >To: ico...@itl.co.il; <mailto:ico...@itl.co.il;> emc-p...@ieee.org > ><mailto:emc-p...@ieee.org> > >Subject: RE: Compliance of a USB telephone > > > > > >Let me see if I understand this product. It is a telephone like device > that > >is solely intended to be connected to the USB port of a PC and it is not > >intended to be connected to the telephone network. > >If this is true, then no telephone standards, regulations or directives > >apply. Only the EMC directive applies in the EU. The RTTE directive does > not > >apply since the device is not intended to be connected to the telephone > >network. The LVD does not apply since the source voltage is too low. > >Compliance with safety requirements of EN60950 is sufficient to show due > >diligence for the Liability Directive and General Product Safety > Directive. > > > > > > > Dear Group > > > > > > We are testing an PC telephone unit! > > > > > > It is a telephone terminal unit that connects to the USB port > of > >the PC from > > > which it receives power. There is no other connection, just the > >USB. > > > > > > Clearly this unit must comply with EMC requirements. Safety > >requirements are > > > not mandatory but clearly they are recommended to be performed > >for > >UL1950 > > > for the US and EN60950 for Europe. > > > > > > Two questions: > > > > > > 1) What about Part 68 in the US? Since unit is not directly > >connected to the > > > PSTN officially it is exempt from the standard. (Acoustics > tests > >are covered > > > under UL1950) > > > > > > 2) What about RTTE directive in Europe? There is no standard > you > >can test > > > for. All of TBR 21 tests are not applicable. > > > > > > Thanks > > > Ilan > > > > > > ---------------------------------------------------- > > > Ilan Cohen > > > Manager, Telecom Division > > > I.T.L (PRODUCT TESTING) Ltd. > > > 26 Hacharoshet St, POB 211, Or Yehuda, Israel. > > > Tel 972-3-5339022, Fax 972-3-5339019 > > > ico...@itl.co.il <mailto:ico...@itl.co.il> , website: > >http://www.itl.co.il <http://www.itl.co.il> > > > ---------------------------------------------------- > > > > > > ------------------------------------------- > > > This message is from the IEEE EMC Society Product Safety > > > Technical Committee emc-pstc discussion list. > > > > > > To cancel your subscription, send mail to: > > > majord...@ieee.org <mailto:majord...@ieee.org> > > > with the single line: > > > unsubscribe emc-pstc > > > > > > For help, send mail to the list administrators: > > > Jim Bacher: jim_bac...@mail.monarch.com > ><mailto:jim_bac...@mail.monarch.com> > > > Michael Garretson: pstc_ad...@garretson.org > ><mailto:pstc_ad...@garretson.org> > > > > > > For policy questions, send mail to: > > > Richard Nute: ri...@ieee.org > ><mailto:ri...@ieee.org> > > > > > > ------------------------------------------- > >This message is from the IEEE EMC Society Product Safety Technical > Committee > >emc-pstc discussion list. > >To cancel your subscription, send mail to: > >majord...@ieee.org <mailto:majord...@ieee.org> with the single line: > > unsubscribe emc-pstc > >For help, send mail to the list administrators: > > Jim Bacher: jim_bac...@mail.monarch.com > ><mailto:jim_bac...@mail.monarch.com> > > Michael Garretson: pstc_ad...@garretson.org > ><mailto:pstc_ad...@garretson.org> > > > >For policy questions, send mail to: > > Richard Nute: ri...@ieee.org <mailto:ri...@ieee.org> > > > >------------------------------------------- > >This message is from the IEEE EMC Society Product Safety Technical > Committee > >emc-pstc discussion list. > >To cancel your subscription, send mail to: > >majord...@ieee.org <mailto:majord...@ieee.org> with the single line: > > unsubscribe emc-pstc > >For help, send mail to the list administrators: > > Jim Bacher: jim_bac...@mail.monarch.com > ><mailto:jim_bac...@mail.monarch.com> > > Michael Garretson: pstc_ad...@garretson.org > ><mailto:pstc_ad...@garretson.org> > > > >For policy questions, send mail to: > > Richard Nute: ri...@ieee.org <mailto:ri...@ieee.org> > > > > > > > >------------------------------------------- > >This message is from the IEEE EMC Society Product Safety > >Technical Committee emc-pstc discussion list. > > > >To cancel your subscription, send mail to: > > majord...@ieee.org > >with the single line: > > unsubscribe emc-pstc > > > >For help, send mail to the list administrators: > > Jim Bacher: jim_bac...@mail.monarch.com > > Michael Garretson: pstc_ad...@garretson.org > > > >For policy questions, send mail to: > > Richard Nute: ri...@ieee.org > > > > > > -- > Allan G.Carr B.Sc.(Elec.Eng) AMIEE | AGC-Tel Consultants Ltd > Telecommunications Consultant | Tel: +44(0)141-956-2506 > European Approvals Specialist | Fax: +44(0)141-956-5347 > 62 Crawford Road, Milngavie | Voice Mail: +44(0)1252-30-3062 > Glasgow, G62 7LF, Scotland | http://www.agctel.co.uk > > ------------------------------------------- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Jim Bacher: jim_bac...@mail.monarch.com > Michael Garretson: pstc_ad...@garretson.org > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > > > ------------------------------------------- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Jim Bacher: jim_bac...@mail.monarch.com > Michael Garretson: pstc_ad...@garretson.org > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > > > > > ------------------------------------------- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Jim Bacher: jim_bac...@mail.monarch.com > Michael Garretson: pstc_ad...@garretson.org > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > > > ------------------------------------------- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Jim Bacher: jim_bac...@mail.monarch.com > Michael Garretson: pstc_ad...@garretson.org > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Jim Bacher: jim_bac...@mail.monarch.com Michael Garretson: pstc_ad...@garretson.org For policy questions, send mail to: Richard Nute: ri...@ieee.org ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Jim Bacher: jim_bac...@mail.monarch.com Michael Garretson: pstc_ad...@garretson.org For policy questions, send mail to: Richard Nute: ri...@ieee.org ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Jim Bacher: jim_bac...@mail.monarch.com Michael Garretson: pstc_ad...@garretson.org For policy questions, send mail to: Richard Nute: ri...@ieee.org
