On 31/10/2012 21:58, E-Mail Sent to this address will be added to the
BlackLists wrote:
[]
IIRC the Raspberry pi has a GPIO pin 24 Hard PPS patch,
so the USB Serial PPS issue can be avoided.
Correct - and it works very well:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#pps
--
Cheers,
On 2012-10-31, Richard B. Gilbert wrote:
> On 10/31/2012 5:04 PM, unruh wrote:
>> On 2012-10-31, Richard B. Gilbert wrote:
>>> On 10/31/2012 4:30 AM, David Woolley wrote:
Kennedy, Paul wrote:
> I believe the answer to your question is 12.5 minutes.
>
> This is the time it takes t
Rob wrote:> Martin Burnicki wrote:
>> Of course, if you are using an USB-to-serial converter
>> and simply apply the PPS signal via the USB connection
>> it depends on which time the chip inside the converter
>> needs to detect the slope and send an appropriate
>> USB message "DCD changed" to t
On 10/31/2012 5:04 PM, unruh wrote:
On 2012-10-31, Richard B. Gilbert wrote:
On 10/31/2012 4:30 AM, David Woolley wrote:
Kennedy, Paul wrote:
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPST
On 2012-10-31, Richard B. Gilbert wrote:
> On 10/31/2012 4:30 AM, David Woolley wrote:
>> Kennedy, Paul wrote:
>>> I believe the answer to your question is 12.5 minutes.
>>>
>>> This is the time it takes to receive the full set of 25 almanac frames,
>>> which contains the GPSTime/UTC offset (among
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
On 10/31/2012 4:30 AM, David Woolley wrote:
Kennedy, Paul wrote:
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPSTime/UTC offset (amongst other things).
http://en.wikipedia.org/wiki/GPS_signals
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'
Martin Burnicki wrote:
> What you say sounds also reasonable. However, the requirement for the
> minimum pulse length should only depend on on the pulse length the UART
> requires to detect the slope at the DCD input, which should be *much*
> less than 100 ms. So my comment was just a little bi
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 31/10/2012 10:34, Martin Burnicki wrote:
[]
Under Linux, header files are usually provided by separate packages
since you don't need them unless you compile your own software.
[- much useful information snipped-]
Since the header file will bypass the package management the file should
be c
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
Rob wrote:
Martin Burnicki wrote:
Rob wrote:
David Taylor wrote:
You need to add a circuit to stretch the narrow pulse into a 100ms
pulse. The exact duration is not important. Just arrange for a
monostable multivibrator that gets triggered by the rising edge
of the pulse and extends the pul
Martin Burnicki wrote:
> Rob wrote:
>> David Taylor wrote:
>> You need to add a circuit to stretch the narrow pulse into a 100ms
>> pulse. The exact duration is not important. Just arrange for a
>> monostable multivibrator that gets triggered by the rising edge
>> of the pulse and extends the p
Rob wrote:
David Taylor wrote:
You need to add a circuit to stretch the narrow pulse into a 100ms
pulse. The exact duration is not important. Just arrange for a
monostable multivibrator that gets triggered by the rising edge
of the pulse and extends the pulse by R/C time. Make sure the pulse
David Woolley wrote:
Kennedy, Paul wrote:
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPSTime/UTC offset (amongst other things).
http://en.wikipedia.org/wiki/GPS_signals#Almanac
I think he k
David Taylor wrote:
On 29/10/2012 15:09, John Hasler wrote:
David Taylor writes:
if I try and compile with the flags for automatic start-up the make
fails due a missing file: sys/capability.h. Happens with both 4.2.6p5
and 4.2.7p314.
Install the linux-headers package appropriate to your kern
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Rob wrote:
>> The main point is that the local clock is not supposed to be broken.
>>
>> It worked OK years ago when I implemented it, and I wonder what has
>> changed now so that it no longer works. Maybe a change in the Trimble
>> firmware or
Rob wrote:
The main point is that the local clock is not supposed to be broken.
It worked OK years ago when I implemented it, and I wonder what has
changed now so that it no longer works. Maybe a change in the Trimble
firmware or a change in gpsd (although I do not see that in the git
browser).
David Woolley wrote:
> Kennedy, Paul wrote:
>> I believe the answer to your question is 12.5 minutes.
>>
>> This is the time it takes to receive the full set of 25 almanac frames,
>> which contains the GPSTime/UTC offset (amongst other things).
>>
>> http://en.wikipedia.org/wiki/GPS_signals#Alma
Kennedy, Paul wrote:
I believe the answer to your question is 12.5 minutes.
This is the time it takes to receive the full set of 25 almanac frames,
which contains the GPSTime/UTC offset (amongst other things).
http://en.wikipedia.org/wiki/GPS_signals#Almanac
I think he knows the time taken fo
30 matches
Mail list logo
