Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example of hardware-based 1Hz signal #384

Open
jphickey opened this issue Mar 28, 2023 · 2 comments
Open

Add example of hardware-based 1Hz signal #384

jphickey opened this issue Mar 28, 2023 · 2 comments
Labels
enhancement New feature or request Equuleus-rc3 Priority: Mission Feature or bug related to stakeholder needs

Comments

@jphickey
Copy link
Contributor

Is your feature request related to a problem? Please describe.
A few releases back the 1Hz configuration was changed to be initiated by CFE TIME itself, rather than started by the PSP. This was done in order to resolve a race condition where the signal arrived before CFE TIME was ready to process it.

However, as a result, we no longer have a good example of a "real" hardware-based 1PPS/1Hz signal driving the CFE TIME 1Hz input, as the current example uses a software kernel timer only.

Describe the solution you'd like
Create an alternative to the soft_timebase module that reads a 1PPS signal from an external reference such as a serial port - as a number of GPS receivers do use a serial line to provide 1PPS along with location data. This probably still wouldn't be directly usable but it would at least provide a (closer) example of how this could be achieved, that the user could modify for their particular setup.

Describe alternatives you've considered
There are two other ways this could be synced:

  1. Use an external process like gpsd to sync the kernel clock to the 1PPS, then use soft_timebase as-is. The result is that the 1Hz TIME signal will be in phase with the reference signal, but it won't occur at the same time. This phase delay may or may not acceptable depending on the application. This does have the advantage of having only a single time domain across the entire system (kernel/OS clocks and timers will all be synchronous with the GPS time) and it is totally transparent to apps - they just read time as normal.
  2. Use an external sync routine (last argument to OS_TimeBaseCreate to wait for the 1PPS. This is similar to 1 but easier to implement (no external dependencies) however the result will be more jittery and apps must know that this timebase may not be synchronous with the OS/kernel clock.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey added the CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) label Mar 28, 2023
@jphickey
Copy link
Contributor Author

Marking as item for discussion

@jphickey jphickey added the enhancement New feature or request label Mar 28, 2023
@dzbaker dzbaker added Priority: Mission Feature or bug related to stakeholder needs Equuleus-rc3 and removed CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) Equuleus-rc2 labels Jan 4, 2024
@CDKnightNASA
Copy link

I think a RTC module for a Raspberry Pi would be a reasonable target for an example. Such as the I2C module: https://www.adafruit.com/product/3386#technical-details

This uses the RTC chip, which includes three timers (see section 8.9):
https://www.nxp.com/docs/en/data-sheet/PCF8523.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Equuleus-rc3 Priority: Mission Feature or bug related to stakeholder needs
Projects
None yet
Development

No branches or pull requests

3 participants