Project

General

Profile

Actions

Feature #3237

closed

Come up with GPS-DO design for E1 Interface

Added by laforge almost 6 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/04/2018
Due date:
% Done:

0%

Spec Reference:
Tags:
E1

Description

We want to include a GPS-DO in our design, to ensure operation of the BTS at proper carrier frequency. That GPS-DO should have
  • some GPS receiver with 1PPS output
  • some local, voltage-controlled oscillator (VCTCXO)
    • the frequency should permit simple division to generate the 2.048 MHz required for E1 (otherwise we'd need a PLL)
  • some DAC to steer the voltage-controlled oscillator
  • some circuitry to count the number of of oscillator cycles between 1PPS edges
  • some software to compensate for 1PPS jitter, loop filtering, possibly temperature compensation, etc.

See E1_Clock_Notes for more information.


Files

sam4s_clock_pll_scheme.pdf View sam4s_clock_pll_scheme.pdf 227 KB vogelchr, 05/22/2018 05:17 PM
sam4s_clock_pll_scheme.svg View sam4s_clock_pll_scheme.svg 111 KB vogelchr, 05/22/2018 05:21 PM

Related issues

Related to E1/T1 Hardware Interface (including icE1usb) - Feature #2484: Architecture of USB E1/T1/J1 adapterResolvedlaforge09/02/2017

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #3272: next-generation osmo-e1-xcvr boardRejectedvogelchr05/15/2018

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #3967: design a custom board for the ICE40 E1 adapterResolvedtnt04/30/2019

Actions
Actions #1

Updated by tnt almost 6 years ago

The clocking architecture might be highly dependent on the choice of 'MCU' (sam3/xmos/ti/fpga...).

Most of these would have timer peripheral that will allow to do the counting, possibly even do the division to generate the 2.048M clock (if the vctxo clocks that 'mcu' directly) or have DAC, ...

Actions #2

Updated by laforge almost 6 years ago

On Sat, May 05, 2018 at 04:41:56AM +0000, tnt [REDMINE] wrote:

The clocking architecture might be highly dependent on the choice of 'MCU' (sam3/xmos/ti/fpga...).

Most of these would have timer peripheral that will allow to do the counting, possibly even do the division to generate the 2.048M clock (if the vctxo clocks that 'mcu' directly) or have DAC, ...

I'm not sure any of those (except FPGA) are really suitable for the job? I guess you'd want a synchronous
counter that really counts at the clock rate of the OCXO, without any clock conversion to some other clock
internally which introduces significant jitter?

AFAIK, on both sam3 and possibly also xmos, all inputs are (re)sampled with some internal clock and hence I would expect related jitter.

Using something like the non-counter approach of the "Lars" GPS-DO, or something like http://www.leapsecond.com/pic/picdiv.htm to go from 10MHz t 1 pps (and then simply compare the phase of the two 1PPS with each other?) would not suffer from that.

But then, maybe the jitter is tolerable, I don't know...

In the ideal world, we would come up with some GPS-DO that's capable of generating the 2.048 MHz
irrespective of what we use as processor for the E1. This way we stay open to multiple approaches.

Actions #3

Updated by tnt almost 6 years ago

I was thinking of two options (that I'll illustrate using the SAM4S here, didn't check XMOS):

  1. Timers have an external clock input pin and feed that with the VCXO. I actually thought that this would synchronously feed the counter directly, but you're right, it's actually re-synced to the internal peripheral clock. Now, I don't think it would be that much of an issue because:
    • The peripheral clock is going to be much higher in any case
    • By progressively increasing the time constant of the software filtering (to get quick lock at the beginning, but be more stable after), that jitter wouldn't matter much I think
    • In any case I don't think the jitter of the clock we generate any way is all that important (well, needs to be reasonable of course and withing E1 spec), because the BTS is going to have its own oscillator and will just lock the long term frequency to what we send.
  1. But any way, a better option I would think is to clock the MCU itself with the VCXO as well. So for instance for the SAM4S:
    • You'd use a 30.72M VCXO and feed that to the SAM4S
    • Using the internal PLL, you can divide it by 8 and then multiply by 25 to generate the 96 MHz output needed for USB.
    • Using the other PLL you can generate the core clock, something like divide by 3, multiply by 10 to generate a 102.4 MHz clock.
    • Using a PWM peripheral it should be possible to output 2.048 MHz that's perfectly synced to the input 30.72M
    • Use the TC to count pulse between PPS and drive a DAC, or even possibly use a heavy filtered PWM channel.
Actions #4

Updated by vogelchr almost 6 years ago

If we do it all within a microcontroller, and to receive E1 bits we probably want to sample the incoming signal at a rate ≥4×f_E1 (pulses are ~250ns), so we would need two synchronized SPI blocks at 8,192 Mhz. Same holds true for generating the pulses.

Otherwise the idea of running the MCU from the VCXO seems to be a good idea.

Actions #5

Updated by laforge almost 6 years ago

  • Related to Feature #2484: Architecture of USB E1/T1/J1 adapter added
Actions #6

Updated by laforge almost 6 years ago

  • Related to Feature #3272: next-generation osmo-e1-xcvr board added
Actions #7

Updated by laforge almost 6 years ago

  • Assignee set to vogelchr
Actions #8

Updated by vogelchr almost 6 years ago

I've drawn up the clocking scheme proposed by tnt on top of a page of the SAM4S user manual. The programmable clock controller can output the 2,048 MHz for the LIU directly to a pin. That way we use up both PLLs and we will run the core at 96 MHz.

Actions #9

Updated by laforge almost 6 years ago

  • Tags set to E1
Actions #10

Updated by vogelchr almost 6 years ago

SAM-BA over USB works for an 18.432 MHz XTAL (9*2.048), but the boot code seems to expect a crystal, not an external oscillator which has different input requirements on the signal fed to XIN. (§24.2, Note 1). We will have to attenuate the 3.3V crystal oscillator output to not overdrive the xtal input amplifier.

If 18.432 MHz oscillators are unavailable, we could add a separate one only for SAM-BA, and alternate between them outputs via the oscillator enable pins.

Actions #11

Updated by laforge almost 6 years ago

As indicated, I think having SAM-BA only on UART is not such a big issue. We add
the usual 2.5mm jack, and people can use their "Motorola T191" aka "OsmocomBB" serial
cables.

Actions #12

Updated by laforge almost 5 years ago

  • Related to Feature #3967: design a custom board for the ICE40 E1 adapter added
Actions #13

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!

Actions #14

Updated by laforge about 2 years ago

  • Related to Feature #4675: Add + document vendor specific control commands added
Actions #15

Updated by laforge about 2 years ago

  • Related to deleted (Feature #4675: Add + document vendor specific control commands)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)