Project

General

Profile

Feature #3272

next-generation osmo-e1-xcvr board

Added by laforge 3 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/15/2018
Due date:
% Done:

70%

Estimated time:
(Total: 0.00 h)
Tags:
E1

Description

Since osmo-e1-xcvr is full of bugs, and it doesn't yet include a microcontroller, it might be worth collecting ideas about a next board version.

As soon as I have my SAM4S firmware code working, I guess it would be a good idea to make a board that contains
  • a (fixed) osmo-e1-xcvr
    • no missing GND on Vref resistor
    • no wrong transformer symbol/layout
    • proper silkscreen
    • make sure IC pin is connected to GND as specified in data sheet
  • a suitable SAM4S
  • a first version of the GPS-DO (mschramm: we can use the DAC and maybe also the voltage reference from sob-jb, but drive a 30.72 MHz OCXO from it)

For people working on a non-SAM4S approach, that part could simply be DNP, as long as we still have headers (possibly with identical pinout) for SPI + serial data stream, it would remain copatible. Basically one could populate either the LIU+magnetics part, and/or the SAM3+USB part, and/or the GPS-DO part.

GNS2201_datasheet.pdf View GNS2201_datasheet.pdf 1.14 MB laforge, 05/16/2018 08:07 PM
GNS3301_datasheet.pdf View GNS3301_datasheet.pdf 1.28 MB laforge, 05/16/2018 08:08 PM
GNS3301B_datasheet.pdf View GNS3301B_datasheet.pdf 1.19 MB laforge, 05/16/2018 08:08 PM
Venus828F_PB_v1.pdf View Venus828F_PB_v1.pdf 177 KB laforge, 05/16/2018 08:08 PM
T604.pdf View T604.pdf 1.47 MB Connor-Winfield T604 VCTCXO (280ppb) laforge, 05/16/2018 08:11 PM
XO-0040-VT-CMOSTYPE.pdf View XO-0040-VT-CMOSTYPE.pdf 298 KB Taitien VT VCXO (50ppm) laforge, 05/16/2018 08:13 PM
GNS3301.lbr GNS3301.lbr 18.6 KB EAGLE library for GNS3301/2201 laforge, 05/23/2018 10:55 AM
laforge.lbr laforge.lbr 520 KB laforge, 06/27/2018 08:43 AM
MAX521x.lbr MAX521x.lbr 8.87 KB MAX5215 DAC library laforge, 06/27/2018 08:45 AM
MAX616x.lbr MAX616x.lbr 8.89 KB MAX6163 precision reference library laforge, 06/27/2018 08:45 AM

Subtasks

Feature #3275: release connor-winfield + SJ-2523 EAGLE footprints Resolvedmschramm


Related issues

Related to E1/T1 Hardware Interface - Feature #3237: Come up with GPS-DO design for E1 InterfaceNew2018-05-04

History

#1 Updated by laforge 3 months ago

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, ...

#2 Updated by laforge 3 months ago

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

#3 Updated by laforge 3 months ago

  • Checklist item SAM4S added
  • Checklist item GPS receiver with 1PPS output added
  • Checklist item VC[TC]XO driven by DAC [of SAM4?] added
  • Checklist item possibly precision voltage reference for DAC? added
  • Checklist item LIU added
  • Checklist item magnetics matching to LIU and with fixed symbol/footprint added
  • Checklist item SAM-BA capable UART (PA9/PA10?) on 2.5mm jack (SJ-2523-SMT) added
  • File T604.pdf T604.pdf added
  • File XO-0040-VT-CMOSTYPE.pdf XO-0040-VT-CMOSTYPE.pdf added
In terms of 30.72 MHz oscillator, we have identified the following models:

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)

#4 Updated by tnt 3 months ago

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.

#5 Updated by laforge 3 months ago

On Wed, May 16, 2018 at 08:48:57PM +0000, tnt [REDMINE] wrote:

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

yes, I think it's useful to have some kind of "cold start" behavior where the clock is reasonable even in
absence of GPS (or before GPS is locked). In the end we might be able to do without any of that. But at
least for now it seems interesting to keep all options open.

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.

Is it that bad? I understand there's voltage / load / temperature related implications on frequency, but if
I'm using the same board with the exact same voltage / load / temperature, without having a year of time in
between, then the outcome should be rather close to the situation before?

I guess we need to do some testing on all of this, including how the relevant BTSs react to E1 clock error
[and over what period, ...]

#6 Updated by laforge 3 months ago

  • Related to Feature #3237: Come up with GPS-DO design for E1 Interface added

#7 Updated by tnt 3 months ago

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.

#8 Updated by vogelchr 3 months ago

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)

  • 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).

#9 Updated by laforge 3 months ago

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.

#10 Updated by mschramm 3 months ago

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

#11 Updated by laforge 3 months ago

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.

#12 Updated by laforge 3 months ago

  • Tags set to E1

#13 Updated by vogelchr about 2 months ago

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.

  • 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)

#14 Updated by laforge about 2 months ago

Hi Christian,

thank for all your work!

On Mon, Jun 25, 2018 at 06:02:45AM +0000, vogelchr [REDMINE] wrote:

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.

One attempt could be to solve this by manually patching the XML file to remote/replace the
"offending" library elements. But then, it might be easier to do this in the GUI, if one can simply
use swap the new-lib part against a pin-compatible old-lib part.

- interface to old LIU only board (SPI + DATA on pinheader)

I don't think it's worth it. I would have assumed we simply continue to use the LIU using which
several of us have already successfully performed experiments with. It's only a very small increase
in price, and one gets all kinds of benefits such as reading signal levels via SPI. Also, a basic
driver already exists today. The pinout has been debugged and is now fixed. Same about the
transformer. Using new parts for the first time always introduces some risk / unknown factors.

Now of course this is your board and you can do with it as you pleae. I'm just saying from my point
of view, if I had done it, I would have tried to reuse as much as possible from osmo-e1-xcvr.

So from my POV: There's no need in adding the header. Either you keep the LIU you choose, or
switch to the LIU we have on the e1-xcvr board, but having both options is overkill.

I'll give the schematics a more thorough review as soon as I can (hopefully still today).

#15 Updated by vogelchr about 2 months ago

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.

#16 Updated by laforge about 2 months ago

  • Checklist item SAM4S set to Done
  • Checklist item GPS receiver with 1PPS output set to Done
  • Checklist item VC[TC]XO driven by DAC [of SAM4?] set to Done
  • Checklist item LIU set to Done
  • Assignee changed from laforge to vogelchr

#17 Updated by laforge about 2 months ago

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

#18 Updated by laforge about 2 months ago

adding more eagle libraries

#19 Updated by vogelchr about 1 month ago

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!

#20 Updated by laforge about 1 month ago

Thanks for putting in all the effort.

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.

No critical remarks from my side. I'm happy to cover the board prototype costs, but then sysmocom would have to buy them directly. What about a set of 3 prototypes from aisler.net?

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

thanks.

- 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.

But it's probably just to get the last 0.01 dB in sensitivity, something we're not worrying
about here.

#21 Updated by laforge about 1 month ago

one more thought: If you want to put this into an enclosure with a front
panel on the "west" side of the PCB, then the edge-launch SMA won't
work, as it adds some ~2mm of body which doesn't fit between PCB edge
and the front panel.

So either a horizontal THT SMA could be used (probably easiest), or the
PCB would have to be milled in the area of the edge-launch SMA to
accomodate those ~2mm of space requirement.

#22 Updated by laforge about 1 month ago

btw: I just ordered 3x GNS2201 and 3x GNS3301 samples.

#23 Updated by vogelchr about 1 month ago

- 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)