Re: [time-nuts] Connecting my Oncores
My manual suggests you need to send
@@Ci<mode><cksum><CR><LF>
I had a similar problem a while ago.
I wrote a simple python hack to compute the checksum. The manual probably
has an example you can test it on.
I sent individual commands with things like this:
echo -e -n "$PSRF103,0,0,0,1*24\r\n" > /dev/ttyUSB1
I collected the commands I used and other notes in a text file so I could
grab them with cut/paste when I needed them the next time. Things like:
stty --file=/dev/ttyUSB1 4800
I don't collect elaborate notes, just enough to remind me what man pages I
need to look in and/or what key idea it took me so long to uncover the first
time. The above line reminds me that I have to set the tty to 4800 and that
stty is the program that does things like that.
You can also write your own simple c code to do exactly what you want. It
may be a lot of thrashing to get off the ground.
ntpd has a driver for Oncore refclocks. It might have useful ideas.
It's also worth checking gpsd. It knows how to talk to lots and lots of GPS
units and can smash some of them into a useful state.
--
These are my opinions, not necessarily my employer's. I hate spam.
Quoth Hal Murray at 2008-04-02 14:08...
My manual suggests you need to send
@@Ci<mode><cksum><CR><LF>
I had a similar problem a while ago.
I wrote a simple python hack to compute the checksum. The manual probably
has an example you can test it on.
...
It's also worth checking gpsd. It knows how to talk to lots and lots of GPS
units and can smash some of them into a useful state.
Thanks for the suggestions. I'll play around in Perl to get something
going and then translate it to C for use as a start-up routine. (I was
going to put on of the GT+s in a Nixie clock, so Perl is out of the
question there ;-))
The GT+s are definitely behaving strangely; I just connected the one
that finally decided to talk to me to the computer that will be the time
server and fired up gpsd:
gpsd -D 4 -n -N /dev/cua00
gpsd: launching (Version 2.34)
gpsd: listening on port 2947
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: opening GPS data source at '/dev/cua00'
gpsd: speed 9600, 8N1
gpsd: garmin_gps not active.
gpsd: no probe matched...
gpsd: gpsd_activate(1): opened GPS (6)
Didn't recognise it, just sat there. (The documentation mentions
specifically that it knows about GT+s.) I re-connected the module to
the machine with VisualGPS, now I can't get it to talk to me again.
This doesn't seem right - either the thing should work or not. I do
have my suspicions about those on-board batteries and wonder if I would
be better off without them.
Think I'll use the VP for the time server and leave the GT+s for further
experimentation unless anyone just happens to know why they aren't
playing along.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
I have tried to reach James Miller at
james@jrmiller.demon.co.uk
Twice in the past two weeks but the mail is rejected.
Is anyone else having problems reaching him?
Dennis
This is the latest response I got. It isn't very helpful.
Your message has encountered delivery problems
to the following recipient(s):
james@jrmiller.demon.co.uk
(Was addressed to james@jrmiller.demon.co.uk)
Delivery failed after 1 attempts within 0 hours and 0 minutes 550 Visit
http://www.demon.net/Scripts/fp.do?id=4J5-geVo5ZxNxCqrS98mx6s8OedirEs8 to
report false positives
No recipients were successfully delivered to.
Quoth Dennis Tillman at 2008-04-02 14:44...
I have tried to reach James Miller at
james@jrmiller.demon.co.uk
Twice in the past two weeks but the mail is rejected.
Is anyone else having problems reaching him?
Dennis
This is the latest response I got. It isn't very helpful.
That indicates to me that your messages are getting eaten by an
anti-spam system. Did you try visiting that link?
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
On Tue, Apr 1, 2008 at 8:38 PM, Hal Murray hmurray@megapathdsl.net wrote:
It's also worth checking gpsd. It knows how to talk to lots and lots of GPS
units and can smash some of them into a useful state.
I haven't got around to writing an oncore driver yet. There was one in
the works but the people working on it fell off the edge of the world.
I just (like within the last 5 minutes) got my inside antenna
distribution gear set up. My garmin is happy, so I can look into
hacking on oncore support now.
CK
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
Quoth Chris Kuethe at 2008-04-02 16:15...
On Tue, Apr 1, 2008 at 8:38 PM, Hal Murray hmurray@megapathdsl.net wrote:
It's also worth checking gpsd. It knows how to talk to lots and lots of GPS
units and can smash some of them into a useful state.
I haven't got around to writing an oncore driver yet. There was one in
the works but the people working on it fell off the edge of the world.
I just (like within the last 5 minutes) got my inside antenna
distribution gear set up. My garmin is happy, so I can look into
hacking on oncore support now.
Aha - didn't realise you were a gpsd author, although I have now spotted
a familiar name at the bottom of the man page...
I've got the VP and the GT+ here (if I can get the latter to work at
all) if you want anything tested.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
Matthew,
The battery can indeed cause some problems if you don't have the software
necessary to reset the receiver to a known state. The simplest thing to do
is get a copy of Rick Hambly's TAC32 at cnssys.com. TAC32 will light up just
about any Moto receiver ever made no matter what state it is in. If TAC32
can't talk to any given receiver the receiver is most likely toast. I'm not
sure how smart gpsd is, but it may not know about switching the receiver
between binary and NMEA mode. Since the gpsd commands you show in your email
specify 9600 baud, I assume you want binary? Visual GPS will only talk to
Moto receivers in NMEA mode at 4800 baud. It is NOT able to switch a Moto
receiver into NMEA from binary.
Randy Warner
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Matthew Smith
Sent: Tuesday, April 01, 2008 8:57 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Connecting my Oncores
Quoth Hal Murray at 2008-04-02 14:08...
My manual suggests you need to send
@@Ci<mode><cksum><CR><LF>
I had a similar problem a while ago.
I wrote a simple python hack to compute the checksum. The manual probably
has an example you can test it on.
...
It's also worth checking gpsd. It knows how to talk to lots and lots of
GPS
units and can smash some of them into a useful state.
Thanks for the suggestions. I'll play around in Perl to get something
going and then translate it to C for use as a start-up routine. (I was
going to put on of the GT+s in a Nixie clock, so Perl is out of the
question there ;-))
The GT+s are definitely behaving strangely; I just connected the one
that finally decided to talk to me to the computer that will be the time
server and fired up gpsd:
gpsd -D 4 -n -N /dev/cua00
gpsd: launching (Version 2.34)
gpsd: listening on port 2947
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: opening GPS data source at '/dev/cua00'
gpsd: speed 9600, 8N1
gpsd: garmin_gps not active.
gpsd: no probe matched...
gpsd: gpsd_activate(1): opened GPS (6)
Didn't recognise it, just sat there. (The documentation mentions
specifically that it knows about GT+s.) I re-connected the module to
the machine with VisualGPS, now I can't get it to talk to me again.
This doesn't seem right - either the thing should work or not. I do
have my suspicions about those on-board batteries and wonder if I would
be better off without them.
Think I'll use the VP for the time server and leave the GT+s for further
experimentation unless anyone just happens to know why they aren't
playing along.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Wed, Apr 2, 2008 at 5:39 PM, randy warner randy@geodetics.com wrote:
I'm not
sure how smart gpsd is, but it may not know about switching the receiver
between binary and NMEA mode. Since the gpsd commands you show in your email
specify 9600 baud, I assume you want binary?
gpsd can't do anything with a non-NMEA oncore yet, but i do have
enough copies of enough revisions of enough versions of enough
variants of oncores (thanks to this list) that i think i've got all
the mode switching commands covered.
gpsd is designed with autodetection and configuration in mind. where
possible, we try to probe the receiver to see what speed it's running
at, what protocol it uses, what hardware and firmware revision this
particular device is, and will attempt to set up a receiver in a
reasonable fashion. For example, if you've got an oncore in binary
mode with all the messages turned off (or a thales/magellan ac12 for
that matter) we should be able to detect that, and turn on enough
messages to get reasonable use out of the gps.
CK
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
Quoth randy warner at 2008-04-03 11:09...
<snip>
The battery can indeed cause some problems if you don't have the software
necessary to reset the receiver to a known state. The simplest thing to do
is get a copy of Rick Hambly's TAC32 at cnssys.com. TAC32 will light up just
about any Moto receiver ever made no matter what state it is in.
Thanks Randy; I just downloaded TAC32 and it's got one of my catatonic
GT+s talking to me now. I'll leave it to its devices for a while longer
and then try the other one.
I'm going to be mounting all the modules with interface and power supply
boards and will be feeding backup power from an AA-size lithium battery.
So, those on-board batteries will be coming OFF! If anything goes
wrong then, I can just power down, pop out the backup battery (or unplug
the module) and hopefully get back to a default state.
Now I discover that I don't have a good sky view so think that I'll have
to wait until the builder finally turns up (already 6 months late) and
can get my antennas up on the ridge cap.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
Matthew,
Don't pull off the batteries! The boards are populated differently for
battery/non-battery uses. Your external battery will not be connected to the
onboard RAM.
That being said, not using batteries might be a good solution. First, the
old lithiums currently on the receivers are probably on their last legs
anyway. Secondly, as you mentioned, pulling power is a good easy way to
reset the GT+ receiver to binary with all messages disabled. This is the way
timing receivers are normally used because TTFF is not usually a concern,
and it eliminates the headache of replacing batteries out in the field. Can
you imagine every TDMA cell-site needing new batteries every 5-10 years?
One last item - Even without a battery a VP will save its setup information
through power cycles because the older Moto receivers such as the VP save
this information in EEPROM. To default these receivers you need to
explicitly send the binary default command.
Randy Warner
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Matthew Smith
Sent: Wednesday, April 02, 2008 7:10 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Connecting my Oncores
Quoth randy warner at 2008-04-03 11:09...
<snip>
The battery can indeed cause some problems if you don't have the software
necessary to reset the receiver to a known state. The simplest thing to do
is get a copy of Rick Hambly's TAC32 at cnssys.com. TAC32 will light up
just
about any Moto receiver ever made no matter what state it is in.
Thanks Randy; I just downloaded TAC32 and it's got one of my catatonic
GT+s talking to me now. I'll leave it to its devices for a while longer
and then try the other one.
I'm going to be mounting all the modules with interface and power supply
boards and will be feeding backup power from an AA-size lithium battery.
So, those on-board batteries will be coming OFF! If anything goes
wrong then, I can just power down, pop out the backup battery (or unplug
the module) and hopefully get back to a default state.
Now I discover that I don't have a good sky view so think that I'll have
to wait until the builder finally turns up (already 6 months late) and
can get my antennas up on the ridge cap.
Cheers
M
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.