MD
Marcelo Dantas
Tue, Sep 20, 2022 11:35 AM
I am wondering if this issue could be caused by the way I am setting the
date/time when setting it up on WinOncore.
I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data into
the initial reference position. Telling the software to set it into the
position hold position.
For the initial reference time I tried entering UTC time and leaving the
GMT offset +0, or my local time and setting the GMT offset to -4, also some
combinations of that.
I already gave up on the UT+, but the GT+ at some point showed "visible
satellites", though it wouldn't track any. As this happened way into my
trial and error process, I was unable to verify which combination gave me
these results.
Sorry if I sound like a complete noob (which I am) but I have noticed that,
by changing the time it would show different satellites in different
positions, so I thought: aha, it is based on almanac+time, not on what it
is actually "seeing" in the sky. I mean, I am not a specialist on this by
any means, but I am suspecting it tracks based on where the satellites
should be at a given time, not by listening to where they actually are?
(please don't give up on me)
Anyways, could be that I am telling the GPS wrong information on its
initialization, which makes it go bananas and not find anything. And
lacking a valid almanac it would not be able to even build one based on the
wrong information I provided? I am shooting in the dark here.
Thanks,
Marcelo.
On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
Hi,
Not really. The format is the same. Subtle clarifications and use of
flag fields is however.
One aviation GPS receiver crashed whenever the flag was set as a new
satellite was introduced into the constellation. Considering the cost
and effort involved of recertifying it after a bugfix, it became a
hesitation to fix it. I think this was a learning experience to the air
industry, so I think they now have means to address it on more regular
basis, since I know that in more recent history the lack of timely
update has been the reason for GPS receiver problems, not the lack of
update as such. I will ask around on this.
It's the GPS III signals which will be very different, as it is packet
based.
Cheers,
Magnus
On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
Hi
It would not surprise me at all to find that a modern version of the
almanac is different than the 1998 version. A lot has changed since
then.
Given that you can find these for < $10 on eBay. I would not invest
a lot in them at this point …. Once you get them running, you will
have roll over issues.
Bob
Hi Bob,
The modules are old. 1998/2000.
I have left the UT+ running for about 36 Hrs. I have noticed that the
battery on the UT+ is dead, so I am ordering a replacement.
However, while running powered for 36 hours I expected it would see
"something". I wish there was a way to verify some of its internal
information, to see if it was actually collecting something.
The WinOncore software allows you to upload an almanac, and it talks
about a .alm file extension, and on the .gov site I only found a
latest_yuma.alm file, which I uploaded, but it would still show "bad
almanac".
I have also tried to upload a .al3 (SEM) file, with the same result.
Both files seem to upload, so I am not sure which one should be the
correct one, or if both are. I am assuming the yuma because it has the
.alm extension. (still a noob in this matter)
On a new development, the GT+ started showing satellites, it shows 10
satellites visible, zero tracked.
The UT+ regardless of the almanacs uploaded, still shows zero visible,
I am still trying to find a reference to the correct (expected) almanac
file format and to the eventual calibration procedure referred previously.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
Hi
If it’s showing “bad almanac” then that is part of the issue.
It may not be all of the issue ….
How old are these modules? They went through several
revisions and each one was a big leap over the previous
version. If they date back far enough, it could take a very
long time to come up with an almanac.
Bob
On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
@Bjorn: It is the same antenna which worked back then, it was sitting
there in the same drawer. So, unless it degrades somehow over time, it
should continue to work I guess.
I have no idea though how to measure/verify if there's saturation
When I plugged this antenna to a U-Blox it immediately kicked in with
a bunch of satellites in view, but the U-Blox might also have a different
input impedance.
@Bob "off for a while" means since mid 2018. So I immediately thought
of an almanac, however I could not yet figure out the .alm file it would
require.
I have downloaded almanac files from the web, not oncore specific, but
when importing them via WinOncore I do not get any success/failure
messages, and the device continues to show "bad almanac" on its status.
I have a feeling that the issue is towards bad/outdated internal
information. Or maybe the calibration John spoke about, if I can figure it
out, could help.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
Hi
The other gotcha depends a lot on just how long “off for a while” is.
If any of these devices are off power for decades, the internal data
for the almanac ( = which sats are where ) will be way off.
The process of random search is a lot faster with the newer modules.
They have way more processing horsepower. Just how many hours
(or days) it takes this or that example of an early module to come
back to life …. who knows ….
Bob
On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts <
Some of the early Motorola receivers had an issue with long-term XO
drift. That can result in failure to lock if the unit has been powered off
for a long time. There is a procedure to recalibrate it (no test equipment
required). I think it was written up in a Motorola app note that's
available on line, but I can't put my finger on it right now.
John
On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
UT Plus model numbers:
R5122U111x - right angle OSX
R5222U111x - right angle OSX, on-board Lithium battery
R5122U115x - straight OSX
GT Plus model numbers:
R3111G111x - standard version
R3211G111x - on-board Lithium battery
R3111G114x - SMB antenna connector
greg, w9gb
Date: Sun, 18 Sep 2022 08:42:18 -0400
From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
Subject: [time-nuts] Thanks for adding me, and please help. Motorola
user and could assist.
I have a couple Motorola Oncore modules, which I use mounted to a
"baseboard" for timing purposes.
One is a R5222U1115 and the other a R3111G1112.
They have been sitting in a drawer for some time. Being "some time"
the pre-pandemic era.
Now I am trying to use them again but for whatever reason they won't
to any satellites.
The modules are starting up, sending 1pps and seem to be accepting
correctly.
I have also tested the baseboard (power, serial, etc) and the
The antenna works well on a third (non-motorola) module.
I have tried everything, left the modules there running for 24 hours.
No joy. None of them will lock to any satellites.
I have tried defaulting them using WinOncore, no change.
I have also tried to find an almanac file to upload, hoping it would
but couldn't find one with the required .alm file extension.
At this point I do not know what to do anymore. I have a system
board, antenna, power, etc.) that should just work, and yet it
Maybe there's some special factory reset? Maybe there's some command
not know about? Maybe other software than WinOncore with some extra
debug options?
Any guidance here would be deeply appreciated.
Thanks a lot in advance,
Marcelo.
time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
I am wondering if this issue could be caused by the way I am setting the
date/time when setting it up on WinOncore.
I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data into
the initial reference position. Telling the software to set it into the
position hold position.
For the initial reference time I tried entering UTC time and leaving the
GMT offset +0, or my local time and setting the GMT offset to -4, also some
combinations of that.
I already gave up on the UT+, but the GT+ at some point showed "visible
satellites", though it wouldn't track any. As this happened way into my
trial and error process, I was unable to verify which combination gave me
these results.
Sorry if I sound like a complete noob (which I am) but I have noticed that,
by changing the time it would show different satellites in different
positions, so I thought: aha, it is based on almanac+time, not on what it
is actually "seeing" in the sky. I mean, I am not a specialist on this by
any means, but I am suspecting it tracks based on where the satellites
should be at a given time, not by listening to where they actually are?
(please don't give up on me)
Anyways, could be that I am telling the GPS wrong information on its
initialization, which makes it go bananas and not find anything. And
lacking a valid almanac it would not be able to even build one based on the
wrong information I provided? I am shooting in the dark here.
Thanks,
Marcelo.
On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
> Hi,
>
> Not really. The format is the same. Subtle clarifications and use of
> flag fields is however.
>
> One aviation GPS receiver crashed whenever the flag was set as a new
> satellite was introduced into the constellation. Considering the cost
> and effort involved of recertifying it after a bugfix, it became a
> hesitation to fix it. I think this was a learning experience to the air
> industry, so I think they now have means to address it on more regular
> basis, since I know that in more recent history the lack of timely
> update has been the reason for GPS receiver problems, not the lack of
> update as such. I will ask around on this.
>
> It's the GPS III signals which will be very different, as it is packet
> based.
>
> Cheers,
> Magnus
>
> On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
> > Hi
> >
> > It would not surprise me at all to find that a modern version of the
> > almanac is different than the 1998 version. A lot has changed since
> > then.
> >
> > Given that you can find these for < $10 on eBay. I would not invest
> > a lot in them at this point …. Once you get them running, you will
> > have roll over issues.
> >
> > Bob
> >
> >> On Sep 19, 2022, at 4:36 PM, Marcelo Dantas <marcelo.f.dantas@gmail.com>
> wrote:
> >>
> >> Hi Bob,
> >>
> >> The modules are old. 1998/2000.
> >>
> >> I have left the UT+ running for about 36 Hrs. I have noticed that the
> battery on the UT+ is dead, so I am ordering a replacement.
> >> However, while running powered for 36 hours I expected it would see
> "something". I wish there was a way to verify some of its internal
> information, to see if it was actually collecting something.
> >>
> >> The WinOncore software allows you to upload an almanac, and it talks
> about a .alm file extension, and on the .gov site I only found a
> latest_yuma.alm file, which I uploaded, but it would still show "bad
> almanac".
> >> I have also tried to upload a .al3 (SEM) file, with the same result.
> >> Both files seem to upload, so I am not sure which one should be the
> correct one, or if both are. I am assuming the yuma because it has the
> .alm extension. (still a noob in this matter)
> >>
> >> On a new development, the GT+ started showing satellites, it shows 10
> satellites visible, zero tracked.
> >> The UT+ regardless of the almanacs uploaded, still shows zero visible,
> zero tracked.
> >>
> >> I am still trying to find a reference to the correct (expected) almanac
> file format and to the eventual calibration procedure referred previously.
> >>
> >> Thanks,
> >> Marcelo.
> >>
> >>
> >> On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
> kb8tq@n1k.org>> wrote:
> >> Hi
> >>
> >> If it’s showing “bad almanac” then that is part of the issue.
> >> It may not be *all* of the issue ….
> >>
> >> How old are these modules? They went through several
> >> revisions and each one was a big leap over the previous
> >> version. If they date back far enough, it could take a very
> >> long time to come up with an almanac.
> >>
> >> Bob
> >>
> >>> On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
> marcelo.f.dantas@gmail.com <mailto:marcelo.f.dantas@gmail.com>> wrote:
> >>>
> >>> @Bjorn: It is the same antenna which worked back then, it was sitting
> there in the same drawer. So, unless it degrades somehow over time, it
> should continue to work I guess.
> >>> I have no idea though how to measure/verify if there's saturation
> going on.
> >>> When I plugged this antenna to a U-Blox it immediately kicked in with
> a bunch of satellites in view, but the U-Blox might also have a different
> input impedance.
> >>>
> >>> @Bob "off for a while" means since mid 2018. So I immediately thought
> of an almanac, however I could not yet figure out the .alm file it would
> require.
> >>> I have downloaded almanac files from the web, not oncore specific, but
> when importing them via WinOncore I do not get any success/failure
> messages, and the device continues to show "bad almanac" on its status.
> >>> I have a feeling that the issue is towards bad/outdated internal
> information. Or maybe the calibration John spoke about, if I can figure it
> out, could help.
> >>>
> >>> Thanks,
> >>> Marcelo.
> >>>
> >>>
> >>>
> >>> On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
> time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> >>> Hi
> >>>
> >>> The other gotcha depends a lot on just how long “off for a while” is.
> >>> If any of these devices are off power for decades, the internal data
> >>> for the almanac ( = which sats are where ) will be way off.
> >>>
> >>> The process of random search is a lot faster with the newer modules.
> >>> They have way more processing horsepower. Just how many hours
> >>> (or days) it takes this or that example of an early module to come
> >>> back to life …. who knows ….
> >>>
> >>> Bob
> >>>
> >>>> On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts <
> time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> >>>>
> >>>> Some of the early Motorola receivers had an issue with long-term XO
> drift. That can result in failure to lock if the unit has been powered off
> for a long time. There is a procedure to recalibrate it (no test equipment
> required). I think it was written up in a Motorola app note that's
> available on line, but I can't put my finger on it right now.
> >>>>
> >>>> John
> >>>> -----
> >>>>
> >>>> On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
> >>>>> IF you start with Fixed Position mode, THEN this speeds up process.
> >>>>> I would also suggest a CLEAR View of Sky for the Antenna.
> >>>>> Motorola Oncore UT Plus Engineering Notes (circa 2000)
> >>>>> https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf
> <https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf>
> >>>>> Motorola Oncore GT Plus Engineering Notes (circa 2000)
> >>>>> https://www.tapr.org/pdf/GT_Eng_Notes.pdf <
> https://www.tapr.org/pdf/GT_Eng_Notes.pdf>
> >>>>> UT Plus model numbers:
> >>>>> R5122U111x - right angle OSX
> >>>>> R5222U111x - right angle OSX, on-board Lithium battery
> >>>>> R5122U115x - straight OSX
> >>>>> GT Plus model numbers:
> >>>>> R3111G111x - standard version
> >>>>> R3211G111x - on-board Lithium battery
> >>>>> R3111G114x - SMB antenna connector
> >>>>> greg, w9gb
> >>>>> ==
> >>>>> Date: Sun, 18 Sep 2022 08:42:18 -0400
> >>>>> From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
> marcelo.f.dantas@gmail.com>>
> >>>>> Subject: [time-nuts] Thanks for adding me, and please help. Motorola
> Oncore
> >>>>> To: time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
> >>>>> Hi there Everyone,
> >>>>> Thanks for accepting me to this list.
> >>>>> I am in (dire) need of help here and maybe one of you is a Motorola
> Oncore
> >>>>> user and could assist.
> >>>>> I have a couple Motorola Oncore modules, which I use mounted to a
> >>>>> "baseboard" for timing purposes.
> >>>>> One is a R5222U1115 and the other a R3111G1112.
> >>>>> They have been sitting in a drawer for some time. Being "some time"
> since
> >>>>> the pre-pandemic era.
> >>>>> Now I am trying to use them again but for whatever reason they won't
> lock
> >>>>> to any satellites.
> >>>>> The modules are starting up, sending 1pps and seem to be accepting
> commands
> >>>>> correctly.
> >>>>> I have also tested the baseboard (power, serial, etc) and the
> antenna.
> >>>>> The antenna works well on a third (non-motorola) module.
> >>>>> I have tried everything, left the modules there running for 24 hours.
> >>>>> No joy. None of them will lock to any satellites.
> >>>>> I have tried defaulting them using WinOncore, no change.
> >>>>> I have also tried to find an almanac file to upload, hoping it would
> help,
> >>>>> but couldn't find one with the required .alm file extension.
> >>>>> At this point I do not know what to do anymore. I have a system
> (module,
> >>>>> board, antenna, power, etc.) that should just work, and yet it
> refuses to.
> >>>>> Maybe there's some special factory reset? Maybe there's some command
> I do
> >>>>> not know about? Maybe other software than WinOncore with some extra
> >>>>> debug options?
> >>>>> Any guidance here would be deeply appreciated.
> >>>>> Thanks a lot in advance,
> >>>>> Marcelo.
> >>>>> _______________________________________________
> >>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> time-nuts@lists.febo.com>
> >>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> <mailto:time-nuts-leave@lists.febo.com>
> >>>> _______________________________________________
> >>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> time-nuts@lists.febo.com>
> >>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> <mailto:time-nuts-leave@lists.febo.com>
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> time-nuts@lists.febo.com>
> >>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> <mailto:time-nuts-leave@lists.febo.com>
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
AB
Azelio Boriani
Wed, Sep 21, 2022 9:08 AM
I am wondering if this issue could be caused by the way I am setting the
date/time when setting it up on WinOncore.
I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data into
the initial reference position. Telling the software to set it into the
position hold position.
For the initial reference time I tried entering UTC time and leaving the
GMT offset +0, or my local time and setting the GMT offset to -4, also some
combinations of that.
I already gave up on the UT+, but the GT+ at some point showed "visible
satellites", though it wouldn't track any. As this happened way into my
trial and error process, I was unable to verify which combination gave me
these results.
Sorry if I sound like a complete noob (which I am) but I have noticed that,
by changing the time it would show different satellites in different
positions, so I thought: aha, it is based on almanac+time, not on what it
is actually "seeing" in the sky. I mean, I am not a specialist on this by
any means, but I am suspecting it tracks based on where the satellites
should be at a given time, not by listening to where they actually are?
(please don't give up on me)
Anyways, could be that I am telling the GPS wrong information on its
initialization, which makes it go bananas and not find anything. And
lacking a valid almanac it would not be able to even build one based on the
wrong information I provided? I am shooting in the dark here.
Thanks,
Marcelo.
On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
Hi,
Not really. The format is the same. Subtle clarifications and use of
flag fields is however.
One aviation GPS receiver crashed whenever the flag was set as a new
satellite was introduced into the constellation. Considering the cost
and effort involved of recertifying it after a bugfix, it became a
hesitation to fix it. I think this was a learning experience to the air
industry, so I think they now have means to address it on more regular
basis, since I know that in more recent history the lack of timely
update has been the reason for GPS receiver problems, not the lack of
update as such. I will ask around on this.
It's the GPS III signals which will be very different, as it is packet
based.
Cheers,
Magnus
On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
Hi
It would not surprise me at all to find that a modern version of the
almanac is different than the 1998 version. A lot has changed since
then.
Given that you can find these for < $10 on eBay. I would not invest
a lot in them at this point …. Once you get them running, you will
have roll over issues.
Bob
On Sep 19, 2022, at 4:36 PM, Marcelo Dantas marcelo.f.dantas@gmail.com
wrote:
Hi Bob,
The modules are old. 1998/2000.
I have left the UT+ running for about 36 Hrs. I have noticed that the
battery on the UT+ is dead, so I am ordering a replacement.
However, while running powered for 36 hours I expected it would see
"something". I wish there was a way to verify some of its internal
information, to see if it was actually collecting something.
The WinOncore software allows you to upload an almanac, and it talks
about a .alm file extension, and on the .gov site I only found a
latest_yuma.alm file, which I uploaded, but it would still show "bad
almanac".
I have also tried to upload a .al3 (SEM) file, with the same result.
Both files seem to upload, so I am not sure which one should be the
correct one, or if both are. I am assuming the yuma because it has the
.alm extension. (still a noob in this matter)
On a new development, the GT+ started showing satellites, it shows 10
satellites visible, zero tracked.
The UT+ regardless of the almanacs uploaded, still shows zero visible,
zero tracked.
I am still trying to find a reference to the correct (expected) almanac
file format and to the eventual calibration procedure referred previously.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
kb8tq@n1k.org>> wrote:
Hi
If it’s showing “bad almanac” then that is part of the issue.
It may not be all of the issue ….
How old are these modules? They went through several
revisions and each one was a big leap over the previous
version. If they date back far enough, it could take a very
long time to come up with an almanac.
Bob
On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
marcelo.f.dantas@gmail.com mailto:marcelo.f.dantas@gmail.com> wrote:
@Bjorn: It is the same antenna which worked back then, it was sitting
there in the same drawer. So, unless it degrades somehow over time, it
should continue to work I guess.
I have no idea though how to measure/verify if there's saturation
going on.
When I plugged this antenna to a U-Blox it immediately kicked in with
a bunch of satellites in view, but the U-Blox might also have a different
input impedance.
@Bob "off for a while" means since mid 2018. So I immediately thought
of an almanac, however I could not yet figure out the .alm file it would
require.
I have downloaded almanac files from the web, not oncore specific, but
when importing them via WinOncore I do not get any success/failure
messages, and the device continues to show "bad almanac" on its status.
I have a feeling that the issue is towards bad/outdated internal
information. Or maybe the calibration John spoke about, if I can figure it
out, could help.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com> wrote:
Hi
The other gotcha depends a lot on just how long “off for a while” is.
If any of these devices are off power for decades, the internal data
for the almanac ( = which sats are where ) will be way off.
The process of random search is a lot faster with the newer modules.
They have way more processing horsepower. Just how many hours
(or days) it takes this or that example of an early module to come
back to life …. who knows ….
Bob
On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts <
time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com> wrote:
Some of the early Motorola receivers had an issue with long-term XO
drift. That can result in failure to lock if the unit has been powered off
for a long time. There is a procedure to recalibrate it (no test equipment
required). I think it was written up in a Motorola app note that's
available on line, but I can't put my finger on it right now.
John
On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
IF you start with Fixed Position mode, THEN this speeds up process.
I would also suggest a CLEAR View of Sky for the Antenna.
Motorola Oncore UT Plus Engineering Notes (circa 2000)
https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf
https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf
Motorola Oncore GT Plus Engineering Notes (circa 2000)
https://www.tapr.org/pdf/GT_Eng_Notes.pdf <
https://www.tapr.org/pdf/GT_Eng_Notes.pdf>
UT Plus model numbers:
R5122U111x - right angle OSX
R5222U111x - right angle OSX, on-board Lithium battery
R5122U115x - straight OSX
GT Plus model numbers:
R3111G111x - standard version
R3211G111x - on-board Lithium battery
R3111G114x - SMB antenna connector
greg, w9gb
Date: Sun, 18 Sep 2022 08:42:18 -0400
From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
marcelo.f.dantas@gmail.com>>
Subject: [time-nuts] Thanks for adding me, and please help. Motorola
Oncore
To: time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com
Hi there Everyone,
Thanks for accepting me to this list.
I am in (dire) need of help here and maybe one of you is a Motorola
Oncore
user and could assist.
I have a couple Motorola Oncore modules, which I use mounted to a
"baseboard" for timing purposes.
One is a R5222U1115 and the other a R3111G1112.
They have been sitting in a drawer for some time. Being "some time"
since
the pre-pandemic era.
Now I am trying to use them again but for whatever reason they won't
lock
to any satellites.
The modules are starting up, sending 1pps and seem to be accepting
commands
correctly.
I have also tested the baseboard (power, serial, etc) and the
antenna.
The antenna works well on a third (non-motorola) module.
I have tried everything, left the modules there running for 24 hours.
No joy. None of them will lock to any satellites.
I have tried defaulting them using WinOncore, no change.
I have also tried to find an almanac file to upload, hoping it would
help,
but couldn't find one with the required .alm file extension.
At this point I do not know what to do anymore. I have a system
(module,
board, antenna, power, etc.) that should just work, and yet it
refuses to.
Maybe there's some special factory reset? Maybe there's some command
I do
not know about? Maybe other software than WinOncore with some extra
debug options?
Any guidance here would be deeply appreciated.
Thanks a lot in advance,
Marcelo.
time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
time-nuts@lists.febo.com>
To unsubscribe send an email to time-nuts-leave@lists.febo.com
mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
time-nuts@lists.febo.com>
To unsubscribe send an email to time-nuts-leave@lists.febo.com
mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
time-nuts@lists.febo.com>
To unsubscribe send an email to time-nuts-leave@lists.febo.com
mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
The Motorola service note, that John Ackermann was referring to, should be this:
<https://synergy-gps.com/wp-content/uploads/2019/06/VP_SERVICE_NOTE.pdf>
It should be not relevant for the GT+ and UT+ mentioned here.
On Tue, Sep 20, 2022 at 6:23 PM Marcelo Dantas via time-nuts
<time-nuts@lists.febo.com> wrote:
>
> I am wondering if this issue could be caused by the way I am setting the
> date/time when setting it up on WinOncore.
> I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data into
> the initial reference position. Telling the software to set it into the
> position hold position.
> For the initial reference time I tried entering UTC time and leaving the
> GMT offset +0, or my local time and setting the GMT offset to -4, also some
> combinations of that.
> I already gave up on the UT+, but the GT+ at some point showed "visible
> satellites", though it wouldn't track any. As this happened way into my
> trial and error process, I was unable to verify which combination gave me
> these results.
> Sorry if I sound like a complete noob (which I am) but I have noticed that,
> by changing the time it would show different satellites in different
> positions, so I thought: aha, it is based on almanac+time, not on what it
> is actually "seeing" in the sky. I mean, I am not a specialist on this by
> any means, but I am suspecting it tracks based on where the satellites
> should be at a given time, not by listening to where they actually are?
> (please don't give up on me)
> Anyways, could be that I am telling the GPS wrong information on its
> initialization, which makes it go bananas and not find anything. And
> lacking a valid almanac it would not be able to even build one based on the
> wrong information I provided? I am shooting in the dark here.
>
> Thanks,
> Marcelo.
>
>
>
> On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
> time-nuts@lists.febo.com> wrote:
>
> > Hi,
> >
> > Not really. The format is the same. Subtle clarifications and use of
> > flag fields is however.
> >
> > One aviation GPS receiver crashed whenever the flag was set as a new
> > satellite was introduced into the constellation. Considering the cost
> > and effort involved of recertifying it after a bugfix, it became a
> > hesitation to fix it. I think this was a learning experience to the air
> > industry, so I think they now have means to address it on more regular
> > basis, since I know that in more recent history the lack of timely
> > update has been the reason for GPS receiver problems, not the lack of
> > update as such. I will ask around on this.
> >
> > It's the GPS III signals which will be very different, as it is packet
> > based.
> >
> > Cheers,
> > Magnus
> >
> > On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
> > > Hi
> > >
> > > It would not surprise me at all to find that a modern version of the
> > > almanac is different than the 1998 version. A lot has changed since
> > > then.
> > >
> > > Given that you can find these for < $10 on eBay. I would not invest
> > > a lot in them at this point …. Once you get them running, you will
> > > have roll over issues.
> > >
> > > Bob
> > >
> > >> On Sep 19, 2022, at 4:36 PM, Marcelo Dantas <marcelo.f.dantas@gmail.com>
> > wrote:
> > >>
> > >> Hi Bob,
> > >>
> > >> The modules are old. 1998/2000.
> > >>
> > >> I have left the UT+ running for about 36 Hrs. I have noticed that the
> > battery on the UT+ is dead, so I am ordering a replacement.
> > >> However, while running powered for 36 hours I expected it would see
> > "something". I wish there was a way to verify some of its internal
> > information, to see if it was actually collecting something.
> > >>
> > >> The WinOncore software allows you to upload an almanac, and it talks
> > about a .alm file extension, and on the .gov site I only found a
> > latest_yuma.alm file, which I uploaded, but it would still show "bad
> > almanac".
> > >> I have also tried to upload a .al3 (SEM) file, with the same result.
> > >> Both files seem to upload, so I am not sure which one should be the
> > correct one, or if both are. I am assuming the yuma because it has the
> > .alm extension. (still a noob in this matter)
> > >>
> > >> On a new development, the GT+ started showing satellites, it shows 10
> > satellites visible, zero tracked.
> > >> The UT+ regardless of the almanacs uploaded, still shows zero visible,
> > zero tracked.
> > >>
> > >> I am still trying to find a reference to the correct (expected) almanac
> > file format and to the eventual calibration procedure referred previously.
> > >>
> > >> Thanks,
> > >> Marcelo.
> > >>
> > >>
> > >> On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
> > kb8tq@n1k.org>> wrote:
> > >> Hi
> > >>
> > >> If it’s showing “bad almanac” then that is part of the issue.
> > >> It may not be *all* of the issue ….
> > >>
> > >> How old are these modules? They went through several
> > >> revisions and each one was a big leap over the previous
> > >> version. If they date back far enough, it could take a very
> > >> long time to come up with an almanac.
> > >>
> > >> Bob
> > >>
> > >>> On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
> > marcelo.f.dantas@gmail.com <mailto:marcelo.f.dantas@gmail.com>> wrote:
> > >>>
> > >>> @Bjorn: It is the same antenna which worked back then, it was sitting
> > there in the same drawer. So, unless it degrades somehow over time, it
> > should continue to work I guess.
> > >>> I have no idea though how to measure/verify if there's saturation
> > going on.
> > >>> When I plugged this antenna to a U-Blox it immediately kicked in with
> > a bunch of satellites in view, but the U-Blox might also have a different
> > input impedance.
> > >>>
> > >>> @Bob "off for a while" means since mid 2018. So I immediately thought
> > of an almanac, however I could not yet figure out the .alm file it would
> > require.
> > >>> I have downloaded almanac files from the web, not oncore specific, but
> > when importing them via WinOncore I do not get any success/failure
> > messages, and the device continues to show "bad almanac" on its status.
> > >>> I have a feeling that the issue is towards bad/outdated internal
> > information. Or maybe the calibration John spoke about, if I can figure it
> > out, could help.
> > >>>
> > >>> Thanks,
> > >>> Marcelo.
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
> > time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> > >>> Hi
> > >>>
> > >>> The other gotcha depends a lot on just how long “off for a while” is.
> > >>> If any of these devices are off power for decades, the internal data
> > >>> for the almanac ( = which sats are where ) will be way off.
> > >>>
> > >>> The process of random search is a lot faster with the newer modules.
> > >>> They have way more processing horsepower. Just how many hours
> > >>> (or days) it takes this or that example of an early module to come
> > >>> back to life …. who knows ….
> > >>>
> > >>> Bob
> > >>>
> > >>>> On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts <
> > time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> > >>>>
> > >>>> Some of the early Motorola receivers had an issue with long-term XO
> > drift. That can result in failure to lock if the unit has been powered off
> > for a long time. There is a procedure to recalibrate it (no test equipment
> > required). I think it was written up in a Motorola app note that's
> > available on line, but I can't put my finger on it right now.
> > >>>>
> > >>>> John
> > >>>> -----
> > >>>>
> > >>>> On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
> > >>>>> IF you start with Fixed Position mode, THEN this speeds up process.
> > >>>>> I would also suggest a CLEAR View of Sky for the Antenna.
> > >>>>> Motorola Oncore UT Plus Engineering Notes (circa 2000)
> > >>>>> https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf
> > <https://synergy-gps.com/wp-content/uploads/2018/11/ut-engg-notes.pdf>
> > >>>>> Motorola Oncore GT Plus Engineering Notes (circa 2000)
> > >>>>> https://www.tapr.org/pdf/GT_Eng_Notes.pdf <
> > https://www.tapr.org/pdf/GT_Eng_Notes.pdf>
> > >>>>> UT Plus model numbers:
> > >>>>> R5122U111x - right angle OSX
> > >>>>> R5222U111x - right angle OSX, on-board Lithium battery
> > >>>>> R5122U115x - straight OSX
> > >>>>> GT Plus model numbers:
> > >>>>> R3111G111x - standard version
> > >>>>> R3211G111x - on-board Lithium battery
> > >>>>> R3111G114x - SMB antenna connector
> > >>>>> greg, w9gb
> > >>>>> ==
> > >>>>> Date: Sun, 18 Sep 2022 08:42:18 -0400
> > >>>>> From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
> > marcelo.f.dantas@gmail.com>>
> > >>>>> Subject: [time-nuts] Thanks for adding me, and please help. Motorola
> > Oncore
> > >>>>> To: time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
> > >>>>> Hi there Everyone,
> > >>>>> Thanks for accepting me to this list.
> > >>>>> I am in (dire) need of help here and maybe one of you is a Motorola
> > Oncore
> > >>>>> user and could assist.
> > >>>>> I have a couple Motorola Oncore modules, which I use mounted to a
> > >>>>> "baseboard" for timing purposes.
> > >>>>> One is a R5222U1115 and the other a R3111G1112.
> > >>>>> They have been sitting in a drawer for some time. Being "some time"
> > since
> > >>>>> the pre-pandemic era.
> > >>>>> Now I am trying to use them again but for whatever reason they won't
> > lock
> > >>>>> to any satellites.
> > >>>>> The modules are starting up, sending 1pps and seem to be accepting
> > commands
> > >>>>> correctly.
> > >>>>> I have also tested the baseboard (power, serial, etc) and the
> > antenna.
> > >>>>> The antenna works well on a third (non-motorola) module.
> > >>>>> I have tried everything, left the modules there running for 24 hours.
> > >>>>> No joy. None of them will lock to any satellites.
> > >>>>> I have tried defaulting them using WinOncore, no change.
> > >>>>> I have also tried to find an almanac file to upload, hoping it would
> > help,
> > >>>>> but couldn't find one with the required .alm file extension.
> > >>>>> At this point I do not know what to do anymore. I have a system
> > (module,
> > >>>>> board, antenna, power, etc.) that should just work, and yet it
> > refuses to.
> > >>>>> Maybe there's some special factory reset? Maybe there's some command
> > I do
> > >>>>> not know about? Maybe other software than WinOncore with some extra
> > >>>>> debug options?
> > >>>>> Any guidance here would be deeply appreciated.
> > >>>>> Thanks a lot in advance,
> > >>>>> Marcelo.
> > >>>>> _______________________________________________
> > >>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > >>>> _______________________________________________
> > >>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > >>> _______________________________________________
> > >>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > > _______________________________________________
> > > time-nuts mailing list -- time-nuts@lists.febo.com
> > > To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
AS
Art Sepin
Wed, Sep 21, 2022 8:24 PM
It should be not relevant for the GT+ and UT+ mentioned here.
Azelio is correct. That Motorola App-Note was only relevant for the Motorola 6 and 8 channel VP Oncore series of GPS receivers (from model numbers starting with B1, B3, B4 and B8) that incorporated a "pendulum oscillator." That oscillator design required a periodic power-cycle to store current oscillator data. Over long periods of being powered on, the VP Oncore oscillator frequency would drift to the extent that satellites were difficult to acquire and those that were already being tracked exhibited lower signal strengths (a condition that closely resembled an RF front end operating in compression). A different oscillator design was incorporated in the follow-on 8 channel GT+, UT+ designs and the 12 channel M12+/M12M receivers. We still have a few of those old receivers that work fine for time of day and 1PPS but the date is incorrect.
I forwarded a more relevant "VP Oncore Start-Up" App-Note to John. It and other Tech-Notes covering Motorola's legacy receivers have not been available from Synergy's web site since we were hacked a couple of years ago. We plan to restore those archives but our current business obligations come first.
Art
-----Original Message-----
From: Azelio Boriani via time-nuts time-nuts@lists.febo.com
Sent: Wednesday, September 21, 2022 2:08 AM
To: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Azelio Boriani azelio.boriani@gmail.com
Subject: [time-nuts] Re: Please help. Motorola Oncore
The Motorola service note, that John Ackermann was referring to, should be this:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsynergy-gps.com%2Fwp-content%2Fuploads%2F2019%2F06%2FVP_SERVICE_NOTE.pdf&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rXHaX2viR1Rchh0mJrffAq9QcFzw6saKjTi9vpqFsWQ%3D&reserved=0
It should be not relevant for the GT+ and UT+ mentioned here.
On Tue, Sep 20, 2022 at 6:23 PM Marcelo Dantas via time-nuts time-nuts@lists.febo.com wrote:
I am wondering if this issue could be caused by the way I am setting
the date/time when setting it up on WinOncore.
I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data
into the initial reference position. Telling the software to set it
into the position hold position.
For the initial reference time I tried entering UTC time and leaving
the GMT offset +0, or my local time and setting the GMT offset to -4,
also some combinations of that.
I already gave up on the UT+, but the GT+ at some point showed
"visible satellites", though it wouldn't track any. As this happened
way into my trial and error process, I was unable to verify which
combination gave me these results.
Sorry if I sound like a complete noob (which I am) but I have noticed
that, by changing the time it would show different satellites in
different positions, so I thought: aha, it is based on almanac+time,
not on what it is actually "seeing" in the sky. I mean, I am not a
specialist on this by any means, but I am suspecting it tracks based
on where the satellites should be at a given time, not by listening to where they actually are?
(please don't give up on me)
Anyways, could be that I am telling the GPS wrong information on its
initialization, which makes it go bananas and not find anything. And
lacking a valid almanac it would not be able to even build one based
on the wrong information I provided? I am shooting in the dark here.
Thanks,
Marcelo.
On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
Hi,
Not really. The format is the same. Subtle clarifications and use of
flag fields is however.
One aviation GPS receiver crashed whenever the flag was set as a new
satellite was introduced into the constellation. Considering the
cost and effort involved of recertifying it after a bugfix, it
became a hesitation to fix it. I think this was a learning
experience to the air industry, so I think they now have means to
address it on more regular basis, since I know that in more recent
history the lack of timely update has been the reason for GPS
receiver problems, not the lack of update as such. I will ask around on this.
It's the GPS III signals which will be very different, as it is
packet based.
Cheers,
Magnus
On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
Hi
It would not surprise me at all to find that a modern version of
the almanac is different than the 1998 version. A lot has changed
since then.
Given that you can find these for < $10 on eBay. I would not
invest a lot in them at this point .... Once you get them running,
you will have roll over issues.
Bob
Hi Bob,
The modules are old. 1998/2000.
I have left the UT+ running for about 36 Hrs. I have noticed that
the
battery on the UT+ is dead, so I am ordering a replacement.
However, while running powered for 36 hours I expected it would
see
"something". I wish there was a way to verify some of its internal
information, to see if it was actually collecting something.
The WinOncore software allows you to upload an almanac, and it
talks
about a .alm file extension, and on the .gov site I only found a
latest_yuma.alm file, which I uploaded, but it would still show "bad
almanac".
I have also tried to upload a .al3 (SEM) file, with the same result.
Both files seem to upload, so I am not sure which one should be
the
correct one, or if both are. I am assuming the yuma because it has the
.alm extension. (still a noob in this matter)
On a new development, the GT+ started showing satellites, it
shows 10
satellites visible, zero tracked.
The UT+ regardless of the almanacs uploaded, still shows zero
visible,
I am still trying to find a reference to the correct (expected)
almanac
file format and to the eventual calibration procedure referred previously.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
Hi
If it's showing "bad almanac" then that is part of the issue.
It may not be all of the issue ....
How old are these modules? They went through several revisions
and each one was a big leap over the previous version. If they
date back far enough, it could take a very long time to come up
with an almanac.
Bob
On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
@Bjorn: It is the same antenna which worked back then, it was
sitting
there in the same drawer. So, unless it degrades somehow over time,
it should continue to work I guess.
I have no idea though how to measure/verify if there's
saturation
When I plugged this antenna to a U-Blox it immediately kicked in
with
a bunch of satellites in view, but the U-Blox might also have a
different input impedance.
@Bob "off for a while" means since mid 2018. So I immediately
thought
of an almanac, however I could not yet figure out the .alm file it
would require.
I have downloaded almanac files from the web, not oncore
specific, but
when importing them via WinOncore I do not get any success/failure
messages, and the device continues to show "bad almanac" on its status.
I have a feeling that the issue is towards bad/outdated internal
information. Or maybe the calibration John spoke about, if I can
figure it out, could help.
Thanks,
Marcelo.
On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
Hi
The other gotcha depends a lot on just how long "off for a while" is.
If any of these devices are off power for decades, the internal
data for the almanac ( = which sats are where ) will be way off.
The process of random search is a lot faster with the newer modules.
They have way more processing horsepower. Just how many hours
(or days) it takes this or that example of an early module to
come back to life .... who knows ....
Bob
On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts
<
Some of the early Motorola receivers had an issue with
long-term XO
drift. That can result in failure to lock if the unit has been
powered off for a long time. There is a procedure to recalibrate it
(no test equipment required). I think it was written up in a
Motorola app note that's available on line, but I can't put my finger on it right now.
John
On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
IF you start with Fixed Position mode, THEN this speeds up process.
I would also suggest a CLEAR View of Sky for the Antenna.
Motorola Oncore UT Plus Engineering Notes (circa 2000)
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2
F%2Fsynergy-gps.com%2Fwp-content%2Fuploads%2F2018%2F11%2Fut-en
gg-notes.pdf&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52
e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%
7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
00%7C%7C%7C&sdata=MWfmHEZV86UmB5NZ%2FW9C7zXwxcIIQPvRb%2F6t
AD59yF0%3D&reserved=0
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs
ynergy-gps.com%2Fwp-content%2Fuploads%2F2018%2F11%2Fut-engg-notes.pd
f&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52e03c484899400408d
a9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C6379934948009
91034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MWfmHEZV86UmB
5NZ%2FW9C7zXwxcIIQPvRb%2F6tAD59yF0%3D&reserved=0>
Motorola Oncore GT Plus Engineering Notes (circa 2000)
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2
F%2Fwww.tapr.org%2Fpdf%2FGT_Eng_Notes.pdf&data=05%7C01%7Ca
rt%40synergy-gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f
9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C637993494800991034%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Zp9Vr5IPVPM
PKy1jfkVZrsxVP4NMnY142cF80v4eIs4%3D&reserved=0 <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.tapr.org%2Fpdf%2FGT_Eng_Notes.pdf&data=05%7C01%7Cart%40synergy
-gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779a
faa0cad9ed%7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJW
IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
0%7C%7C%7C&sdata=Zp9Vr5IPVPMPKy1jfkVZrsxVP4NMnY142cF80v4eIs4%3D&
amp;reserved=0>
UT Plus model numbers:
R5122U111x - right angle OSX
R5222U111x - right angle OSX, on-board Lithium battery
R5122U115x - straight OSX GT Plus model numbers:
R3111G111x - standard version
R3211G111x - on-board Lithium battery R3111G114x - SMB antenna
connector greg, w9gb ==
Date: Sun, 18 Sep 2022 08:42:18 -0400
From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
Subject: [time-nuts] Thanks for adding me, and please help.
Motorola
user and could assist.
I have a couple Motorola Oncore modules, which I use mounted
to a "baseboard" for timing purposes.
One is a R5222U1115 and the other a R3111G1112.
They have been sitting in a drawer for some time. Being "some time"
the pre-pandemic era.
Now I am trying to use them again but for whatever reason they
won't
to any satellites.
The modules are starting up, sending 1pps and seem to be
accepting
correctly.
I have also tested the baseboard (power, serial, etc) and the
The antenna works well on a third (non-motorola) module.
I have tried everything, left the modules there running for 24 hours.
No joy. None of them will lock to any satellites.
I have tried defaulting them using WinOncore, no change.
I have also tried to find an almanac file to upload, hoping it
would
but couldn't find one with the required .alm file extension.
At this point I do not know what to do anymore. I have a
system
board, antenna, power, etc.) that should just work, and yet it
Maybe there's some special factory reset? Maybe there's some
command
not know about? Maybe other software than WinOncore with some
extra debug options?
Any guidance here would be deeply appreciated.
Thanks a lot in advance,
Marcelo.
time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
Hi Folks,
> It should be not relevant for the GT+ and UT+ mentioned here.
Azelio is correct. That Motorola App-Note was only relevant for the Motorola 6 and 8 channel VP Oncore series of GPS receivers (from model numbers starting with B1, B3, B4 and B8) that incorporated a "pendulum oscillator." That oscillator design required a periodic power-cycle to store current oscillator data. Over long periods of being powered on, the VP Oncore oscillator frequency would drift to the extent that satellites were difficult to acquire and those that were already being tracked exhibited lower signal strengths (a condition that closely resembled an RF front end operating in compression). A different oscillator design was incorporated in the follow-on 8 channel GT+, UT+ designs and the 12 channel M12+/M12M receivers. We still have a few of those old receivers that work fine for time of day and 1PPS but the date is incorrect.
I forwarded a more relevant "VP Oncore Start-Up" App-Note to John. It and other Tech-Notes covering Motorola's legacy receivers have not been available from Synergy's web site since we were hacked a couple of years ago. We plan to restore those archives but our current business obligations come first.
Art
-----Original Message-----
From: Azelio Boriani via time-nuts <time-nuts@lists.febo.com>
Sent: Wednesday, September 21, 2022 2:08 AM
To: Discussion of precise time and frequency measurement <time-nuts@lists.febo.com>
Cc: Azelio Boriani <azelio.boriani@gmail.com>
Subject: [time-nuts] Re: Please help. Motorola Oncore
The Motorola service note, that John Ackermann was referring to, should be this:
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsynergy-gps.com%2Fwp-content%2Fuploads%2F2019%2F06%2FVP_SERVICE_NOTE.pdf&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rXHaX2viR1Rchh0mJrffAq9QcFzw6saKjTi9vpqFsWQ%3D&reserved=0>
It should be not relevant for the GT+ and UT+ mentioned here.
On Tue, Sep 20, 2022 at 6:23 PM Marcelo Dantas via time-nuts <time-nuts@lists.febo.com> wrote:
>
> I am wondering if this issue could be caused by the way I am setting
> the date/time when setting it up on WinOncore.
> I am in NY, N 41.10.0481, W 074.11.2900, 408ft. So I enter this data
> into the initial reference position. Telling the software to set it
> into the position hold position.
> For the initial reference time I tried entering UTC time and leaving
> the GMT offset +0, or my local time and setting the GMT offset to -4,
> also some combinations of that.
> I already gave up on the UT+, but the GT+ at some point showed
> "visible satellites", though it wouldn't track any. As this happened
> way into my trial and error process, I was unable to verify which
> combination gave me these results.
> Sorry if I sound like a complete noob (which I am) but I have noticed
> that, by changing the time it would show different satellites in
> different positions, so I thought: aha, it is based on almanac+time,
> not on what it is actually "seeing" in the sky. I mean, I am not a
> specialist on this by any means, but I am suspecting it tracks based
> on where the satellites should be at a given time, not by listening to where they actually are?
> (please don't give up on me)
> Anyways, could be that I am telling the GPS wrong information on its
> initialization, which makes it go bananas and not find anything. And
> lacking a valid almanac it would not be able to even build one based
> on the wrong information I provided? I am shooting in the dark here.
>
> Thanks,
> Marcelo.
>
>
>
> On Tue, Sep 20, 2022 at 4:27 AM Magnus Danielson via time-nuts <
> time-nuts@lists.febo.com> wrote:
>
> > Hi,
> >
> > Not really. The format is the same. Subtle clarifications and use of
> > flag fields is however.
> >
> > One aviation GPS receiver crashed whenever the flag was set as a new
> > satellite was introduced into the constellation. Considering the
> > cost and effort involved of recertifying it after a bugfix, it
> > became a hesitation to fix it. I think this was a learning
> > experience to the air industry, so I think they now have means to
> > address it on more regular basis, since I know that in more recent
> > history the lack of timely update has been the reason for GPS
> > receiver problems, not the lack of update as such. I will ask around on this.
> >
> > It's the GPS III signals which will be very different, as it is
> > packet based.
> >
> > Cheers,
> > Magnus
> >
> > On 2022-09-20 00:27, Bob kb8tq via time-nuts wrote:
> > > Hi
> > >
> > > It would not surprise me at all to find that a modern version of
> > > the almanac is different than the 1998 version. A lot has changed
> > > since then.
> > >
> > > Given that you can find these for < $10 on eBay. I would not
> > > invest a lot in them at this point .... Once you get them running,
> > > you will have roll over issues.
> > >
> > > Bob
> > >
> > >> On Sep 19, 2022, at 4:36 PM, Marcelo Dantas
> > >> <marcelo.f.dantas@gmail.com>
> > wrote:
> > >>
> > >> Hi Bob,
> > >>
> > >> The modules are old. 1998/2000.
> > >>
> > >> I have left the UT+ running for about 36 Hrs. I have noticed that
> > >> the
> > battery on the UT+ is dead, so I am ordering a replacement.
> > >> However, while running powered for 36 hours I expected it would
> > >> see
> > "something". I wish there was a way to verify some of its internal
> > information, to see if it was actually collecting something.
> > >>
> > >> The WinOncore software allows you to upload an almanac, and it
> > >> talks
> > about a .alm file extension, and on the .gov site I only found a
> > latest_yuma.alm file, which I uploaded, but it would still show "bad
> > almanac".
> > >> I have also tried to upload a .al3 (SEM) file, with the same result.
> > >> Both files seem to upload, so I am not sure which one should be
> > >> the
> > correct one, or if both are. I am assuming the yuma because it has the
> > .alm extension. (still a noob in this matter)
> > >>
> > >> On a new development, the GT+ started showing satellites, it
> > >> shows 10
> > satellites visible, zero tracked.
> > >> The UT+ regardless of the almanacs uploaded, still shows zero
> > >> visible,
> > zero tracked.
> > >>
> > >> I am still trying to find a reference to the correct (expected)
> > >> almanac
> > file format and to the eventual calibration procedure referred previously.
> > >>
> > >> Thanks,
> > >> Marcelo.
> > >>
> > >>
> > >> On Mon, Sep 19, 2022 at 5:10 PM Bob kb8tq <kb8tq@n1k.org <mailto:
> > kb8tq@n1k.org>> wrote:
> > >> Hi
> > >>
> > >> If it's showing "bad almanac" then that is part of the issue.
> > >> It may not be *all* of the issue ....
> > >>
> > >> How old are these modules? They went through several revisions
> > >> and each one was a big leap over the previous version. If they
> > >> date back far enough, it could take a very long time to come up
> > >> with an almanac.
> > >>
> > >> Bob
> > >>
> > >>> On Sep 19, 2022, at 3:41 PM, Marcelo Dantas <
> > marcelo.f.dantas@gmail.com <mailto:marcelo.f.dantas@gmail.com>> wrote:
> > >>>
> > >>> @Bjorn: It is the same antenna which worked back then, it was
> > >>> sitting
> > there in the same drawer. So, unless it degrades somehow over time,
> > it should continue to work I guess.
> > >>> I have no idea though how to measure/verify if there's
> > >>> saturation
> > going on.
> > >>> When I plugged this antenna to a U-Blox it immediately kicked in
> > >>> with
> > a bunch of satellites in view, but the U-Blox might also have a
> > different input impedance.
> > >>>
> > >>> @Bob "off for a while" means since mid 2018. So I immediately
> > >>> thought
> > of an almanac, however I could not yet figure out the .alm file it
> > would require.
> > >>> I have downloaded almanac files from the web, not oncore
> > >>> specific, but
> > when importing them via WinOncore I do not get any success/failure
> > messages, and the device continues to show "bad almanac" on its status.
> > >>> I have a feeling that the issue is towards bad/outdated internal
> > information. Or maybe the calibration John spoke about, if I can
> > figure it out, could help.
> > >>>
> > >>> Thanks,
> > >>> Marcelo.
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Sep 19, 2022 at 4:26 PM Bob kb8tq via time-nuts <
> > time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> > >>> Hi
> > >>>
> > >>> The other gotcha depends a lot on just how long "off for a while" is.
> > >>> If any of these devices are off power for decades, the internal
> > >>> data for the almanac ( = which sats are where ) will be way off.
> > >>>
> > >>> The process of random search is a lot faster with the newer modules.
> > >>> They have way more processing horsepower. Just how many hours
> > >>> (or days) it takes this or that example of an early module to
> > >>> come back to life .... who knows ....
> > >>>
> > >>> Bob
> > >>>
> > >>>> On Sep 19, 2022, at 2:14 PM, John Ackermann N8UR via time-nuts
> > >>>> <
> > time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>> wrote:
> > >>>>
> > >>>> Some of the early Motorola receivers had an issue with
> > >>>> long-term XO
> > drift. That can result in failure to lock if the unit has been
> > powered off for a long time. There is a procedure to recalibrate it
> > (no test equipment required). I think it was written up in a
> > Motorola app note that's available on line, but I can't put my finger on it right now.
> > >>>>
> > >>>> John
> > >>>> -----
> > >>>>
> > >>>> On 9/19/22 07:53, Gregory Beat via time-nuts wrote:
> > >>>>> IF you start with Fixed Position mode, THEN this speeds up process.
> > >>>>> I would also suggest a CLEAR View of Sky for the Antenna.
> > >>>>> Motorola Oncore UT Plus Engineering Notes (circa 2000)
> > >>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2
> > >>>>> F%2Fsynergy-gps.com%2Fwp-content%2Fuploads%2F2018%2F11%2Fut-en
> > >>>>> gg-notes.pdf&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52
> > >>>>> e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%
> > >>>>> 7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > >>>>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > >>>>> 00%7C%7C%7C&sdata=MWfmHEZV86UmB5NZ%2FW9C7zXwxcIIQPvRb%2F6t
> > >>>>> AD59yF0%3D&reserved=0
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs
> > ynergy-gps.com%2Fwp-content%2Fuploads%2F2018%2F11%2Fut-engg-notes.pd
> > f&data=05%7C01%7Cart%40synergy-gps.com%7C4ace52e03c484899400408d
> > a9bb408f1%7Cc81f9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C6379934948009
> > 91034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MWfmHEZV86UmB
> > 5NZ%2FW9C7zXwxcIIQPvRb%2F6tAD59yF0%3D&reserved=0>
> > >>>>> Motorola Oncore GT Plus Engineering Notes (circa 2000)
> > >>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2
> > >>>>> F%2Fwww.tapr.org%2Fpdf%2FGT_Eng_Notes.pdf&data=05%7C01%7Ca
> > >>>>> rt%40synergy-gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f
> > >>>>> 9fdec0e04d8c95779afaa0cad9ed%7C1%7C0%7C637993494800991034%7CUn
> > >>>>> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > >>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Zp9Vr5IPVPM
> > >>>>> PKy1jfkVZrsxVP4NMnY142cF80v4eIs4%3D&reserved=0 <
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.tapr.org%2Fpdf%2FGT_Eng_Notes.pdf&data=05%7C01%7Cart%40synergy
> > -gps.com%7C4ace52e03c484899400408da9bb408f1%7Cc81f9fdec0e04d8c95779a
> > faa0cad9ed%7C1%7C0%7C637993494800991034%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> > 0%7C%7C%7C&sdata=Zp9Vr5IPVPMPKy1jfkVZrsxVP4NMnY142cF80v4eIs4%3D&
> > amp;reserved=0>
> > >>>>> UT Plus model numbers:
> > >>>>> R5122U111x - right angle OSX
> > >>>>> R5222U111x - right angle OSX, on-board Lithium battery
> > >>>>> R5122U115x - straight OSX GT Plus model numbers:
> > >>>>> R3111G111x - standard version
> > >>>>> R3211G111x - on-board Lithium battery R3111G114x - SMB antenna
> > >>>>> connector greg, w9gb ==
> > >>>>> Date: Sun, 18 Sep 2022 08:42:18 -0400
> > >>>>> From: Marcelo Dantas <marcelo.f.dantas@gmail.com <mailto:
> > marcelo.f.dantas@gmail.com>>
> > >>>>> Subject: [time-nuts] Thanks for adding me, and please help.
> > >>>>> Motorola
> > Oncore
> > >>>>> To: time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
> > >>>>> Hi there Everyone, Thanks for accepting me to this list.
> > >>>>> I am in (dire) need of help here and maybe one of you is a
> > >>>>> Motorola
> > Oncore
> > >>>>> user and could assist.
> > >>>>> I have a couple Motorola Oncore modules, which I use mounted
> > >>>>> to a "baseboard" for timing purposes.
> > >>>>> One is a R5222U1115 and the other a R3111G1112.
> > >>>>> They have been sitting in a drawer for some time. Being "some time"
> > since
> > >>>>> the pre-pandemic era.
> > >>>>> Now I am trying to use them again but for whatever reason they
> > >>>>> won't
> > lock
> > >>>>> to any satellites.
> > >>>>> The modules are starting up, sending 1pps and seem to be
> > >>>>> accepting
> > commands
> > >>>>> correctly.
> > >>>>> I have also tested the baseboard (power, serial, etc) and the
> > antenna.
> > >>>>> The antenna works well on a third (non-motorola) module.
> > >>>>> I have tried everything, left the modules there running for 24 hours.
> > >>>>> No joy. None of them will lock to any satellites.
> > >>>>> I have tried defaulting them using WinOncore, no change.
> > >>>>> I have also tried to find an almanac file to upload, hoping it
> > >>>>> would
> > help,
> > >>>>> but couldn't find one with the required .alm file extension.
> > >>>>> At this point I do not know what to do anymore. I have a
> > >>>>> system
> > (module,
> > >>>>> board, antenna, power, etc.) that should just work, and yet it
> > refuses to.
> > >>>>> Maybe there's some special factory reset? Maybe there's some
> > >>>>> command
> > I do
> > >>>>> not know about? Maybe other software than WinOncore with some
> > >>>>> extra debug options?
> > >>>>> Any guidance here would be deeply appreciated.
> > >>>>> Thanks a lot in advance,
> > >>>>> Marcelo.
> > >>>>> _______________________________________________
> > >>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > >>>> _______________________________________________
> > >>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > >>> _______________________________________________
> > >>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:
> > time-nuts@lists.febo.com>
> > >>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > <mailto:time-nuts-leave@lists.febo.com>
> > > _______________________________________________
> > > time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe
> > > send an email to time-nuts-leave@lists.febo.com
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe
> > send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send
> an email to time-nuts-leave@lists.febo.com
_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com
