I recently acquired a pair of Spectracom 8195B GPS Ageless Master Oscillators.
Using terminal emulation on PC and RS232, I can configure and monitor their
operations. They are working fine.
But, I cannot seem to be able to find any Windows based software to configure
OR monitor operations.
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
Sure sounds to me like the distribution amp does have some sort of shielding
problem, in effect.
Are the power connections (whether AC or DC) properly filtered? Are all
the
coax connectors' bodies well-bonded to the metallic enclosure?
You might want to try sniffing with a small diameter (~1
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
Hi
Running and shielding a 10 MHz standard signal is never easy. Ground loops
here or there are highly likely to exist and create all sorts of issues. In
some
setups, -10 to -20 dbm is not an uncommon result ( = fix the termination on
your Spectracom system …). Getting below -90 is actually
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
I have been using a Tbolt and TAPR TADD-1 for a few years, mainly as an
external reference source for my workbench equipment. Just got a SDR radio
kit (Ubitx) and trying to calibrate the local oscillators found this
annoying substantial 10MHz signal heterodyning with the LO's (45MHz and
12MHz).
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,
Hi
There are an enormous number of combinations and permutations to the whole
GNSS timing question.
1) Does your multi band receiver only track GPS L2C? ( = is it like a F9T or
F9P)
If so, the number of GPS stats will be smaller and performance will not be as
good
as it might be.
2) Are
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
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
On Sat, Jul 13,
In message <20190712203821.5ddb6406...@ip-64-139-1-69.sjc.megapath.net>, Hal Mu
rray writes:
>Shipping a TEC cooler could get interesting. You need to get rid of the heat
>somehow. Cooling fins on a package would be interesting.
They have ways of dealing with freight like that
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
Hi Luciano,
Yes this is typically the case. GPS is the most reliably good system
currently. When the Galileo system is working nominally and the geometry
over our antenna is good (remember, the constellation is not yet complete),
the single frequency performance easily rivals GPS. BeiDou will
28 matches
Mail list logo
