Date: Wed, 31 Jul 2019 17:22:56 +0100 From: Kaya Saman <kayasaman@optiplex-networks.com> To: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! Message-ID: <20926ddd-425d-601c-0d8d-46bb480f61ff@optiplex-networks.com> In-Reply-To: <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <c601f08c4b3f1ad7beed5465622df37f583f844e.camel@freebsd.org> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/31/19 4:32 PM, Ian Lepore wrote:
> On Wed, 2019-07-31 at 16:17 +0100, Kaya Saman wrote:
>> On 7/31/19 3:06 PM, Ian Lepore wrote:
>>> On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote:
>>>> On 7/31/19 1:42 AM, Ian Lepore wrote:
>>>>> On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote:
> [...]
>>>> I am seeing this:
>>>>
>>>> gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @
>>>> 1564579823.472659791
>>>> gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime
>>>>
>>>>
>>>> Perfect ;-)
>>>>
>>>>
>>>> I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is
>>>> inverted.
>>>>
>>>>
>>>> This setup was working previously using a Prolific Serial to USB adapter
>>>> for testing purposes as of course the USB introduces high latency.
>>>>
>>> Actually, not so much as you'd think. I expected both high latency and
>>> a lot of jitter when using a usb-serial for PPS, and what I found was a
>>> fixed latency of less than a millisecond and jitter on the order of 60-
>>> 80 microseconds. Even trying to saturate the usb bus by doing
>>> continuous or bursty IO to a disk drive didn't noticibly increase the
>>> pps latency or jitter. I was pretty surprised.
>>>
>>> -- Ian
>>>
>>>
>> That's very interesting!
>>
>>
>> My finding was that the accuracy went from the 10's of uS using a
>> standard RS232 D-Sub port on one of my x64 systems to the 100's of uS
>> range when switching to the Pine64 and using the USB->Serial adapter.
>>
>>
>> Looks like the PPS signal just kicked in:
>>
>>
>> gpsd:PROG: KPPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @
>> 1564585351.860177245
>> gpsd:PROG: PPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @
>> 1564585351.860177245
>> gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled
>> gpsd:PROG: KPPS:/dev/gps1 assert 1564585352.060170121, sequence: 5543,
>> clear 1564585351.860177245, sequence: 5543 - using: assert
>> gpsd:PROG: KPPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @
>> 1564585352.060170121
>> gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @
>> 1564585352.060170121
>> gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge
>>
>>
>> After stopping the gpsd service and restarting it's finding it difficult
>> to startup again. I attempted with dev.uart.4.pps_mode=0x21 for 'narrow'
>> pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessing.
>>
>>
>> Once I understand a little bit more about the behavior and quirks of the
>> setup I'll probably start looking at how to enable an input switch on a
>> GPIO pin then trying to get/write a driver for lcdproc and the Newhaven
>> display. The aim is to use the retractive mechanical switch to change
>> the LCD display from clock to GPS info....
>> / {
>> pps@0 {
>> compatible = "pps-gpio";
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_pps0>;
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */
>> status = "okay";
>> };
>> };
>>
>> The gpios= property will need to refer to the right bank and
>>
>> Still lots of work to go but it's definitely a really fun project :-)
>>
>>
>> Regards,
>>
>>
>> Kaya
> I've never used gpsd and don't know how to interpret its output.
> Narrow-pulse mode is for pulses down in the few-microseconds range
> (professional timekeeping equipment often has very short pps pulses, in
> the 1-100us range).
Ok then I don't need to use it as my receiver isn't capable of anything
below 20ms-1
http://static.garmin.com/pumac/GPS_18x_Tech_Specs.pdf
>
> I've always been uneasy with the idea of using CTS for a pps signal,
> since the uart hardware itself may want to use that line. I wonder if
> it would help to use the .lock device to force off rtscts flow control?
I could try this though I'm not sure how to go about it. Would this be
performed by the stty command? Currently -ixon is set on the port so
that makes output control disabled. I could also try setting -ixoff to
disable the input queue....
>
> Or, maybe even better, instead of using that pin as a uart cts signal,
> maybe redo the pinmux to make it a gpio pin, then use the standard
> gpiopps driver. You might need to add a symlink from /dev/gpiopps0 to
> /dev/gps1 or whatever gpsd expects.
>
> I'm not sure how to do the pinmux node for a gpio pin on that hardware,
> but you can probably find an example of that. The dts source to enable
> a gpio pin for pps is:
>
> / {
> pps@0 {
> compatible = "pps-gpio";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pps0>;
> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */
> status = "okay";
> };
> };
>
> The gpios= property will need to refer to the right bank and pin number
> for that hardware.
>
> -- Ian
>
This might work better. I'll have a go later today. I did have issues
while trying things out on Armbian so I don't know if it will the same
case with FreeBSD. Virtually what happened was that setting the pin in
the loader didn't take effect.
Thanks again Ian :-)
Best Regards,
Kaya
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20926ddd-425d-601c-0d8d-46bb480f61ff>