usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

GPS fix behavior on USRP E320

DR
David Raeman
Wed, Jun 5, 2024 12:43 PM

Hello,

I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run).

When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels.

I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected.

Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think:

  • The X410 sets the module in 1Hz mode instead of 5Hz.
  • The X410 uses it in "mobile" mode instead of auto-surveying "stationary" mode.
  • Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC.

Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don't mind changing resistor populations if there is a reason to. Or any other suggestions around this topic?

Thank you,
David Raeman

Hello, I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run). When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels. I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected. Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think: * The X410 sets the module in 1Hz mode instead of 5Hz. * The X410 uses it in "mobile" mode instead of auto-surveying "stationary" mode. * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC. Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don't mind changing resistor populations if there is a reason to. Or any other suggestions around this topic? Thank you, David Raeman
MD
Marcus D. Leech
Wed, Jun 5, 2024 12:56 PM

On 05/06/2024 08:43, David Raeman via USRP-users wrote:

Hello,

I'm having a difficult time getting consistent GPS fix behavior from a
set of USRP E320 radios. They are all using UHD 4.4 with the same
active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short
~6" coax run).

When outside with a view of the sky and 6 radios sitting together,
10-15 minutes after power-on, some of the radios will have a lock and
others will not. For radios that get a lock, sometimes they will
briefly glitch into "unlocked" state briefly every 20-30 seconds
before reporting as locked again. If I let it sit another 10-15
minutes, nothing really changes. Looking at the output of 'gpsmon' on
the radio, the radios which never locked will see fewer satellites,
and the ones in common will have far different SNR levels.

I'm trying to find a solution for more consistent behavior, especially
since these are outside with a view of the sky. I confirmed the
radio's GPS ANT port has the +3.3V bias so I assume the antennas
receive power as expected.

Searching the mailing list, over the years this topic has come up a
couple times specifically with E320 radios. I know the same Jackson
Labs LTE-Lite SOM is also used in the newer X410 radios, though it's
configured a bit differently via strapping pins. I think:

  • The X410 sets the module in 1Hz mode instead of 5Hz.

  • The X410 uses it in "mobile" mode instead of auto-surveying
    “stationary” mode.

  • Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC),
    though this doesn't make any sense based on the LTE-Lite public tech
    manual. The X410 leaves them NC.

Does anybody know whether any of the changes (or others) represent
"lessons learned" that would improve GPS TTFF or disciplining
behavior? I don’t mind changing resistor populations if there is a
reason to. Or any other suggestions around this topic?

Thank you,

David Raeman


USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com

IF you move the antennas further apart, what happens?

If they are all tightly packed together, there's an opportunity for
shadowing (small, but, maybe?).

On 05/06/2024 08:43, David Raeman via USRP-users wrote: > > Hello, > > I'm having a difficult time getting consistent GPS fix behavior from a > set of USRP E320 radios. They are all using UHD 4.4 with the same > active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short > ~6" coax run). > > When outside with a view of the sky and 6 radios sitting together, > 10-15 minutes after power-on, some of the radios will have a lock and > others will not. For radios that get a lock, sometimes they will > briefly glitch into "unlocked" state briefly every 20-30 seconds > before reporting as locked again. If I let it sit another 10-15 > minutes, nothing really changes. Looking at the output of 'gpsmon' on > the radio, the radios which never locked will see fewer satellites, > and the ones in common will have far different SNR levels. > > I'm trying to find a solution for more consistent behavior, especially > since these are outside with a view of the sky. I confirmed the > radio's GPS ANT port has the +3.3V bias so I assume the antennas > receive power as expected. > > Searching the mailing list, over the years this topic has come up a > couple times specifically with E320 radios. I know the same Jackson > Labs LTE-Lite SOM is also used in the newer X410 radios, though it's > configured a bit differently via strapping pins. I think: > > * The X410 sets the module in 1Hz mode instead of 5Hz. > > * The X410 uses it in "mobile" mode instead of auto-surveying > “stationary” mode. > > * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), > though this doesn't make any sense based on the LTE-Lite public tech > manual. The X410 leaves them NC. > > Does anybody know whether any of the changes (or others) represent > "lessons learned" that would improve GPS TTFF or disciplining > behavior? I don’t mind changing resistor populations if there is a > reason to. Or any other suggestions around this topic? > > Thank you, > > David Raeman > > > _______________________________________________ > USRP-users mailing list --usrp-users@lists.ettus.com > To unsubscribe send an email tousrp-users-leave@lists.ettus.com IF you move the antennas further apart, what happens? If they are all tightly packed together, there's an opportunity for shadowing (small, but, maybe?).
DR
David Raeman
Wed, Jun 5, 2024 3:19 PM

Thanks for the suggestion – in this case they were all sitting on the roof of my vehicle in an open parking lot, with 6-8” separation between radios. I guess there could be minimal shadowing for satellites at low grazing angles, but I’m skeptical of that as a full explanation.

I have a hypothesis that the default 5Hz update rate is problematic on these devices. The serial connection between the GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1 framing, that only allows for 768 bytes of sentence data per 200ms cycle. If I capture the raw GPS serial output (by directly watching /dev/ttyPS1, not the scrubbed data filtered through gpsd), it’s quickly obvious that many sentences get truncated and/or dropped. For example, there are very frequent “time skips” happening in the time-related sentences, as well as random sentence fragments. Some cycles would be expected to have a larger data volume, such as when multiple GPGSV sentences list all satellites in view, and I think that’s mangling the serial stream.

This explains discrepancies in what ‘gpsmon’ sees, as well as discrepancies I’ve sometimes seen on E320s trying to sync common GPS time with PPS assertion (sometimes radios are wrong by 200ms). This should not impact the “gps_locked” sensor, which gets its state via an I/O signal from the GPS receiver and not by parsing sentences. However, I am currently using information from sentences to determine lock status because “gps_locked” doesn’t seem to work as expected in UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5 though).

So long story short – I think 5Hz update rate is problematic. It can be changed to 1Hz by removing a resistor, and as far as I can tell, neither UHD nor the radio filesystem would care about that change. I may try this on one radio and see if it helps improve consistency..

-David

From: Marcus D. Leech patchvonbraun@gmail.com
Sent: Wednesday, June 5, 2024 8:56 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: GPS fix behavior on USRP E320

On 05/06/2024 08:43, David Raeman via USRP-users wrote:
Hello,

I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run).

When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels.

I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected.

Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think:

  • The X410 sets the module in 1Hz mode instead of 5Hz.
  • The X410 uses it in "mobile" mode instead of auto-surveying “stationary” mode.
  • Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC.

Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don’t mind changing resistor populations if there is a reason to. Or any other suggestions around this topic?

Thank you,
David Raeman


USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com

To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
IF you move the antennas further apart, what happens?

If they are all tightly packed together, there's an opportunity for shadowing (small, but, maybe?).

Thanks for the suggestion – in this case they were all sitting on the roof of my vehicle in an open parking lot, with 6-8” separation between radios. I guess there could be minimal shadowing for satellites at low grazing angles, but I’m skeptical of that as a full explanation. I have a hypothesis that the default 5Hz update rate is problematic on these devices. The serial connection between the GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1 framing, that only allows for 768 bytes of sentence data per 200ms cycle. If I capture the raw GPS serial output (by directly watching /dev/ttyPS1, not the scrubbed data filtered through gpsd), it’s quickly obvious that many sentences get truncated and/or dropped. For example, there are very frequent “time skips” happening in the time-related sentences, as well as random sentence fragments. Some cycles would be expected to have a larger data volume, such as when multiple GPGSV sentences list all satellites in view, and I think that’s mangling the serial stream. This explains discrepancies in what ‘gpsmon’ sees, as well as discrepancies I’ve sometimes seen on E320s trying to sync common GPS time with PPS assertion (sometimes radios are wrong by 200ms). This should not impact the “gps_locked” sensor, which gets its state via an I/O signal from the GPS receiver and not by parsing sentences. However, I am currently using information from sentences to determine lock status because “gps_locked” doesn’t seem to work as expected in UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5 though). So long story short – I think 5Hz update rate is problematic. It can be changed to 1Hz by removing a resistor, and as far as I can tell, neither UHD nor the radio filesystem would care about that change. I may try this on one radio and see if it helps improve consistency.. -David From: Marcus D. Leech <patchvonbraun@gmail.com> Sent: Wednesday, June 5, 2024 8:56 AM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: GPS fix behavior on USRP E320 On 05/06/2024 08:43, David Raeman via USRP-users wrote: Hello, I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run). When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels. I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected. Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think: * The X410 sets the module in 1Hz mode instead of 5Hz. * The X410 uses it in "mobile" mode instead of auto-surveying “stationary” mode. * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC. Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don’t mind changing resistor populations if there is a reason to. Or any other suggestions around this topic? Thank you, David Raeman _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-leave@lists.ettus.com<mailto:usrp-users-leave@lists.ettus.com> IF you move the antennas further apart, what happens? If they are all tightly packed together, there's an opportunity for shadowing (small, but, maybe?).
MD
Marcus D. Leech
Wed, Jun 5, 2024 11:59 PM

On 05/06/2024 11:19, David Raeman wrote:

Thanks for the suggestion – in this case they were all sitting on the
roof of my vehicle in an open parking lot, with 6-8” separation
between radios. I guess there could be minimal shadowing for
satellites at low grazing angles, but I’m skeptical of that as a full
explanation.

I have a hypothesis that the default 5Hz update rate is problematic on
these devices. The serial connection between the GPS receiver the Zynq
PS runs at 38400 baud. With standard 8N1 framing, that only allows for
768 bytes of sentence data per 200ms cycle. If I capture the raw GPS
serial output (by directly watching /dev/ttyPS1, not the scrubbed data
filtered through gpsd), it’s quickly obvious that many sentences get
truncated and/or dropped. For example, there are very frequent “time
skips” happening in the time-related sentences, as well as random
sentence fragments. Some cycles would be expected to have a larger
data volume, such as when multiple GPGSV sentences list all satellites
in view, and I think that’s mangling the serial stream.

This explains discrepancies in what ‘gpsmon’ sees, as well as
discrepancies I’ve sometimes seen on E320s trying to sync common GPS
time with PPS assertion (sometimes radios are wrong by 200ms). This
should not impact the “gps_locked” sensor, which gets its state via an
I/O signal from the GPS receiver and not by parsing sentences.
However, I am currently using information from sentences to determine
lock status because “gps_locked” doesn’t seem to work as expected in
UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5
though).

So long story short – I think 5Hz update rate is problematic. It can
be changed to 1Hz by removing a resistor, and as far as I can tell,
neither UHD nor the radio filesystem would care about that change. I
may try this on one radio and see if it helps improve consistency..

-David

You're not trying to capture /dev/ttyPS1 data while GPSD is capturing
it, are you?  You can't usefully share a resource like a
  serial port -- some characters will go to you, some to GPSD.

Now, having said that, yeah, only 768 bytes per update interval max. 
How many bytes in a typical NMEA sentence, and how
  many sentences per interval?

*From:*Marcus D. Leech patchvonbraun@gmail.com
Sent: Wednesday, June 5, 2024 8:56 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: GPS fix behavior on USRP E320

On 05/06/2024 08:43, David Raeman via USRP-users wrote:

 Hello,

 I'm having a difficult time getting consistent GPS fix behavior
 from a set of USRP E320 radios. They are all using UHD 4.4 with
 the same active GPS antenna (Siretta Tango 21, which has a 28dB
 LNA and short ~6" coax run).

 When outside with a view of the sky and 6 radios sitting together,
 10-15 minutes after power-on, some of the radios will have a lock
 and others will not. For radios that get a lock, sometimes they
 will briefly glitch into "unlocked" state briefly every 20-30
 seconds before reporting as locked again. If I let it sit another
 10-15 minutes, nothing really changes. Looking at the output of
 'gpsmon' on the radio, the radios which never locked will see
 fewer satellites, and the ones in common will have far different
 SNR levels.

 I'm trying to find a solution for more consistent behavior,
 especially since these are outside with a view of the sky. I
 confirmed the radio's GPS ANT port has the +3.3V bias so I assume
 the antennas receive power as expected.

 Searching the mailing list, over the years this topic has come up
 a couple times specifically with E320 radios. I know the same
 Jackson Labs LTE-Lite SOM is also used in the newer X410 radios,
 though it's configured a bit differently via strapping pins. I think:

 * The X410 sets the module in 1Hz mode instead of 5Hz.

 * The X410 uses it in "mobile" mode instead of auto-surveying
 “stationary” mode.

 * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC),
 though this doesn't make any sense based on the LTE-Lite public
 tech manual. The X410 leaves them NC.

 Does anybody know whether any of the changes (or others) represent
 "lessons learned" that would improve GPS TTFF or disciplining
 behavior? I don’t mind changing resistor populations if there is a
 reason to. Or any other suggestions around this topic?

 Thank you,

 David Raeman



 _______________________________________________

 USRP-users mailing list --usrp-users@lists.ettus.com

 To unsubscribe send an email tousrp-users-leave@lists.ettus.com

IF you move the antennas further apart, what happens?

If they are all tightly packed together, there's an opportunity for
shadowing (small, but, maybe?).

On 05/06/2024 11:19, David Raeman wrote: > > Thanks for the suggestion – in this case they were all sitting on the > roof of my vehicle in an open parking lot, with 6-8” separation > between radios. I guess there could be minimal shadowing for > satellites at low grazing angles, but I’m skeptical of that as a full > explanation. > > I have a hypothesis that the default 5Hz update rate is problematic on > these devices. The serial connection between the GPS receiver the Zynq > PS runs at 38400 baud. With standard 8N1 framing, that only allows for > 768 bytes of sentence data per 200ms cycle. If I capture the raw GPS > serial output (by directly watching /dev/ttyPS1, not the scrubbed data > filtered through gpsd), it’s quickly obvious that many sentences get > truncated and/or dropped. For example, there are very frequent “time > skips” happening in the time-related sentences, as well as random > sentence fragments. Some cycles would be expected to have a larger > data volume, such as when multiple GPGSV sentences list all satellites > in view, and I think that’s mangling the serial stream. > > This explains discrepancies in what ‘gpsmon’ sees, as well as > discrepancies I’ve sometimes seen on E320s trying to sync common GPS > time with PPS assertion (sometimes radios are wrong by 200ms). This > should not impact the “gps_locked” sensor, which gets its state via an > I/O signal from the GPS receiver and not by parsing sentences. > However, I am currently using information from sentences to determine > lock status because “gps_locked” doesn’t seem to work as expected in > UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5 > though). > > So long story short – I think 5Hz update rate is problematic. It can > be changed to 1Hz by removing a resistor, and as far as I can tell, > neither UHD nor the radio filesystem would care about that change. I > may try this on one radio and see if it helps improve consistency.. > > -David > You're not trying to capture /dev/ttyPS1 data *while* GPSD is capturing it, are you?  You can't usefully share a resource like a   serial port -- some characters will go to you, some to GPSD. Now, having said that, yeah, only 768 bytes per update interval max.  How many bytes in a typical NMEA sentence, and how   many sentences per interval? > *From:*Marcus D. Leech <patchvonbraun@gmail.com> > *Sent:* Wednesday, June 5, 2024 8:56 AM > *To:* usrp-users@lists.ettus.com > *Subject:* [USRP-users] Re: GPS fix behavior on USRP E320 > > On 05/06/2024 08:43, David Raeman via USRP-users wrote: > > Hello, > > I'm having a difficult time getting consistent GPS fix behavior > from a set of USRP E320 radios. They are all using UHD 4.4 with > the same active GPS antenna (Siretta Tango 21, which has a 28dB > LNA and short ~6" coax run). > > When outside with a view of the sky and 6 radios sitting together, > 10-15 minutes after power-on, some of the radios will have a lock > and others will not. For radios that get a lock, sometimes they > will briefly glitch into "unlocked" state briefly every 20-30 > seconds before reporting as locked again. If I let it sit another > 10-15 minutes, nothing really changes. Looking at the output of > 'gpsmon' on the radio, the radios which never locked will see > fewer satellites, and the ones in common will have far different > SNR levels. > > I'm trying to find a solution for more consistent behavior, > especially since these are outside with a view of the sky. I > confirmed the radio's GPS ANT port has the +3.3V bias so I assume > the antennas receive power as expected. > > Searching the mailing list, over the years this topic has come up > a couple times specifically with E320 radios. I know the same > Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, > though it's configured a bit differently via strapping pins. I think: > > * The X410 sets the module in 1Hz mode instead of 5Hz. > > * The X410 uses it in "mobile" mode instead of auto-surveying > “stationary” mode. > > * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), > though this doesn't make any sense based on the LTE-Lite public > tech manual. The X410 leaves them NC. > > Does anybody know whether any of the changes (or others) represent > "lessons learned" that would improve GPS TTFF or disciplining > behavior? I don’t mind changing resistor populations if there is a > reason to. Or any other suggestions around this topic? > > Thank you, > > David Raeman > > > > _______________________________________________ > > USRP-users mailing list --usrp-users@lists.ettus.com > > To unsubscribe send an email tousrp-users-leave@lists.ettus.com > > IF you move the antennas further apart, what happens? > > If they are all tightly packed together, there's an opportunity for > shadowing (small, but, maybe?). >
DR
David Raeman
Thu, Jun 6, 2024 2:36 AM

Correct, gpsd was stopped (in fact I cannot even open the tty device if gpsd is running).

I am also going to backpedal because I haven’t able to reproduce what I saw/logged in the earlier test. The largest NMEA sentence burst I’m seeing is about 550 bytes. It possible my earlier observation is a sporadic issue with the receiver, but it’s more likely I botched something in my test because I cannot reproduce that behavior.

I did find the root cause of my problem, though, and it’s unrelated to the SDR. I have a Raspberry Pi in the same chassis as the USRP E320, and it has an attached USB3/Ethernet dongle. There’s a well-known issue where certain USB3 devices and cables emit significant broadband RF interference via the high-speed bus signaling. Afflicted devices can jam co-located receivers including GPS and WiFi. Intel published a whitepaper on the topic more than a decade ago [1]. When I remove this USB3/Ethernet dongle from the system, GPS immediately works well. When I plug it back in, I immediately lose the satellites again. This dongle has nothing to do with the USRP’s function, but it was positioned just 3-4 inches from the GPS antenna that feeds into the USRP.

So not an SDR issue, but perhaps this thread may help a USRP user in the future..

[1] https://www.usb.org/sites/default/files/327216.pdf

From: Marcus D. Leech patchvonbraun@gmail.com
Sent: Wednesday, June 5, 2024 7:59 PM
To: David Raeman david@SynopticEngineering.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: GPS fix behavior on USRP E320

On 05/06/2024 11:19, David Raeman wrote:
Thanks for the suggestion – in this case they were all sitting on the roof of my vehicle in an open parking lot, with 6-8” separation between radios. I guess there could be minimal shadowing for satellites at low grazing angles, but I’m skeptical of that as a full explanation.

I have a hypothesis that the default 5Hz update rate is problematic on these devices. The serial connection between the GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1 framing, that only allows for 768 bytes of sentence data per 200ms cycle. If I capture the raw GPS serial output (by directly watching /dev/ttyPS1, not the scrubbed data filtered through gpsd), it’s quickly obvious that many sentences get truncated and/or dropped. For example, there are very frequent “time skips” happening in the time-related sentences, as well as random sentence fragments. Some cycles would be expected to have a larger data volume, such as when multiple GPGSV sentences list all satellites in view, and I think that’s mangling the serial stream.

This explains discrepancies in what ‘gpsmon’ sees, as well as discrepancies I’ve sometimes seen on E320s trying to sync common GPS time with PPS assertion (sometimes radios are wrong by 200ms). This should not impact the “gps_locked” sensor, which gets its state via an I/O signal from the GPS receiver and not by parsing sentences. However, I am currently using information from sentences to determine lock status because “gps_locked” doesn’t seem to work as expected in UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5 though).

So long story short – I think 5Hz update rate is problematic. It can be changed to 1Hz by removing a resistor, and as far as I can tell, neither UHD nor the radio filesystem would care about that change. I may try this on one radio and see if it helps improve consistency..

-David
You're not trying to capture /dev/ttyPS1 data while GPSD is capturing it, are you?  You can't usefully share a resource like a
serial port -- some characters will go to you, some to GPSD.

Now, having said that, yeah, only 768 bytes per update interval max.  How many bytes in a typical NMEA sentence, and how
many sentences per interval?

From: Marcus D. Leech patchvonbraun@gmail.commailto:patchvonbraun@gmail.com
Sent: Wednesday, June 5, 2024 8:56 AM
To: usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Subject: [USRP-users] Re: GPS fix behavior on USRP E320

On 05/06/2024 08:43, David Raeman via USRP-users wrote:
Hello,

I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run).

When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels.

I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected.

Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think:

  • The X410 sets the module in 1Hz mode instead of 5Hz.
  • The X410 uses it in "mobile" mode instead of auto-surveying “stationary” mode.
  • Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC.

Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don’t mind changing resistor populations if there is a reason to. Or any other suggestions around this topic?

Thank you,
David Raeman


USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com

To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
IF you move the antennas further apart, what happens?

If they are all tightly packed together, there's an opportunity for shadowing (small, but, maybe?).

Correct, gpsd was stopped (in fact I cannot even open the tty device if gpsd is running). I am also going to backpedal because I haven’t able to reproduce what I saw/logged in the earlier test. The largest NMEA sentence burst I’m seeing is about 550 bytes. It possible my earlier observation is a sporadic issue with the receiver, but it’s more likely I botched something in my test because I cannot reproduce that behavior. I did find the root cause of my problem, though, and it’s unrelated to the SDR. I have a Raspberry Pi in the same chassis as the USRP E320, and it has an attached USB3/Ethernet dongle. There’s a well-known issue where certain USB3 devices and cables emit significant broadband RF interference via the high-speed bus signaling. Afflicted devices can jam co-located receivers including GPS and WiFi. Intel published a whitepaper on the topic more than a decade ago [1]. When I remove this USB3/Ethernet dongle from the system, GPS immediately works well. When I plug it back in, I immediately lose the satellites again. This dongle has nothing to do with the USRP’s function, but it was positioned just 3-4 inches from the GPS antenna that feeds into the USRP. So not an SDR issue, but perhaps this thread may help a USRP user in the future.. [1] https://www.usb.org/sites/default/files/327216.pdf From: Marcus D. Leech <patchvonbraun@gmail.com> Sent: Wednesday, June 5, 2024 7:59 PM To: David Raeman <david@SynopticEngineering.com>; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: GPS fix behavior on USRP E320 On 05/06/2024 11:19, David Raeman wrote: Thanks for the suggestion – in this case they were all sitting on the roof of my vehicle in an open parking lot, with 6-8” separation between radios. I guess there could be minimal shadowing for satellites at low grazing angles, but I’m skeptical of that as a full explanation. I have a hypothesis that the default 5Hz update rate is problematic on these devices. The serial connection between the GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1 framing, that only allows for 768 bytes of sentence data per 200ms cycle. If I capture the raw GPS serial output (by directly watching /dev/ttyPS1, not the scrubbed data filtered through gpsd), it’s quickly obvious that many sentences get truncated and/or dropped. For example, there are very frequent “time skips” happening in the time-related sentences, as well as random sentence fragments. Some cycles would be expected to have a larger data volume, such as when multiple GPGSV sentences list all satellites in view, and I think that’s mangling the serial stream. This explains discrepancies in what ‘gpsmon’ sees, as well as discrepancies I’ve sometimes seen on E320s trying to sync common GPS time with PPS assertion (sometimes radios are wrong by 200ms). This should not impact the “gps_locked” sensor, which gets its state via an I/O signal from the GPS receiver and not by parsing sentences. However, I am currently using information from sentences to determine lock status because “gps_locked” doesn’t seem to work as expected in UHD 4.4 on the E320 (looks like that might’ve been fixed in UHD 4.5 though). So long story short – I think 5Hz update rate is problematic. It can be changed to 1Hz by removing a resistor, and as far as I can tell, neither UHD nor the radio filesystem would care about that change. I may try this on one radio and see if it helps improve consistency.. -David You're not trying to capture /dev/ttyPS1 data *while* GPSD is capturing it, are you? You can't usefully share a resource like a serial port -- some characters will go to you, some to GPSD. Now, having said that, yeah, only 768 bytes per update interval max. How many bytes in a typical NMEA sentence, and how many sentences per interval? From: Marcus D. Leech <patchvonbraun@gmail.com><mailto:patchvonbraun@gmail.com> Sent: Wednesday, June 5, 2024 8:56 AM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: GPS fix behavior on USRP E320 On 05/06/2024 08:43, David Raeman via USRP-users wrote: Hello, I'm having a difficult time getting consistent GPS fix behavior from a set of USRP E320 radios. They are all using UHD 4.4 with the same active GPS antenna (Siretta Tango 21, which has a 28dB LNA and short ~6" coax run). When outside with a view of the sky and 6 radios sitting together, 10-15 minutes after power-on, some of the radios will have a lock and others will not. For radios that get a lock, sometimes they will briefly glitch into "unlocked" state briefly every 20-30 seconds before reporting as locked again. If I let it sit another 10-15 minutes, nothing really changes. Looking at the output of 'gpsmon' on the radio, the radios which never locked will see fewer satellites, and the ones in common will have far different SNR levels. I'm trying to find a solution for more consistent behavior, especially since these are outside with a view of the sky. I confirmed the radio's GPS ANT port has the +3.3V bias so I assume the antennas receive power as expected. Searching the mailing list, over the years this topic has come up a couple times specifically with E320 radios. I know the same Jackson Labs LTE-Lite SOM is also used in the newer X410 radios, though it's configured a bit differently via strapping pins. I think: * The X410 sets the module in 1Hz mode instead of 5Hz. * The X410 uses it in "mobile" mode instead of auto-surveying “stationary” mode. * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 (NC), though this doesn't make any sense based on the LTE-Lite public tech manual. The X410 leaves them NC. Does anybody know whether any of the changes (or others) represent "lessons learned" that would improve GPS TTFF or disciplining behavior? I don’t mind changing resistor populations if there is a reason to. Or any other suggestions around this topic? Thank you, David Raeman _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-leave@lists.ettus.com<mailto:usrp-users-leave@lists.ettus.com> IF you move the antennas further apart, what happens? If they are all tightly packed together, there's an opportunity for shadowing (small, but, maybe?).
MD
Marcus D. Leech
Thu, Jun 6, 2024 2:39 AM

On 05/06/2024 22:36, David Raeman wrote:

Correct, gpsd was stopped (in fact I cannot even open the tty device
if gpsd is running).

I am also going to backpedal because I haven’t able to reproduce what
I saw/logged in the earlier test. The largest NMEA sentence burst I’m
seeing is about 550 bytes. It possible my earlier observation is a
sporadic issue with the receiver, but it’s more likely I botched
something in my test because I cannot reproduce that behavior.

I did find the root cause of my problem, though, and it’s unrelated to
the SDR. I have a Raspberry Pi in the same chassis as the USRP E320,
and it has an attached USB3/Ethernet dongle. There’s a well-known
issue where certain USB3 devices and cables emit significant broadband
RF interference via the high-speed bus signaling. Afflicted devices
can jam co-located receivers including GPS and WiFi. Intel published a
whitepaper on the topic more than a decade ago [1]. When I remove this
USB3/Ethernet dongle from the system, GPS immediately works well. When
I plug it back in, I immediately lose the satellites again. This
dongle has nothing to do with the USRP’s function, but it was
positioned just 3-4 inches from the GPS antenna that feeds into the USRP.

So not an SDR issue, but perhaps this thread may help a USRP user in
the future..

[1] https://www.usb.org/sites/default/files/327216.pdf

Thanks for sleuthing this, David!

*From:*Marcus D. Leech patchvonbraun@gmail.com
Sent: Wednesday, June 5, 2024 7:59 PM
To: David Raeman david@SynopticEngineering.com;
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: GPS fix behavior on USRP E320

On 05/06/2024 11:19, David Raeman wrote:

 Thanks for the suggestion – in this case they were all sitting on
 the roof of my vehicle in an open parking lot, with 6-8”
 separation between radios. I guess there could be minimal
 shadowing for satellites at low grazing angles, but I’m skeptical
 of that as a full explanation.

 I have a hypothesis that the default 5Hz update rate is
 problematic on these devices. The serial connection between the
 GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1
 framing, that only allows for 768 bytes of sentence data per 200ms
 cycle. If I capture the raw GPS serial output (by directly
 watching /dev/ttyPS1, not the scrubbed data filtered through
 gpsd), it’s quickly obvious that many sentences get truncated
 and/or dropped. For example, there are very frequent “time skips”
 happening in the time-related sentences, as well as random
 sentence fragments. Some cycles would be expected to have a larger
 data volume, such as when multiple GPGSV sentences list all
 satellites in view, and I think that’s mangling the serial stream.

 This explains discrepancies in what ‘gpsmon’ sees, as well as
 discrepancies I’ve sometimes seen on E320s trying to sync common
 GPS time with PPS assertion (sometimes radios are wrong by 200ms).
 This should not impact the “gps_locked” sensor, which gets its
 state via an I/O signal from the GPS receiver and not by parsing
 sentences. However, I am currently using information from
 sentences to determine lock status because “gps_locked” doesn’t
 seem to work as expected in UHD 4.4 on the E320 (looks like that
 might’ve been fixed in UHD 4.5 though).

 So long story short – I think 5Hz update rate is problematic. It
 can be changed to 1Hz by removing a resistor, and as far as I can
 tell, neither UHD nor the radio filesystem would care about that
 change. I may try this on one radio and see if it helps improve
 consistency..

 -David

You're not trying to capture /dev/ttyPS1 data while GPSD is
capturing it, are you?  You can't usefully share a resource like a
  serial port -- some characters will go to you, some to GPSD.

Now, having said that, yeah, only 768 bytes per update interval max. 
How many bytes in a typical NMEA sentence, and how
  many sentences per interval?

 *From:*Marcus D. Leech <patchvonbraun@gmail.com>
 <mailto:patchvonbraun@gmail.com>
 *Sent:* Wednesday, June 5, 2024 8:56 AM
 *To:* usrp-users@lists.ettus.com
 *Subject:* [USRP-users] Re: GPS fix behavior on USRP E320

 On 05/06/2024 08:43, David Raeman via USRP-users wrote:

     Hello,

     I'm having a difficult time getting consistent GPS fix
     behavior from a set of USRP E320 radios. They are all using
     UHD 4.4 with the same active GPS antenna (Siretta Tango 21,
     which has a 28dB LNA and short ~6" coax run).

     When outside with a view of the sky and 6 radios sitting
     together, 10-15 minutes after power-on, some of the radios
     will have a lock and others will not. For radios that get a
     lock, sometimes they will briefly glitch into "unlocked" state
     briefly every 20-30 seconds before reporting as locked again.
     If I let it sit another 10-15 minutes, nothing really changes.
     Looking at the output of 'gpsmon' on the radio, the radios
     which never locked will see fewer satellites, and the ones in
     common will have far different SNR levels.

     I'm trying to find a solution for more consistent behavior,
     especially since these are outside with a view of the sky. I
     confirmed the radio's GPS ANT port has the +3.3V bias so I
     assume the antennas receive power as expected.

     Searching the mailing list, over the years this topic has come
     up a couple times specifically with E320 radios. I know the
     same Jackson Labs LTE-Lite SOM is also used in the newer X410
     radios, though it's configured a bit differently via strapping
     pins. I think:

     * The X410 sets the module in 1Hz mode instead of 5Hz.

     * The X410 uses it in "mobile" mode instead of auto-surveying
     “stationary” mode.

     * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2
     (NC), though this doesn't make any sense based on the LTE-Lite
     public tech manual. The X410 leaves them NC.

     Does anybody know whether any of the changes (or others)
     represent "lessons learned" that would improve GPS TTFF or
     disciplining behavior? I don’t mind changing resistor
     populations if there is a reason to. Or any other suggestions
     around this topic?

     Thank you,

     David Raeman




     _______________________________________________

     USRP-users mailing list --usrp-users@lists.ettus.com

     To unsubscribe send an email tousrp-users-leave@lists.ettus.com

 IF you move the antennas further apart, what happens?

 If they are all tightly packed together, there's an opportunity
 for shadowing (small, but, maybe?).
On 05/06/2024 22:36, David Raeman wrote: > > Correct, gpsd was stopped (in fact I cannot even open the tty device > if gpsd is running). > > I am also going to backpedal because I haven’t able to reproduce what > I saw/logged in the earlier test. The largest NMEA sentence burst I’m > seeing is about 550 bytes. It possible my earlier observation is a > sporadic issue with the receiver, but it’s more likely I botched > something in my test because I cannot reproduce that behavior. > > I did find the root cause of my problem, though, and it’s unrelated to > the SDR. I have a Raspberry Pi in the same chassis as the USRP E320, > and it has an attached USB3/Ethernet dongle. There’s a well-known > issue where certain USB3 devices and cables emit significant broadband > RF interference via the high-speed bus signaling. Afflicted devices > can jam co-located receivers including GPS and WiFi. Intel published a > whitepaper on the topic more than a decade ago [1]. When I remove this > USB3/Ethernet dongle from the system, GPS immediately works well. When > I plug it back in, I immediately lose the satellites again. This > dongle has nothing to do with the USRP’s function, but it was > positioned just 3-4 inches from the GPS antenna that feeds into the USRP. > > So not an SDR issue, but perhaps this thread may help a USRP user in > the future.. > > [1] https://www.usb.org/sites/default/files/327216.pdf > Thanks for sleuthing this, David! > *From:*Marcus D. Leech <patchvonbraun@gmail.com> > *Sent:* Wednesday, June 5, 2024 7:59 PM > *To:* David Raeman <david@SynopticEngineering.com>; > usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Re: GPS fix behavior on USRP E320 > > On 05/06/2024 11:19, David Raeman wrote: > > Thanks for the suggestion – in this case they were all sitting on > the roof of my vehicle in an open parking lot, with 6-8” > separation between radios. I guess there could be minimal > shadowing for satellites at low grazing angles, but I’m skeptical > of that as a full explanation. > > I have a hypothesis that the default 5Hz update rate is > problematic on these devices. The serial connection between the > GPS receiver the Zynq PS runs at 38400 baud. With standard 8N1 > framing, that only allows for 768 bytes of sentence data per 200ms > cycle. If I capture the raw GPS serial output (by directly > watching /dev/ttyPS1, not the scrubbed data filtered through > gpsd), it’s quickly obvious that many sentences get truncated > and/or dropped. For example, there are very frequent “time skips” > happening in the time-related sentences, as well as random > sentence fragments. Some cycles would be expected to have a larger > data volume, such as when multiple GPGSV sentences list all > satellites in view, and I think that’s mangling the serial stream. > > This explains discrepancies in what ‘gpsmon’ sees, as well as > discrepancies I’ve sometimes seen on E320s trying to sync common > GPS time with PPS assertion (sometimes radios are wrong by 200ms). > This should not impact the “gps_locked” sensor, which gets its > state via an I/O signal from the GPS receiver and not by parsing > sentences. However, I am currently using information from > sentences to determine lock status because “gps_locked” doesn’t > seem to work as expected in UHD 4.4 on the E320 (looks like that > might’ve been fixed in UHD 4.5 though). > > So long story short – I think 5Hz update rate is problematic. It > can be changed to 1Hz by removing a resistor, and as far as I can > tell, neither UHD nor the radio filesystem would care about that > change. I may try this on one radio and see if it helps improve > consistency.. > > -David > > You're not trying to capture /dev/ttyPS1 data *while* GPSD is > capturing it, are you?  You can't usefully share a resource like a >   serial port -- some characters will go to you, some to GPSD. > > Now, having said that, yeah, only 768 bytes per update interval max.  > How many bytes in a typical NMEA sentence, and how >   many sentences per interval? > > > > *From:*Marcus D. Leech <patchvonbraun@gmail.com> > <mailto:patchvonbraun@gmail.com> > *Sent:* Wednesday, June 5, 2024 8:56 AM > *To:* usrp-users@lists.ettus.com > *Subject:* [USRP-users] Re: GPS fix behavior on USRP E320 > > On 05/06/2024 08:43, David Raeman via USRP-users wrote: > > Hello, > > I'm having a difficult time getting consistent GPS fix > behavior from a set of USRP E320 radios. They are all using > UHD 4.4 with the same active GPS antenna (Siretta Tango 21, > which has a 28dB LNA and short ~6" coax run). > > When outside with a view of the sky and 6 radios sitting > together, 10-15 minutes after power-on, some of the radios > will have a lock and others will not. For radios that get a > lock, sometimes they will briefly glitch into "unlocked" state > briefly every 20-30 seconds before reporting as locked again. > If I let it sit another 10-15 minutes, nothing really changes. > Looking at the output of 'gpsmon' on the radio, the radios > which never locked will see fewer satellites, and the ones in > common will have far different SNR levels. > > I'm trying to find a solution for more consistent behavior, > especially since these are outside with a view of the sky. I > confirmed the radio's GPS ANT port has the +3.3V bias so I > assume the antennas receive power as expected. > > Searching the mailing list, over the years this topic has come > up a couple times specifically with E320 radios. I know the > same Jackson Labs LTE-Lite SOM is also used in the newer X410 > radios, though it's configured a bit differently via strapping > pins. I think: > > * The X410 sets the module in 1Hz mode instead of 5Hz. > > * The X410 uses it in "mobile" mode instead of auto-surveying > “stationary” mode. > > * Curiously, the E320 seems to connect pin 1 (EFC) to pin 2 > (NC), though this doesn't make any sense based on the LTE-Lite > public tech manual. The X410 leaves them NC. > > Does anybody know whether any of the changes (or others) > represent "lessons learned" that would improve GPS TTFF or > disciplining behavior? I don’t mind changing resistor > populations if there is a reason to. Or any other suggestions > around this topic? > > Thank you, > > David Raeman > > > > > _______________________________________________ > > USRP-users mailing list --usrp-users@lists.ettus.com > > To unsubscribe send an email tousrp-users-leave@lists.ettus.com > > IF you move the antennas further apart, what happens? > > If they are all tightly packed together, there's an opportunity > for shadowing (small, but, maybe?). > >