Project

General

Profile

Actions

Feature #5625

closed

icE1usb gateware/firmware support for external GPS receiver

Added by laforge 4 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
07/22/2022
Due date:
% Done:

70%


Description

So far, icE1usb supports only 1PPS from its internal GPS receiver. In a data-centre co-location environment, we will have to use a remote receiver attached via RS422/485 (see #5624)

This ticket is for supporting this from the gateware/firmware side


Checklist

  • what to do with the rs422 branch? can it be integrated to master (ifdef/...)?
  • don't require 12V to be present before 5V/VUSB

Related issues

Related to OCTOI - Osmocom Community TDM over IP - Bug #5542: Move hub to datacenter colocationResolvedlaforge04/21/202209/19/2022

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Bug #5708: rs422: Support runtime re-init of the GPS receiverNewtnt10/13/2022

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #5709: rs422: Merge as much of the firmware into master to avoid separate branchNewtnt10/13/2022

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #5710: rs422: Merge as much of the gateware in master as possibleNewtnt10/13/2022

Actions
Actions #1

Updated by tnt 3 months ago

  • % Done changed from 0 to 50

I started doing this (for the testing).

  • ATM the gateware only supports one E1 channel in that configuration simply because the added logic didn't fit ...
  • The firmware still needs some work too:
    • It should really only export 1 port since the gateware only supports that
    • ATM there is no error recovery if the isolated PSU goes down. It needs to be powered before the icE1usb because at init time we configure some I2C expander on the isolated side and that means the isolated side needs power. And if it looses power it looses config ...
    • We should also be using the PERC message to know the GPS status because the other message only come once every minute which is very not often
Actions #2

Updated by tnt 3 months ago

  • Status changed from New to In Progress
Actions #3

Updated by laforge 3 months ago

Hi tnt,

On Wed, Aug 31, 2022 at 07:45:32PM +0000, tnt wrote:

I started doing this (for the testing).

thanks.

  • ATM the gateware only supports one E1 channel in that configuration simply because the added logic didn't fit ...

That's completely fine, and this can very well stay a permanent constraint from my point of view.

  • ATM there is no error recovery if the isolated PSU goes down. It needs to be powered before the icE1usb because at init time we configure some I2C expander on the isolated side and that means the isolated side needs power. And if it looses power it looses config ...

it's unlikely to loose power during operation (both parts are assembled in one enclosure). The only reason
would be a PSU failure or the 300mA PTC fuse (just for the icE40 isolated side; the GPS02 has a separate PTC) blowing. Both rather unlikely.

However, we cannot guarantee power-up sequencing during normal start-up, so this indeed will need to be
adressed before deployment.

  • We should also be using the PERC message to know the GPS status because the other message only come once every minute which is very not often

agreed. One could also change the intervals via NMEA, but then we are talking about a 9600 bps
interface which simply cannot carry a lot of sentences at second granularity.

The $PERC,GPsts, is the relevant message. The first part behind the comma tells us the
1PPS state:

Integer Description 1PPS Active
0 Acquisition mode False
1 Survey mode True
2 Position-Hold True
3 Acquisition-Mode (Position-Hold Complete) True

$PERC,ppr would tell us the time-of-week and week number, but its easier to update
that when we get the standard NMEA messages.

Actions #4

Updated by tnt 3 months ago

Pushed a `tnt/rs422` branch with both the firmware and gateware changes.

  • Firmware changed to report only 1 E1 interface
  • Changed it to use PERC messages to evaluate validity of PPS. (ATM I don't consider 3 as valid. AFAICT in that state there is no GPS fix, so we might as well hold over with our internal clock)
Actions #5

Updated by laforge 3 months ago

I've been doing some testing and it seems that the GPS03 I have behaves different in terms of GPsts than what tnt has been experiencing on his side.

One minor change, and it works like expected in terms of reported GPS status by osmo-e1d:

        if (!strncmp(nmea, "$PERC,GPsts,", 12))
        {
-               g_gps.fix.valid =
-                       ((nmea[12] == '1') || (nmea[12] == '2')) &&
-                       (nmea[16] == '2');
+               g_gps.fix.valid = (nmea[12] == '1') || (nmea[12] == '2');
        }
 }

I've also tested antenna disconnect + reconnect and the osmo-e1d reported GPS status now behaves exactly like I know it from the built-in GPS.

I haven't yet done any actual tests on the frequency stability. I'll maybe put a X/Y scope plot up with an E1 signal from a rs422-icE1 vs. a internal-gps-icE1.

Actions #6

Updated by laforge 3 months ago

  • Checklist item what to do with the rs422 branch? can it be integrated to master (ifdef/...)? added
  • Checklist item don't require 12V to be present before 5V/VUSB added
  • % Done changed from 50 to 70

laforge wrote in #note-5:

I haven't yet done any actual tests on the frequency stability. I'll maybe put a X/Y scope plot up with an E1 signal from a rs422-icE1 vs. a internal-gps-icE1.

I did that last night and also again today (comparing the transmit bit clock of two TE820 cards, where one is synced to the RS422-GPS03-icE1usb and the other to a normal icE1usb). Looks great.

Adding some checklist items to this issue so we don't forget about them. Nothing critical that needs resolving before the initial installation, though.

Actions #7

Updated by laforge about 2 months ago

  • Parent task deleted (#5542)
Actions #8

Updated by laforge about 2 months ago

  • Related to Bug #5542: Move hub to datacenter colocation added
Actions #9

Updated by tnt about 2 months ago

  • Related to Bug #5708: rs422: Support runtime re-init of the GPS receiver added
Actions #10

Updated by tnt about 2 months ago

  • Related to Feature #5709: rs422: Merge as much of the firmware into master to avoid separate branch added
  • Related to Feature #5710: rs422: Merge as much of the gateware in master as possible added
Actions #11

Updated by tnt about 2 months ago

  • Status changed from In Progress to Resolved

Closing this since the open points now have dedicated issues.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)