Having just been through the endian issue with a similar parser, I'll mention
that in Python the struct.unpack() function can handle endian swaps at tne same
time as it pulls binary data out of the message. It makes it pretty painless.
On Jul 13, 2019, 11:08 PM, at 11:08 PM, Mark Sims wrote:
Super slow from Canada too. Does eventually respond.
They might be seeing a little more traffic than they usually get...
On 14/07/2019 3:49 AM, Bj??rn wrote:
InsideGNSS is responding really slow (only from Sweden?) My phone browsers gave
up. My computer Mozilla finally got it.
/Bj??rn
On 14
-Original Message-
From: Leif Johansson
Sent: Sunday, July 14, 2019 7:24 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Galileo service currently degraded
That site seems to be down now
=
See:
https
InsideGNSS is responding really slow (only from Sweden?) My phone browsers gave
up. My computer Mozilla finally got it.
/Björn
> On 14 Jul 2019, at 08:24, Leif Johansson wrote:
>
> That site seems to be down now
>
> Skickat från min iPhone
>
>> 14 juli 2019 kl. 00:14 skrev Michael Wouters
> On 14 Jul 2019, at 00:25, Mark Sims wrote:
>
> A report that the outage is due to a failure at the Galileo "precise time
> facility" in Italy. It has all their cesiums and a maser. Hmmm... no
> backup facility... sounds like a recipe for disaster?
To my knowledge both Italian and
That site seems to be down now
Skickat från min iPhone
> 14 juli 2019 kl. 00:14 skrev Michael Wouters :
>
> The Galileo outage is being attributed to problems at the Precise Timing
> Facility in Italy
>
>
Lady Heather is open source and has parsers/decoders for just about any
receiver you are likely to see... and a few that your aren't.One big issue
with binary protocols is handling big/little endian (byte order) issues when
reading messages or sending them to the device. You need to be
Hi
One alternative, if you only need two lines is to write a parser just for them.
There’s not a whole lot to the protocol and the uBlox doc’s are pretty good at
describing it. Yes, it’s a binary protocol so there will be a bit of this and
that
involved.
Bob
> On Jul 13, 2019, at 5:16 PM,
Thanks for the info Gary! I will check this out -- I am using the F9P for
another project now, so that might be useful.
Unrelated to gpsd...
I forgot about this until now, but I actually encountered a WNRO bug in the
U-Blox M8N (or possibly my library?) when my data collection was running. I
only
Yo Kevin!
On Sat, 13 Jul 2019 17:16:37 -0400
Kevin Croissant wrote:
> Looking at gpsd, I'm still not sure that it supports UBX,
gpsd has supported u-blox since the SiRF2-ublox TIM chip in 2007.
gpsd now support all the way up to the ZED series.
RGDS
GARY
Hello Kevin
There is a Perl script to configure and log the ublox that is
available as part of OpenTTP
https://github.com/openttp/openttp/tree/master/software/gpscv/ublox
Cheers
Michael
On Sun, Jul 14, 2019 at 8:03 AM Kevin Croissant
wrote:
>
> This is the library I am using:
>
We monitor GNSS timing in this way ie with common, single-frequency
receivers configured to track a single GNSS system only, measured with
respect to UTC(AUS). The plan was to make the data publicly available
but that's still on the TODO. Currently we monitor GPS, GLONASS and
BeiDou.
Over the
> Looking at gpsd, I'm still not sure that it supports UBX, and I think that was
> why I disregarded it before. Do you know if it does? The only UBX messages my
> project truly needs are NAV-PVT and NAV-DOP, though I look at other ones for
> data validation and debugging.
I haven't been
The Galileo outage is being attributed to problems at the Precise Timing
Facility in Italy
https://insidegnss.com/update-galileo-service-degraded-on-all-satellites-precise-timing-facility-problems-cited/
Cheers
Michael
On Sun, 14 Jul 2019 at 7:06 am, Mark Sims wrote:
> The satellite tracking
A report that the outage is due to a failure at the Galileo "precise time
facility" in Italy. It has all their cesiums and a maser. Hmmm... no backup
facility... sounds like a recipe for disaster? Service outage may last over 90
hours.
This is the library I am using:
https://github.com/jkua/ubx
Basically the only applicable files are ublox2.py and ubloxMessage.py.
There's some bug in how it handles its byte buffer and the buffer grows out
of control, which causes all sorts of issues. I tried to fix it but failed
due to time
The satellite tracking / health info is sent by the receiver. Heather just
reports what the receiver is sending.
Oh, and the Galileo system status has changed from "degraded" to "service
outage".
https://www.gsc-europa.eu/system-status/Constellation-Information
What is amazing is that I can
ke...@kevincroissant.com said:
> The library I used for the U-blox UBX protocol frankly sucks, and was a major
> source of issues.
What library are you using and/or did you look at gpsd?
--
These are my opinions. I hate spam.
___
time-nuts
In message
, Kevin Croissant writes:
>Great! We were hoping that more people would set up similar sites as well,
>so I am glad to see interest.
>The only outstanding issue with the website is the data collection. The
>library I used for the U-blox UBX protocol frankly sucks, and was a
Kevin,
I am very interested in your GNSS monitoring website. I would consider
building a system similar to yours, perhaps using dual frequency
receivers. I am not exactly in 'another part of the world' (though it
often seems another planet) in central Missouri at 38.947232, -92.303583.
I would
Hi Dave,
Great! We were hoping that more people would set up similar sites as well,
so I am glad to see interest.
The only outstanding issue with the website is the data collection. The
library I used for the U-blox UBX protocol frankly sucks, and was a major
source of issues. As such, messages
Hi Mark,
What prompts Heather to mark visible satellites as yellow, and not use
them? Maybe that the calculated results are too far away from your known
position?
Regards,
Peter
On Sat, 13 Jul 2019 at 18:20, Mark Sims wrote:
> ... Sats that are visible but not being
Not this time... Heather flags unhealthy sats in RED. Sats that are visible
but not being used for navigation are flagged in YELLOW. Sats that are
actively being used are shown in GREEN and are used to draw the satellite count
plot line (CYAN line at the bottom of the plot area).
Typically
My M8T and Lady Heather, from UTC-4:
. When I first checked (July 12, ~10:00?), all Gal sats seen showed with
good dBc, but where yellow.
. 14:50 all Gal sats seen showed as red, with good dBc.
. 22:00 showed ten Gal were N/A and red, three had good dBc: one red,
two yellow.
. Today July 13,
eok.it wrote:
>>
>>>
>>> Looking at the data it seems that GPS is the best system among the
>>> four, correct?
>>>
>>> Luciano
>>>
>>>
>>> Da "time-nuts" time-nuts-boun...@lists.febo.com
>>&g
I wonder if a case could be made for multi-GNSS reception in the case of a
poorly-located GPS antenna at the reception site. That is, could the
benefits of having a lot more sats in the sky outweigh poorer performance of
some of the systems with respect to other systems?
Dana
it seems that GPS is the best system among the
> > four, correct?
> >
> >Luciano
> >
> >
> >Da "time-nuts" time-nuts-boun...@lists.febo.com
> >A "Discussion of precise time and frequency measurement"
> > time-nuts@lists.febo.com
In message , Mark Sims writes:
>It seems to more than a little "degradation". My F9T is seeing and tracking
>Galileo sats, but is not using the results for navigation... Lady Heather
>shows all Galileo sats in yellow. Selecting Galileo only, the receiver
>reports it is attempting
.febo.com
>A "Discussion of precise time and frequency measurement"
> time-nuts@lists.febo.com
>Cc
> Data Fri, 12 Jul 2019 18:29:10 -0400
>Oggetto Re: [time-nuts] Galileo service currently degraded
>I built this website as my senior design project last year,
&g
It seems to more than a little "degradation". My F9T is seeing and tracking
Galileo sats, but is not using the results for navigation... Lady Heather shows
all Galileo sats in yellow. Selecting Galileo only, the receiver reports it
is attempting to acquire satellites and not producing a
-0400
Oggetto Re: [time-nuts] Galileo service currently degraded
I built this website as my senior design project last year, unfortunately
there's no timing data (except for tdop) being logged but you can see the
impact. Data is collected with four ublox m8n receivers, one per
conste
I built this website as my senior design project last year, unfortunately
there's no timing data (except for tdop) being logged but you can see the
impact. Data is collected with four ublox m8n receivers, one per
constellation.
Galileo data from last 1 week:
> Galileo service is currently degraded, see: https://www.gsc-europa.eu/
> notice-advisory-to-galileo-users-nagu-2019025
Thanks.
Is anybody monitoring a Galileo-only setup to see how far off the timing
drifts?
--
These are my opinions. I hate spam.
Galileo service is currently degraded, see:
https://www.gsc-europa.eu/notice-advisory-to-galileo-users-nagu-2019025
Martin
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
34 matches
Mail list logo
