Set via two procedures as below.
Use dpkg-reconfigure as an alternative
# sudo dpkg-reconfigure tzdata
https://linuxize.com/post/how-to-set-or-change-timezone-on-ubuntu-18-04/
--30--
Showing posts with label time. Show all posts
Showing posts with label time. Show all posts
Sunday, January 17, 2021
Sunday, January 20, 2019
configuration notes for beaglebone pocket
local link to BBB if connected (presented for convenience).
http://192.168.7.2/bone101/Support/bone101/
This will probably apply to the beaglebone black (wireless) which will be used in the Unibone project that is in the queue.
This has some number of extra complications since it has a USB OTG connection for power and also presents a USB networking adapter via that conduit to the host.
This allows for a very interesting control interface via the web, but makes it a bit tricky to
get to the internet with the pocket (since it has no network NIC).
The first few notes here are for configuring the network, setting up ssh.
The default login is debian for the system, which is default for the debian releases.
The network router / gateway address is 192.168.7.1, and 192.168.7.2 is the IP for the debian board on the other side of the USB. On windows at least, the win 10 automagically recognized the connection, created an eth instance for the USB NDIS nic and the ip 192.168.7.1 is visible there.
Login worked to the 192.168.7.2 as advertised.
The time page below doesn't use Debian, so such as installing software must be translated to debian commands. The page's example uses Angstrom (which is advertised on the BBB images).
Also it did not include the incantation for getting the time to be set. ntp was not in the downloaded debian image used, so one must use some way to get the time to set.
http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/
I also wanted to set the timezone. Not sure how one would do it on the Angstrom release, but on debian, the dpkg reconfigure worked as usual.
dpkg-reconfigure tzdataThis page has info for making Windows 7 host the network connection.
https://ofitselfso.com/BeagleNotes/HowToConnectBeagleboneBlackToTheInternetViaUSB.php
Will research how to use a raspberry pi W or such linux system to host this, with possibly less foolishness with the network setup on the hosting system end. With windows not sure how much has to be redone everytime the system starts and stops.
Also since this will be frequently used on a windows laptop, not sure whether the whole thing will survive suspend, even if the BBB pocket is turned off prior to the exercise of suspending.
Eventually setting up a raspberry pi zero as a router would be valuable as it could also present an IP and make it accessible by natting the connection used by the BBB.
***********************
Hosting system + network with a linux host:
https://elementztechblog.wordpress.com/2014/12/22/sharing-internet-using-network-over-usb-in-beaglebone-black/
The Debian OS is used for the testing which is obtained from here.
BBB console can be obtained by using the following command
ssh 192.168.7.2 -l root ifconfig usb0 192.168.7.2
route add default gw 192.168.7.1
In the linux console of host system type
sudo su #wlan0 is my internet facing interface, eth5 is the BeagleBone USB connection
ifconfig eth5 192.168.7.1
iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
iptables --append FORWARD --in-interface eth5 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
To set up a domain use the following (example uses pri domain):
domain pri
search pri
nameserver 10.192.168.1
nameserver 8.8.8.8
***********************
Other links of use:
getting started
How to Connect a BeagleBone Black to the Internet Using USB
discussion for Armbian, but some good info on USB OTG as a tether.
USB OTG as a network - Development - Armbian forum
Announcing $25 PocketBeagle - Google Groups (link into GG discussions)
BeagleBoard.org - latest-images
eLinux org links
BeagleBoardDebian - eLinux.org
--30--
Wednesday, January 2, 2013
Ntp on the Raspberry pi
http://www.talkunafraid.co.uk/2012/12/the-ntpi-accurate-time-with-a-raspberry-pi-and-venus638flpx/
Includes building the source to reconfigure the use of the Pi serial port, besides building a time server with the pi.
The ntpi: accurate time with a Raspberry Pi and Venus638FLPx
One of the things I’ve always loved to tinker with is time sources
and synchronization. Typically this has been tied to sensible things
like the Network Time Protocol and designing and maintaining time
distribution systems for broadcast networks. Lately though I’ve been
toying with ‘real’ time sources – GPS and MSF broadcasts. This is a
quick tutorial on how to set up a Raspberry Pi, which at only a few
watts makes for an economical time server, to talk to a Venus 638FLPx
GPS receiver (available from Sparkfun on a suitable breakout board here).
It’s worth noting that the GPS chip in question is not really ideal for timing applications. There are nicer boards for this purpose. But the great thing is that because most of these things are pretty standard, almost all this guide will still work. Venus do make an IC, the 638LPx-T, which is a variant of this chip designed for timing with an accuracy of plus/minus 30us, but I can’t find that on a breakout board and I had the FLPx board spare from a UAS platform.
The basic requirements for a GPS time source/server are:
The tricky bit comes with the software. Let’s talk about how GPS time sourcing works.
The GPS satellites rely on highly accurate timing, and broadcast UTC time information as part of their signals. The difference in the timestamps is what, largely, allows your receiver to figure out where you are. If you know where you are, though, you can use those timestamps to come up with a very accurate fix for time.
The NMEA strings that come off the GPS describe all sorts of things. They look a bit like this:
Sadly this won’t get us a very accurate reference. Let’s look at what the PPS looks like, for starters, with an oscilloscope:
We can see quite clearly these are small, 5ms pulses exactly once a second. Great! So how about those NMEA strings being sent over serial?
We can see in the top half of this trace a full NMEA transmission occurring just after (1.18ms) the PPS pulse – but the NMEA transmission is huge! And if we follow it, we see it move around, too.
This is a zoomed in view of a PPS pulse against the NMEA transmission (1.6ms after the pulse, this time – plenty of variance). This was taken with the GPS in ‘send NMEA in sync with PPS’ mode!
So if we want to get our device accurate we need to use PPS. But if we just use PPS, we don’t know which second we’re in! So we have to use both. Fortunately, ntpd will manage this for us.
Diving back to the software, then – we need a kernel that can deal with the PPS pulses on our GPI port. Let’s install one:
Next up: telling ntp about this shiny new local clock!
We need to do one thing first – if your local network has a DHCP server that announces time servers, you want to use your local NTP config despite this. You need to edit /etc/init.d/ntp and comment the following lines out:
Restart ntpd, wait a few minutes for it all to settle down, and verify things are working:
You really, really want to make sure your system is using the PPS, is what I’m getting at.
Another thing I ran into was the GPS reporting the wrong time or not reporting its timing offset – just ensure you have enabled the GPZDA statement to avoid this. Symptoms of this can include huge offsets and being marked as a falseticker (x) in peer lists of other peers. Just make sure your module is configured properly. This is what I did to configure my module:
It’s worth noting that the GPS chip in question is not really ideal for timing applications. There are nicer boards for this purpose. But the great thing is that because most of these things are pretty standard, almost all this guide will still work. Venus do make an IC, the 638LPx-T, which is a variant of this chip designed for timing with an accuracy of plus/minus 30us, but I can’t find that on a breakout board and I had the FLPx board spare from a UAS platform.
The basic requirements for a GPS time source/server are:
- GPS module which outputs NMEA strings on serial and has a 1PPS output
- Computer with GPI pin for 1PPS and serial connectivity running Linux
- GPS antenna in a place that can see a good chunk of sky with a feed back to the module
The tricky bit comes with the software. Let’s talk about how GPS time sourcing works.
The GPS satellites rely on highly accurate timing, and broadcast UTC time information as part of their signals. The difference in the timestamps is what, largely, allows your receiver to figure out where you are. If you know where you are, though, you can use those timestamps to come up with a very accurate fix for time.
The NMEA strings that come off the GPS describe all sorts of things. They look a bit like this:
pi@ntpi ~ $ cat /dev/gps0 $GPGGA,201705.000,5644.4848,N,00142.3529,W,1,10,0.9,64.4,M,49.0,M,,0000*75 $GPGLL,5644.4848,N,00142.3529,W,201705.000,A,A*43 $GPGSA,A,3,07,26,08,19,15,05,09,21,18,24,,,1.5,0.9,1.2*3B $GPZDA,201705.000,29,12,2012,00,00*5EThey’re a bit obscure but they have the time encoded into them along with things like how many satellites are used in the solution, velocity/heading, and so on. The first chunk, $GPGGA for instance, is a preamble for each string – the last three characters are used to refer to a string of that type, eg GGA.
Sadly this won’t get us a very accurate reference. Let’s look at what the PPS looks like, for starters, with an oscilloscope:
We can see quite clearly these are small, 5ms pulses exactly once a second. Great! So how about those NMEA strings being sent over serial?
We can see in the top half of this trace a full NMEA transmission occurring just after (1.18ms) the PPS pulse – but the NMEA transmission is huge! And if we follow it, we see it move around, too.
This is a zoomed in view of a PPS pulse against the NMEA transmission (1.6ms after the pulse, this time – plenty of variance). This was taken with the GPS in ‘send NMEA in sync with PPS’ mode!
So if we want to get our device accurate we need to use PPS. But if we just use PPS, we don’t know which second we’re in! So we have to use both. Fortunately, ntpd will manage this for us.
Diving back to the software, then – we need a kernel that can deal with the PPS pulses on our GPI port. Let’s install one:
git clone https://github.com/davidk/adafruit-raspberrypi-linux-pps.git cd adafruit-raspberrypi-linux-pps/ sudo mv /boot/kernel.img /boot/kernel.img.orig sudo cp kernel.img /boot sudo mv modules/* /lib/modules sudo sh -c "echo 'pps-gpio' >> /etc/modules"We need to disable the default usage of the Pi’s serial, which is to provide a tty. Open /boot/cmdline.txt and remove all elements referring to ttyAMA0. Mine looks like this:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwaitNext, open /etc/inittab and comment this line out:
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100We also want to configure udev to put our GPS module and PPS where ntpd will expect it to be:
sudo nano /etc/udev/rules.d/80-gps-to-ntp.rules # Change MODE of ttyAMA0 so it is readable by NTP and provide a symlink to # /dev/gps0 KERNEL=="ttyAMA0", SUBSYSTEM=="tty", DRIVER=="", SYMLINK+="gps0", MODE="0666" # Symlink /dev/pps0 to /dev/gpspps0 KERNEL=="pps0", SUBSYSTEM=="pps", DRIVER=="", SYMLINK+="gpspps0", MODE="0666"Next we’re going to install then remove ntpd – we’ll be back with an updated version.
sudo apt-get install ntp sudo apt-get remove ntp sudo apt-get install libcap-devTime to install and compile a PPS-enabled ntpd.
wget http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p340.tar.gz tar zxf ntp-dev-4.2.7p340.tar.gz cd ntp-dev-4.2.7p340/ ./configure --prefix=/usr --enable-all-clocks --enable-parse-clocks --enable-SHM --enable-debugging --sysconfdir=/var/lib/ntp --with-sntp=no --with-lineeditlibs=edit --without-ntpsnmpd --disable-local-libopts --disable-dependency-tracking --enable-ipv6 && make && sudo make installNow we’ve got all this we need to reboot to load the new kernel:
sudo rebootFirst, we can verify that we can see the NMEA sentences:
cat /dev/gps0You should see NMEA strings! Ctrl+C to kill it. Next, let’s test the PPS.
pi@ntpi ~ $ dmesg | grep pps [ 0.000000] Linux version 3.1.9adafruit-pps+ (davidk@bender) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #21 PREEMPT Sun Sep 2 10:57:58 PDT 2012 [ 1.148909] usb usb1: Manufacturer: Linux 3.1.9adafruit-pps+ dwc_otg_hcd [ 14.707851] pps_core: LinuxPPS API ver. 1 registered [ 14.712724] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 14.728437] pps pps0: new PPS source pps-gpio.-1 [ 14.731832] pps pps0: Registered IRQ 108 as PPS sourceLooks like we’re good to go. Check the pps-utils package if you need to verify more completely.
Next up: telling ntp about this shiny new local clock!
We need to do one thing first – if your local network has a DHCP server that announces time servers, you want to use your local NTP config despite this. You need to edit /etc/init.d/ntp and comment the following lines out:
#if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then # NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp" #fiOpen up /etc/ntp.conf and adjust it to taste. The following stanza should get you up and running:
server 127.127.20.0 mode 24 minpoll 3 maxpoll 4 iburst true prefer fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 flag4 1 time2 0.093The settings here are documented here and can be configured to suit your module. The time2 value may need to be larger (0.4 or so), and you may want to keep or remove the existing servers configured in ntp.conf – or just reconfigure them to be geographically local. You can get an idea of the time2 offset by adding 128 to whatever mode value you’re using, then looking at the timings in /var/log/ntpstats/clockstats after a ntpd restart. Pick the time offset for the first NMEA string seen and there’s your number.
Restart ntpd, wait a few minutes for it all to settle down, and verify things are working:
pi@ntpi ~ $ ntptime
ntp_gettime() returns code 0 (OK)
time d489d596.2b0cfe14 Sat, Dec 29 2012 20:48:22.168, (.168167784),
maximum error 2000 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 2.518 us, frequency 79.473 ppm, interval 1 s,
maximum error 2000 us, estimated error 1 us,
status 0x2007 (PLL,PPSFREQ,PPSTIME,NANO),
time constant 3, precision 0.001 us, tolerance 500 ppm,
pi@ntpi ~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .GPS. 0 l 8 8 377 0.000 0.002 0.004
+ns0.luns.net.uk 157.44.176.4 2 u 63 64 17 44.161 3.389 0.709
-ntp.oceanmediag 192.93.2.20 2 u 5 64 37 34.806 2.048 0.585
+dns1.rmplc.co.u 193.62.22.74 2 u 63 64 17 36.375 2.488 0.282
*mail1.itdojo.or 10.10.120.2 2 u 56 64 17 51.280 3.977 0.270
pi@ntpi ~ $ ntptrace
localhost: stratum 1, offset 0.000001, synch distance 0.001090, refid 'GPS'
Note the o before GPS_NMEA(0) in ntpq -p – this indicates the PPS is
being used. If you don’t have the PPS enabled your time will kinda suck,
as we saw a bit with the scope traces. To illustrate this, here’s a
comparison of system performance between NMEA-only and PPS.
You really, really want to make sure your system is using the PPS, is what I’m getting at.Another thing I ran into was the GPS reporting the wrong time or not reporting its timing offset – just ensure you have enabled the GPZDA statement to avoid this. Symptoms of this can include huge offsets and being marked as a falseticker (x) in peer lists of other peers. Just make sure your module is configured properly. This is what I did to configure my module:
- Enabled position pinning
- Disabled all NMEA strings except for GGA, GSA, GLL and ZDA
- Set update rate to 1Hz and output sync to UTC
- Set baud rate to 9600 (higher is not better!)
Wednesday, July 18, 2012
NTP tips
setting time with ntp and other tools.
http://www.linuxhomenetworking.com/
see if ntp running: pgrep ntpd
stop service if running: service ntpd stop
set from known server ntpdate -u 64.250.177.145
Determining If NTP Is Synchronized Properly: ntpq -p
http://www.linuxhomenetworking.com/
see if ntp running: pgrep ntpd
stop service if running: service ntpd stop
set from known server ntpdate -u 64.250.177.145
Determining If NTP Is Synchronized Properly: ntpq -p
Subscribe to:
Posts (Atom)