Discussion and technical support related to USRP, UHD, RFNoC
View all threadsHello,
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:
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
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?).
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:
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?).
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?).
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:
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?).
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..
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?).