Retronetworking » OCTOI - Osmocom Community TDM over IP

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:

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

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)

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.