| ??? 01/10/04 17:36 Read: times |
#62308 - RE: isdn Responding to: ???'s previous message |
Edwin:
I will not be able to directly help you write the code for your design. Surely I could do it of course but you need to understand that it is a rather complex project. I would first ask you what you think you are intending to actually do. Be aware that depending upon where you live the ISDN phone line delivered to the internal wiring of your building may be a different interface type than the wiring delivered from the telephone company central office. In the USA (and possibly north america as well) the central office provides the U level interface as a hard copper connection all the way into the building and right to the desk top. It is then possible to connect to this interface directly in your equipment with the likes of the National chip you selected. On the other hand in most of the rest of the world, Europe in particular, the central office interface U level interface is terminated at the entry junction point into an interface converter to provide the short range S/T level interface to the internal wiring of the building to the desk top. Most ISDN instruments built in the world use the ISDN S/T interface on terminal equipment because the electrical and signalling characteristics of this interface are rather standardized across the world. In the ISDN world is it common to see a device in use called an NT1. It is used to convert from a U inteface type to a S/T interface. In general terms the U interface is the "outside" wiring, the S interface is the inside wiring end at the NT1 and the T interface is the inside wiring end at the user end terminal equipment. Since the S and T are connected by "inside" wiring the protocol and signalling here is often called the S/T interface as I was talking about above. Please note that in Eurpoe the NT1 is provided by the telephone service provider where as in the USA the customer is expected to provide the NT1. Now it is common these days to find USA equipment that has the NT1 function built directly into the user equipment (much as I did in the RSI VideoFlyer video conferencing system I designed about 7 years ago. (I also designed a version of the product that provided an S/T interface as well. That equipment interfaced to three separate ISDN lines so that it could in parallel support six B channels and three D channels). The S/T version of the VideoFlyer was used in Europe and elsewhere while the U version was used in North America. It was of course possible to use the S/T version of the VideoFlyer in the USA with three external NT1 adapters. OK, now. Another thing to keep in mind is that the signalling protocol and electrical characteristics of the U interface are different in North America than in Europe and elsewhere. So the NT1's provided by the service provider in Europe are different adapters than a user would have to purchase in the USA / North America. Almost all chips that you will find to interface to either a U interface or to an S/T interface terminate inside the equipment into a bit serial bus commonly referred to as a TDM bus. (Time Domain Multiplexed). In order to get the data off such a synchronous serial bus it is necessary to use a processor, interface peripheral, or CPLD that has been designed to be able to pick off the bits of either the 16k bits per second D channel or either one of the 64k bits per second B channels. It is not recommended to try to even attempt to do this with a microcontroller using bit banging technigues. The serial TDM bus often runs at a clocking rate of a couple of megahertz (such as 2.54 MHz). There is a need to be able to pick bits off a TDM bus and gate them on. As such the tristate driver enable onto the TDM must be enabled at just the right time with respect to the clocking signals. This is why the TDM bus interface is never bit banged!! So I say do not ignore me and think that you will try it anyway. Moving on....the U or S/T interface chips in common usage these days come from companies like Motorola, National, Mitel (some other name these days), and Siemens/Infineon. My favorite chips are those from Motorola by the way. You can interface the TDM bus into devices with a TDM interface capability. Most devices of this type have an onboard programmable circuit called a time slot assigner that lets you determine the time slots on the TDM bus upon which the device will operate (i.e. which B or D channel that device will communicate with). You can find video chips from the likes of 8X8, DSPs from TI, HDLC controllers from Motorola and Infineon and so forth. In the VideoFlyer I happened to use a several chips from Motorola called the DDLC which was basically a dual HDLC controller with a TDM interface on the serial side. Motorola also has a processor called a MC68302 which is a CPU-32 variant that also has a on-board HDLC controller capability with a TDM bus interface. Note that since ATT is a big supplier of NT1 devices for use in North America they also make ISDN interface components for use mainly in NT1's. Ten years ago an NT1 typically consisted of a U interface chip and its transformer, a S/T inteface chip with its transformer, and a microcontroller such as an 8052. On the earlier ATT type chips it was possible to put the line interface chips into a mode wherein the D channel data could be accessed over a parallel data bus and brought into and out of the microcontroller. Most often the HDLC and bit stuffing was done in the microcontroller firmware. These days most NT1s are built using "single chip NT1" devices wherein no microcontrollers are used. Another subject that needs to be addressed regarding connecting devices to ISDN phone lines is that agency certification must be obtained before you can connect to the live lines. For engineering development you should obtain a piece of equipment called an ISDN line simulator. Agency certification is a 3 part process. There is the usual RF emissions and immunity requirement, then the safety component, and finally the ISDN protocol stack component. It is generally possible to satisfy the emissions/immunity requirements by testing separately to US requirements and to European requirements. The same is true for the safety as well however there is today a recognized international safety standard that you can test to that will satisfy the requirements in most countries. However just testing to the international safety standard does not get you labeled and stickered for every country where in most cases you must file a submittal and pay a fee in each country and attach your safety test results. The ISDN protocol stack testing can generally be done at a lab that can test to most countries requirements. You can then sumbit the test results to the various countries to obtain your certification in those countries. The ISDN protocol stack testing is a complex test that verifys the firmware inside your ISDN device to make sure it sequences its control states properly. It also includes tests to make sure that the signal pulse shapes, amplitudes and timings on your U or S/T interface fit within a very tight window. (Note that proper selection of the line interface magnetics is critical in being able to pass these latter tests. APC, a company in the UK provides top notch ISDN interface modules that are matched to the line interface chips from various manufacturers. I used APC modules in the VideoFlyer and passing the tests was a breeze). The ISDN protocol stack software that you use to perform call setup, answering, and data flow control is a complex state machine piece of code. It typically is the code that processes the data that flows over the D channel into and out of your equipment. I do not actually recommend that you try to write this stuff - you could invest a lifetime in it!! The main problem with ISDN protocol stack software is many faceted. First off it must pass the agency testing I mentioned above - but then it must also be made to work with many different types of central office switches that each have odd-ball quirks, even between different software releases! Personally I would recommend that you contact a protocol stack vendor and purchase this as a piece of source code IP. I can recommend a vendor if you are interested. Please note that taking on an IDSN design is not a simple weekend project. I spent 3 years becoming an expert on ISDN by designing the VideoFlyer and MediaPro video conferencing products for RSI Systems (which is unfortunately out of business now). There are books you can buy to learn the concepts and protocol, data sheets and applications notes that can help a lot in the line interface designs (Motorola is most helpful in this area I found) and don't forget what I said about transformer modules above, and finally there is the complex protocol stack software. At RSI we had bought the source license for this code and I helped make changes to it to solve a minor problem getting call setup to work in Taiwan and my head hurt after about a week of work with it! Edwin, if you decide to take it on please feel free to contact me. I can try to help if you get stuck on some certain point. Of course I can be most helpful if you choose to use Motorola ISDN transceivers. Michael Karas |
| Topic | Author | Date |
| isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 | |
RE: isdn | 01/01/70 00:00 | |
| RE: isdn | 01/01/70 00:00 |



