Not all GPS receivers are alike!

The GPS receiver I first ordered on Amazon is not designed to be used as an accurate time source. Don't get me wrong, the U-Blox NEO-6M is a good receiver but it was designed as a general-purpose GPS receiver. It processes and outputs the location every second, that's a waste of resources and a potential source of time drift. On top of that, the device would not accept a lot of commands from the U-Blox Center software which lead me to suspect I have a cheap Chinese clone... Oh well...

Many dedicated GPS time sources can be found on eBay, mostly reclaimed from "starter kits" or cellular towers. If you know what you are looking for, gems can be found for cheap. Some units are even equipped with TCXO, OCXO, or DCXO if you are lucky. More on that later maybe :)

There is one important thing to keep in mind with this kind of device: they require a stationary antenna! They are designed to stay in the same place, not to be moved around. A time-dedicated GPS receiver should stop reporting its position after a specific, sometimes configurable, amount of time. During this first phase of operation, the chip would average its position and then save it in its memory. After that, the chip would only report the time of day, some internal status for monitoring purposes, and PPS. 

Trimble 66266

The first time-oriented GPS receiver I ordered was a Trimble board based on a Trimble 66266, for less than $15 on eBay probably reclaimed from a Trimble starter kit. 

It has an SMB antenna connector and a 3.3v to 5v active antenna is needed. These receivers are quite accurate, down to 15 ns according to the datasheet.

Fortunately, the kit's user guide is still available and has all the information we need including the board's pinout (the connector is a 2.00 mm pitch 2x4 pins, not a standard 2.54 mm):

The user guide can be downloaded from here or from this project's main page.

By default, the chip should have the following configuration:

After ordering an SMB to SMA cable adapter and a second active GPS antenna, it was time to hook this new toy to a computer. The Meru NTP server is in semi-production right now, so it will not be used... For now! I will not talk about the wiring much here because everything is temporary and not related to the Meru server.

Lady Heather to the rescue for the first power-up

Lady Heather is a great piece of art! But a rather complicated software. Since the GPS receiver is also complicated to talk to, with a proprietary protocol, I figured this software could be of good use. Indeed it was! However:

• While you can build and run it on Linux, the installer is made for Windows.
• It needs a serial port with DCD support, even if you don't care about PPS for now.
• Most USB to Serial interfaces don't support DCD, I used the same RS232-TTL board as before on my Windows workstation for that reason, connected to the DB9 RS232 port on the motherboard.

Version 5.0 can be downloaded from here and can be upgraded to version 6.14 Beta. 

If the GPS is connected to COM1, simply execute the shortcut on the desktop. Lady Heather will try to autodetect and autoconfigure the GPS. If you are using another COM port, let's say COM3, then execute the program with the argument "/3" where 3 would be the COM number (COM3).

With the software running, you should see the device progressing through the self-survey mode while acquiring your position. If it is already locked to a position, the chip must be reset... Read along to the next chapter.

In the following screenshot, we can see:

• Lady Heather is connected to the Trimble 66266 board on COM1. 
• Self-survey is still going:
  • Sampling is set to 2000.
  • Progress: 38%.
  • 2D/3D position (lat/lon/alt) is slightly changing over time.
• The position has not been saved yet (red alert near the cyan analog clock with satellite positions). 
• Actually, the chip is reporting a lot of information:
  • Its name is "RESOLUTION SMT".
  • Manufacturing date.
  • Temperature.
  • ROM/RAM/OSC/FPGA and Power status.
  • Antenna status (open, short-circuit, ok...).
  • Almanac status.
  • PPS status...

After letting the GPS run for a while, Lady Heather is now indicating the following information:

• Self-survey is complete:
  • Survey data are grayed, and progress is at 100%.
  • The position is in white, in a locked state.
• The red alert turned green indicating the position has been saved to flash.

Is it GPSD friendly?

Yes, GPSD does support its proprietary protocol so let's connect the board to a Linux computer. However, the monitoring tool "gpsmon" doesn't support Trimble devices much, and "cgps" must be used instead. The following pictures show 2 very specific "cgps" this device will output (the glary zone is the listing of the tracked satellites):

What language does this thing speak?

TSIP of course! Which is a proprietary binary protocol...

Ok, that's great, but I moved the antenna (or the device came pre-locked from China), how do I reset the chip to factory default? Easy: download the Trimble starter kit user guide, go to Appendix A, and read through 44 pages of instructions... or simply read the following summary ;)

Let's say the board is connected to /dev/ttyUSB0, we can simply use the "echo" command to send raw hexadecimal data to the chip:

# Hexadecimal packet structure:
# Byte 1 = "DLE" byte, always 0x10
# Byte 2 = Command ID
# Byte 3-n = Payload
# Ending bytes = DLE then ETX, always 0x10 0x03

# Factory reset 
# Command ID = 0x1E
# Payload:
#    0x4B = Cold reset
#    0x46 = Factory reset
echo -en '\x10\x1E\x46\x10\x03' > /dev/ttyUSB0

# The chip will reboot, wait at least 2 seconds before sending other commands or they will be ignored

# PPS output configuration
# Command ID = 0x8E 0x4E (2 bytes long)
# Payload :
#    0x02 = PPS is always on. PPS is generated every second.
#    0x03 = PPS is output when at least one satellite is tracking. PPS is generated every second.
#    0x04 = PPS is output when at least three satellites are tracking. PPS is generated every second.
#    0x82 = PPS is always on. PPS is generated every even second.
#    0x83 = PPS is output when at least one satellite is tracking. PPS is generated every even second.
#    0x84 = PPS is output when at least three satellites are tracking. PPS is generated every even second.
echo -en '\x10\x8E\x4E\x04\x10\x03' > /dev/ttyUSB0

# Save device configuration to flash
# Command ID = 0x8E 0x26 (2 bytes long)
# No payload
echo -en '\x10\x8E\x26\x10\x03' > /dev/ttyUSB0

It is also possible to only restart the self-survey. This is useful if you find out the stored location doesn't accurately match where you are located, or if the 2000 samples were not enough to acquire a stable location but you don't want to change this setting.

# Self-survey
# Command ID = 0x8E 0xA6 (2 bytes long)
# Payload:
#    0x00 = Restart self-survey
#    0x01 = Save position to flash
#    0x02 = Delete position from flash
echo -en '\x10\x8E\xA6\x00\x10\x03' > /dev/ttyUSB0

And sure enough, CGPS is now reporting a slightly changing position for the next 2000 samples: 

Just a little treat: this picture shows the Trimble board installed in a WYSE V90LE, slightly modded, running Debian 11.7. I might convert this "computer" to a time server at some point. Don't pay too much attention to the wiring, this is a temporary setup ;)

What's next?

Another time-dedicated GPS receiver is on its way, as well as some 2.00 mm pitch IDC cables. I also want to compare the NEO-6M PPS output against this Trimble unit, to see if one is more reliable than the other...

This Trimble board has a lot of unpopulated components, it looks like there is room for an LVDS chip of some kind and two U.FL connectors. One U.FL is directly connected to the 1PPS TTL output, the second goes to where the LVDS would be (a 10 MHz output maybe?). It could be nice to solder a U.FL connector to the 1PPS line to add a BNC output to the Meru...

Stay tuned!

So we now have a working NTP server, but how can we, humans, know what time it is? What about audible feedback?

There is no soundcard in the Meru of course, but there is a basic buzzer that we can use. So let's install the "beep" package first:

apt install beep

And let's create a bash script, let's say "/root/ring.sh", 

#! /bin/bash

# Getting the number of hours (12 hours format)
HOUR=$(date +"%-I")

# Getting attention "hey listen, I'm gonna tell you what time it is!"
beep -f 440 -l 100
sleep 0.050
beep -f 880 -l 100
sleep 0.050
beep -f 440 -l 100
sleep 0.050

# Wait a bit
sleep 1

# Ring HOUR times
for (( i=0; i<$HOUR; i++ ))
do
        # This can be modified
        MAX=35 

        # Looping
        for (( j=0; j<$MAX; j++ ))
        do
                beep -f 440 -l $((MAX - i))
                sleep $((j / 1000))
        done
        
        # Waiting for 1 second
        sleep 1
done

Now edit the "root" crontab: 

# Execute as root
crontab -e

And finally, insert the following cron line to execute the script every ticking hour:

0 * * * * bash /root/ring.sh

Now wait for an hour to tick, and listen :)

Awesome! We have wired a GPS with its PPS to the motherboard, and now what?

First, we need a few missing components: "gpsd" will handle the GPS, while "chrony" will take care of the NTP.

# Installing required packages
apt install gpsd gpsd-clients pps-tools chrony

# Making sure PPS kernel module is loaded
modprobe pps_ldisc

# Attaching PPS device on serial port
ldattach PPS /dev/ttyS1

# Allow Chrony sockets in AppArmor
apt install apparmor-utils
aa-complain /usr/sbin/chronyd

By now, the PPS LED on the GPS module is ticking meaning we should have a GPS fix. Let's test the PPS output to see if it is working. It is indeed ticking as expected:

root@rsfo-ntp01:~# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1682168016.866888991, sequence: 2171 - clear  1682168015.966901011, sequence: 2952
source 0 - assert 1682168016.866888991, sequence: 2171 - clear  1682168016.966901919, sequence: 2953
source 0 - assert 1682168017.866881448, sequence: 2172 - clear  1682168016.966901919, sequence: 2953
source 0 - assert 1682168017.866881448, sequence: 2172 - clear  1682168017.966892630, sequence: 2954
source 0 - assert 1682168018.866880401, sequence: 2173 - clear  1682168017.966892630, sequence: 2954
source 0 - assert 1682168018.866880401, sequence: 2173 - clear  1682168018.966878452, sequence: 2955
source 0 - assert 1682168019.866878585, sequence: 2174 - clear  1682168018.966878452, sequence: 2955
source 0 - assert 1682168019.866878585, sequence: 2174 - clear  1682168019.966890814, sequence: 2956
source 0 - assert 1682168020.866877816, sequence: 2175 - clear  1682168019.966890814, sequence: 2956
source 0 - assert 1682168020.866877816, sequence: 2175 - clear  1682168020.966887531, sequence: 2957

Now, let's configure the GPSD daemon. This daemon will talk to the GPS module while allowing multiple processes to access the GPS information. This would not be possible if we were using the serial port directly from the NTP server. Edit the file "/etc/default/gpsd":

# GPS is conected to ttyS1, the 2nd hardare serial port
DEVICES="/dev/ttyS1"

# Options we want to pass to gpsd
# -s 9600 = baudrate, -G = listen to any address, -n = don't wait for clients to poll GPS
GPSD_OPTIONS="-s 9600 -G -n"

# We don't care about USB modules, let's ignore them!
USBAUTO="false"

We also need to configure the Chrony daemon by editing the file "/etc/chrony/chrony.conf". The "makestep" should not be required, but since the Meru has a bad RTC/BIOS battery the time would keep reverting to 2002... Chrony doesn't like that and doesn't update the time with such an offset in timing. With this command, Chrony will force updates on the first 10 syncs. 

# Allow connections from remote
allow

# Reference clocks, PPS locked on GPS
refclock SOCK /run/chrony.ttyS1.sock refid GPS precision 1e-1
refclock PPS /dev/pps0 lock GPS refid PPS precision 1e-9 poll 2

# Step the clock on first 10 updates if ofset is larger than one second
makestep 1 10

I had trouble starting Chrony on boot because the PPS device (/dev/pps0) would not be initialized yet. So I added an "ExecStartPre" command in Chrony's daemon service file located at "/lib/systemd/system/chrony.service":

[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=openntpd.service ntp.service ntpsec.service
Wants=time-sync.target
Before=time-sync.target
After=network.target
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/run/chrony/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStartPre=bash -c '/usr/sbin/ldattach PPS /dev/ttyS1 && /bin/sleep 10'
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

[Install]
Alias=chronyd.service
WantedBy=multi-user.target

Make sure the GPSD service is set to start after Chrony, edit the file "/lib/systemd/system/gpsd.service" and look for the line "After=chronyd.service":

[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service

[Service]
Type=forking
EnvironmentFile=-/etc/default/gpsd
ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES

[Install]
WantedBy=multi-user.target
Also=gpsd.socket

Reboot the server with the "reboot" command to make sure everything starts correctly on boot... Then let's have a look at the GPS output with the "gpsmon" command. U-Blox is detected, we have a 3D fix, TDOP is low, that's a good start.

/dev/ttyS1                    u-blox>
lqqqqqqqqqqqqqqqqqqqqqqqqqqklqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
xCh PRN  Az  El S/N Flag U xxECEF Pos: +45xxxxx.61m +3xxxxx.98m +43xxxxx.21m  x
x 0   2  52  60  10 040d Y xxECEF Vel:     -0.01m/s     -0.03m/s     -0.02m/s x
x 1   7 331   4   0 0104   xx                                                 x
x 2   8 280  13  25 040d Y xxLTP Pos:  43.xxxxxxxxxf   4.xxxxxxxxf   106.00m x
x 3  10 154  24  30 050d Y xxLTP Vel:    0.00m/s   0.0f   0.00m/s             x
x 4  16 296  69  23 040d Y xx                                                 x
x 5  18  53  56  25 040d Y xxTime: 6 13:05:47.00                              x
x 6  22   0 -91   0 0110   xxTime GPS: 2258+565547.000     Day: 6             x
x 7  23 117  40  33 060d Y xx                                                 x
x 8  26 176  65  39 060d Y xxEst Pos Err  10.93m Est Vel Err   0.00m/s        x
x 9  27 291  45  20 040d Y xxPRNs:  9 PDOP:  1.6 Fix 0x03 Flags 0xdd          x
x10  29  86   5  13 040d Y xmqqqqqqqqqqqqqqqqqqq NAV_SOL qqqqqqqqqqqqqqqqqqqqqj
x11  31 202  13   7 030c   xlqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x12 120 207  36   0 0110   xxDOP [H]  1.1 [V]  1.2 [P]  1.6 [T]  0.8 [G]  1.8 x
x13 124 155  37   0 0110   xmqqqqqqqqqqqqqqqqqqq NAV_DOP qqqqqqqqqqqqqqqqqqqqqj
x14 126 151  35   0 0110   xlqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x15                        xxTOFF: -0.295365554       PPS: -0.429079607       x
mqqqqqq NAV_SVINFO qqqqqqqqjmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
blablablablablablablabla
(26) blablablablablablablabla
(24) blablablablablablablabla

Let's now have a look at the NTP with the "chronyc" command... Not bad, everything is working :)

root@rsfo-ntp01:~# chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#- GPS                           0   4   377    11   -796ns[ -951ns] +/-  100ms
#* PPS                           0   2   377     2  -1965ns[-2129ns] +/- 3142ns
root@rsfo-ntp01:~#
root@rsfo-ntp01:~#
root@rsfo-ntp01:~# chronyc sourcestats -v
root@rsfo-ntp01:~# chronyc sourcestats -v                             .- Number of sample points in measurement set.                            /    .- Number of residual runs with same sign.                           |    /    .- Length of measurement set (time).                           |   |    /      .- Est. clock freq error (ppm).                           |   |   |      /           .- Est. error in freq.                           |   |   |     |           /         .- Est. offset.                           |   |   |     |          |          |   On the -.                           |   |   |     |          |          |   samples. \                           |   |   |     |          |          |             |
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
GPS                        12   9   177     -0.012      0.015   -811ns   612ns
PPS                        59  25   232     -0.000      0.013     -1ns  1987ns
root@rsfo-ntp01:~#
root@rsfo-ntp01:~#
root@rsfo-ntp01:~# chronyc tracking
Reference ID    : 50505300 (PPS)
Stratum         : 1
Ref time (UTC)  : Sun Apr 23 16:58:14 2023
System time     : 0.000000327 seconds slow of NTP time
Last offset     : -0.000000122 seconds
RMS offset      : 0.000000652 seconds
Frequency       : 2.603 ppm slow
Residual freq   : -0.000 ppm
Skew            : 0.032 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000007401 seconds
Update interval : 4.0 seconds
Leap status     : Normal

Of course, Debian cannot get GPS messages from the sky without a GPS module. Since we want to discipline the NTP/kernel accurately, we need a GPS module with a PPS (pulse per second) output. USB modules should be avoided because of delays that can be caused by the TTL-USB chip, and most of them can't handle PPS anyways.

I decided to buy a module from Amazon, it has a PPS output and a TTL interface making it more reliable than USB. The GPS chip is a NEO-6M which will do the trick for now. A proper chip for time reference should be the NEO-6T but more on that latter.

On an RPi the PPS output could be wired to a GPIO, but since we have a "real" motherboard we have 2 options:

1. Parallel port: PPS output is wired to the ACK pin of the port, but we either need a serial port or serial-to-USB to get the actual GPS time from the NMEA messages.
2. Serial port: PPS output is wired to the DCD pin of the port, TX and RX can be used to get the actual GPS time messages from NMEA. 

Option 2 is great, and since there is a second serial port on the motherboard we can use it! But there is a catch: the port itself expects RS232 signals, and they are incompatible with the module TTL output. A simple MAX3232 with a few capacitors can be used as an interface between the two, and I went with a pre-made module from Amazon, again. 

Here are some pictures of the wiring:

First, it looks like this connector there is a parallel port. It is connected to a PACSZ1284 chip so there might be something to do with this later!

And a few information about the hardware from the OS:

lspci

root@rsfo-ntp01:~# lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04)
00:1d.0 USB controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04)
00:1d.1 USB controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04)
00:1d.7 USB controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

lscpu

root@rsfo-ntp01:~# lscpu
Architecture:                    i686
CPU op-mode(s):                  32-bit
Byte Order:                      Little Endian
Address sizes:                   32 bits physical, 32 bits virtual
CPU(s):                          1
On-line CPU(s) list:             0
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           13
Model name:                      Intel(R) Celeron(R) M processor         1.50GHz
Stepping:                        8
CPU MHz:                         1500.033
BogoMIPS:                        3000.06
Vulnerability Itlb multihit:     KVM: Mitigation: VMX unsupported
Vulnerability L1tf:              Mitigation; PTE Inversion
Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no mic
                                 rocode; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Mmio stale data:   Unknown: No mitigations
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user
                                  pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, STIBP disabled, RSB fil
                                 ling, PBRSB-eIBRS Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtr
                                 r pge mca cmov clflush dts acpi mmx fxsr sse ss
                                 e2 ss tm pbe nx bts cpuid pti

lsusb

root@rsfo-ntp01:~# lsusb
Bus 001 Device 002: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device (charging + debug)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

sensors-detect (after installing lm-sensors and i2c-tools). Unfortunately, the "sensors" command doesn't show any sensor, yet...

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `w83627hf':
  * ISA bus, address 0xa00
    Chip `Winbond W83627THF/THG Super IO Sensors' (confidence: 9)

i2cdetect

root@rsfo-ntp01:~# echo i2c-dev >> /etc/modules
root@rsfo-ntp01:~# systemctl restart kmod
root@rsfo-ntp01:~# i2cdetect -l
i2c-3   i2c             i915 gmbus panel                        I2C adapter
i2c-1   i2c             i915 gmbus ssc                          I2C adapter
i2c-6   i2c             i915 gmbus dpd                          I2C adapter
i2c-4   i2c             i915 gmbus dpc                          I2C adapter
i2c-2   i2c             i915 gmbus vga                          I2C adapter
i2c-0   smbus           SMBus I801 adapter at 0400              SMBus adapter
i2c-5   i2c             i915 gmbus dpb                          I2C adapter
root@rsfo-ntp01:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- 49 -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- 61 -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@rsfo-ntp01:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@rsfo-ntp01:~# i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@rsfo-ntp01:~# i2cdetect -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@rsfo-ntp01:~# i2cdetect -y 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@rsfo-ntp01:~# i2cdetect -y 5
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
root@rsfo-ntp01:~# i2cdetect -y 6
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Let's execute "sensors" again:

root@rsfo-ntp01:~# sensors
w83627thf-isa-0a00
Adapter: ISA adapter
in0:           1.29 V  (min =  +0.70 V, max =  +1.87 V)
in1:           3.31 V  (min =  +0.72 V, max =  +0.05 V)  ALARM
in2:           3.22 V  (min =  +2.61 V, max =  +3.82 V)
+5V:           4.96 V  (min =  +1.52 V, max =  +2.19 V)  ALARM
in4:           3.58 V  (min =  +2.67 V, max =  +2.30 V)  ALARM
5VSB:          4.91 V  (min =  +0.05 V, max =  +6.69 V)
Vbat:          3.23 V  (min =  +0.96 V, max =  +2.43 V)  ALARM
fan1:        7031 RPM  (min =  907 RPM, div = 8)
fan2:        7031 RPM  (min = 2596 RPM, div = 8)
fan3:        7336 RPM  (min = 1622 RPM, div = 8)
temp1:        +32.0°C  (high = +98.0°C, hyst = +12.0°C)  sensor = thermistor
temp2:        +28.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = CPU diode
temp3:        +39.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
beep_enable: enabled

Fitting a hard drive

The 4GB CompactFlash that came with the unit was corrupted and did not survive the dump I made to retrieve the license. Since I had a brand new SATA HDD, I gave it a try. After looking up the prices of CF memory cards, I think it would be wise to stick to HDD or even SSD, you get more GB per $$$. If the drive is recognized by the BIOS!

Running Putty on a computer with the Meru connected via an old Cisco RJ45-DB9 console cable, I powered the device and watched the BIOS loading. Sometimes, most of the POST information would not show up on the console. Oh well... Here is a log extracted from Putty, the disk is indeed recognized!

Press <spacebar> to update BIOS.S
AMIBIOS(C)2005 American Megatrends, Inc.
MB-7560 Ver.ACB 09/06/2010
CPU : Intel(R) Celeron(R) M processor         1.50GHz
Speed : 1.49 GHz
Press F12 if you want to boot from the network
Press F11 for BBS POPUP  (F3 on Remote Keyboard)
Initializing USB Controllers .. Done.
1016MB OK
0075
Auto-Detecting Pri Master..
0078Auto-Detecting Pri Master..IDE Hard Disk
Pri Master: WDC WD3200AAJS-56M0A0  01.03E01
Ultra DMA Mode-5, S.M.A.R.T. Capable and Status OK
Auto-detecting USB Mass Storage Devices ..
00 USB mass storage devices found and configured.
CMOS Settings Wrong
CMOS Date/Time Not Set
0085Checking NVRAM..</spacebar>

Preparing a bootable Debian USB key

The Celeron M is a 32 bits CPU so an x86 Linux distribution must be used (no x64/amd64). I went with Debian 11.6 and used Rufus to burn the full DVD image named "debian-11.6.0-i386-DVD-1.iso" to a USB flash drive, with Rufus's default settings. A few files have to be modified on the key:

isolinux/adtxt.cfg

label expert
    menu label E^xpert install
    kernel /install.386/vmlinuz
    #append priority=low vga=788 initrd=/install.386/initrd.gz --- 
    append priority=low vga=788 console=ttyS0,115200n8 initrd=/install.386/initrd.gz --- console=ttyS0,115200n8
include rqtxt.cfg
label auto
    menu label ^Automated install
    kernel /install.386/vmlinuz
    #append auto=true priority=critical vga=788 initrd=/install.386/initrd.gz --- quiet 
    append auto=true priority=critical vga=788 console=ttyS0,115200n8 initrd=/install.386/initrd.gz --- quiet console=ttyS0,115200n8

isolinux/isolinux.cfg

Add "serial 0 115200" and "console 0" after the line "path":

# D-I config version 2.0
# search path for the c32 support libraries (libcom32, libutil etc.)
path 
serial 0 115200
console 0
include menu.cfg
default vesamenu.c32
prompt 0
timeout 0

isolinux/txt.cfg

label install
    menu label ^Install
    kernel /install.386/vmlinuz
    #append vga=788 initrd=/install.386/initrd.gz --- quiet 
    append vga=788 console=ttyS0,115200n8 initrd=/install.386/initrd.gz --- quiet console=ttyS0,115200n8

boot/grub/grub.cfg

Edit the two menu entries as follow, removing the "quiet" command:

...
menuentry --hotkey=g 'Graphical install' {
    set background_color=black
    linux    /install.386/vmlinuz vga=788 console=tty0 console=ttyS0,115200n8 --- quiet console=tty0 console=ttyS0,115200n8
    initrd   /install.386/gtk/initrd.gz
}
menuentry --hotkey=i 'Install' {
    set background_color=black
    linux    /install.386/vmlinuz vga=788 console=tty0 console=ttyS0,115200n8 --- quiet console=tty0 console=ttyS0,115200n8
    initrd   /install.386/initrd.gz
}
...

Installing Debian!

Now plug the key into the device and reboot... Grub should load eventually. Select the 2nd install option, and follow the wizard. Configure the network (I used /dev/usb0, sharing my phone's Internet connection via USB on the 2nd port), etc... The hard drive is detected and can be partitioned, awesome! We don't need any desktop environment so we can safely deselect that in the installation options ;) Installing the OpenSSH package is highly recommended :) 

Unfortunately, I lost all screenshots from the installation procedure!

After the installation completes, reboot the "computer" and unplug the USB key... And... Debian is booting :) 

Edit the file /etc/apt/sources.list to comment out the "cdrom" depot. You don't want to use "vi" over serial, "nano" is way easier... I decided to include the non-free depots as well:

Let's update the APT cache, install a few packages that we might need later, and update the distribution and packages... And we now have an up-to-date Debian running on the Meru controller!

apt update
apt install vim curl wget git
apt upgrade
apt dist-upgrade

General view

Once opened, the device looks like a small computer. There is plenty of room for "upgrades" in there. The power supply connector to the motherboard looks to be a v1.x type with 20 pins, and it has 2 SATA power connectors. AC input is in the back of the device with a standard computer plug, as well as the power button.

On the front of the device we have:

• Power/Status/HDD LEDs
• RJ45 console "Cisco-like", mapped as /dev/ttyS0
  • RS232 level, a cheap USB-RS232 might not work
  • 115200 bps, 8 data bits, 1 stop bit, no parity
• Reset switch (small hole)
• 2x USB 2.0
• 2x Gigabit ethernet

Internal components

The motherboard itself has the following easily identifiable "components":

• mPGA479M CPU socket with an Intel Celeron M 370 @ 1.5 GHz
• 1x SODIMM DDR2 socket (1 GB DDR2 667 pre-installed)
• 1x CompactFlash 
• 2x SATA 
• 1x Mini PCI (as plain old Mini PCI, not PCIe)

There are also some headers that can be used on the board. However, none of them have named labels... There looks to be some kind of male PCI extension header on one side, probably a VGA (the MC1000 motherboard has one so that's a guess) between the two case fan connectors, one "lockable" connector between the console port and the CF connector, and finally a second RS232 interface, DTK/INTEL header style. This serial interface is mapped to /dev/ttyS1 and will be used for the GPS signal and PPS. 

What's next?

We know we have a working "computer" with no storage and no display output, that's a start! In the next episode, we will try to install some Linux distro on a hard drive via the console port, and see what we have in more detail!