Feature #5625
closedicE1usb gateware/firmware support for external GPS receiver
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
Updated by tnt over 1 year 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
Updated by laforge over 1 year 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.
Updated by tnt over 1 year 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)
Updated by laforge over 1 year 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.
Updated by laforge over 1 year 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.
Updated by laforge over 1 year ago
- Related to Bug #5542: Move hub to datacenter colocation added
Updated by tnt over 1 year ago
- Related to Bug #5708: rs422: Support runtime re-init of the GPS receiver added
Updated by tnt over 1 year 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
Updated by tnt over 1 year ago
- Status changed from In Progress to Resolved
Closing this since the open points now have dedicated issues.