Building an E1/T1/J1 line interface

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sat Dec 24 14:43:36 UTC 2011


Hi Christian,

thanks a lot for your review!

On Sat, Dec 24, 2011 at 01:59:36PM +0100, Christian Vogel wrote:

> Is it on purpose that you can open the Tx-Line by removing R4/R5 (0 Ohm),
> or is it planned to maybe add a RC-Filter there? (why?)

This is in order to put non-0-ohm resistors into the lines (as required
for hardware termination).  It's not reall required, but I thought it
might be a nice option to have, as there is no cost associated with
it...

> > The design has the following features:
> >  * the 4x3 and 2x3 jumpers like on the HFC-E1 eval board to set TE mode
> >    and NT mode as well as two possible configurations of the pairs
> 
> As you are trying to conserve space, have you thought about using
> 2x2 jumpers for TE/NT selection, such as:

No, I didn't think about that.  But I've meanwhile updated the design
(last night) to actually place two RJ45 sockets, one in TE and one in NT
mode.

The second jumper for determining 1-2 / 3-6 has been removed completely.
I guess if you want to use a less common configuration, you just have to
crimp your own adapter cable.  That's not hard to do.

So now there are much less jumpers, especially no invalid
combinations...

> It might be useful to have pads for the RTIP/RRING TTIP/TRING signals + GND
> accessible for debugging (maybe as unpopulated jumpers), those signals should
> be cleaner than what's accessible on the jumpers/RJ45.

good point. I'll add that.

> On Ethernet cards, the unused pairs are normally terminated in something ~100 Ohm,
> and the central tap of the transformers and the unused pairs connected to system
> ground via a few 100pF capacitor, I don't have any E1/T1 equipment here
> to compare, but maybe one could consider doing this?

The HFC-E1 evaluation board (of which you get the schematics if you buy
one) has the center tap left open.  I don't think I have other
schematics, but I will try to check what Digium is doing.  The unused
pairs are left open as a standard, I'm quite sure.

> >  * jumper to decide whether TCLK should be sourced from MCLK or if it is
> >    provided externally by the transmitter
> 
> >  * 10pin header for SPI control interface
> >  * 10pin header for TDM interface
> 
> Is there an established standard for these interfaces, or a "most popular
> eval board" in use? 

I don't think so.

> On the TDM-Interface TDN/TDP and RDN/RDP don't run on adjacent pairs
> if a press-on flat-cable connector is used, 

The TDN / RDN are not differential signals, if that's what you're
thinking of.  They just indicate if the ternary encoding had a positive
or negative symbol.  In fact, I anticipate RDN and TDN to not be used
much at all, as the benefit of using this specific IDT chip is that it
can do the HDB3/B8ZS/AMI coding completely itself, i.e. only TDP and RDP
will be used for an un-coded bitstream.  I think the data sheet calls
this single-ended mode.

I just put the signals on the connector anyway, as the pins were free
and somebody might want to use that other mode one day.

> if this is a established
> standard, please ignore this comment, otherwise I'd propose
> 
> 	\RST	1   2	\LOS	<- control signals
> 	GND	3   4	TCLK	<- gnd+tx clock
> 	TDP	5   6	TDN	<- transmit pair
> 	GND	7   8	RCLK	<- tnd+rx clock
> 	RDP	9  10	RDN	<- receive pair
> 
> When testing the chip on a bench, maybe with only a oscilloscope connected
> to the TDM-pins, it might be useful if \RST is pulled high on the board.

this was also already done by my revision last night.  but thanks :)

> For the SPI interface my suggestion would be to use something compatible
> to the most prevalent JTAG pinout (SDO=TDO, \CS=TMS, SCLK=TCK), that way
> one can easily talk to the 82V2081 from the PC using a common (dumb) USB
> JTAG cable and custom software, and please include Vcc on SPI.

Mh, now thinking more about it, I'll primarily use the board with Olimex
development boards, and the typically have this UEXT connector for
UART/SPI/I at C.  I will align the pin-out to make sure this works 1:1.

this means:

1	3V3
2	GND
6	MISO
8	MOSI
9	CLK
10	nPCS1

> I don't know about the intended cable lengths, but maybe a few series resistors
> for dampening the signal wouldn't hurt.

You're referring to which signals?  Where do you want to have them?

> >  * 5x5cm size for cheapest pcb prototyping ;)
> 
> For the board, can you please move all external connectors to the side
> opposing the RJ45?

I'm not sure how easy that is, I've already spent a lot of time with the
layout to make sure the autorouter doesn't produce complete crap.   So
in order to conserve time, I may not be doing that.

> All but one diode have the same orientation, that's unnecessarily confusing
> during population of the board.

I actually only rotated them based on layout requirements.  But yes,
will try to rotate that one diode.

> To conserve space, a quad diode array (first google hit: BAV99DW has
> one pair with common cathode, one pair with common anode) could be
> useful.

I was thinking about a BAV99 (it's used on HFC-E1),  but the IDT data
sheet specifically specifies one diode type, and it has very different
characteristics (200mV less forward voltage, ...) than the BAV99.   So I
decided to play safe and use the recommended component at least in the
first generation.

> Include a LED for loss-of-signal and power?

Good idea.  Will do that.

> Include pads for a 3.3V linear low-dropout regulator,
> normally bridged by a 0 Ohm resistor?

I've placed a LDO now in last nights' version, but it's unconditional.
But yes, a 0 ohm resistor placement option might be a good idea.

> Hmm... ok, this has become more than I intended, but maybe
> the comments are useful? ;-)

definitely, thanks again.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list