[time-nuts] Re: Please help. Motorola Oncore

Marcelo Dantas marcelo.f.dantas at gmail.com
Tue Sep 20 11:35:47 UTC 2022


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 at 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 at 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 at n1k.org <mailto:
> kb8tq at 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 at gmail.com <mailto:marcelo.f.dantas at 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 at lists.febo.com <mailto:time-nuts at 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 at lists.febo.com <mailto:time-nuts at 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 at gmail.com <mailto:
> marcelo.f.dantas at gmail.com>>
> >>>>> Subject: [time-nuts] Thanks for adding me, and please help. Motorola
> Oncore
> >>>>> To: time-nuts at lists.febo.com <mailto:time-nuts at 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 at lists.febo.com <mailto:
> time-nuts at lists.febo.com>
> >>>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> <mailto:time-nuts-leave at lists.febo.com>
> >>>> _______________________________________________
> >>>> time-nuts mailing list -- time-nuts at lists.febo.com <mailto:
> time-nuts at lists.febo.com>
> >>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> <mailto:time-nuts-leave at lists.febo.com>
> >>> _______________________________________________
> >>> time-nuts mailing list -- time-nuts at lists.febo.com <mailto:
> time-nuts at lists.febo.com>
> >>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> <mailto:time-nuts-leave at lists.febo.com>
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe send an email to time-nuts-leave at lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com




More information about the Time-nuts_lists.febo.com mailing list