Troubleshooting, Debugging, and More!¶

This section lists some potential pitfalls, solutions to issues and helpful tips for each of the steps on the manual installation page.

Note

This help page follows the same format as Manual Installation Instructions. Each step here corresponds to the same step on the instruction page.

Board and Lure Setup¶

This step is fairly dependent on the environment, but be sure that everything is plugged in properly and switched on. Also be sure that the GPS is getting a good signal. A clear shot of the sky from the onboard or an external antenna is ideal, however even an antenna on a windowsill will usually get a lock. Patchy locks have been known to cause occasional anomalies, however NTPD will usually ignore this data or correct it.
OS installation instructions are easy to find online and most issues have been resolved. One issue specific to MinnowBoard which sometimes arises is that SD cards will not appear on the boot menu, making booting from and SD card impossible. If this issue arises, try installing to a SATA hard drive. Alternatively, use a large flash drive to make a persistent Linux boot environment. This will allow for any changes made to the OS or files to stay with the flash drive upon reboot.
Rather than type sudo before most of these commands, it is typically easier to type sudo -s and run all the commands from a root standpoint. Remember to re-run this command after every reboot during the installation process. Also verify the internet connection before trying to install any of these packages.

Setting up the Pulse Per Second¶

The best practice is to copy and paste long URLs to avoid typos. Also note that the nano command will open an empty file unless the specified file is in the current directory, or it has an address.

If the kernel version ever changes, it may be necessary to repeat steps 1.3-2.5.
A list of GPIO pin numbers can be found on the MinnowBoard website under the board section. Check the Linux kernel version to determine which number is correct for a given OS as older kernels use different numbers. To check the kernel version, either check the folder name in the modules folder or run uname -a in terminal.
Make sure the line added has nothing else on it. Also be sure to reboot the system for changes to take effect.
At this step, if the PPS entry is not showing up, it is likely that the GPIO pin was incorrect.
The 20150721 number on each line is the version number, which can be found inside the dkms.conf file. Should these commands result in an error, it is possible that the package has updated and that number (the date of publish) changed.

Note that modprobe needs to be run every time the system starts up.

If the dmesg command did not give similar output, check the modprobe and driver installation. The lack of results means the PPS signal is not being routed from the GPIO pin to pps0.

If the PPS test keeps printing out a timeout error for more than 20 minutes or so, but the dmesg command is working, and it is identifying a PPS pin, there might be an error with the PPS output itself. Check that it is working by using an oscilloscope
The PPS should show up in ntpq immediately after the restart of NTP, however it might show all zero values. As long as the PPS test worked, this is normal and nothing to worry about. The PPS will be zero until it has a clock to reference itself from, such as the GPS clock or internet clock.

Setting up the GPS¶

The Serial port for devices not using the Lure can be found on the MinnowBoard website. Other GPS modules might use different baud rates.
If the GPS is not on Serial port 4, change ttyS4 to reflect that. Also note that this step needs to be performed every boot.
On the fudge line for the GPS, time2 XX.XX can help offset the GPS time. This improves accuracy by accounting for processing lag time. After a while, running ntpq -p might show that the GPS offset is consistent. If this happens, add a time2 offset roughly equal and opposite in sign to the observed offset. Note, though, that adding an offset may require the full MinnowBoard to be shut down and the GPS to be turned off to take full effect (remove the power).
If the GPS is not in the list, or it is not printing any times, check the system log by running:
```
cat /var/log/syslog
```
Towards the bottom few lines, if the log contains apparmor = DENIED, then apparmor is blocking NTPD. To fix this, run:
```
nano /etc/apparmor.d/usr.sbin.ntpd
```
Scroll to the bottom and add capability ipc_owner, then save the file. Restart NTPD and the error should be gone.
Be sure to either manually re-run the needed linking commands after reboot or added a script to the rc.local file before rebooting. The system will now attempt to sync the GPS with the PPS. This takes quite some time usually. During the first 5 minutes, give or take, ntpq -p may output all zero values for the PPS and/or GPS. After a few minutes, actual values will appear in the offset and jitter columns. These will fluctuate greatly as they hone in on a stable value.

It can be helpful to run a script to automatically run the ntpq -p command periodically to check the clock locking and tuning process. Here is a script which runs the command every 15 seconds.
```
#!/bin/bash
clear
while true; do
ntpq -p
sleep 15
done
```

Broadcasting the Time¶

Do not use the device IP address, use the broadcast IP address for this to work properly. If other computers will directly link to the MinnowBoard, then use the IP address of the MinnowBoard.
Note that a network device which is using the broadcast address will not show up in the list of connected clients, however one that is directly connected to the MinnowBoard will.

Final Steps¶

The script may run when the MinnowBoard shuts off. This is normal.
When the device reboots, check in /dev/ to see if the pps0 and gps0 devices are present. If yes, the boot script worked. If not, the rc.local file did not run the script. Check for typos as any error will prevent it from working.