PPS Beaglebone Black Glued Dune

[Bjørn Spockeli]

Hi,

Im using a uBlox EVK-6T GPS receiver that has a 1PPS output that I would like to connect to the BeagleBone Black running glued and dune. Looking on the Dune Github page there is already a PPS task under Sensors and Hardware, with Sensors.PPS Task  taking  "PPS Device" as input. THis is in turn  used by Hardware.PPS that tries to find the source by using the supplied "path" name. Searching for PPS on the glued github page and found what seems to be a dedicated PPS pin, gpio2_13. 

What I would like to know is:

1.  Does /dev/pps0 refer to gpio2_13?
2. Do I connect the PPS output to this pin?
3. Should I give /dev/pps0 as the path name to Sensors.PPS?
   

 

 

Regards,
Bjørn

[Ricardo Martins]

Hi Bjørn,

On Mon, Jan 19, 2015 at 4:35 PM, Bjørn Spockeli <bjorn.s...@gmail.com> wrote:

Hi,

Im using a uBlox EVK-6T GPS receiver that has a 1PPS output that I would like to connect to the BeagleBone Black running glued and dune. Looking on the Dune Github page there is already a PPS task under Sensors and Hardware, with Sensors.PPS Task  taking  "PPS Device" as input. THis is in turn  used by Hardware.PPS that tries to find the source by using the supplied "path" name. Searching for PPS on the glued github page and found what seems to be a dedicated PPS pin, gpio2_13. 

What I would like to know is:

1.  Does /dev/pps0 refer to gpio2_13?

Yes.

 

1. Do I connect the PPS output to this pin?

Yes, but make sure you are connecting the 3.3V PPS not the one on the DB9 connector.

 

1. Should I give /dev/pps0 as the path name to Sensors.PPS?
   

Yes. But I have written that task for a specific purpose, not sure if it does what you need. There's another implementation, in DUNE's branch feature/pps that uses a slightly different approach to the problem and produces better results. In this revised implementation the PPS is used by the kernel (Hard PPS) to synchronize the system clock with the PPS pulse, this means that in one or two seconds after the PPS is applied and stable the monotonic system clock will be aligned to the PPS with a few microseconds of offset. Once this is achieved we can then steer the non-monotonic system clock to the UTC time. I think I got sidetracked by something else and didn't implement the part of setting the UTC time, but it shouldn't be very hard to do that. Do you want to share your use case ?

 

 

 

Regards,
Bjørn

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/3b1f441c-de2b-46cb-9927-a6aa9982644c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bjørn Spockeli]

Hi Ricardo, 

What I want to do is:

1) Find the processing + transmission delay of the GPS receiver  the by comparing the timestamp of the Pulse Message and the GPS_Fix Message.

2) Log Attitude, Acceleration, PPS  and  Gps IMC Messages and use the PPS to align the senor measurements

Im aware that the Sensors.PPS does not synchronize the system clock to UTC time, but I have been using it because it sends the IMC::Pulse message. If the system clock can be synchronized to UTC and the PPS signal logged, that would be great!

[Ricardo Martins]

Hi Bjørn,

On Wed, Jan 28, 2015 at 1:17 PM, Bjørn Spockeli <bjorn.s...@gmail.com> wrote:

Hi Ricardo, 

What I want to do is:

1) Find the processing + transmission delay of the GPS receiver  the by comparing the timestamp of the Pulse Message and the GPS_Fix Message.

2) Log Attitude, Acceleration, PPS  and  Gps IMC Messages and use the PPS to align the senor measurements

Im aware that the Sensors.PPS does not synchronize the system clock to UTC time, but I have been using it because it sends the IMC::Pulse message. If the system clock can be synchronized to UTC and the PPS signal logged, that would be great!

The branch I talked about is better for you use case. Even if the clock is not synchronized to UTC you will know that the start of the second will be the same for the CPU and for the GPS. I will revive the branch as soon as possible and will keep you posted.

 

tirsdag 27. januar 2015 22.30.39 UTC+1 skrev Ricardo Martins følgende:

Hi Bjørn,

On Mon, Jan 19, 2015 at 4:35 PM, Bjørn Spockeli <bjorn.s...@gmail.com> wrote:

Hi,

Im using a uBlox EVK-6T GPS receiver that has a 1PPS output that I would like to connect to the BeagleBone Black running glued and dune. Looking on the Dune Github page there is already a PPS task under Sensors and Hardware, with Sensors.PPS Task  taking  "PPS Device" as input. THis is in turn  used by Hardware.PPS that tries to find the source by using the supplied "path" name. Searching for PPS on the glued github page and found what seems to be a dedicated PPS pin, gpio2_13. 

What I would like to know is:

1.  Does /dev/pps0 refer to gpio2_13?

Yes.

 

1. Do I connect the PPS output to this pin?

Yes, but make sure you are connecting the 3.3V PPS not the one on the DB9 connector.

 

1. Should I give /dev/pps0 as the path name to Sensors.PPS?
   

Yes. But I have written that task for a specific purpose, not sure if it does what you need. There's another implementation, in DUNE's branch feature/pps that uses a slightly different approach to the problem and produces better results. In this revised implementation the PPS is used by the kernel (Hard PPS) to synchronize the system clock with the PPS pulse, this means that in one or two seconds after the PPS is applied and stable the monotonic system clock will be aligned to the PPS with a few microseconds of offset. Once this is achieved we can then steer the non-monotonic system clock to the UTC time. I think I got sidetracked by something else and didn't implement the part of setting the UTC time, but it shouldn't be very hard to do that. Do you want to share your use case ?

 

 

 

Regards,
Bjørn

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/3b1f441c-de2b-46cb-9927-a6aa9982644c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.

To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/bc56e9f9-cf6e-445e-b25e-0f295f1e8bbf%40googlegroups.com.

[Bjørn Spockeli]

Hi Ricardo,

Im still using the uncompleted PPS function, trying to find my GPS receiver processing delay and by comparing the timestamps of the logged GpsFix and Pulse messages gives me a delay of about 0.095s.
If I measure directly on output of the GPS with an oscilloscope the delay ( defined by the time from the rising edge of PPS pulse to the last falling edge of the first data packet after the pulse ) is at least 0.140s 

Does the timestamp of the IMC::Pulse message correspond to the rising edge of the PPS? If not is there any way to achive this?

Regards
Bjørn

fredag 30. januar 2015 11.18.13 UTC+1 skrev Ricardo Martins følgende:

Hi Bjørn,