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 <patchvonbr...@gmail.com>
*Sent:* Wednesday, June 5, 2024 7:59 PM
*To:* David Raeman <da...@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 <patchvonbr...@gmail.com>
<mailto:patchvonbr...@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-le...@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?).
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
