Last weekend I started on an ISDN related design for a customer. A neat solution would have been based around a Zarlink chip, I downloaded the datasheet and saw that it was last updated in 2006, always a good sign. Having used Zarlink Echo cancellation silicon it was reasonably priced and did a nice job, so it was my first port of call. I read the datasheet and realized that it would do just fine. ISDN is broadly similar to Ethernet in the transport layer, it needs a specialized “magnetic” (set of transformers and chokes) to isolate and condition the signals. Zarlink recommended a particular magnetic and I downloaded the datasheet for that too, and began to make the schematic over the weekend.
On Monday I rang first the representative for the transformers in the UK and asked approximately how much they are. He sounded surprised and told me these transformers were “ancient” and would need making to order. Now ISDN is a, ahem, mature technology but even so I experienced that sinking feeling, and my next call was to the Zarlink rep in the UK. Sure enough there too the device was “ancient”, dating from the late 90s, and although still available (and in RoHS compliant form too), considering the design called for 4 chip and 4 transformers the whole thing was starting to smell bad.
I Google(TM)-ed around for a while and found CologneChip. They had a quad port device that would do the whole job for the price of two ports of the Zarlink method, and the magnetics were a third of the price too. I started reading the datasheet rather resistant to the idea of throwing away the work I had done on the Zarlink implementation, but it was quickly obvious that the CologneChip implementation was radically superior. In addition, the same family offered an E1 compatible part. Oh well. I threw out the Zarlink version and completed the initial CologneChip version in three days. I also had a sales call from a very knowledgeable guy from there offering what sounded like very good design-in support. But in fact the datasheets and an app note seemed to be enough to get started (or get in trouble, we will see!).
ISDN-2, the consumer ISDN, has three virtual channels: two 64kbps B “Bearer” channels that contain the bulk audio data in A-law PCM, and a 16kbps D channel that contains “signalling data”, which appears to be a bidirectional packet-based setup. A software state machine is needed to service the D-channel actions according to a protocol stack that includes LAPD, I.465 and Q.931 specifications. Luckily there are some GPL’d implementations, or partial implementations anyway; the CologneChip guy was also saying that many exchanges do not implement all the options. Therefore it will be interesting to see what kind of packets are issued by the exchange as a start on understanding the protocol stack.
I'm