Hardware Projects » E1/T1 Hardware Interface (including icE1usb)

another idea is to make the LIU usable (Even for transmit) without SPI. There are some strapping options. It is's possible without too much effort, we could witch from SPI to strapping mode - but only if all the related strapping pins would then actually put it in regular E1 mode with Rx/Tx enabled, single-rail, ...

• GNS2201 as GPS-only module
• GNS3301 as GPS/GLONASS module
• GNS3301B as GPS/BEIDOU module
  • they appear to be pin compatible, so one could choose between GPS / GPS+GLONASS / GPS+BEIDOU depending on region and political preference
• Venus828
  • nice, compact QFN package
  • should be cheap, you can get circuit boards with them for 6 USD (http://www.skytraq.com.tw/homesite/Venus828F_PB_v1.pdf)
  • we have samples at sysmocom

• https://www.digikey.de/product-detail/de/VTEUALJANF-30.720000/1664-1336-1-ND/6126639 for low accuracy (50ppm)
  • most likely sufficient if BTS has internal OCXO and performs long-term averaging/filtering of E1 clock anyway
  • slope is not really specified, but at least something like 100ppm/(3-0.3=2.7V)=37ppm/V. At a 12bit DAC, that's 9ppb/LSB
  • this might be a too large stepsize?
• https://www.digikey.de/product-detail/de/T604-030.72M/CW854CT-ND/5171444 for high accuracy / longer hold-over (280ppb)
  • slope is 8ppm/V
  • sysmocom has EAGLE footprint, as 25MHz version already used in other project

I would think we ideally put both footprints on one board to experiment with.

NOTE: A 30.72MHz clock for the SAM4S means it's USB SAM-BA loader can no longer be used. This means we need to expose SAM-BA on UART (using 2.5mm jack so osomocom-style serial cables can be used for recovery flashing)

Precision voltage reference is only required if you want to 'save' a calibration value. When locked to GPS, then it doesn't matter.

And of course that 'saved' value would really only work in the same condition (temp, etc ...) because even if your voltage reference and tune voltage is perfect, nothing guarantees that your xtal is always going to respond to it the same way.

I'm not sure how "bad" it is. But it's more in relation with what the gain of using a precision voltage reference rather than just relying on the "normal" regulator.
If the frequency error you get from saving and restoring a DAC value comes mainly for change in the actual DAC output because of supply variation or not.

tnt wrote:

I'm not sure how "bad" it is. But it's more in relation with what the gain of using a precision voltage reference rather than just relying on the "normal" regulator.
If the frequency error you get from saving and restoring a DAC value comes mainly for change in the actual DAC output because of supply variation or not.

Taitien VCXO (VTEUALJANF-30.720000)¶

• http://www.taitien.com/wp-content/uploads/2015/12/Model-Numbering-Guide_VCXO.pdf
• http://www.taitien.com/wp-content/uploads/2016/01/XO-0040-VT-CMOSTYPE.pdf

• 50ppm stability, pulling range ±50 ppm (0,3 … 3,0V) ≈ 16,7 ppm/V

Connor Winfield VCTCXO (T604-030.72M)¶

• 0,28 ppm stability, abs. freq. tolerance ±4,7 ppm
• stability vs. load, voltage ≤ 0,05 ppm
• "holdover" ≤ 0,3 ppm
• pulling range is ±10 ppm (0,3 … 3,0V) ≈ 3,33 ppm/V

Standard voltage regulator: http://www.ti.com/lit/ds/symlink/lm1117.pdf¶

Page 9, Fig. 6, Temperature Stability is certainly better than ±0,5%,
    let's just say it's better than ±10mV for brevity, and let's ignore the
    variation with load, because we could use a separate Vreg for Vref + VCXO.

Assume that a voltage regulator with 3,3V±10mV is used as a voltage reference,
this means that a control voltage held at approx. Vcc/2 moves by 5mV which
would be 16ppb (Connor) or 83,5 ppb (Taitien).

laforge wrote:

In terms of GPS receivers, I would propose the following candidates: [...]

The GNS2201/3301 appear to be the favorites so far. the Venus828 is less expensive, but is not typically stocked in Germany and we'd have 6-8 weeks lead time for every production, which is not a good idea. GNS GmbH typically has EAGLE library footprints available, so we don't have to create that one. I'll inquire.

(As the ticket has one subticket which is solved, it appears to be 100% solved too which isn't true ,) )

laforge wrote:

GNS GmbH typically has EAGLE library footprints available, so we don't have to create that one. I'll inquire.

I got a response, see attached library.

I'm soliciting comments on my latest revision for a LIU + Microcontroller + GPS + Oscillator board, I've postet it (for the time being) on https://github.com/vogelchr/e1_sam4_usb . Unfortunately due to me mixing up old and new libraries it does currently not open in Eagle 7, I'll fixup within the next few days.

The issues we've already identified are below.

• Repository / File Formats

  - EAGLE 7 compatibility
  - rename .brd/.sch to sensible name, integrate in old
  http://cgit.osmocom.org/osmo-e1-xcvr/ repository.

• Board

  - ERASE jumper
  - make JTAGSEL pullup DNP (JTAGSEL, TEST, ERASE should float)
  - LEDs near frontpanel
  - interface to old LIU only board (SPI + DATA on pinheader)

I've updated the files in the github repo listed above, ..._v7.brd/sch. The IDT LIU is smaller and needs less external components, I've copied over the SPI config (modes, clk polarity, ..) from the old board.

Review of vogelchr design using the "20180625" PDF schematics:

Critical¶

• USB has no transient voltage suppressor, possible ESD damage (recommended: IP4234CZ6)
• UART has not transient voltage suppressor, possible ESD damage (recommended: IP4234CZ6)
• UART has no pull-up resistor on RxD input, i.e. floating input unless UART is connected
• GPS antenna input has no transient voltage suppressor, possible ESD damage (unless the
  GNS module has one inside? Did you find any documentation on that in the module data sheet? Recommended: 0603ESDA-TR

Proven IP3234CZ6 + 0603ESDA-TR library parts can be found in attached laforge.lbr

Non-critical¶

• !RESET has no pull-up, design is possibly susceptible to picking up RF/noise as reset trigger
• 1k series resistors for LEDs seems quite high resistance for 3.3V. I would usually expect 330..680 Ohms there?
• JTAG connector doesn't appear to have standard 2x10 ARM-JTAG pin-out. If there's space I'd prefer a 20pin ARM-JTAG.
• GPS receiver rx/tx/pps doen't have series termination (27R or the like), possibly resulting in switching tranients degrading GPS performance
• does SPI+I2C header (SV6) have UEXT compatible pin-out? If we use a 2x5 header, it might make senese to use the olimex-standard UEXT format as there are plenty of other boards/devices with that pin-out
• SV3 serial pin-out could be aligned with FTDI 1x5 (or 1x6?) usb serial cables. I think it makes sense to align with pin-out of industry standard cables that people might already have
• for the DAC, it might make sense to align with what sylvain is using in his FPGA based design (and what sysmocom has used in other designs): MAX5215 (14bit). Could be upgraded to 16bit MAX5217 if ever needed.
• might make sense to add a precision voltage reference for the DAC, e.g. MAX6163ESA?

Cosmetic¶

• If inverted-logic signals would use !SIGNAL instead of #SIGNAL, EAGLE would over-stroke their names
• diescrete resistors instead of U$2 resistor array is probably lower cost in SMT, as it's a standard 10k resistor reel and not one more "cut-tape" reel only for that part

adding more eagle libraries

Waiting for my plumber -- who did not arrive, btw :-( -- I integrated most of the comments from laforge. If no one makes any critical remarks the next few days, I think I'll spin one version of this board.

Updates can be found on https://github.com/vogelchr/e1_sam4_usb and as always I'd appreciate any comments.

As a next step, I'll clean up the files and integrate in the proper osmocom repository.

--- from README.txt in above repository ---

DONE after 20180625:
- USB has no transient voltage suppressor, possible ESD damage
(recommended: IP4234CZ6)
- R1 120 Ohms (LIU Rx term)
- R2, R8 9 Ohms (LIU Tx in series)
- LIU move signal from LOS to #INT
-> Interrupt can be generated on LOS anyway.
- diescrete resistors instead of U$2 resistor array is probably lower
cost in SMT, as it's a standard 10k resistor reel and not one more
"cut-tape" reel only for that part
-> introduced quad resistor packs 10k for various pullups
- for the DAC, it might make sense to align with what sylvain is using
in his FPGA based design (and what sysmocom has used in other designs):
MAX5215 (14bit). Could be upgraded to 16bit MAX5217 if ever needed.
- UART has not transient voltage suppressor, possible ESD damage
(recommended: IP4234CZ6)
- JTAG connector doesn't appear to have standard 2x10 ARM-JTAG pin-out.
If there's space I'd prefer a 20pin ARM-JTAG.
- SV3 serial pin-out could be aligned with FTDI 1x5 (or 1x6?) usb
serial cables. I think it makes sense to align with pin-out of industry
standard cables that people might already have
- LEDs near frontpanel
- does SPI+I2C header (SV6) have UEXT compatible pin-out? If we use a
2x5 header, it might make senese to use the olimex-standard UEXT format
as there are plenty of other boards/devices with that pin-out
- !RESET has no pull-up, design is possibly susceptible to picking up
RF/noise as reset trigger
- UART has no pull-up resistor on RxD input, i.e. floating input unless
UART is connected
- add pullup on LIU #RST
- GPS antenna input has no transient voltage suppressor, possible ESD
damage (unless the
GNS module has one inside? Did you find any documentation on that in
the module data sheet? Recommended: 0603ESDA-TR

REFUSED:
- interface to old LIU only board (SPI + DATA on pinheader)
- might make sense to add a precision voltage reference for the DAC,
e.g. MAX6163ESA?
regulation seems to be good enough with the crappy DAC
in the SAM4S, so I think having the "good" +UB supply that
has constant load will be sufficient

- GPS receiver rx/tx/pps doen't have series termination (27R or
        the like), possibly resulting in switching tranients degrading GPS
        performance
          => not needed in my oppinion
         - 1k series resistors for LEDs seems quite high resistance for 3.3V. I
        would usually expect 330..680 Ohms there?
          => with modern LEDs it's really bright enough, even with 1k (or even 5k)

- If inverted-logic signals would use !SIGNAL instead of #SIGNAL, EAGLE
        would over-stroke their names
          => (vogelchr) Nice, didn't know this, but will probably not change.

- USB_VBUS_SENS not routed to microcontroller!
          device is bus powered, hence monitoring not needed!

- GPS receiver rx/tx/pps doen't have series termination (27R or
the like), possibly resulting in switching tranients degrading GPS
performance
=> not needed in my oppinion

Rationale: I've seen this in various reference designs for GPS receiver modules, including some
from u-blox and (AFAIR) GNS. Not sure how much voodoo it is. I typically add it to
all boards as it's just two extra resistors and close to zero risk that it would ever
create any problem.

You are right, it's too cheap to not do it. And thanks for the remark about the SMA conn.

My already dated notes from bringup, so that the info doesn't get lost.

- due to PLL restrictions we cannot generate PCK 2.048 MHz

We'll just use the SSC clk output (which can divide MCK by any funky divider) and feed that to TX_CLK and LIU MCLK: Remove CLK2048 net, remove connections to PA21 and PB3. Bridge MCLK and TCLK at LIU for 2MHz input.

- LIU spi interface configuration, pull SCLKE up (now: gnd)

- SCLKE=high: shift SDO on falling edge of SCLK

- SCLKE=low: shift SDO on rising edge of SCLK

SDI is always sampled on the rising edge, so to be consistent with SDI which is shifted on the falling edge, SDO should also be shifted on the falling eddge and SCLKE therefore should be HIGH.

- Implement the frame-sync as thought up by LaF0rge using the timer/counter:

So use PA27{TIOB2, Tp14}, bridge to PA20{RF, Tp13} for receive frame and PA28{TClk1, Tp15} as RX_Clk input to timer.

- we probably want the board to also be non-usb powered, add connector for 5V power via diode and vbus monitoring via resistive divider to sam4s.

as much as it pains me, sylvain's ICE40 approach has turned out to be the more attractive approach, if not only from the per-unit cost (no LIU, smaller PCB, etc.). So I'm rejecting this ticket.

I might at some point not be able to resist implementing the missing firmware bits to make it USB-protocol compatible to the ICE40 so I can use the 2-3 boards of the SAM4 based approach.

I'm particularly sorry for vogelchr who spent significant time and effort on this SAM4 based approach. Thanks!