phoenix-9 / es100-shm

NTP shared memory driver for es100 WWVB BPSK receiver
3 stars 1 forks source link

Question: #1

Open deanf5 opened 3 years ago

deanf5 commented 3 years ago

Hi phoenix-9,

I tried to run this to synchronise my rpi but ran into a problem of setting up the options. Could you please clarify (or share an example) on what the format is for the following statement:

Just run it. It needs one or two command line options to tell the program which shared memory segment to use, or to use a unix socket (or both).

Thank you for your time.

phoenix-9 commented 3 years ago

You need to be running ntpd or chrony.

With nptd you need to use the shared memory diver (SHM). In your configuration file for ntpd you would specify a unit number. This has to match the unit number that the es100 program uses. For example, if you use unit 0 in your ntpd config file, your your run “es100-shm -s 0”

If you use a chrony socket, you would configure it in your crony.conf file something like: “refclock SOCK /path/to/socket” and you would run “es100-shm -c /path/to/socket”

If you give some more information on your setup, I can try and be more helpful. What program are you running to sync time? ntp, ntpsec, chrony?

What does your config file look like now?

If you run es100-shm with no options, you should get some information logged to syslog. It will try to read the time from the es-100 chip. Does that work? In other words, is the es100-shm program able to successfully use i2c and the GPIOs? Are the electrical connections correct? You may need to change the GPIO numbers to suit your needs.

Cheers,

Marc

On Aug 12, 2021, at 6:01 PM, deanf5 @.***> wrote:

Hi phoenix-9,

I tried to run this to synchronise my rpi but ran into a problem of setting up the options. Could you please clarify (or share an example) on what the format is for the following statement:

Just run it. It needs one or two command line options to tell the program which shared memory segment to use, or to use a unix socket (or both).

Thank you for your time.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/phoenix-9/es100-shm/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOU6MDOI52YSDYDCA5TFPTT4RHF7ANCNFSM5CCLVUXA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

deanf5 commented 3 years ago

Hi Marc,

Thank you for the reply.

I am using ntpd to synchronise my pi. I was hoping to make radio clock an alternative to my gps as a time source for my pi.

Here is the conf file I am using at the moment:

`

radio clock

server 127.127.28.13 mode 0 prefer fudge 127.127.28.13 refid WWVB flag1 1

gps - pps-gpio /dev/pps0

server 127.127.22.0 minpoll 17 maxpoll 17 fudge 127.127.22.0 refid PPS

gps

server 127.127.28.0 minpoll 17 maxpoll 17 prefer fudge 127.127.28.0 time1 +0.130 refid GPS flag1 1 `

I tried to do "./es100-shm -s 0", and looked at the systemlogs, it says Not using Shared Memory and Not using Chrony Socket. and then the program seems to end as no other logs are produced. Same logs are produced when I run the above command again.

I would greatly appreciate any feedback on how I can make this work.

Thank you for your time.

phoenix-9 commented 3 years ago

On Aug 18, 2021, at 12:13 PM, deanf5 @.***> wrote:

radio clock

server 127.127.28.13 mode 0 prefer fudge 127.127.28.13 refid WWVB flag1 1

How did you pick “13”? The 13 is the “unit number”. It needs to match in both programs (ntpd and es100-shm). Usually you would use 0, but I see you are using it for gpsd. So then I would use unit 1. If gpsd and es100-shm are both trying to write to unit 0, unpredictable things may happen. I tried to do "./es100-shm -s 0", and looked at the systemlogs, it says Not using Shared Memory and Not using Chrony Socket. and then the program seems to end as no other logs are produced. Same logs are produced when I run the above command again.

I’m not sure how that is possible. if you use “-s 0” it should not say “Not using shared memory”.

Are there any other entries in the syslog?

Does anything print on stdout after you run the command?

The program is designed to fork into the background. So it’s normal for it to return to the command line after you run it. But it should still be running in the background. You can check with “ps x”.

Are you running the program as root? There might be an issue with permissions.

Marc

I would greatly appreciate any feedback on how I can make this work.

Thank you for your time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/phoenix-9/es100-shm/issues/1#issuecomment-901285687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOU6MBQOA5NRMLLYW74SJTT5PS2JANCNFSM5CCLVUXA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

deanf5 commented 3 years ago

Hey Marc,

Thank you for your reply. You are right I can see output on the logs when I do ./es100-shm -s 13:

es100 started Set up shared memory unit 13. not using chrony socket

and then nothing. I ran "ps - x" and didn't see the program in the list. I added a few syslog statements and realised that the code exits at the first step of setting up GPIO:

' if( (mc_gpio_chip = gpiod_chip_open_lookup( GPIO_CHIP)) == NULL) exit(EXIT_FAILURE); '

mc_gpio_chip comes out null. Have you come across this issue while running this on a raspberry pi ?

Thank you for your time.

Edit:

I did gpiodetect to findout that the GPIO_CHIP name has changed to pinctrl-bcm2711 which allowed the code to move forward till it stopped at Failed gpiod_line_event_wait(). Could you please clarify what this means?

phoenix-9 commented 3 years ago

I assume you tried running as root, so it’s not a permissions problem.

Looks like you can’t open the gpio device.

On my RPI1B, the chip was called pinctl-bcm2835. Maybe it’s different for you.

define GPIO_CHIP "pinctrl-bcm2835”

Let’s troubleshoot using command line utilities. Install gpiodetect using whatever method works for your linux distribution. "apt install gpiod” for Debian.

run gpiodetect and let me know what it says. Something like:

gpiodetect

gpiochip0 [pinctrl-bcm2835] (54 lines) marc

On Aug 19, 2021, at 1:19 PM, deanf5 @.***> wrote:

Hey Marc,

Thank you for your reply. You are right I can see output on the logs when I do ./es100-shm -s 13:

es100 started Set up shared memory unit 13. not using chrony socket

and then nothing. I ran "ps - x" and didn't see the program in the list. I added a few syslog statements and realised that the code exits at the first step of setting up GPIO:

' if( (mc_gpio_chip = gpiod_chip_open_lookup( GPIO_CHIP)) == NULL) exit(EXIT_FAILURE); '

mc_gpio_chip comes out null. Have you come across this issue while running this on a raspberry pi ?

Thank you for your time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/phoenix-9/es100-shm/issues/1#issuecomment-902137726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOU6MEYPI3HYROUZVJOJ5TT5VDJTANCNFSM5CCLVUXA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

deanf5 commented 3 years ago

Hey Marc,

Thank you for the reply.

I edited my previous comment to clarify I was able to change the CHIP name, I am working on rpi4 and hence had to change it to pinctrl-bcm2711 which allowed the code to move forward till it stopped at Failed gpiod_line_event_wait(). Could you please clarify what this means? Looking at the code, it looks like it failed because it times out waiting for the irq signal. Is the expectation that it should get an interrupt every 0.18 seconds? Because my desk does not get very clear reception of the WWVB signal.

Thank you for your time.

phoenix-9 commented 3 years ago

It’s supposed to wait 180 seconds (not milliseconds). That’s the longest it should take for the reception of a 1 minute frame.

Could be a couple of things. The IRQ pin is not electrically connected properly. Or the number of the GPIO for the IRQ is not correct.

define GPIO_IRQ 4

Or the ES100 never received the I2C message to start reception (less likely).

Cheers,

Marc

On Aug 19, 2021, at 4:45 PM, deanf5 @.***> wrote:

Hey Marc,

Thank you for the reply.

I edited my previous comment to clarify I was able to change the CHIP name, I am working on rpi4 and hence had to change it to pinctrl-bcm2711 which allowed the code to move forward till it stopped at Failed gpiod_line_event_wait(). Could you please clarify what this means? Looking at the code, it looks like it failed because it times out waiting for the irq signal. Is the expectation that it should get an interrupt every 0.18 seconds? Because my desk does not get very clear reception of the WWVB signal.

Thank you for your time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/phoenix-9/es100-shm/issues/1#issuecomment-902269354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOU6MHYOUEW37ARKCYYWNTT5V3QPANCNFSM5CCLVUXA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

deanf5 commented 3 years ago

Hi Marc,

Thank you for the message.

I had to play around with the pins and used gpioinfo to find that pin 17 was being used by pps or something similar which was why IRQ was not working. I have now made irq to 4 and enable to 27 (1 pin below gpio17) and was able to reach the while loop that searches for the signal.

I think I was able to capture a complete signal according to the syslogs but I do not see ntp or system time update update and no changes to ntpq -q (all zeros). Is there a requirement that the time has to be close to a certain limit? Because when I start my pi, the time sets to 2019 Feb 10 3:12 and was hoping after a signal fix, the radio clock would push it to the right time. That is what my GPS does when i setup my pi with the gps and was hoping radio clock could do the same.

Thank you for your help!