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), 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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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), 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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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@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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Christan and others, I've updated the schematics and PCB layout, please see below. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
Hi Christian, On Sat, Dec 24, 2011 at 10:47:09PM +0100, Christian Vogel wrote:
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.
Sorry, I'm not going to change back now ;)
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.
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'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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
On 14/01/2012 21:16, Peter Stuge wrote:
Alex J Lennon wrote:
Will any of you chaps be in Brussels for Fosdem?
I'm going, and I think a few others are as well.
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
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
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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (7)
-
Alex J Lennon -
Christian Vogel -
Christopher Orr -
Harald Welte -
Lars Immisch -
Nalin Karunasinghe -
Peter Stuge