Jeff Epler's blog

Pi Zero W USB Proxy

I'm not sure exactly what to call it, but here's a little something I set up this weekend.

On my Linux desktop, I have occasional problems where being stopped at the debugger prompt for a plugged-in USB device hoses the whole computer. The problem waxes and wanes but on a particularly frustrating day I decided that maybe a Pi was the answer to the problem.

Using screen I can access the USB-serial devices on the pi, and using sshfs I can access the files. If the whole pi freezes, I can just reboot it with essentially no harm done.

I selected a Pi Zero W with a Zero4U hub and Adafruit MiniPiTFT 1.14" attached. To a base raspbian lite system I added some software, including tio, udiskie, screen, and Adafruit Blinka; enabled ssh access and disk mounting by the pi user, and set up GNU screen and my custom script for the LCD which is (confusingly) also called screen.

The screen shows information about each of the 4 USB connectors. In brackets "S" is shown if there is a serial device; "D" is shown if there's a partitioned disk, "d" if there's an unpartitioned disk; and "M" is shown if it is mounted. After that, the device name is shown.

Automount can be toggled with the B button (silk screen 23) and any non-mounted disks can be mounted with the A button (silk screen 24)

So far I've only used it lightly, but if it prevents a single crash of my desktop, it will be worth it.

This isn't a detailed guide so a lot of the setup is omitted. However, here are the scripts that are the essential parts:

[permalink]

GPS and relativity

At the time of launch of the first NTS-2 satellite (June 1977), which contained the first Cesium clock to be placed in orbit, there were some who doubted that relativistic effects were real. A frequency synthesizer was built into the satellite clock system so that after launch, if in fact the rate of the clock in its final orbit was that predicted by GR, then the synthesizer could be turned on bringing the clock to the coordinate rate necessary for operation. The atomic clock was first operated for about 20 days to measure its clock rate before turning on the synthesizer. The frequency measured during that interval was +442.5 parts in 10¹² faster than clocks on the ground; if left uncorrected this would have resulted in timing errors of about 38,000 nanoseconds per day. The difference between predicted and measured values of the frequency shift was only 3.97 parts in 10¹², well within the accuracy capabilities of the orbiting clock. This then gave about a 1% validation of the combined motional and gravitational shifts for a clock at 4.2 earth radii.

An earlier document, NTS-2 Cesium Bean Frequency Standard for GPS states (errors mine)

The NTS-2 program office at NRL was tasked by GPS NAVSTAR program office to generate a 10.23 MHz frequency for use with the Pseudo Random Noise System (PRNSA) onboard the NTS-2 Satellite. Frequency requrements for the NTS-2 Orbit Determination and Tracking Systerm (ODATS) was 5MHz with a tunable ΔF offset of approximately +1 × 10^-9 with a resolution of approximately 3 × 10^-12. The ΔF offset was to compensate for relativistic effects and could not be accomplished by offsetting the cesium standard which has a tuning range of ± 1 × 10^-11. The relativistic offset was later added to the 10.23MHz requirement.

Citing "Alley, C., “Proper time experiments in gravitational fields with atomic clocks, aircraft, and laser light pulses”, in Meystre, P., and Scully, M.O., eds., Quantum Optics, Experimental Gravitation, and Measurement Theory", we have

There is an interesting story about this frequency offset. At the time of launch of the NTS-2 satellite (23 June 1977), which contained the first Cesium atomic clock to be placed in orbit, it was recognized that orbiting clocks would require a relativistic correction, but there was uncertainty as to its magnitude as well as its sign. Indeed, there were some who doubted that relativistic effects were truths that would need to be incorporated!

Alley: (again, errors mine)

There was considerable uncertainty among the Air Force and contractor personnel designing and building the system whether these effects were being correctly handled, and even, on the part of some, whether the effects were real. The last group was not satisfied until a gravitational frequency shift was measured with a GPS test satellite called NTS-2 by a group at the Naval Research Laboratory in 1977.

So, left without a citation to follow, I am still in doubt as to whether there were doubters of general relativity on the project. Rather, except for the resigned voice that the offset was "later added" everything seems consistent with: GR (at least once the issue was raised) was assumed correct, but for other reasons (such as synchronizing it with the ground based cesium clocks before launch) the system was built with two modes, and that a story about doubters grew in the retelling.

Files currently attached to this page:

[permalink]

Some notes on the Si5351a

Si5351 "XA" can be driven by a clock signal (25/27 MHz, 1Vpp)
    source: [2] p23, figure 14

Internet commenters report success driving it with a much wider frequency range
as well as successfully exceeding the specified PLL range.  Inputs from 3MHz to
146MHz and PLL frequencies from 168 to 1168MHz were tested.
    source: [1]

intermediate PLL frequency:
    600 to 900 MHz [3] p2
    divider range 15 + 0/1048575 .. 90
    "integer divide" FBA_INT flag is for _EVEN_ integers [3] p4

multisynth:
    valid dividiers are 4, 6, 8, 8 + 1/1048575 ... 2048
    "integer divide" FBA_INT flag is for _EVEN_ integers [3] p6

[1]: http://www.simonsdialogs.com/2018/11/si5351a-any-frequency-cmos-clock-generator-and-vco-specifications-myths-and-truth/
[2]: https://www.silabs.com/documents/public/data-sheets/Si5351-B.pdf (rev 1.3)
[3]: https://www.silabs.com/documents/public/application-notes/AN619.pdf Manually Generating an Si5351 Register Map rev 0.8

[permalink]

Si5351 Frequency Planner in Python

The basic design of the Si5351 is that an incoming frequency is first multiplied to create a high internal frequency (nominally in the range from 600MHz to 900MHz), then divided to create an output frequency. The multipliers and dividers have restrictions on their ranges, there are just 2 PLLs but 3 output clocks, and certain types of configurations (e.g., "divisor is an integer multiple of 2") are said to give lower jitter outputs than others.

The datasheet advising users on how to create their own register values is very complicated and some of the parts resist comprehension even after multiple readings. Thie chip maker Silicon Labs provides a graphical closed source Windows program for generating register maps, though some internet commenters regard it as buggy.

This program represents my own effort to create a frequency planner. It neglects some datasheet rules, mostly related to output frequencies above 50MHz or so. It tries to

• Favor lower-jitter configurations where possible
• Favor making the first-listed frequency as accurate as possible
• Try each combination of ways to allocate output clocks to the PLLs
• Obey the datasheet restrictions as I've understood them
• Do all arithmetic as infinite precision arithmetic, not floating point

• Implement the divisor rules for extremely fast clocks
• Implement the divisor rules for higher numbered outputs on 20QFN packages

For exact input clocks such as 25MHz, it is surprisingly hard to find a "plausible" frequency that is inexact, and even harder to find a "plausible" frequency that is less exact than your reference clock. I didn't actually find a case where the error is not much smaller than the frequency stability of any reference I'd plausibly have access to.

(Of course, if you measure your reference clock as 25MHz + 13.37Hz and plug that in as the --input-freq then almost everything is related to that clock inexactly, so the fact that the clocks will still be really, really close to the requested value is very nice.)

It does not directly create a register map, but the values shown are easy enough to convert to the form used in the CircuitPython adafruit_si5151 library. Sadly, as CircuitPython does not support the fractions module, it's not currently feasible to run this code on a CircuitPython board directly controlling the si5351 chip.

Example:

Generate 315M/88 (NTSC colorburst), 4.43361875M (PAL colour carrier), 25.8048M (UART clock) all exactly from a 25MHz reference clock or crystal. However, the PAL colour carrier will have more jitter since it uses a fractional divisor:

$ ./party.py 315M/88 4.43361875M 25.8048M
Input frequency: 25000000 (25000000.0)
Frequency plan score: 10.38

PLL A:
Frequency plan type: Fractional multiplier, double integer divisor (1)
Multiplier = 126/5 (25.2)
Intermediate frequency = 630000000 (630000000.0)

Desired output frequency: 39375000/11 (3579545.4545454546)
Divider = 176 (176.0)
Exact
r_divider = 0 (/ 1)


PLL B:
Frequency plan type: Fractional multiplier, fractional divisor (5)
Multiplier = 12059443/500000 (24.118886)
Intermediate frequency = 602972150 (602972150.0)

Desired output frequency: 17734475/4 (4433618.75)
Divider = 136 (136.0)
Exact
r_divider = 0 (/ 1)

Desired output frequency: 25804800 (25804800.0)
Divider = 12059443/516096 (23.366666279141864)
Exact
r_divider = 0 (/ 1)

Generate pi MHz from a 25MHz reference clock or crystal (error: 27.8 nano Hz)

$ ./party.py 3.1415926535898M
Input frequency: 25000000 (25000000.0)
Frequency plan score: 1.00

PLL A:
Frequency plan type: Fractional multiplier, fractional divisor (5)
Multiplier = 24 (24.0)
Intermediate frequency = 600000000 (600000000.0)

Desired output frequency: 15707963267949/5000000 (3141592.6535898)
Divider = 40306053/211042 (190.98593171027568)
Actual output frequency: 42208400000000/13435351 (3141592.653589772)
Relative Error: -8.83757e-15
Absolute Error: 2.78e-08Hz
r_divider = 0 (/ 1)

The source is available in a github gist:

[permalink]

Quad CharliePlex FeatherWing hack

Adafruit makes these neat "CharlieWing" displays that allow you to control a 15x7 LED matrix using the I2C bus. I2C uses two signal wires (called SDA and SCL, for Serial DAta and Serial CLock), and can connect multiple devices as long as they have different addresses.

I noticed that the bigger brother of this device, with a whopping 144 LEDs, could be configured for 4 different I2C addresses, while this one could only be configured for 2.

Or could it?

read more…

Minimal Time-Zone Handling for CircuitPython

For my clock, I want automatic handling of Daylight Saving Time. However, CircuitPython doesn't build in any distinction between local and UTC time, and fitting in the entire Python3 datetime module or an Olson time zone database is simply not going to happen. What can we do that is simple enough to fit, but can represent the reality of timezones where I live?

read more…

Calibrating the DS3231 and PCF8523 RTCs

The DS3231 and PCF8523 real time clocks (RTCs) can both be calibrated by writing various register values. To follow the calibration procedures you'll need a frequency counter you trust, with at least 6 digits to calibrate the PCF8523 and 7 digits to calibrate the DS3231. (It also has to operate at the comparatively low frequency of 32.768kHz; a common inexpensive 8-digit frequency counter such as the "SANJIAN STUDIO" has a minimum of 100kHz so it's not usable for this purpose) I use an old HP 5315B universal counter that has been calibrated against GPS time.

read more…

Helpful Scripts for CircuitPython & Real Time Clocks (RTCs)

I have used two different RTCs in the Feather form factor. One has the PCF8523, and the other has the DS3231. The former has an SD card slot while the latter has higher precision including a temperature-compensated crystal oscillator.

read more…

Raspberry Pi Gross Hacks

Software I want: Self-hosted 3D-printing static site

Black Lives Matter

Updates

Six Years of Prius (2013) Fuel Efficiency

Future directions for SCORPION STARE: 2022 Grant Recipients

Yet another Raspberry Pi Stratum 1 NTP server

Precision vs Accuracy: A Clock