On 2012-10-31, David Taylor wrote:
> On 31/10/2012 18:35, Rob wrote:
>
>> I think it is sort of standard Linux, but then there really is no
>> standard Linux anymore due to all the silly changes that Ubuntu people
>> have been bringing.
>
> Yes, the multiple variations was one of the reasons I did
On 31/10/2012 19:25, Rob wrote:
I think it does not look bad and should basically work.
Maybe someone with more Raspberry experience can suggest what to
do.
As mentioned, it is possible to remove the /etc/init.d/gpsd and
start gpsd as a hotplug action, but I have no forther detail
about that.
John Hasler wrote:
> Rob wrote:
>> I don't know much about the raspberry.
>> I think it is sort of standard Linux,
>
> Raspbian is just Debian, recompiled for the particular ARM cpu the
> Raspberry uses and with drivers for the Broadcom video added. The
> recompilation permits the use of hardware
Rob wrote:
> I don't know much about the raspberry.
> I think it is sort of standard Linux,
Raspbian is just Debian, recompiled for the particular ARM cpu the
Raspberry uses and with drivers for the Broadcom video added. The
recompilation permits the use of hardware floating point, which is
diffe
I think it does not look bad and should basically work.
Maybe someone with more Raspberry experience can suggest what to
do.
As mentioned, it is possible to remove the /etc/init.d/gpsd and
start gpsd as a hotplug action, but I have no forther detail
about that. You could see if you can locate th
On 31/10/2012 18:35, Rob wrote:
[]
I don't know much about the raspberry.
Snap!
I think it is sort of standard Linux, but then there really is no
standard Linux anymore due to all the silly changes that Ubuntu people
have been bringing.
Yes, the multiple variations was one of the reasons I
On 31/10/2012 17:22, Rob wrote:
I see errors that are related to permission.
I had wondered about that as well...
I would recommend to type in the session before you do anything else:
sudo sh
or: sudo bash
OK, I can try that.
When it works ok you should have a shell running as root, and
David Taylor wrote:
> Ignoring the offset for the moment, if I power up the Rasberry Pi from
> cold while it sees the PPS signals (to an interrupt-driver GPIO pin) is
> never sees gpsd data ( and trying cgps -s also times out with a can't
> connect). I've left it for about 30 minutes but gpsd
Miroslav Lichvar wrote:
> On Wed, Oct 31, 2012 at 05:22:44PM +, Rob wrote:
>> Using USB ports in a service started at boot time should normally
>> work ok, but when it has issues on the Raspberry maybe it could
>> be solved by delaying the startup of gpsd a bit. But don't try to
>> tackle all
On Wed, Oct 31, 2012 at 05:22:44PM +, Rob wrote:
> Using USB ports in a service started at boot time should normally
> work ok, but when it has issues on the Raspberry maybe it could
> be solved by delaying the startup of gpsd a bit. But don't try to
> tackle all issues at the same time.
Isn'
I see errors that are related to permission.
I would recommend to type in the session before you do anything else:
sudo sh
or: sudo bash
When it works ok you should have a shell running as root, and then
you can stop the service and start gpsd without the risk that you
start to run it as user 1
A follow-up to this: it seems that my GPS is only recognised by gpsd if
it is plugged into the USB port sometime /after/ the computer has
started. This is obviously not acceptable in an operational
environment, and has to be the first problem to solve. Anyone any ideas?
I can then go back to
On 30/10/2012 20:51, Rob wrote:
[]
The log level is set by a startup option of gpsd.
You now probably run "gpsd -n /dev/ttyS0" from some startup script.
(e.g. /etc/init.d/gpsd)
First stop the running server using: /etc/init.d/gpsd stop
Then run gpsd from a shell using: gpsd -N -D 2 -n /dev/tty
David Taylor wrote:
> On 30/10/2012 19:45, Rob wrote:
> []
>> Are you using NMEA mode or TSIP mode on that receiver?
>
> TSIP - as it's what it powers up in by default.
>
>> I wrote the TSIP driver and checked the original source and the
>> current version 3.7, and in the processing of the packet
On 30/10/2012 20:06, David Woolley wrote:
David Taylor wrote:
On 30/10/2012 17:57, David Woolley wrote:
Thanks, David. Do you think that it would still be 20 minutes when
the clock in question is being polled every 16 seconds?
The starting point, without using tinker stepout, is 15 minute
On 30/10/2012 19:45, Rob wrote:
[]
Are you using NMEA mode or TSIP mode on that receiver?
TSIP - as it's what it powers up in by default.
I wrote the TSIP driver and checked the original source and the
current version 3.7, and in the processing of the packet 0x41 there
is a check on the valid
David Taylor wrote:
On 30/10/2012 17:57, David Woolley wrote:
Thanks, David. Do you think that it would still be 20 minutes when the
clock in question is being polled every 16 seconds?
The starting point, without using tinker stepout, is 15 minutes. To
that you have to add the time to g
David Taylor wrote:
> On 30/10/2012 17:59, Rob wrote:
> []
>> When I wrote that part of gpsd, I implemented the proper checks so
>> that the time is only put in the SHM after the GPS receiver has
>> indicated that it has a valid fix on the satellites.
>
> THanks for this information, Rob. In this
On 2012-10-30, David Taylor wrote:
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's a
On 30/10/2012 17:59, Rob wrote:
[]
When I wrote that part of gpsd, I implemented the proper checks so
that the time is only put in the SHM after the GPS receiver has
indicated that it has a valid fix on the satellites.
THanks for this information, Rob. In this case the GPS appears to have
a v
On 30/10/2012 17:57, David Woolley wrote:
David Taylor wrote:
However, suppose I had /only/ the GPS receiver? NTP has the GPS time
and the PPS signal for the exact second, syncs, and then a few minutes
in the time suddenly changes by 16 seconds. I would hope that then
causes NTP to step the
David Taylor wrote:
> I have discovered that on a cold start my Resolution SMT GPS receiver
> outputs the time in GPS time, until it has downloaded enough information
> to determine the GSP offset, when it switches to UTC. This particular
> receiver has no battery backup (it's an evaluation bo
David Taylor wrote:
However, suppose I had /only/ the GPS receiver? NTP has the GPS time
and the PPS signal for the exact second, syncs, and then a few minutes
in the time suddenly changes by 16 seconds. I would hope that then
causes NTP to step the clock onto UTC rather than GPS time. I
I have discovered that on a cold start my Resolution SMT GPS receiver
outputs the time in GPS time, until it has downloaded enough information
to determine the GSP offset, when it switches to UTC. This particular
receiver has no battery backup (it's an evaluation board).
I'm feeding this into
24 matches
Mail list logo
