Introduction Screenshot Capturing Interfaces Hardware and Software Tools Capturing GPIB data in Talk Only mode TDS 540 Oscilloscope - GPIB - PCL Output HP 54542A Oscilloscope - Parallel Port - PCL or HPGL Output HP Inifinium 54825A Oscilloscope - Parallel Port - Encapsulated Postscript TDS 684B - Parallel Port - PCX Color Output Advantest R3273 Spectrum Analyzer - Parallel Port - PCL Output HP 8753C Vector Network Analyzer - GPIB - HP 8753 Companion Siglent SDS 2304X Oscilloscope - USB Drive, Ethernet or USB Introduction Last year, I create Fake Parallel Printer, a tool to capture the output of the parallel printer port of old-ish test equipment so that it can be converted into screenshots for blog posts etc. It’s definitely a niche tool, but of all the projects that I’ve done, it’s definitely the one that has seen the most amount of use. One issue is that converting the captured raw printing data to a bitmap requires recipes that may need quite a bit of tuning. Some output uses HP PCL, other is Encapsulated Postscript (EPS), if you’re lucky the output is a standard bitmap format like PCX. In the blog post, describe the procedures that I use to create screenshots of the test equipment that I personally own, so that don’t need to figure it out again when I use the device a year later. That doesn’t make it all that useful for others, but somebody may benefit from it when googling for it… As always, I’m using Linux so the software used below reflects that. Screenshot Capturing Interfaces Here are some common ways to transfer screenshots from test equipment to your PC: USB flash drive Usually the least painless by far, but it only works on modern equipment. USB cable Requires some effort to set the right udev driver permissions and a script that sends commands that are device specific. But it generally works fine. Ethernet Still requires slightly modern equipment, and there’s often some configuration pain involved. RS-232 serial Reliable, but often slow. Floppy disk I have a bunch of test equipment with a floppy drive and I also have a USB floppy drive for my PC. However, the drives on all this equipment is broken, in the sense that it can’t correctly write data to a disc. There must be some kind of contamination going on when a floppy drive head isn’t used for decades. GPIB Requires an expensive interface dongle and I’ve yet to figure out how to make it work for all equipment. Below, I was able to make it work for a TDS 540 oscilloscope, but not for an HP 54532A oscilloscope, for example. Parallel printer port Available on a lot of old equipment, but it normally can’t be captured by a PC unless you use Fake Parallel Printer. We’re now more than a year later, and I use it all the time. I find it to be the easiest to use of all the printer interfaces. Hardware and Software Tools GPIB to USB Dongle If you want to print to GPIB, you’ll need a PC to GPIB interface. These days, the cheapest and most common are GPIB to USB dongles. I’ve written about those here and here. The biggest take-away is that they’re expensive (>$100 second hand) and hard to configure when using Linux. And as mentioned above, I have only had limited success and using them in printer mode. ImageMagick ImageMagick is the swiss army knife of bitmap file processing. It has a million features, but I primarily use it for file format conversion and image cropping. I doubt that there’s any major Linux distribution that doesn’t have it as a standard package… sudo apt install imagemagick GhostPCL GhostPCL is used to decode PCL files. On many old machines, these files are created when printing to Thinkjet, Deskjet or Laserjet. Installation: Download the GhostPCL/GhostPDL source code. Compile cd ~/tools tar xfv ~/Downloads/ghostpdl-10.03.0.tar.gz cd ghostpdl-10.03.0/ ./configure --prefix=/opt/ghostpdl make -j$(nproc) export PATH="/opt/ghostpdl/bin:$PATH" Install sudo make install A whole bunch of tools will now be available in /opt/ghostpdl/bin, including gs (Ghostscript) and gpcl6. hp2xx hp2xx converts HPGL files, originally intended for HP plotter, to bitmaps, EPS etc. It’s available as a standard package for Ubuntu: sudo apt install hp2xx Inkscape Inkscape is full-featured vector drawing app, but it can also be used as a command line tool to convert vector content to bitmaps. I use it to convert Encapsulated Postscript file (EPS) to bitmaps. Like other well known tools, installation on Ubuntu is simple: sudo apt install inkscape HP 8753C Companion This tool is specific to HP 8753 vector network analyzers. It captures HPGL plotter commands, extracts the data, recreates what’s displayed on the screen, and allow you to interact with it. It’s available on GitHub. Capturing GPIB data in Talk Only mode Some devices will only print to GPIB in Talk Only mode, or sometimes it’s just easier to use that way. When the device is in Talk Only mode, the PC GPIB controller becomes a Listen Only device, a passive observer that doesn’t initiate commands but just receives data. I wrote the following script to record the printing data and save it to a file: gpib_talk_to_file.py: (Click to download) #! /usr/bin/env python3 import sys import pyvisa gpib_addr = int(sys.argv[1]) output_filename = sys.argv[2] rm = pyvisa.ResourceManager() inst = rm.open_resource(f'GPIB::{gpib_addr}') try: # Read data from the device data = inst.read_raw() with open(output_filename, 'wb') as file: file.write(data) except pyvisa.VisaIOError as e: print(f"Error: {e}") Pyvisa is a universal library to take to test equipement. I wrote about it here. It will quickly time out when no data arrives in Talk Only mode, but since all data transfers happen with valid-ready protocol, you can avoid time-out issued by pressing the hardcopy or print button on your oscilloscope first, and only then launch the script above. This will work as long as the printing device doesn’t go silent while in the middle of printing a page. TDS 540 Oscilloscope - GPIB - PCL Output My old TDS 540 oscilloscope doesn’t have a printer port, so I had to make do with GPIB. Unlike later version of the TDS series, it also doesn’t have the ability to export bitmaps directly, but it has outputs for: Thinkjet, Deskjet, and Laserjet in PCL format Epson in ESC/P format Interleaf format EPS Image format HPGL plotter format The TDS 540 has a screen resolution of 640x480. I found the Thinkjet output format, with a DPI of 75x75, easiest to deal with. The device adds a margin of 20 pixels to the left, and 47 pixels at the top, but those can be removed with ImageMagick. With a GPIB address of 11, the overall recipe looks like this: # Capture the PCL data gpib_talk_to_file.py 11 tds540.thinkjet.pcl # Convert PCL to png gpcl6 -dNOPAUSE -sOutputFile=tds540.png -sDEVICE=png256 -g680x574 -r75x75 tds540.thinkjet.pcl # Remove the margins and crop the image to 640x480 convert tds540.png -crop 640x480+20+47 tds540.crop.png The end result looks like this: HP 54542A Oscilloscope - Parallel Port - PCL or HPGL Output This oscilloscope was an ridiculous $20 bargain at the Silicon Valley Electronics Flea Market and it’s the one I love working with the most: the user interface is just so smooth and intuitive. Like all other old oscilloscopes, the biggest thing going against it is the amount if desk space it requires. It has a GPIB, RS-232, and Centronics parallel port, and all 3 can be used for printing. I tried to get printing to GPIB to work but wasn’t successful: I’m able to talk to the device and send commands like “*IDN?” and get a reply just fine, but the GPIB script that works fine with the TDS 540 always times out eventually. I switched to my always reliable Fake Parallel Printer and that worked fine. There’s also the option to use the serial cable. The printer settings menu can by accessed by pressing the Utility button and then the top soft-button with the name “HPIB/RS232/CENT CENTRONICS”. You have the following options: ThinkJet DeskJet75dpi, DeskJet100dpi, DeskJet150dpi, DeskJet300dpi LaserJet PaintJet Plotter Unlike the TDS 540 I wasn’t able to get the ThinkJet option to convert into anything, but the DeskJet75dpi option worked fine with this recipe: ~/projects/fake_parallel_printer/fake_printer.py -i -p /dev/ttyACM0 -f hp54542a_ -s deskjet.pcl -v gpcl6 -dNOPAUSE -sOutputFile=hp54542a.png -sDEVICE=png256 -g680x700 -r75x75 hp54542a_0.deskjet.pcl convert hp54542a.png -crop 640x388+19+96 hp54542a.crop.png The 54542A doesn’t just print out the contents of the screen, it also prints the date and adds the settings for the channels that are enabled, trigger options etc. The size of these additional values depends on how many channels and other parameters are enabled. When you select PaintJet or Plotter as output device, you have the option to select different colors for regular channels, math channels, graticule, markers etc. So it is possible to create nice color screenshots from this scope, even if the CRT is monochrome. I tried the PaintJet option, and while gcpl6 was able to extract an image, the output was much worse than the DeskJet option. I had more success using the Plotter option. It prints out a file in HPGL format that can be converted to a bitmap with hp2xx. The following recipe worked for me: ~/projects/fake_parallel_printer/fake_printer.py -i -p /dev/ttyACM0 -f hp54542a_ -s plotter.hpgl -v hp2xx -m png -a 1.4 --width 250 --height 250 -c 12345671 -p 11111111 hp54542a_0.plotter.hpgl I’m not smitten with the way it looks, but if you want color, this is your best option. The command line options of hp2xx are not intuitive. Maybe it’s possible to get this to look a bit better with some other options. Click to enlarge HP Inifinium 54825A Oscilloscope - Parallel Port - Encapsulated Postscript This indefinite-loaner-from-a-friend oscilloscope has a small PC in it that runs an old version of Windows. It can be connected to Ethernet, but I’ve never done that: capturing parallel printer traffic is just too convenient. On this oscilloscope, I found that printing things out as Encapsulated Postscript was the best option. I then use inkscape to convert the screenshot to PNG: ./fake_printer.py --port=/dev/ttyACM0 -t 2 -v --prefix=hp_osc_ -s eps inkscape -f ./hp_osc_0.eps -w 1580 -y=255 -e hp_osc_0.png convert hp_osc_0.png -crop 1294x971+142+80 hp_osc_0_cropped.png Ignore the part circled in red, that was added in post for an earlier article: Click to enlarge TDS 684B - Parallel Port - PCX Color Output I replaced my TDS 540 oscilloscope with a TDS 684B. On the outside they look identical. They also have the same core user interface, but the 648B has a color screen, a bandwidth of 1GHz, and a sample rate of 5 Gsps. Print formats The 684B also has a lot more output options: Thinkjet, Deskjet, DeskjetC (color), Laserjet output in PCL format Epson in ESC/P format DPU thermal printer PC Paintbrush mono and color in PCX file format TIFF file format BMP mono and color format RLE color format EPS mono and color printer format EPS mono and color plotter format Interleaf .img format HPGL color plot Phew. Like the HP 54542A, my unit has GPIB, parallel port, and serial port. It can also write out the files to floppy drive. So which one to use? BMP is an obvious choice and supported natively by all modern PCs. The only issue is that it gets written out without any compression so it takes over 130 seconds to capture with fake printer. PCX is a very old bitmap file format, I used it way back in 1988 on my first Intel 8088 PC, but it compresses with run length encoding which works great on oscilloscope screenshots. It only take 22 seconds to print. I tried the TIFF option and was happy to see that it only took 17 seconds, but the output was monochrome. So for color bitmap files, PCX is the way to go. The recipe: ~/projects/fake_parallel_printer/fake_printer.py -i -p /dev/ttyACM0 -f tds684_ -s pcx -v convert tds684_0.pcx tds684.png The screenshot above uses the Normal color setting. The scope also a Bold color setting: There’s a Hardcopy option as well: It’s a matter of personal taste, but my preference is the Normal option. Advantest R3273 Spectrum Analyzer - Parallel Port - PCL Output Next up is my Advantest R3273 spectrum analyzer. It has a printer port, a separate parallel port that I don’t know what it’s used for, a serial port, a GPIB port, and floppy drive that refuses to work. However, in the menus I can only configure prints to go to floppy or to the parallel port, so fake parallel printer is what I’m using. The print configuration menu can be reached by pressing: [Config] - [Copy Config] -> [Printer]: The R3273 supports a bunch of formats, but I had the hardest time getting it create a color bitmap. After a lot of trial and error, I ended up with this: ~/projects/fake_parallel_printer/fake_printer.py -i -p /dev/ttyACM0 -f r3273_ -s pcl -v gpcl6 -dNOPAUSE -sOutputFile=r3273_tmp.png -sDEVICE=png256 -g4000x4000 -r600x600 r3273_0.pcl convert r3273_tmp.png -filter point -resize 1000 r3273_filt.png rm r3273_tmp.png convert r3273_filt.png -crop 640x480+315+94 r3273.png rm r3273_filt.png The conversion loses something in the process. The R3273 hardcopy mimics the shades of depressed buttons with a 4x4 pixel dither pattern: If you use a 4x4 pixel box filter and downsample by a factor of 4, this dither pattern converts to a nice uniform gray, but the actual spectrum data gets filtered down as well: With the recipe above, I’m using 4x4 to 1 pixel point-sampling instead, with a phase that is chosen just right so that the black pixels of the dither pattern get picked. The highlighted buttons are now solid black and everything looks good. HP 8753C Vector Network Analyzer - GPIB - HP 8753 Companion My HP 8753C VNA only has a GPIB interface, so there’s not a lot of choice there. I’m using HP 8753 Companion. It can be used for much more than just grabbing screenshots: you can save the measured data to a filter, upload calibration kit data and so on. It’s great! You can render the screenshot the way it was plotted by the HP 8753C, like this: Click to enlarge Or you can display it as in a high resolution mode, like this: Click to enlarge Default color settings for the HPGL plot aren’t ideal, but everything is configurable. If you don’t have one, the existence of HP 8753 Companion alone is a good reason to buy a USB-to-GPIB dongle. Click to enlarge Siglent SDS 2304X Oscilloscope - USB Drive, Ethernet or USB My Siglent SDS 2304X was my first oscilloscope. It was designed 20 years later than all the other stuff, with a modern UI, and modern interfaces such as USB and Ethernet. There is no GPIB, parallel or RS-232 serial port to be found. I don’t love the scope. The UI can become slow when you’re displaying a bunch of data on the screen, and selecting anything from a menu with a detentless rotary knob can be the most infuriating experience. But it’s my daily driver because it’s not a boat anchor: even on my messy desk, I can usually create room to put it down without too much effort. You’d think that I use USB or Ethernet to grab screenshots, but most of the time I just use a USB stick and shuttle it back and forth between the scope and the PC. That’s because setting up the connection is always a bit of pain. However, if you insist, you can set things up this way: Ethernet To configure Ethernet, you need to go to [Utility] -> [Next Page] -> [I/O] -> [LAN]. Unlike my HP 1670G logic analyzer, the Siglent supports DHCP but when writing this blog post, the scope refused to grab an IP address on my network. No amount of rebooting, disabling and re-enabling DHCP helped. I have gotten it to work in the past, but today it just wasn’t happening. You’ll probably understand why using a zero-configuration USB stick becomes an attractive alternative. USB If you want to use USB, you need an old relic of a USB-B cable. It shows up like this: sudo dmesg -w [314170.674538] usb 1-7.1: new full-speed USB device number 11 using xhci_hcd [314170.856450] usb 1-7.1: not running at top speed; connect to a high speed hub [314170.892455] usb 1-7.1: New USB device found, idVendor=f4ec, idProduct=ee3a, bcdDevice= 2.00 [314170.892464] usb 1-7.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [314170.892469] usb 1-7.1: Product: SDS2304X [314170.892473] usb 1-7.1: Manufacturer: Siglent Technologies Co,. Ltd. [314170.892476] usb 1-7.1: SerialNumber: SDS2XJBD1R2754 Note 3 key parameters: USB vendor ID: f4ec USB product ID: ee3a Product serial number: SDS2XJBD1R2754 Set udev rules so that you can access this device of USB without requiring root permission by creating an /etc/udev/rules.d/99-usbtmc.rules file and adding the following line: SUBSYSTEM=="usb", ATTR{idVendor}=="f4ec", ATTR{idProduct}=="ee3a", MODE="0666" You should obviously replace the vendor ID and product ID with the one of your case. Make the new udev rules active: sudo udevadm control --reload-rules sudo udevadm trigger You can now download screenshots with the following script: siglent_screenshot_usb.py: (Click to download) #!/usr/bin/env python3 import argparse import io import pyvisa from pyvisa.constants import StatusCode from PIL import Image def screendump(filename): rm = pyvisa.ResourceManager('') # Siglent SDS2304X scope = rm.open_resource('USB0::0xF4EC::0xEE3A::SDS2XJBD1R2754::INSTR') scope.read_termination = None scope.write('SCDP') data = scope.read_raw(2000000) image = Image.open(io.BytesIO(data)) image.save(filename) scope.close() rm.close() if __name__ == '__main__': parser = argparse.ArgumentParser( description='Grab a screenshot from a Siglent DSO.') parser.add_argument('--output', '-o', dest='filename', required=True, help='the output filename') args = parser.parse_args() screendump(args.filename) Once again, take note of this line scope = rm.open_resource('USB0::0xF4EC::0xEE3A::SDS2XJBD1R2754::INSTR') and don’t forget to replace 0xF4EC, 0xEE3A, and SDS2XJBD1R2754 by the correct USB product ID, vendor ID and serial number. Call the script like this: ./siglent_screenshot_usb.py -o siglent_screenshot.png If all goes well, you’ll get something like this:

Introduction IMPORTANT: Use the Right GPS Antenna! The Problem: SyncServer Refuses to Lock to GPS The GPS Week Number Rollover Issue Making the Furuno GT-8031 Work Again How It Works Build Instructions Power Supply Recapping The Future: A Software-Only Solution The Result References Footnotes Introduction In my earlier blog post, I wrote about how to set up a SyncServer S200 as a regular NTP server, and how to install the backside BNC connectors to bring out the 10 MHz and 1PPS outputs. The ultimate goal is to use the SyncServer as a lab timing reference, but at the end of that blog post, it’s clear that using NTP alone is not good enough to get a precise 10 MHz clock: the output frequency was off by almost 100Hz! To get a more accurate output clock, you need to synchronize the SyncServer to the GPS system so that it becomes a GPS disciplined oscillator (GPSDO) and a stratum 1 time keeping device. The S200 has a GPS antenna input and a GPS receiver module inside, so in theory this should be a matter of connecting the right GPS antenna. But in practice it wasn’t simple at all because the GPS module in the SyncServer S200 is so old that it suffers from the so-called Week Number Roll-Over (WNRO) problem. In this blog post, I’ll discuss what the WNRO problem is all about and show my custom hardware solution that fixed the problem. IMPORTANT: Use the Right GPS Antenna! Let me once again point out the importance of using the right GPS antenna to avoid damaging it permanently due to over-voltage. GPS antennas have active elements that amplify the received signal right at the point of reception before sending it down the cable to the GPS unit. Most antennas need 3.3V or 5V that is supplied through the GPS antenna connector, but Symmetricom S200 supplies 12V! Make sure you are using a 12V GPS antenna! Check out my earlier blog post for more information. The Problem: SyncServer Refuses to Lock to GPS When you connect a GPS antenna to a SyncServer in its original configuration, everything seems to go fine initially. The front panel reports the antenna connection as “Good”, a few minutes later the number of satellites detected goes up, and the right location gets reported. But the most important “Status” field remains stuck in the “Unlocked” state which means that the SyncServer refuses to lock its internal clock to the GPS unit. This issue has been discussed to death in a number of EEVblog forum threads, but conclusion is always the same: the Furuno GT-8031 GPS module suffers from the GPS Week Number Roll-Over (WNRO) issue and nothing can be done about it other than replacing the GPS module with an after-market replacement one. The GPS Week Number Rollover Issue The original GPS system used a 10-bit number to count the number of weeks that have elapsed since January 6, 1980. Every 19.7 years, this number rolls over from 1023 back to 0. The first rollover happened on August 21, 1999, the second on April 6, 2019, and the next one will be on November 20, 2038. Check out this US Naval Observatory presention for some more information. GPS module manufacturers have dealt with the issue is by using a dynamic base year or variable pivot year. Let’s say that a device is designed in at the start of 2013 during week 697 of the 19.7 year epoch that started in 1999. The device then assumes that all week numbers higher than 697 are for years 2013 to 2019, and that numbers from 0 to 697 are for the years 2019 and later. Such a device will work fine for the 19.7 years from 2013 until 2032. And with just a few bits of non-volatile storage it is even possible to make a GPS unit robust against this kind of rollover forever: if the last seen date by the GPS unit was 2019 and suddenly it sees a date of 1999, it can infer that there was a rollover and record in the storage that the next GPS epoch has started. Unfortunately many modules don’t do that. The only way to fix the issue is to either update the module firmware or for some external device to tell the GPS module about the current GPS epoch. Many SyncServer S2xx devices shipped with a Motorola M12 compatible module that is based on a Furuno GT-8031 which has a starting date of February 2, 2003 and rolled over on September 18, 2022. You can send a command to the module that hints the current date and that fixes the issue, but there is no SyncServer S200 firmware that supports that. Check out this Furuno technical document for more the rollover details. The same document also tells us how to adjust the rollover date. It depends on the protocol that is supposed by the module. For a GT-8031, you need to use the ZDA command, other modules require the @@Gb or the TIME command. If you want to run a SyncServer for its intended purpose, a time server, it is of course important that you get the correct date. But if you don’t care about the date because the primary purpose it to use it as a GPSDO then the 1PPS output from the GPS module should be sufficient to drive a PLL that locks the internal 10 MHz oscillator to the GPS system. This 1PPS signal is still present on the GT-8031 of my unit and I verified with an oscilloscope that it matches the 1PPS output of my TM4313 GPSDO both in frequency and in phase as soon as it sees a copule of satellites. But there is something in the SyncServer firmware that depends on more than just the 1PPS signal because my S200 refuses to enter into “GPS Locked” mode, and the 10 MHz oscillator stays in free-running mode at the miserable frequency of roughly 9,999,993 Hz. Making the Furuno GT-8031 Work Again There are aftermarket replacement modules out there with a rollover date that is far into the future, but they are priced pretty high. There’s the iLotus IL-GPS-0030-B Module which goes for around $100 in AliExpress but that one has a rollover date on August 2024, and other modules go as high as $240. The reason for these high prices is because these modules don’t use a $5 location GPS chip but specialized ones that are designed for accurate time keeping such as the u-blox NEO/LEA series. Instead of solving the problem with money, I wondered if it was possible to make the GT-8031 send the right date to the S200 with a hardware interposer that sits between the module and motherboard. There were 2 options: intercept the date sent from the GPS module, correct it, and transmit it to the motherboard I tried that, but didn’t get it work. send a configuration command to the GPS module to set the right date This method was suggested by Alex Forencich on the time-nuts mailing list. He implemented it by patching the firmware of a microcontroller on his SyncServer S350. His solution might be the best one eventually, it doesn’t require extra hardware, but by the time he posted his message, my interposer was already up and running on my desk. It took 2 PCB spins, but I eventually came up with the following solution: Click to enlarge In the picture above, you see the GT-8031 plugged into my interposer that is in turn plugged into the motherboard. The interposer itself looks like this: The design is straightforward: an RP2024-zero, a smaller variant of the Raspberry Pico, puts itself in between the serial TX and RX wires that normally go between the module and the motherboard. It’s up to the software that runs on the RP2040 to determine what to do with the data streams that run over those wires. There are a few of other connectors: the one at the bottom right is for observing the signals with a logic analyzer. There are also 2 connectors for power. When finally installed, the interposer gets powered with a 5V supply that’s available on a pin that is conveniently located right behind the GPS module. In the picture above, the red wires provides the 5V, the ground is connected through the screws that hold the board in place. The total cost of the board is as follows: PCB: $2 for 5 PCBs + $1.50 shipping = $3.50 RP2040-zero: $9 on Amazon 2 5x2 connectors: $5 on Mouser + $5 shipping = $10 Total: $22.50 The full project details can be found my gps_interposer GitHub repo. How It Works To arrive at a working solution, I recorded all the transactions on the serial port RX and TX and ran them through a decoder script to convert them into readable GPS messages. Here are the messages that are exchanged between the motherboard after powering up the unit: >>> @@Cf - set to defaults command: [], [37], [13, 10] - 7 >>> @@Gf - time raim alarm message: [0, 10], [43], [13, 10] - 9 >>> @@Aw - time correction select: [1], [55], [13, 10] - 8 >>> @@Bp - request utc/ionospheric data: [0], [50], [13, 10] - 8 >>> @@Ge - time raim select message: [1], [35], [13, 10] - 8 >>> @@Gd - position control message: [3], [32], [13, 10] - 8 <<< @@Aw - time correction select: [1], [55], [13, 10] - 8 time_mode:UTC <<< @@Co - utc/ionospheric data input: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [44], [13, 10] - 29 alpha0:0, alpha1:0, alhpa2:0, alpha3:0 beta0:0, beta1:0, alhpa2:0, beta3:0 A0:0, A1:0 delta_tls:0, tot:0, WNt:0, WNlsf:0, DN:0, delta_Tlsf:0 The messages above can be seen in the blue and green rectangles of this logic analyzer screenshot: Click to enlarge Earlier, we saw that the GT-8031 module itself needs the ZDA command to set the time. This is an NMEA command. The messages above are Motorola M12 commands however. On the M12 module that contains the GT-8031 there is also a TI M430F147 microcontroller that takes care of the conversion between Motorola and NMEA commands. Note how the messages that arrive at the interposer immediately get forwarded to the other side. But there is one transaction marked in red, generated by the interposer itself, that sends the @@Gb command. When the GPS module is not yet locked to a satelllite, this command sends an initial estimate of the current date and time. The M12 User Guide has the following to say about this command: The interposer sends a hinted date of May 4, 2024. When the GPS module receives date from its first satellite, it corrects the date and time to the right value but it uses the initial estimated date to correct for the week number rollover! I initially placed the @@Gb command right after the @@Cf command that resets the module to default values, but that didn’t work. The solution was to send it after the initial burst of configuration commmands. With this fix in place, it still takes almost 15 minutes before the S200 enters into GPS lock. You can see this on the logic analyzer by an increased rate of serial port traffic: Click to enlarge There’s also the immense satisfaction to see the GPS status changed to “Locked”: Build Instructions Disclaimer: it’s easy to make mistakes and permanently damage your SyncServer. Build this at your own risk! All design assets for this project can be found in my gps_interposer project on GitHub. There is a KiCAD project with schematic, PCB design and gerber files. A PDF with the schematics can be found here. The design consists of a few connectors, some resistors and the RP2024-zero. If you just want the Gerbers, you can use gps_interposer_v2.zip. The interposer is connected to the motherboard and to the M12 module with 2x5 pin 0.050” connectors, one male and one female. But because it was difficult to come up with the right height of the male connector, I chose to add 2 female connectors, available here on Mouser and used a loose male-to-male connector between them to make the connection. The trickiest part of the build is soldering 2x5 pin connectors that connects to the motherboard: it needs to be reasonably well positioned otherwise the alignment of the screw holes will be out of whack. I applied some solder past on the solder pads, carefully placed the connector on top of the past, and used a soldering iron to melt the paste without moving the connector. It wasn’t too bad. Under normal circumstances, the board is powered by the 5V rail that’s present right next to the GPS module. However, when you plug in the USB-C cable into the RP2040-zero, you need to make sure to remove that connection because you’ll short out the 5V rail of the S200 otherwise! The board has 2 connectors for the 5V: at the front next to the USB-C connector and in the back right above the 5V of the motherboard. The goal was to plug in the power there, but it turned out to be easier to use a patch wire between the motherboard and the front power connector. You’ll need to the program the RP2024-zero with the firmware of course. You can find it in the sw/rp2040_v2 directory of my gps_interposer GitHub repo. Power Supply Recapping If you plan to deploy the SyncServer in alway-on mode, you should seriously consider replacement the capacitors in the power supply unit: they are known to be leaky and if things really go wrong they can be a fire hazard. The power supply board can easily be removed with a few screws. In my version, the capacitors were held in place with some hard sticky goo, so it takes some effort to remove them. The Future: A Software-Only Solution My solution uses a cheap piece of custom hardware. Alex’s solution currently requires patching some microcontroller firmware and then flashing this firmware with $30 programming dongle. So both solutions require some hardware. A software-only solution should be possible though: the microcontroller gets reprogrammed during an official SyncServer software update procedure. It should be possible to insert the patched microcontroller firmware into an existing software update package and then do an upgrade. Since the software update package is little more than a tar-archive of the Linux disk image that runs the embedded PC, it shouldn’t be very hard to make this happen, but right now, this doesn’t exist, and I’m happy with what I have. The Result The video below shows the 10 MHz output of the S200 being measured by a frequency counter that uses a calibrated stand-alone frequency standard as reference clock. The stability of the S200 seems slightly worse than that of my TM4313 GPSDO, but it’s close. Right now, I don’t have the knowledge yet to measure and quantify these differences in a scientifically acceptable way. References Microsemi SyncServer S200 datasheet Microsemi SyncServer S200, S250, S250i User Guide EEVblog - Symmetricom S200 Teardown/upgrade to S250 EEVblog - Symmetricom Syncserver S350 + Furuno GT-8031 timing GPS + GPS week rollover EEVblog - Synserver S200 GPS lock question Furuno GPS/GNSS Receiver GPS Week Number Rollover Footnotes

Introduction What was the SyncServer S200 Supposed to be Used For? IMPORTANT: Use the Right GPS Antenna! The SyncServer S200 Outside and Inside Installing the Missing BNC Connectors Setting Up a SyncServer S200 from Scratch Opening up the SyncServer S200 The SyncServer File System on the Flash Card Cloning the CompactFlash Card Reset to Default Settings Setting the IP Address Accessing the Web Interface DNS Configuration External NTP Server Configuration Testing your NTP server A Complicated Power Hungry Clock with a Terrible 10MHz Output Coming Up: Make the S200 Lock to GPS References Footnotes Introduction The Silicon Valley Electronics Flea Market runs every month from March to September and then goes on a hiatus for 6 months, so when the new March episode hits, there is a ton of pent-up demand… and supply: inevitably, some spouse has reached their limit during spring cleaning and wants a few of those boat anchors gone. You do not want to miss the first flea market of the year, and you better come early, think 6:30am, because the good stuff goes fast. But success is not guaranteed: I saw a broken-but-probably-repairable HP 58503A GPS Time and Frequency Reference getting sold right in front of me for just $40. And while I was able to pick up a very low end HP signal generator and Fluke multimeter for $10, at 8:30am I was on my way back to the car, unsatisfied. Until that guy and his wife, late arrivals, started unloading stuff from their trunk onto a blanket. There it was, right in front of me, a Stanford Research Systems SR620 universal counter. I tried to haggle on the SR620 but was met with a “You know what you’re doing and what this is worth.” Let’s just say that I paid the listed price which was still a crazy good deal. I even had some cash left in my pocket. Which is great, because right next to the SR620 sat a pristine looking Symmetricom SyncServer S200 with accessories for the ridiculously low price of $60. I’ve never left the flea market more excited. I didn’t really know what a network time server does, but since it said GPS time server, I hoped that it could work as a GPSDO with a 10MHz reference clock and a 1 pulse-per-second (1PPS) synchronization output. But even if not, I was sure that I’d learn something new, and worst case I’d reuse the beautiful rackmount case for some future project. Turns out that out of the box a SyncServer S200 can not be used as a GPSDO, but its close sibling, the S250, can do it just fine, and it’s straightforward to do the conversion. A bigger problem was an issue with the GPS module due to the week number rollover (WNRO) problem. In this and upcoming blog posts, I go through the steps required to bring a mostly useless S200 back to life, how to add the connectors for 10MHz and 1PPS output, which allowed it to do double duty as a GPSDO, and how to convert it into a full S250. Some of what is described here is based on discussions on EEVblog forum such as this one. I hope you’ll find it useful. What was the SyncServer S200 Supposed to be Used For? Symmetricom was acquired by Microsemi and the SyncServer S200 is now obsolete but Microsemi still has a data sheet on their website. Here’s what it says in the first paragraph: The SyncServer S200 GPS Network Time Server synchronizes clocks on servers for large or expanding IT enterprises and for the ever-demanding high-bandwidth Next Generation Network. Accurately synchronized clocks are critical for network log file accuracy, security, billing systems, electronic transactions, database integrity, VoIP, and many other essential applications. There’s a lot more, but one of the key aspects of a time server like this is that it uses the Network Time Protocol (NTP), which… … is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. The SyncServer S200 is a stratum 1 level device. The stratum level indicates the hierarchical distance to an authorative atomic reference clock. While it does not act as a stratum 0 oracle of truth, it can derive the time directly from a stratum 0 device, in this case the GPS system. When the GPS signal disappears, a SyncServer can fall back to stratum 2 mode if it can retrieve the time from other stratum 1 devices (e.g. other NTP-capable time servers on the network) or it can switch to a hold-over mode where it lets an internal oscillator run untethered, without being locked to the GPS system. The S200 has 3 oscillator options: a TCXO with a drift of 21ms per day an OCXO with a drift of 1ms per day a rubidium atomic clock with drift of only 25us per day Mine has the OCXO option. It’s clear that the primary use case of the S200 is not to act as a lab clock or frequency reference, but something that belongs in a router cabinet. IMPORTANT: Use the Right GPS Antenna! Before continuing, let’s interrupt with a short but important service message: GPS antennas have active elements that amplify the received signal right at the point of reception before sending it down the cable to the GPS unit. Most antennas need 3.3V or 5V that is supplied through the GPS antenna connector, but Symmetricom S200 supplies 12V! Make sure you are using a 12V GPS antenna! Check out my earlier blog post for more information. The SyncServer S200 Outside and Inside The front panel has 2 USB type-A ports, an RS-232 console interface, a vacuum fluorescent display (VFD), and a bunch of buttons. Click to enlarge VFDs have a tendency to degrade over time, but mine is in perfect shape. Click to enlarge In the back, we can see a power switch for the 100-240VAC mains voltage1, a BNC connector for the GPS antenna, a Sysplex Timer-Out interface, and 3 LAN ports. Let’s see what’s inside: Click to enlarge Under the heatshink with the blue heat transfer pad sits an off-the-shelf embedded PC motherboard with a 500MHz AMD Geode x86 CPU with 256MB of DRAM. Not all SyncServer S200 models use the same motherboard, some of them have a VIA Eden ESP 400MHz processor. Using the front panel RS-232 serial port, I recorded this boot.log file that contains some low level details of the system. The PC is running MontaVista Linux, a commercial Linux distribution for embedded devices. At the bottom left sits a little PCB for the USB and RS-232 ports. There are also two cables for the VFD and the buttons. On the right side of the main PCB we can see a Vectron OCXO, the same brand as the huge OCXO that you can find in the GT300 frequency standard of my home lab. It creates the 10MHz stable clock that’s used for time keeping. A 512MB CompactFlash card contains the operating system. There’s still plenty of room for a Rubidium atomic clock module. It should be possible to upgrade my S200 with a Rubidium standard, but I didn’t try that. At the top left sits a Furuno GT-8031 GPS module that is compatible with Motorola OnCore M12 modules. There are a bunch of connectors, and, very important, 3 unpopulated connector footprints. When looking at it from a different angle, we can also see 6 covered up holes that line up with those 3 unpopulated footprints: Click to enlarge Let’s cut to the chase and show the backside of the next model in the SyncServer product line, the S250: Those 6 holes holes are used for the input and output for the following 3 signals: 10MHz 1PPS IRIG We are primarily interested in the 10MHz and 1PPS outputs, of course. The BNC connectors may be unpopulated, but the driving circuit is not. When you probe the hole for the 10MHz output, you get this sorry excuse of sine wave: There’s also a 50% duty cycle 1PPS signal present on the other BNC footprint. Installing the Missing BNC Connectors The first step is to install the missing BNC connectors. They are are expensive Amphenol RF 031-6577. I got 3 of them for $17.23 a piece from Mouser. Chances are that you’ll never use the IRIG port, so you can make do with only 2 connectors to save yourself some money. You need to remove the whole main PCB from the case, which is a matter of removing all the screws and some easy to disconnect cables and then taking it out. The PCB rests on a bunch of spacers for the screws. When you slide the PCB out, be very careful to not scrape the bottom of the PCB against these spacers! Next up is opening up the covered holes. The plastic that covers these holes is very sturdy. It took quite a bit of time to open them up with a box cutter. The holes are not perfectly round: they have a flat section at the top. Open up the holes as much as possible because the BNC connectors will have to go through them during reassembly and you want this to go smoothly without putting strain on the PCB. The end result isn’t commercial product quality, but it’s good enough for something that will stay hidden at the back of the instrument. Installing the BNC connectors is easy: plug them in and solder them down… Due to the imperfectly cut BNC holes, installing the main PCB back into the chassis will be harder than removing it, so, again, be careful about those spacers at the bottom of the case to prevent damaging the PCB! The end result looks clean enough: Setting Up a SyncServer S200 from Scratch My first goal was to set up the SyncServer so that it’d be synchronized to the GPS time and display the right time on the display. That should be a pretty simple thing to do, but it took many hours before I got there. There were 3 reasons for that: due to the WNRO issue, the SyncServer didn’t want to lock onto the GPS time. the default IP addresses for the Symmetricom NTP servers aren’t operational anymore. But that wasn’t clear in the status screen. when I tried alternative NTP servers, they couldn’t be found because I hadn’t configured any DNS servers. configuring the SyncServer to get its IP using DHCP is a bit of nightmare. My focus was first on the GPS and then the NTP part, but here I’ll do things in the opposite order so that you get somehwere without the kind of hardware hacking that I ended up doing. Opening up the SyncServer S200 Just remove the 4 black screws at the top of the case and lift the top cover. I wish other equipment was just as easy. The SyncServer File System on the Flash Card The S200 uses a 512MB flash card to store the OS. I wanted to have a look at the contents and make a copy as well so that I wouldn’t have to worry about making crucial mistakes. I bought a compact flash card reader on Amazon for $8. After plugging in the drive: $ df /dev/sdb7 97854 2 92720 1% /media/tom/_tmparea /dev/sdb2 8571 442 7683 6% /media/tom/_persist /dev/sdb5 173489 69985 94256 43% /media/tom/_fsroot1 /dev/sdb6 173489 69986 94255 43% /media/tom/_fsroot2 In my case, the drive is mounted on /dev/sdb but this will probably be different for you. The flash card has 4 different partitions. I did some digging to understand how the system works. OS partititions _fsroot1 and _fsroot2 The _fsroot1 and _fsroot2 partitions contain copies of the OS itself. Before making any changes on my system, I checked the chronosver file that resides in the root directory of each partition: cat _fsroot1/chronosver # # SyncServer version # # $Date: 2010-12-08-093436 $ # # The format is Major.Minor Version=1.26 # # For internal identification # Revision=$ProjectRevision: Last Checkpoint: 1.666.10.3420934 $ and: cat _fsroot2/chronosver # # SyncServer version # # $Date: 2010-12-08-093436 $ # # The format is Major.Minor Version=1.26 # # For internal identification # Revision=$ProjectRevision: Last Checkpoint: 1.666.10.3420934 $ The versions are identical and indicate that version 1.26 of the system is installed. Later versions 1.30 and 1.36 are available. When you install those, you’ll see that only 1 of the partitions gets updated, so what’s happening is that one _fsroot partition gets updated and the system boots the newest version. Except when doing an OS upgrade, the _fsroot partitions on the flash card are always mounted as read-only, even when making system configuration changes. Persistent configuration partition _persists The _persist partition contains a tar file of the /var and /etc directories with configuration data. When you make changes through the web interface, the changes end up here. ll _persist/ total 445 drwxr-xr-x 2 root root 1024 Jan 2 2006 ./ drwxr-x---+ 7 root root 4096 Jun 23 17:40 ../ -rw-r--r-- 1 root root 2059 Dec 8 2010 downgradelist -rw-r--r-- 1 root root 50 Jan 1 2006 persist-1.2.md5 -rw-r--r-- 1 root root 440320 Jan 1 2006 persist-1.2.tar -rw-r--r-- 1 root root 2062 Dec 8 2010 upgradelist The _fsroot partitions contain /etc and /var directories as well, but when mounted on the real system, the contents of these directories come from the tar file. However, when you reset the system back to default values, it restores back to the values in the _fsroot partition. System upgrade staging area _tmparea The _tmparea partition is used as a staging area when upgrading the system. When you use the web interface to upload a new version, the file gets stored here before one of the _fsroot directories gets overwritten. Cloning the CompactFlash Card You don’t really need a second flash card: a full disk copy of the contents of the original card can be saved to your PC and restored from there, but I found it useful to have a second one to swap back and forth between different flash cards while experimenting. There is a plenty chatter in the EEVBlog forum about which type of flash card does or doesn’t work. It must a CompactFlash card with fixed disk PIO instead of removable DMA support and it’s also good to use one that is an industrial type because those have long-life SLC-type flash memory chips that allow more read-write operations and a higher temperature range, but that’s where the concensus ends. Some people aren’t able even make a 512MB card work. Others claim that their 512MB card worked, but that larger capacity ones didn’t. I bought this 512MB card and it worked fine, and this 1GB one worked fine too. I ran into none of the issues that some other people seem to have. I wonder if it has to do with the kind of embedded PC motherboard that my system is using: remember that there are different versions out there. Windows people should use something like HDD Raw Copy Tool to make a copy, but it’s just as easy to use the standard Linux disk utilities. Copy the whole flash card contents to a file on your Linux machine like this: $ sudo dd if=/dev/sdb of=flash_contents_orig.img bs=1M [sudo] password for tom: 488+1 records in 488+1 records out 512483328 bytes (512 MB, 489 MiB) copied, 40.6726 s, 12.6 MB/s If you have a second flash card, copying the original contents to that one works the same way: $ sudo dd if=flash_contents_orig.img of=/dev/sdb bs=1M && sync 488+1 records in 488+1 records out 512483328 bytes (512 MB, 489 MiB) copied, 0.143977 s, 3.6 GB/s Notice the sync command at the end: if you don’t do that, you’ll get your command line back right away while the copy operation is going on in the background. I didn’t want to accidentally unplug the thing before it was done. Unmount the drive after copying: sudo unmount /dev/sdb You’re all set now to plug the old or the new CF card back into the S200. Reset to Default Settings Chances are that your SyncServer was used before and that it didn’t come in its default state. That can be a problem, for example when the passwords are different than the default one. The procedure to reset the device back to factory settings is described on page 120 of the user manual. After opening the device, set jumper JP4 on the motherboard. It’s located at the bottom right of the motherboard, next the CR2032 lithium battery. The jumper pins have a smaller than usual 0.1” pitch so you can’t use a standard jumper. I used logic analyzer grabbers to make the connection: Install the jumper connection, power up the device, wait for 100 seconds, power the device back off, and remove the connection. When powered up, there won’t be any messages or visual indications to tell you that defaults have been restored, you just have to wait long enough. Setting the IP Address Configuration of the SyncServer happens through a web interface, so the next step is to setup a network connection. The user guide recommends assigning static IP addresses instead of DHCP because NTP associations and authentication may rely on static network addresses. This was good advice because I was never able to get the SyncServer to work with DHCP… While there are 3 LAN ports, only port 1 can be used for web management. You’ll need to set the IP address, the gateway address mask, and the gateway addresses through the front panel. I used the following settings, because that’s how my home is configured: IP address: 192.168.1.201 Gateway address mask: 255.255.255.0 Gateway IP address: 192.168.1.1 Values for your network may be different. If your home network uses DHCP for all other devices, it’s best to tell your router to exclude the chosen static IP address from the list of dynamically assignable IP addresses. I explain in my HP 1670G blog post how to this with an Asus router. Once LAN port 1 has been enabled an configured, plug in a network cable. The network LED on the front panel of the device should turn green. If all went well, you can now ping the SyncServer from your host machine: ping 192.168.1.201 PING 192.168.1.201 (192.168.1.201): 56 data bytes 64 bytes from 192.168.1.201: icmp_seq=0 ttl=64 time=2.172 ms 64 bytes from 192.168.1.201: icmp_seq=1 ttl=64 time=3.221 ms 64 bytes from 192.168.1.201: icmp_seq=2 ttl=64 time=2.195 ms ... Some DHCP notes If against the general advice, you still decide to use DHCP, here are some notes: when you switch LAN port 1 to DHCP through the front panel for initial configuration, the web interface won’t work. Your first configuration round must happen with a static IP address. It’s during that round that you must tell the device that further web configuration is allowed over a DHCP enabled LAN port 1. when DHCP is enabled and a network cable is not plugged in when powering up, the SyncServer bootup time increase by several minutes. This is because the SyncServer is waiting for IP address assignment until a certain time-out value is reached. DHCP IP address assignment only happens at initial bootup. If you plug in the network cable when the device is already up and running, no IP address will be assigned. Accessing the Web Interface Going forward, most web interface screenshot will show a header that says “SyncServer S250” instead of “S200”. Modding the device to an S250 is something that will be discussed in a future blog post. With your browser, you should now be able to access the web interface by going to IP address that you assigned: When using default settings, the following credentials are active: Username: admin Password: symmetricom DNS Configuration Now is the time to assign DNS servers. This step is crucial if you want your SyncServer to work with external NTP servers, since most of them want you to use a hostname instead of an IP address. Using the web interface, go to “NETWORK” and then the “Ethernet” tab, and then “Add a DNS Server”. I’m using Comcast/Xfinity, which has a DNS server at address 75.75.75.75, so that what’s I used. You’ll need to find the appropriate DNS server for your case, or you can use Google’s Public DNS service at address 8.8.8.8. If you set up the DNS server correctly, you should now be able to ping public Internet servers with the “Ping” tab. For the last 35 years, I’ve used “www.yahoo.com” as my ping testing address. External NTP Server Configuration The default settings of my SyncServer make it use static IP addresses 69.25.96.11, 69.25.96.12, and 69.25.96.14 for external NTP requests. Symmetricom used to have NTP servers there, but they are not operational anymore. You must replace these static IP addresses by other NTP servers. A popular option is ntp.org which offers a free NTP server service. Another alternative are the NTP servers from NIST, the National Institute for Standards and Technology. Or do like I did, and use both! For ntp.org, use the following addresses: 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, or 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org if you want to force using a server that is located in the US. For NIST, I used time.nist.gov. Here is how you fill in the panel to add a server: And here’s how it looks like after all servers were added: Click “Restart” when all servers have been added, and check out “NTP - Sysinfo” to verify that the SyncServer can successfully talk to the external servers: The “St/Poll” columns shows the stratum level and polling time of the servers. In the example above, 4 NTP servers with stratum levels 1 and 2 are being polled. The stratum level will vary because NTP.org rotates through a pool of servers with different levels. If there’s a configuration issue, you’ll see a stratum level of 16. Testing your NTP server After setting up the external NTP servers, your SyncServer can now itself be used as an NTP server. Using Linux, you can query the date from the SyncServer with the ntpdate tool as follows: ntpdate -q 192.168.1.201 server 192.168.1.201, stratum 16, offset -0.019111, delay 0.02856 4 Jun 23:20:32 ntpdate[230482]: no server suitable for synchronization found Initially, the SyncServer may report itself as an unsynchronized stratum 16 device because NTP server synchronization can take a bit of time, but after around 15 minutes, you’ll get this: ntpdate -q 192.168.1.201 server 192.168.1.201, stratum 2, offset -0.034768, delay 0.02989 4 Jun 23:23:21 ntpdate[230491]: adjust time server 192.168.1.201 offset -0.034768 sec The Sync status LED and web page indicator are now be yellow instead of red: you now have something that should be good enough for time serving needs that don’t require nano-second level accuracy. Don’t worry about the NTP LED not being constanstly green: it only lights up when the SyncServer polls the external server and that only happens every some many seconds. On the front panel and on web interface under “STATUS -> Timing”, you’ll see that the current sync source is NTP and that the hardware clock status is “Locked”. On a S200 you will only see the “GPS Input Status - Unlocked”, there won’t be any IRIG, 1 PPS or 10 MHz input status. Those are S250 features that will be unlocked in a later blog post. A Complicated Power Hungry Clock with a Terrible 10MHz Output All that’s left now to display the correct local time is to set the right time zone. You can do this under “Timing” -> “Time Zone”. Once you’ve done that, you can use your SyncServer as a slightly overcomplicated living room clock: It’s power hungry too: mine pulls roughly 19W from the power socket. But what about the 10MHz output? After booting up the S200 when the device is not yet locked to NTP, the Vector OCXO is free-running with a frequency of 9,999,993MHz, an error of 7Hz2 which makes it unusable for the lab. One would expect this error number to go down when the device is locked to NTP, a bad time reference is better than no reference at all, but that’s not the case: as soon as the device locked to NTP, the 10MHz output locked at 10,000,095Hz. The error increased with an order of magnitude! However, since NTP is part of stratum hierarchy, the time should average out to 10MHz, and indeed, the behavior was bimodal: after around 20 minutes, the 10MHz output frequency switches to 9,999,001Hz, which doesn’t quite average to 10MHz, but that’s because the frequency counter was connected to a non-disciplined reference clock. For the SyncServer to be usable as a lab timing reference, it clearly needs that GPS input. It will also be interesting to check the hold-over behavior of the OCXO after it was first locked to the GPS system. Coming Up: Make the S200 Lock to GPS In the next blog post, I’ll describe how I was able to make the S200 lock at GPS satellites which makes it a stratum 1 device. This took a lot of work and designing an interposer PCB to work around the GPS WNRO issue. Stay tuned! References Microsemi SyncServer S200 datasheet Microsemi SyncServer S200, S250, S250i User Guide Footnotes There are also versions for telecom applications that are powered with 40-60 VDC. ↩ This number will be different for your unit. ↩

TLDR: It’s a useless technology demo. Introduction Rules of Engagement Test Ride 1: from Kings Beach to Truckee (11 miles) Test Ride 2: I-80 from Truckee to Blue Canyon (36 miles) Test Ride 3: from West-Valley College to I-85 Entrance (1 mile) Conclusion Introduction In the past months, Tesla has been offering a free, one-month trial of their full self-driving (FSD) system to all current owners. It looks like they are rolling this out in stages, because I only got mine only a few days ago. I’ve had a Model Y for more than 3 years now, well before Elon revealed himself as the kind of person he really is, and I’ve been happy with it. The odometer is now well above 50,000 miles, a significant part of those were spent on I-80 while driving between the SF South Bay and the Lake Tahoe area. For long distance interstate driving, autopilot (in other words: lane centering and adaptive cruise control) has been amazing. I use it all the time, and have little to complain about. Early on, I had one case where the autopilot started slowing down for no good reason, but since I distrust these kind of systems and since phantom braking has been reported quite a bit in the press, I try to keep attention to what the car is doing at all times. I immediately pressed the accelerator, and that was that. I don’t know how prevalent phantom breaking really is. One time is still too many, and disconcerting. It doesn’t help that you can’t anticipate it, there must by a bunch of different factors to trigger it: version of the car, weather, light conditions etc. All I can say, after so many miles, is that autopilot has been amazing for me. When I buy my next car, my requirements will be simple: I want an EV, an extensive charger network along I-80, and an autosteer that’s at least as good as what I have today. Let’s hope there’ll be decent Tesla alternatives by then. But let’s get to FSD. During his last financial conference call, Musk claimed that he wants to focus more on robo-taxis. With no driver in the car at all, such a system better be pretty much flawless. But with the YouTube videos that are out there, often posted by Tesla fans, that show the system making ridiculous errors, I highly doubt that the system is close to ready. I would never pay for FSD, not only do I not trust it, I also don’t really see the point, but with with a free trial, I couldn’t resist checking it out. Here are my impressions. Rules of Engagement During 3 short tests, I watched FSD the way a helicopter parent watches a toddler who’s first exploring the world: allow it do what it wants to do, but intervene the moment you feel things are not going the way you like it. It’s common on social media to see comments like this: “if the driver had waited a bit more, FSD would still have corrected itself.” I’m having none of that. The moment I’m sensing it’s on its way to do something, anything, wrong, I intervene. While it’s possible that benign cases are dinged as interventions, I don’t think any what I describe below can be considered as such. They were real mistakes that should never have happened. Test Ride 1: from Kings Beach to Truckee (11 miles) I first switched on FSD for an 11 mile drive from a mountain biking trailhead in Kings Beach to the I-80 entrance in Truckee, with a stop at a gas station to get some snacks. Click to open in Google Maps This is not a complicated tasks. Other than the gas stop, it’s just driving straight along state route 267 with a 3 traffic lights. What could possibly go wrong? Well, FSD managed to make 2 mistakes. Mistake 1: select the wrong exit lane During the first mistake, instead of turning right at the gas station, it made the decision to prepare to exit one street early, switched on its indicator, and started moving to the right exit lane. Note that there is no way to get to the gas station through that first exist. If I hadn’t immediately interrupted that maneuver (see Rules of Engagement), I assume it would have corrected itself eventually and gone back onto the main lane. But if I had been the driver behind, I’d have questioned the antics of the driver in front of me. FSD managed to screw up its very first maneuver. Not a good look. Mistake 2: selecting the right turn lane when going straight The second mistake happened less than a mile later. At the intersection with Old Brockway Rd, the car was supposed to continue straight. There are 3 lanes at the traffic light: left, middle, and right, and only the middle lane can be used to go straight. For whatever reason, FSD initiated a move to go to the right lane. Another case where I’m sure it would have corrected itself eventually, but it’s clear that the system had no clue about the traffic situation in front of it. While both cases are not life-or-death situations, it’s truly impressive that FSD managed to make 2 easily avoided mistakes before my first 10 miles of using it! Test Ride 2: I-80 from Truckee to Blue Canyon (36 miles) For the second test, my wife reluctantly gave me permission to try out FSD for interstate driving, which should be its best case scenario. Click to open in Google Maps It’s a bit disconcerting to see the car make a decision to change lanes to pass someone, but I guess that something you’ll get used to. But what was baffling was the way in which it behaved worse than autopilot. There were two nearly identical cases, where the 2-lane road was dead straight, with excellent paint marks, and with cars right of me, yet FSD made nervous left-right oscillation-like corrections that I have never experienced before in autopilot mode. It was not a case of FSD wanting to change lanes, no right indicator was ever switched on. The first time, my wife questioned what was going on. The second time, on a section just past the Whitmore Caltrans station near Alta, she ordered me to switch off FSD. In the past 3 years, she never once asked me to switch off autopilot. One would think that autopilot and FSD have the same core lane tracking algorithms, but one way or the other the experience was radically different. I switched back to autopilot. The remaining 3 hours were uneventful. Test Ride 3: from West-Valley College to I-85 Entrance (1 mile) The final test happened yesterday, while driving back from the Silicon Valley Electronics Flea Market back home. These are always held on a Sunday, start very early at 6am, and I’m usually out before 9am, so there’s almost nobody on the road. Click to open in Google Maps FSD managed to turn right out of the parking lot just fine and get past the first traffic light. The second traffic light has a don’t-turn-on-red sign. The light was red, the Tesla came to a full stop, and then pressed on the gas to move on while the light was still red. (According to my colleague, police often lay in wait at this location to catch violators.) By now I fully expected it to make that mistake, so I was ready to press the brake. Conclusion The way it currently behaves, FSD is a system that can’t be trusted to make the right decisions. It makes the most basic mistakes and it makes many of them. Without FSD, you pay attention to the road and everything else is within your control. With FSD, you still need to pay attention but now there’s the additional cognitive load to monitor an unpredictable system over which you don’t have direct control. Forget about just being focused, you need to be hyper-focused, and you need to pay $99 per month or a one time of $12,000 for the privilege. With the limited functionality of autopilot, you hit the sweet spot: adaptive cruise control and lane centering work reliably, and you don’t need to worry about any other mischief. Maybe one day I’ll be able to drive to Lake Tahoe by typing in the address, sit back, take a nap, or play on my phone. Until then, it’s just a fancy technology demo with little practical value.