Feature #3272
closednext-generation osmo-e1-xcvr board
70%
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.
Files
Checklist
- SAM4S
- GPS receiver with 1PPS output
- VC[TC]XO driven by DAC [of SAM4?]
- possibly precision voltage reference for DAC?
- LIU
- magnetics matching to LIU and with fixed symbol/footprint
- SAM-BA capable UART (PA9/PA10?) on 2.5mm jack (SJ-2523-SMT)
Related issues
Updated by laforge over 5 years 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, ...
Updated by laforge over 5 years ago
- File GNS2201_datasheet.pdf GNS2201_datasheet.pdf added
- File GNS3301_datasheet.pdf GNS3301_datasheet.pdf added
- File GNS3301B_datasheet.pdf GNS3301B_datasheet.pdf added
- File Venus828F_PB_v1.pdf Venus828F_PB_v1.pdf added
- 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
Updated by laforge over 5 years 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
- 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)
Updated by tnt over 5 years 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.
Updated by laforge over 5 years 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, ...]
Updated by laforge over 5 years ago
- Related to Feature #3237: Come up with GPS-DO design for E1 Interface added
Updated by tnt over 5 years 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.
Updated by vogelchr over 5 years 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)¶
- 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).
Updated by laforge over 5 years 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.
Updated by mschramm over 5 years ago
(As the ticket has one subticket which is solved, it appears to be 100% solved too which isn't true ,) )
Updated by laforge over 5 years ago
- File GNS3301.lbr GNS3301.lbr added
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.
Updated by vogelchr over 5 years 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.
- 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)
Updated by laforge over 5 years 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).
Updated by vogelchr over 5 years 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.
Updated by laforge over 5 years 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
Updated by laforge over 5 years ago
- File laforge.lbr laforge.lbr added
- % Done changed from 100 to 70
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
Updated by laforge over 5 years ago
- File MAX521x.lbr MAX521x.lbr added
- File MAX616x.lbr MAX616x.lbr added
adding more eagle libraries
Updated by vogelchr over 5 years 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!
Updated by laforge over 5 years 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.
Updated by laforge over 5 years 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.
Updated by laforge over 5 years ago
btw: I just ordered 3x GNS2201 and 3x GNS3301 samples.
Updated by vogelchr over 5 years 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 oppinionRationale: 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.
Updated by vogelchr about 5 years ago
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.
Updated by laforge over 3 years ago
- Status changed from New to Rejected
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!