16 Dec
2011
16 Dec
'11
6:44 p.m.
Hi all,
Dieter and I have been thinking about building a simple/basic E1 line
interface. The idea is to simply put trnasformers + LIU + crystal on a
small PCB, which then exposes the Rx and Tx signals at stanard 3.3V CMOS
levels which can be fed in your favourite FPGA or even directly into a
microcontroller.
The first interesting LIU that's available in single quantity is the
Dallas/Maxim DS21348:
http://www.maxim-ic.com/datasheet/index.mvp/id/2848
It can be operated in "software mode" where all configuration (E1/T1/J1,
attenuation, amplification, termination, ...) is set via SPI from a
microcontroller.
However, it expose "Rx Positive" and "Rx Negative" and does not have
the
HDB3/AMI/B8ZS encoder internally. This means there would be two synchronous
serial streams going into the FPGA or microcontroller. This is probably
ok for an FPGA - but it is a problem for most microcontrollers that only
have one sync serial interface like the sam3s/sam7s SSC.
The other option seems to be the IDT 82V2081
(http://www.idt.com/?genId=82V2041E&cid=58553)553), which as internal
HDB3/AMI/B8ZS encoders and decoders (so-called "single rail mode"). It
is a bit more expensive (USD 20 in single qty), but this would enable us
to hook it up directly at a sam3s / sam7s.
As jolly points out, there is still a lot of work required like
framing, s-bits, multiplexing, hdlc, etc. in order to turn it into a
full E1 interface.
But then, maybe there are some applications that don't even require all
those features, such as building a sniffer-only device, or something
that "simply" tries to forward E1 over IP based transports without
parsing too much of the contents.
Open questions:
* stay with 1port design or immediately do a 4port unit? (for
bidirectional sniffing you already need two)
* how do we achieve synchronization between Rx and Tx data path?
Looking forward to your comments, feedback.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
16 Dec
16 Dec
9:42 p.m.
Hi,
Dieter and I have been thinking about building a
simple/basic E1 line
interface. The idea is to simply put trnasformers + LIU + crystal on a
small PCB, which then exposes the Rx and Tx signals at stanard 3.3V CMOS
levels which can be fed in your favourite FPGA or even directly into a
microcontroller.
The first interesting LIU that's available in single quantity is the
Dallas/Maxim DS21348:
http://www.maxim-ic.com/datasheet/index.mvp/id/2848
It can be operated in "software mode" where all configuration (E1/T1/J1,
attenuation, amplification, termination, ...) is set via SPI from a
microcontroller.
However, it expose "Rx Positive" and "Rx Negative" and does not have
the
HDB3/AMI/B8ZS encoder internally. This means there would be two synchronous
serial streams going into the FPGA or microcontroller. This is probably
ok for an FPGA - but it is a problem for most microcontrollers that only
have one sync serial interface like the sam3s/sam7s SSC.
I haven't studied the datasheets in detail yet, but I was immediately thinking of the
Xmos chips (basically multi-threaded 400MHz 32bit DSPs available with a number of
different cores). Several people in the forums claim they have reached clock SPI clock
speeds of 50MHz and they are easy to use (source #paloaltona).
A single chip with one core (xs1-l1) costs USD 8 at Sparkfun, a dual core (xs1-l2) about
USD 15.
The other option seems to be the IDT 82V2081
(http://www.idt.com/?genId=82V2041E&cid=58553)553), which as internal
HDB3/AMI/B8ZS encoders and decoders (so-called "single rail mode"). It
is a bit more expensive (USD 20 in single qty), but this would enable us
to hook it up directly at a sam3s / sam7s.
As jolly points out, there is still a lot of work required like
framing, s-bits, multiplexing, hdlc, etc. in order to turn it into a
full E1 interface.
But then, maybe there are some applications that don't even require all
those features, such as building a sniffer-only device, or something
that "simply" tries to forward E1 over IP based transports without
parsing too much of the contents.
Open questions:
* stay with 1port design or immediately do a 4port unit? (for
bidirectional sniffing you already need two)
FWIW, I'd do 4 ports.
- Lars
23 Dec
23 Dec
9:08 p.m.
Hi all,
the first draft revision of the schematics and PCB design can be found
at http://cgit.osmocom.org/cgit/osmo-e1-xcvr/
(or "git clone git://git.osmocom.org/osmo-e1-xcvr.git")
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
* jumper to select between 1.544 MHz and 2.048 MHz oscillator clock
i.e. E1/T1
* 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
* 5x5cm size for cheapest pcb prototyping ;)
Comments or feedback is welcome. I decided to use this project to try
current EAGLE (I last used it when there was a DOS version, IIRC). So
I'm sorry it's not KiCAD / gEDA, but I needed a pet project to evaluate
it...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
24 Dec
24 Dec
1:59 p.m.
Hi Harald,
I cannot say anything competent about the IDT82v2081, but I have a few
general remarks.
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?)
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:
jumpers jumpers
Rx+---- o o ----RJ4 Rx+---- o -- o ----RJ4
| |
RJ13--- o o ----Tx+ RJ13--- o -- o ----Tx+ ?
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.
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?
* 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? On the TDM-Interface TDN/TDP and RDN/RDP don't run
on adjacent pairs if a press-on flat-cable connector is used, 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.
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.
I don't know about the intended cable lengths, but maybe a few series resistors
for dampening the signal wouldn't hurt.
* 5x5cm size for cheapest pcb prototyping ;)
For the board, can you please move all external connectors to the side
opposing the RJ45?
All but one diode have the same orientation, that's unnecessarily confusing
during population of the board. 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.
Include a LED for loss-of-signal and power?
Include pads for a 3.3V linear low-dropout regulator,
normally bridged by a 0 Ohm resistor?
The datasheets lists all I/O to be 5V compatible, and
someone might want to use the transceiver with a 5V-only
FPGA/Microcontroller board? Or someone might want to power
the FPGA/Microcontroller via the LDO on the transceiver board?
Hmm... ok, this has become more than I intended, but maybe
the comments are useful? ;-)
Happy Christmas,
Chris
3:43 p.m.
Hi Christian,
thanks a lot for your review!
On Sat, Dec 24, 2011 at 01:59:36PM +0100, Christian Vogel wrote:
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...
I don't think so.
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.
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: 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? 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@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? 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5:06 p.m.
Hi Christan and others,
I've updated the schematics and PCB layout, please see below.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:47 p.m.
Hi Harald,
I've not yet looked at your updated design, just finished the Christmas
celebrations with relatives and so on ;-)...
I've meanwhile updated the design
(last night) to actually place two RJ45 sockets, one in TE and one in NT
mode.
I would go with the jumper-selectable method, but that's maybe just
personal preferance.
The TDN / RDN are not differential signals, if
that's what you're
thinking of.
Indeed, that's what I thought of, nevertheless I'd try to have at least
the clock lines somewhere adjecent to ground, even if it's only based on
my gut feeling.
> 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?
SPI and TMS, if you have fast outputs on either the E1 transceiver or the
microcontroller/fpga, series resistors (say... 68 Ohm) might dampen the
ringing on the edges.
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.
I never used the eagle autorouter, because I think it doesn't produce
elegant routing, or sometimes no routing at all. Fortunately all my boards
were of comparably low complexity (one microcontroller, maybe one or two
small
additional ICs, everything low pin-count). I'll try my luck on manually
routing the new board tomorrow in the morning or so...
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.
I checked the datasheet and they use rather strong (500mA and up) schottky
diodes (hence the lower forward drop compared to the BAV99).
Possibly they are considering their product being connected in a commercial
telco-equipment with a few kilometres of cable connected to it, and the
diodes are for protecting the inputs from overvoltage.
Personally, I'd say that for the current design you can easily go with
a little weaker diodes, such as the BAT54s (dual in SOT23 smd) which
can take up to 200mA (avg).
Greetings from bavaria,
Chris
11:12 p.m.
Hi Christian,
On Sat, Dec 24, 2011 at 10:47:09PM +0100, Christian Vogel wrote:
Sorry, I'm not going to change back now ;)
If it wasn't for the router, I could have done the project in KiCAD,
where from my experience routing is really bad and/or takes ages.
I've
meanwhile updated the design
(last night) to actually place two RJ45 sockets, one in TE and one in NT
mode.
I would go with the jumper-selectable method, but that's maybe just
personal preferance. Indeed, that's what I thought of, nevertheless
I'd try to have at least
the clock lines somewhere adjecent to ground, even if it's only based on
my gut feeling.
ok, I'll look at that. The pin-configuratoin of the TDM connector is
definitely not
SPI and TMS, if you have fast outputs on either the E1
transceiver or the
microcontroller/fpga, series resistors (say... 68 Ohm) might dampen the
ringing on the edges.
Well, I think for SPI there is no speed requirement anyway (it's just
configuring the transceiver and maybe reading an error status back), so
if there are problems, we can simply reduce the clock rate.
For the TDM signals, they are 2MBits/s and there is nothing we can
change about that ;)
I'll see if I can squeeze in some resistor footprints there.
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.
I never used the eagle autorouter, because I think it doesn't produce
elegant routing, or sometimes no routing at all. I'll try my luck on manually > routing the new
board tomorrow in the
morning or so...
Don't bother, it's a waste of time. Really. I've already spent way too
much time on this and would say it's about time to order some actual
PCBs (seeedstudio.com 9.99 for 10 units and cheapest shipping option)
and play with it.
I'll probably render some GErber output, look at it in a gerber viewer
and order tomorrow or on the 26th.
I checked the datasheet and they use rather strong
(500mA and up) schottky
diodes (hence the lower forward drop compared to the BAV99).
Possibly they are considering their product being connected in a commercial
telco-equipment with a few kilometres of cable connected to it, and the
diodes are for protecting the inputs from overvoltage.
I think E1 is not specified over that distance anyway. Last time I
checked, it was in the low hundreds of meters.
Personally, I'd say that for the current design
you can easily go with
a little weaker diodes, such as the BAT54s (dual in SOT23 smd) which
can take up to 200mA (avg).
Yes, you're probably right. But let's try not to over-optimize this.
We're talking about a development board which will probably be produced
and used in a quantity of one or two dozen.
If later somebody emerges with a microcontroller/fpga/cpld design that
does something useful with the transceiver (i.e. implement an actual
functional E1 interface with HDLC, etc.), it would make a lot of sense
to make a custom board with this external logic and the transceiver on
one board.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
13 Jan
13 Jan
11:04 p.m.
Hi all!
The osmo-x1-xcvr PCBs arrived earlier today. I soldered four units, and
from a clock / DC measurements / power consumption point of view things
are looking fine so far.
I don't yet have any driver software for the transceiver though, i.e. no
code that can initialize the registers to a sane E1-mode state. Thus,
I'm not able to verify if the actual analog/digital E1 side is working.
Due to lots of other work, I don't think I'll find much time during the
next 10 days or so.
If anyone is interested in writing that driver, connecting it to a
USB-SPI adapter or a microcontroller development board with SPI: I'm
happy to send two of those fully assembled boards out. One is for me
and another one for dieter.
For anyone else who wants to build one him/herself: There are 6 more
PCBs that I am happy to send out.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
14 Jan
14 Jan
1:53 a.m.
New subject: Fosdem attendance
Hi,
Will any of you chaps be in Brussels for Fosdem? What could be more fun
than talking GSM standards and telco misdemeanours over a Lambic or two ;)
Regards,
Alex
15 Jan
15 Jan
1:39 p.m.
New subject: Fosdem attendance
On 14/01/2012 21:16, Peter Stuge wrote:
Alex J Lennon wrote:
I see there is a telecoms devroom this year, but apparently nothing
relating to GSM:
http://fosdem.org/2012/schedule/track/telephony_and_communications_devroom
However, this may be of interest, if Osmocommers want to meet up at some
point:
http://fosdem.org/2012/news/meeting-rooms
Regards,
Chris
Will any of you chaps be in Brussels for Fosdem?
I'm going, and I think a few others are as well. 
19 Jan
19 Jan
8:05 p.m.
Dear Harald,
I have experience in USB/SPI and telecommunications. I have just
installed and tested openbts and i love to offer my help to osmocom
project. i can make a usb to spi adapter working with your board.
Thanks
Nalin Karunasinghe
20 Jan
20 Jan
4:06 a.m.
Hi Nalin,
Nalin Karunasinghe wrote:
I have experience in USB/SPI and telecommunications. I
have just
installed and tested openbts and i love to offer my help to osmocom
project.
Please note that openbts has nothing to do with osmocom. Do you mean
openbsc?
i can make a usb to spi adapter working with your
board.
Do you know if there's a CDC subclass that fits, or would it be
vendor specific with an open protocol?
Please send your suggestion of what the protocol would look like.
//Peter
8:56 a.m.
Hi Nalin,
On Fri, Jan 20, 2012 at 12:35:22AM +0530, Nalin Karunasinghe wrote:
I have experience in USB/SPI and telecommunications. I
have just
installed and tested openbts and i love to offer my help to osmocom
project. i can make a usb to spi adapter working with your board.
Thanks a lot for bringing this up and offering your help. Right now we
still need to finish the design of the E1 transceiver part.
After that, there is room for evaluating different options of using it,
both using a pure 'software defined E1' approach using a microcontroller
and doing all the mux/demux/HDLC in software - as well as for an
approach with some programmable logic involved.
That kind of experimentation doesn't really need a new board, as you can
just connect the osmo-e1-xcvr via SPI/SSC to e.g. your favorite
microcontroller.
If you're happy to work on that, e.g. to create a 'software defined E1'
implementation, you're most welcome. I can send you either a populated
PCB or a component kit + pcb to solder it yourself.
Design of a new board with integrated microcontroller is premature at
this point. we first have to make it working as a wired-up prototype...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4488
days inactive
4523
days old
14 comments
7 participants
participants (7)
-
Alex J Lennon -
Christian Vogel -
Christopher Orr -
Harald Welte -
Lars Immisch -
Nalin Karunasinghe -
Peter Stuge