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/.
Lars Immisch lars at ibp.deHi, > 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