Signal and noise

Xona X5 data

2025-08-17T12:45:00-04:00

The 10230-chip Xona X5 data code has been added to my Github repository:

https://github.com/pmonta/GNSS-DSP-tools

The signal is somewhat different from a "normal" GNSS data signal in that each code period has the code shifted by an amount equal to the data symbol sent during that period. Shown below is a plot of the correlation-peak positions over an 800-ms interval:

Although the technique of shifting the code is described in one of Xona's patents [1], this structure still puzzled me for a while. The first portion of this signal, from the beginning out to 150 ms, has a nearly-repeating structure across four code periods. This bit of bad luck caused me to wonder: is the data code actually of length 4*10230 chips (4 ms)? Why would there be such strong correlation peaks at 1 ms offsets within this longer code? But no, the code is 10230 chips and 1 ms after all, and the apparent 4 ms structure is just the pattern of data at that time (the data being of unknown organization). Later in the recording, at around 600 ms, we see the data channel being used to its full extent, with apparently random code shifts at each millisecond.

The span from minimum to maximum of these peak-shifts is about 1746 samples or about 255.3 chips. So it seems clear that the code is shifted to one of 256 offsets each millisecond, resulting in a data-payload rate of 8000 bits/second. Theoretically, all 10230 shifts could have been used, resulting in a higher data rate, but perhaps 8 bits is enough (and more convenient than 13 or 13.32 bits).

References

[1]	US patent US11899120B2, Figure 16E. https://patents.google.com/patent/US11899120B2/en

Xona X1 pilot and data tracking

2025-08-11T18:30:00-04:00

I've added the Xona X1 pilot and data codes to my Github repository supporting the various GNSS signals:

https://github.com/pmonta/GNSS-DSP-tools

There are also preliminary acquisition and tracking programs similar to the others. In the case of the Xona signals, though, they really need either external aiding or a third-order loop---with current settings, the carrier loop maintains lock but with a nonzero steady-state phase error due to the high dynamics.

A 13-second track of X1 data:

A closeup of one of the data frames:

A frame of data is sent every second, with each frame using about half of the 1-second slot. (No FEC yet?) Some multipath is visible (causing the amplitude fluctuations), even over this short time interval. It's hard to make much of the data without an ICD. Maybe I should invert the data spreading code, since it seems semantically more likely that most of the data bits would be 0 rather than 1.

Xona spreading codes

2025-08-08T12:30:00-04:00

The spreading code for what appears to be the pilot component of Xona's X1 signal is shown here:

After carrier wipeoff, the signal is sampled at 1.023 MHz and coherently integrated for 800 ms. The code chips are clearly apparent, and they have a 4-level structure because of the FQPSK modulation. After slicing, the spreading code (modulo a sign ambiguity) in hexadecimal is:

0038ec4d442b85abe805542f16e694c29cc0d5666b058f726eb211519888c562f848f3b5a65dd2d1674fd6d0439c89e1b1a779018e56bded20a3a378255d098c1f1b534347d499e522ea05c646b97e6ddf64b0ca9e8973d808e1f893aecdf2d841d52f5fd2430ee04e295e64f9fe49450f56f4d9f76fdff6d96506706e2078fe

Using this code, weaker signals can now be acquired and tracked. It is not a Gold code; I don't know how it is derived.

Wiping off the spreading code reveals the secondary code with period 100 ms:

0100010011110111001011100110010010111111011100011010111010001100111111101111100101001000011110000001

Approximate values of the Doppler and Doppler rate were derived from the space-track.org orbit. Since the satellite is in LEO, the Doppler is quite high compared to MEO satellites, and even the Doppler rate is significant over the 800 ms interval. Chip alignment was obtained by trial and error, and the 1 ms alignment can be found by watching for near-zero-correlation remnants at the edges and then removing them by correcting the offset. (A small code misalignment would not do much harm, but it's nice to try to get all 1023 chips correct.)

Incidentally, the chipping rate and code length are mentioned in an ION GNSS+ abstract [1] but nowhere else that I know of. Since it's the same as GPS C/A, it would be a natural first guess, but this brief mention in the literature at least serves to remove one set of variables.

The 800 ms recording is linked below. See the previous blog post for details (sampling rate, center frequency, etc.).

http://pmonta.com/data/xona-20250807-191936.iq

I have found a few whispers of L5 power near 1216 MHz that occur at the same time as a satellite pass. From the FCC filing I was expecting a 10 Mchip/s signal centered at 1191 MHz, so I'm not sure what to make of this. Its double-sided bandwidth is around 400 kHz, so again a narrowband signal.

References

[1]	"World’s First Authenticated Satellite Pseudorange from Orbit", Jason Anderson, Xona Space Systems. https://www.ion.org/gnss/abstracts.cfm?paperID=16052

GNSS signal from Xona's Pulsar-0 satellite

2025-07-30T22:50:00-04:00

This waterfall plot shows the L1 signal from Pulsar-0:

The frequency is as expected, 1593.322500 MHz give or take the Doppler shift (that is, a nominal carrier frequency of 155.75 times 10.23 MHz), but, curiously, the bandwidth appears to be only ~1.7 MHz rather than the 4 MHz mentioned in their FCC filing [1]. Perhaps this represents additional isolation from nearby services like Galileo PRS.

For total radiated power, I'm guessing "22 dBW" is a typo in their filing and that they really mean 22 W (13.4 dBW). But if they really intend 160 W raining down from LEO range, well, then it's time to increase the dynamic range of my receivers.

The recording with the strongest signal in this pass is available below, though it may not represent the strongest possible signal from the satellite because the recordings are not continuous. The recording is 8-bit signed IQ, 69.984 Ms/s, 200 ms duration, center frequency 1584.754875 MHz, filename-time given in GPS time (UTC + 18 s), observed from Indiana, USA.

http://pmonta.com/data/2025/207/SBTH00USA_2025207191730_L1.iq

Autocorrelation peaks with 1 ms spacing are visible, implying that the signal is not yet encrypted. There's also a dip near the center frequency in the power spectrum, so perhaps the spreading code is not white for some reason.

References

[1]	FCC SAT-LOA-20241215-00282. https://forum.nasaspaceflight.com/index.php?action=dlattach;topic=60273.0;attach=2341527;sess=44407

Compact Disc microscopy, part 2

2023-01-14T02:30:00-05:00

See part 1 here.

In order to capture and decode more bits from the CD's surface, multiple images are needed. Below are 125 images forming a short arc (roughly following the CD's tracks) stitched with Hugin. (Other stitching tools include MIST and Ashlar, though MIST assumes a regular grid structure, so it's not suitable for this case.) The images are spaced by 60 microns, about 40% of the microscope objective's usable field of view. The positioning is not perfectly regular due to the limited precision of the stage.

Here's a zoomable image. The original image and the associated processing code are linked below.

The stitching does quite well, achieving about 0.02 pixels RMS of mismatch between corresponding features in overlapping images. (Hugin works with discrete features rather than image cross-correlation.) This is low enough to not induce significant jitter in the bit clock across the image boundaries.

Once we have the complete image, we can extract a single track for demodulation. As it happens, sampling along a circle is sufficiently accurate (the circle's center and radius were arrived at by trial and error). For larger images, an adaptive tracking scheme will be needed to stay on track, but that's a refinement for another day. This would be analogous to the track servo used in an actual CD player. (The other servo, for focus, is already handled by the microscope's image-acquisition script.)

To acquire and maintain bit sync, the image below is useful. It consists of the track waveform sliced into individual 588-bit frames, then stacked row-by-row into a waterfall plot. The 24-bit frame-sync word, 111111111110000000000011 (or its inverse), is clearly apparent. Any clock error is visible as drift in the bit transitions. In this case, as a quick hack, I assembled a quadratic-spline approximation to the drift by picking a few points by hand in an image editor, then folding this correction into the resampling. Again, for a longer capture, adaptive clock recovery would be needed.

So finally we have about 40 frames, or 20000 channel bits, and this time we have sufficiently many bits to acquire frame sync and decode the inner RS code. (Unfortunately the outer RS code is separated from the inner by about 100 frames of interleaving, so we still can't quite get to final decoded audio samples.)

Below is the sequence of 40 frames in hexadecimal. The first column is the control/data byte (and indeed the pair of sync EFM symbols, S0 and S1, can be seen, although S0 is corrupted with a channel defect), and the other column groups are as follows: 12 bytes of audio, 4 bytes of outer RS parity, 12 more bytes of audio, and 4 bytes of inner RS parity. The red splotches show erasures from invalid EFM codewords.

After decoding the inner RS code (called the C1 code in the specification), the first few codewords are:

01 a7 fc 8b f9 f2 ff 9c 05 3f fe 4c     b0 77 d7 e7     ff ae fb c6 03 62 03 db fb c8 04 ff     39 0d bc 53
fe a1 fe b9 fc c1 00 be 01 ea 03 d3     67 7d 2f 56     01 78 f6 67 01 91 03 41 fa 7c 09 93     98 c4 16 af
ff 4b 00 a1 fd 45 00 db 00 03 05 c7     81 10 c2 4e     01 64 f8 f8 02 4f 02 f8 f9 ff 05 67     75 88 49 a8
00 b8 02 95 fe c3 fe 28 ff b6 02 f9     8e 9e 3c af     01 61 f9 4b ff 26 05 6c f6 4f 03 8f     09 d5 1a 64
fa f1 04 d2 fd f5 fc f2 fd 4f 04 47     07 a7 db 9f     02 48 f5 30 ff 0f 02 65 f4 3e 03 93     b2 09 f0 c7
fb 06 03 15 fd 43 ff c5 fe 59 05 af     57 85 8d b1     06 8a f6 bd fc 17 ff 23 f9 b1 04 46     77 9b 66 fc
fc 6f 03 58 fb a8 02 cc ff ac 04 51     a3 8d b9 3a     06 e5 fa df fc ca 00 37 ff 2c fe 83     70 0d 1e f4
fc 27 04 c7 fc 7f fe c7 00 8e 06 85     4b 0a 8b 65     03 cd fc 04 fa 10 03 e4 00 76 fa 74     0d dc a6 b4
fb 55 00 fb fd 7a f8 94 ff d6 04 80     a7 10 b5 86     00 cb fe da f9 81 00 bc 04 4e fb 50     76 11 f9 c3
fa 52 fd cc fe 3b f9 34 01 e9 01 04     b6 5b eb 93     ff a2 02 a2 f7 4b 01 2b 02 1c f9 73     c6 43 37 a4

Code for all this can be found in my github repository. The repository's Makefile downloads the full stitched image and runs the processing pipeline. The full stitched image is also available here: cd-stitched.png (42k by 12k pixels, 36 MB).

The next step (sigh) is to go all the way around the disc. This will allow a long, continuous spiral to be extracted, and we can finally hear some audio.

Compact Disc microscopy

2022-12-22T11:48:00-05:00

While refining my CNC microscope setup, I thought I'd have a look at some CD surfaces. Unfortunately CDs are not especially useful as calibration artifacts, since the track pitch and channel-bit length can be varied over ~15% ranges and still be in spec (manufacturers played with these parameters to pack more audio onto the disc). Still, it got me interested in the possibility of reading the data using these optical images.

The image below was taken with a Nikon 20x M Plan objective (NA=0.4, 210/0, LWD), a Logitech C270 webcam, and a 3D-printed epi illuminator with microscope-slide beamsplitter, all attached to the carriage of a Lulzbot Taz 4 3D printer:

Some spherical aberration is present. In fact it's a great deal worse if you image through the polycarbonate---a 1.2 mm slab of n=1.55 material is enough to seriously blur the image at this NA. I'd like to find some sort of SA compensator that I could hang on the end of the objective (there is plenty of working distance, ~5 mm). Perhaps just a (spherical) achromat would suffice---I don't want to pay $400 for an Edmund Optics asphere plate. This image is taken from the CD's label side, and there's still ~0.1 mm of polymer acting as a "cover slip". The objective is optimized for an air medium and no cover slip, so this is still suboptimal.

Anyway, here's a section through the image plotted as a waveform.

The eye is open, so slicing detects the following symbols:

0001111100001111100011110001111000001111111000000011000000111111
1100000111000001110000000011111111110000011111110000011110000011
1111110000011110001111000011111000001110000011110000111110000111
0001110001110001110000011111000001111000111000001111100011111100
0001111110000000001110000011100001111000000111111110001110001111
0000011100011100011111110000011110000001110000111111111000011111
0000000001111111000000111100001111000001110000011111111100001110
000011110011110000011100011100001111000000

Decoding the NRZI line code (transition is a "1", no transition is a "0"), the channel bits are:

0010000100010000100100010010001000010000001000000101000001000000
0100001001000010010000000100000000010000100000010000100010000100
0000010000100010010001000100001000010010000100010001000010001001
0010010010010010010000100001000010001001001000010000100100000100
0010000010000000010010000100100010001000001000000010010010010001
0000100100100100100000010000100010000010010001000000001000100001
0000000010000001000001000100010001000010010000100000000100010010
00010001010001000010010010010001000100000

No frame-sync pattern in this short segment (in either direction). I'll have to take several images and stitch them.

A specification for the CD physical format, channel coding, ECC, framing, and metadata is available here:

https://archive.org/details/RedBookAudioRecordingCompactDiscDigitalAudioSystemIEC60908SecondEdition199902ISBN2831846382

Clean version of Logarithmorum Chilias Prima

2022-08-18T12:18:00-04:00

Logarithmorum Chilias Prima is the first table of base-10 logarithms, written by Henry Briggs and published in 1617. I've previously taken a look at the accuracy of the table entries.

I thought it would be neat to have a faithful copy of the original printed version. To this end, the handwritten tutorial pages and tables of differences were removed to pare down to what must have been originally printed: the title page and the 15 pages of main-table entries.

The page images were scanned from EEB microfilm, scaled up, binarized, and the bitmaps hand-edited to remove miscellaneous blots and other noise, though the edits were strictly limited to cosmetic issues: areas near the digits were unchanged. There is also what looks like a hand-drawn line between mantissa and characteristic in each column. It seems unlikely this was printed—as a vertical rule it is packed impossibly close to the figures—so it must have been drawn in later. (An examination of the three extant copies [1] [2] might clarify this.) These lines were removed as well, though it required hand-editing of all digits intersecting the lines.

Here are PDFs of the page images and booklet impositions onto letter-size and A4-size pages, suitable for double-sided printing:

Logarithmorum-Chilias-Prima.pdf

Logarithmorum-Chilias-Prima-booklet-letter.pdf

Logarithmorum-Chilias-Prima-booklet-A4.pdf

Here's what it looks like printed on cream-colored paper with a pamphlet-stitched binding:

[1]	Raymond Clare Archibald. The first published table of logarithms to the base ten. Mathematical Tables and Other Aids to Computation, 9(50):62–63, 1955. https://www.ams.org/journals/mcom/1955-09-050/S0025-5718-1955-0069082-4/S0025-5718-1955-0069082-4.pdf

[2]	Denis Roegel. A reconstruction of Briggs' Logarithmorum chilias prima (1617). https://locomat.loria.fr/briggs1617/briggs1617doc.pdf

GNSS sky recordings

2020-02-01T10:06:00-05:00

I'd like to make available to a wider audience a stream of GNSS sky recordings.

The recordings are made with the GNSS Firehose digitizers and Tallysman TW3972 antennas. Each recording is 200 ms long and contains three GNSS bands, each sampled at 70 MHz with a useful bandwidth of about 50 MHz. The schedule repeats every 5 minutes:

GPS time modulo 300 seconds	Recorded bands
0	L1, L2, L5
150	L1, E6, L5

Thus, the cadence for L1 and L5 is every 150 seconds and for L2 and E6 every 300 seconds.

Here are the nominal center frequencies and spans for the various bands:

Band	Center frequency, MHz	Approximate useful span, MHz
L1	1584.754875	1558-1610
E6	1273.654125	1248-1300
L2	1227.727125	1201-1253
L5	1191.641625	1165-1217

I think this covers every GNSS signal except the S-band signal from IRNSS. (Incidentally, my antennas are not characterized for reception at E6, but the signal is good enough to be useful.)

Now, these are pretty short recordings, but they should still be long enough to obtain good-quality observables for both pseudorange and carrier phase (or at least the fractional parts thereof). The timing is chosen to coincide with observables from other GNSS receivers, which conventionally output estimates every 30 seconds (or faster), aligned with GPS time. The maximum difference in arrival times between observers on Earth is about 20 ms, so a recording duration of 200 ms guarantees at least 180 ms of overlap.

Currently I have two locations continuously uploading these recordings, one in Indiana, USA and one in California, USA. Indiana has the better sky coverage---about half the sky is available, from azimuth 85 to 275, down to elevation 10 degrees or so. I'd like to encourage others to upload waveforms of this type, so that worldwide signal monitoring becomes possible. Of course, IGS and IGS/MGEX have been covering this ground for many years, but at the observable level, not the waveform level.

The carrier-phase observables from successive waveform snippets hundreds of seconds apart will not be linked by integer cycles, unlike those from a continuously-tracking receiver (unless the receiver clock happens to be very stable, with TDEV(300s) << 1 cycle). But this is not an insurmountable drawback. The integers can be put back in by differencing against a nearby reference receiver that does continously track; alternatively, analysis methods can be used that don't depend on integer cycles, for example the ambiguity function.

Storage details

The files are being stored on Amazon's S3 cloud-storage platform. For the first month, standard S3 is used, so the data is available immediately upon request (with request latency of less than one second). After one month, the files are migrated to S3 Glacier Deep Archive, which has much lower storage cost but retrieval latency of up to 48 hours. All the files are still accessible, but you'll have to wait up to 48 hours to get a copy, so it's best to do any processing (such as observable estimation, cross-correlation among stations, signal-health metrics, etc.) during the first month.

The S3 bucket is "s3://gnss-recordings-pmonta", and its region is us-east-1 (Northern Virginia). If you want to do computation with these recordings, it would be cheapest to use EC2 compute resources in that region, since data transfer between S3 and EC2 is then free. If you transfer the files to other AWS regions, or download them over the Internet to your own storage and computation, then transfer costs are imposed.

If you upload GNSS waveforms to AWS, please also use us-east-1 if possible.

Speaking of costs, the S3 bucket is marked "public" and "requester pays". This is so I don't have to foot the bill for possibly voluminous worldwide downloads of these files (I do have to pay for the storage costs though). So downloading these files requires that you have an AWS account. I'd prefer to not have this speed bump, but I don't see any way around it. Sorry. Maybe at some point AWS can make it part of their "free public data set" offering, in which case anonymous access would be free I think. Note that there is a free tier for AWS, which, after signup, allows a limited amount of storage, computation, and data transfer per month.

A shallow hierarchy is used inside the s3://gnss-recordings-pmonta bucket, of the form <year>/<doy>/filename, where <doy> is the ordinal day within the year ranging from 1 to 366. All dates and times are in GPS time, that is, TAI minus 19 seconds.

2020/
  029/
    ...
    PAOC00USA_2020029103500.json
    PAOC00USA_2020029103500_L1.iq.bz2
    ...
    SBTH00USA_2020029103500.json
    SBTH00USA_2020029103500_L1.iq.bz2
    ...

To reduce the friction of getting started with these files, I have a small subset of them available here on a public basis with no need for AWS credentials:

http://gnss-recordings-pmonta-sample.s3-website-us-east-1.amazonaws.com/index.html

This document is an index to the available files: two sets of recordings, seven hours apart, from the two sites. The sample files can be downloaded with a web browser using the provided links, or alternatively with wget as follows:

wget http://gnss-recordings-pmonta-sample.s3-website-us-east-1.amazonaws.com/PAOC00USA_2020029103500.json
wget http://gnss-recordings-pmonta-sample.s3-website-us-east-1.amazonaws.com/PAOC00USA_2020029103500_L1.iq.bz2
...

File format and naming

Each recording consists of a small amount of metadata and sample streams for the various RF bands. There are many choices for packaging them: HDF5, or the recent ION standard for GNSS waveform files [1], or the various RF/IF formats from radio astronomy. After reading this interesting essay about HDF5, archivalness, and software transparency [2], I opted for flat binary files compressed with a well-known compressor (bzip2), together with metadata in JSON. I don't claim it's the best choice, but at least it is easy to understand and can be easily translated into any of these other formats.

Prior to compression, the sample streams consist of 8-bit signed integers, alternating between in-phase and quadrature part (or real and imaginary part): i,q,i,q, etc. This is a common format for SDR sample streams. 8 bits is ordinarily enough precision for GNSS signals; in fact my recordings are 2-bit (4-level), with signal values -3,-1,1,3. (A signal value of 0 is used for missing data resulting from a dropped packet during recording, which is rare.) Higher-precision data, such as 3-bit or 4-bit, would fit seamlessly into this scheme. The compression reduces the file size to approximately the entropy of the underlying source.

File names roughly follow the RINEX3 convention:

a 9-character site string containing a 4-character site ID, 1-digit marker number, 1-digit receiver number, and 3-character country code</li>
Date and time (GPS time)</li>
Suffix, either .json for JSON metadata or <band>.iq.bz2 for IQ sample data</li>

A full set of four files for a given site and time looks like this:

PAOC00USA_2020029103500.json
PAOC00USA_2020029103500_L1.iq.bz2
PAOC00USA_2020029103500_L2.iq.bz2
PAOC00USA_2020029103500_L5.iq.bz2

This scheme results in many small files (about 1000 per site per day), but has the advantage that the user can request just the data desired.

Metadata

I chose metadata fields mostly inspired by RINEX3. In fact one goal is to be able to construct a single-epoch RINEX3 file from each file-set, and for that one needs observables from all the systems of interest and enough RINEX3 metadata to fill in the blanks.

Here is an example JSON file:

{
    "antenna": {
        "serial_number": "xxxx",
        "type": "Tallysman TW3972"
    },
    "approx_position": [
        -2701201.6,
        -4291624.4,
        3855647.9
    ],
    "bands": [
        {
            "center_freq": [
                5797,
                256
            ],
            "filename": "PAOC00USA_2020029103500_L1.iq.bz2",
            "name": "L1",
            "receiver_channel": 1
        },
        {
            "center_freq": [
                4491,
                256
            ],
            "filename": "PAOC00USA_2020029103500_L2.iq.bz2",
            "name": "L2",
            "receiver_channel": 2
        },
        {
            "center_freq": [
                4359,
                256
            ],
            "filename": "PAOC00USA_2020029103500_L5.iq.bz2",
            "name": "L5",
            "receiver_channel": 3
        }
    ],
    "marker_to_ARP": [
        0,
        0,
        0
    ],
    "observer": {
        "name": "Peter Monta"
    },
    "receiver": {
        "serial_number": "70:B3:D5:F7:90:09",
        "software_version": "2",
        "type": "GNSS Firehose"
    },
    "sample_rate": 69984000,
    "site": {
        "country": "USA",
        "marker_number": 0,
        "name": "PAOC",
        "receiver_number": 0
    },
    "time_duration": "0.2",
    "time_start": "1580294099.9"
}

The fields are mostly self-explanatory (when read together with the RINEX3 spec) except for the "bands" list. For each band, a center frequency is given as a ratio of integers P/Q, which is to be multiplied by the sample rate. This represents the coherence between the sample rate and each channel's downconverter local oscillator. If, for example, the user wanted to construct a single wideband signal from multiple overlapping subbands, then the exact ratios would allow the frequency difference to be set in stone, i.e., not estimated. Only the relative phases would need to be estimated. Those phases are fixed because the various PLLs in the receiver frequency chain never go out of lock. (What, never? Well, hardly ever.)

Licensing

I'm not an expert on copyright, but my intent is to provide these files to be used freely by anyone, roughly according to the Creative Commons license CC BY-SA 4.0. If the attribution or derivative portions of this license turn out to be unwieldy, especially if others contribute similar data, then it might be revised. I don't know if entities like IGS or IERS have a formal license for their data, but if so, that might be a good model.

Applications

Possible applications, exclusive of the usual ones involving observables, positioning, etc.:

satellite health monitoring
receiver development and testing
observables obtainable only from waveforms, e.g. cross-correlation of GPS M code, Galileo PRS, etc.
cooperative estimation of things like W bits or M bits (requires many stations)
archival "history" of GNSS

Using the current upload schedule, the average data rate per station is about 1 Mbit/s, with a duty cycle of either 0.07% or 0.13% depending on the band. It is not currently feasible to provide megabit-class uplinks from GNSS stations in the middle of nowhere, although the large LEO constellations under construction might change that in the near future. Continuous waveforms would be even better [3], but currently require deep pockets for the storage and bandwidth. A reasonable path might be a gradual increase in duty cycle.

Disclaimer

I can't make any guarantees about data uploads or data availability. "Best effort."

References

[1]	GNSS Software Defined Receiver Metadata Standard, http://sdr.ion.org.s3-website-us-east-1.amazonaws.com

[2]	Moving away from HDF5, https://cyrille.rossant.net/moving-away-hdf5

[3]	Considerations for Future IGS Receivers, http://www.ngs.noaa.gov/IGSWorkshop2008/docs/recDev-positionpaper.pdf

The L1C signal on GPS III

2019-02-27T01:19:00-05:00

The recently-launched GPS III satellite, SVN 74, is transmitting on PRN 4, though not yet set healthy. But it's a good opportunity to have a look at the L1C signal.

The pilot is TMBOC; here is its correlation peak:

It looks proper to me, though I haven't compared it against the ideal waveform. The BOC(6,1) wiggles are clearly present, narrowing the central peak. Note the small amount of signal on the quadrature phase. This could have a number of sources: the passband of my receiver is not ideally flat in amplitude and group delay (I may add some equalization at some point), and the GPS L1 carrier is significantly offset from the center of the passband (by about 9 MHz) so as to accommodate GLONASS. The satellite signal itself could also be contributing. The recording was taken with a gain antenna (a 15-turn helical, about 11 dBi), and the integration time for the correlation was two seconds.

The data signal is pure BOC(1,1) with no BOC(6,1) content:

I'm not sure what tracking is most appropriate for GPS III. Of course the individual observables for C/A and L1C{p,d} are available, and, in the case of L1C, a combined mode with PLL tracking of the pilot and Costas-loop tracking of the data channel (or PLL tracking after data wipeoff), suitably weighted. But should a joint weighting of both C/A and L1C be considered, which would seem to include even more signal energy, yielding a higher-quality observable? There's no RINEX name for this mode.

BeiDou B2b codes

2018-12-24T10:10:00-05:00

It turns out to be an interesting exercise to extract the BeiDou B2b codes from GNSS recordings. If there were a pilot on B2b, there would have been plenty of SNR with even a short recording to see the pilot using a technique similar to that shown by Yudanov [1]. But, when assuming a pilot with period 100 ms, and then trying a great many other possible periods, there appeared to be nothing there.

As it turns out, there is no pilot. There are data signals on both B2bi and B2bq. One of them has what looks like a 2-second frame structure, but the data in the 2-second window changes periodically, so it is not a fixed pattern as the secondary code of a pilot would be.

So rather than coherently combining many samples of the pilot, we instead need to estimate the data symbols individually by differentially-coherently correlating a designated 1 ms interval with successive intervals. This entails a squaring loss. Even with signals of 45 to 47 dBHz during favorable passes, the QPSK data symbols are quite weak, and the chip decisions after noncoherently integrating for a few seconds are not error-free. But there is enough there to hard-limit the chip estimates, track the signal conventionally using this code-with-some-errors, and then use the track to refine the chip estimates to be truly error-free. (Perhaps there is some relationship to iterative decoding and belief propagation, and maybe a more sophisticated algorithm could deal optimally with even weaker signals.)

As an example, here is a plot of the QPSK B2b chips of BeiDou PRN 34, integrated for 4 seconds after wiping off the data modulation (using the unreliable estimates). The B2a signal is tracked (with its known code) to serve as a guide for code timing and to remove fluctuations of the local clock (a TCXO in my case). The carrier for B2b is then blindly applied as B2a + 30.69 MHz + a differential-doppler correction, which must be good to 0.1 Hz or so for the coherence to be maintained.

The real part of these chips (after rotating a bit), hard limited, is taken as the B2bi code, and the imaginary part the B2bq code. Re-tracking with those codes yields a very much improved estimate of the code chips. One of the two quadratures, call it B2bi_improved, is shown below; the other is very similar when tracked using the other code. (I'm a little puzzled by the discrete nature of the imaginary part of these chips; perhaps it represents part of the ACEBOC multiplex. But the code is just taken as the real part.)

Tracking with this refined code yields the 1 ms data symbols shown below. Shown first are the complex values of the prompt correlator output (which are purely BPSK, showing that tracking is good), and second the real part over time, showing some of the structure of the data. (These are now the data symbols for B2bi over time, not the code chips.)

Codes for the current set of 18 MEO BeiDou-3 satellites are available here:

https://github.com/pmonta/GNSS-DSP-tools

Note that there is a 4-way ambiguity in each of these codes because of the (apparently equal-power) QPSK. But with the data format as yet unknown, this doesn't matter. Or, possibly, looking at B2a (for example by implementing B2ab tracking) could resolve the ambiguity.

It might be possible to reverse-engineer the B2b codes to some underlying Gold-code parameters, if they are in fact of similar provenance as B2a, but there seems to be no tangible benefit to doing that. I think I'll just leave them expressed as memory codes and wait for the ICD.

[1]	Sergei Yudanov, A Case History Using the New Galileo E6-B/C Signal. https://www.gpsworld.com/signal-decoding-with-conventional-receiver-and-antenna-a-case-history-using-the-new-galileo-e6-bc-signal/

GNSS tri-band, quad-constellation sky recording

2017-05-15T10:54:00-04:00

I'd like to share my first tri-band GNSS sky recording along with scripts for acquisition and tracking.

The recording is 50 seconds long with three channels of simultaneous 2-bit complex samples at 70 Msa/s (approx. 50 MHz usable bandwidth per channel) centered on L1, L2, and E5 (~1191 MHz). It's therefore guaranteed to contain a complete data frame for each satellite---the length of an ephemeris frame is 30 seconds for all the GNSS systems, at least for the legacy data formats (though Galileo cuts this in half when using dual frequency via interleaving). An autonomous solution can be obtained for GPS, GLONASS, and Galileo (all of which have at least 4 satellites present), and nearly for BeiDou (only 3 satellites present).

Here is the recording in tcpdump / libpcap format. The utility packet2wav_3ch extracts one of the three RF channels from this packet stream and converts to a raw stream of signed 8-bit values for a downstream software receiver or other tool.

gnss-20170427-L1L2L5.pcap (5.4 GB)

By my count there are 34 satellites in this recording that are emitting 64 distinct GNSS signals (more if you include P/Y and M and CS/PRS codes and count I and Q separately). The satellites with active signals are as follows:

GNSS system	PRNs or FDMA channels
GPS	2 4 5 12 13 15 18 20 21 25 26 29
GLONASS	-7 -5 -3 -2 1 2 3 5 6
Galileo	7 12 14 19 20 24 26
BeiDou	7 14 34
SBAS	133 135 138

and the signals themselves:

GNSS system	Band	PRNs or FDMA channels
GPS	L1	2 4 5 12 13 15 18 20 21 25 26 29
GPS	L2C	4 5 12 25 26 29
GPS	L5	25
GLONASS	L1	-7 -5 -3 -2 2 5 6
GLONASS	L2	-7 -5 -3 -2 1 2 3 5 6
GLONASS	L3OC	9 26
Galileo	E1	7 12 14 19 20 24 26
Galileo	E5b	7 12 14 19 24 26
Galileo	E5a	7 12 14 19 24 26
BeiDou	B1I	7 14 34
BeiDou	B2I	14
SBAS	L1	135
SBAS	L5	133 135 138

Below are plots of some of the acquisition metrics (but I've not yet automated any sort of detection threshold). Click for larger image:

The L5/E5 channel should support tracking of the full Galileo E5 signal (E5ab). I haven't implemented this tracking mode yet, but it involves using a combination of a pure PLL for the pilot signals and a Costas loop for the data signals, optimally weighted and combined. (These would be the "C8X" and "L8X" observables in the taxonomy of RINEX 3.0.)

A makefile is provided in the GNSS-DSP-tools repository that will download the recording, run all the acquisition routines, and track the signals. Acquisition of GPS L1 is quick, but some other signal types are slower because they search all PRNs exhaustively and with a fairly high sensitivity.

Some miscellaneous notes on the signals:

I'm not sure why SBAS 133 and 138 are not showing up on L1. They have strong signals on L5, and other recordings in the past have shown them on both L1 and L5 with no trouble. Perhaps there's some flaw in the acquisition related to the higher data rate on SBAS (although I do only 1 ms integrations, so it should not matter).
Same for GLONASS channels 1 and 3 on L1 vs. L2.
BeiDou PRNs 7 and 34 are apparently not transmitting on B2I. (PRN 34 is probably transmitting the BeiDou phase 3 L1 MBOC signal, incidentally.)
The GLONASS L3OC PRNs nominally run from 1 to 24, corresponding to the slot number, at least according to this GPS World article. Not sure why there's a PRN 26 being transmitted by one of the GLONASS-K satellites. As I recall, there were other PRNs outside of the range 1--24 also used by GLONASS-K; perhaps the code assignments have changed over time.

The antenna is a homemade 3-turn helical with highpass filter and LNA, both from Mini-Circuits. It's pretty much the simplest thing that could possibly work while still having acceptable bandwidth (1150--1610 MHz) and acceptable spatial pattern and circular polarization. Some slight interference from LTE is visible in the waterfall plots (using baudline), but it's weak enough that the GNSS signals are not affected. Probably better preselection filtering is needed, or a stronger LNA, or both.

GNSS Firehose update

2017-05-05T00:06:00-04:00

Some updates on the GNSS Firehose system as it approaches general usability:

now supports three 50 MHz RF channels (nominally covering L1/L2/E5), 840 Mbit/s total payload
supports command and status over Ethernet (in addition to UART)
firmware now in C, running on a RISC-V soft CPU (picorv32 from Clifford Wolf)
change over to KiCad for schematic and PCB layout

The enclosure is the same as before, a Hammond 1455L1201, with fancier artwork this time:

A run of 20 boards was assembled, with a very pleasant yield of 100% (thanks, Sparqtron!). Here's a shot of some of them. They have yet to receive the small 3D-printed plastic cap for the TCXO. That turns out to be quite important to reduce air currents near the device---it dramatically improves the performance of the local clock, so that, for a reasonably strong signal, there's only the occasional excursion of 1 Hz or so over timescales of a few seconds. (I should make an Allan-variance plot from one of the PLL tracks.)

GNSS Firehose status, example L1/L2 sky recording

2015-05-10T21:30:00-04:00

Just a quick update on the GNSS Firehose digitizer project. I've decided to get a few systems professionally assembled; they will be similar to this prototype unit:

Here is some sample data, a sky recording taken on May 6 at around 13:38 UTC:

gnss-3.dat (743 MByte)

This represents 10.2 seconds of data simultaneously sampled on bands centered at ~1584.8 MHz and ~1227.7 MHz; each channel has a useful bandwidth of about 50 MHz. The format is raw Ethernet packets as written by tcpdump. The packet2wav utility unpacks the various sample streams from these packets and checks timestamps.

To use this file with my software receiver, here's a command to acquire all the GPS L1 C/A signals in view:

$ <gnss-3.dat packet2wav | ./acquire-gps-l1.py /dev/stdin 69984000 -9334875
prn   1 doppler  3200.0 metric  3.45 code_offset  863.2
prn   2 doppler  1800.0 metric  1.45 code_offset  603.4
prn   3 doppler  4200.0 metric  2.33 code_offset  456.6
prn   4 doppler  1000.0 metric 10.23 code_offset  134.4
prn   5 doppler -3600.0 metric  1.54 code_offset   57.2
prn   6 doppler -4800.0 metric  1.46 code_offset  433.3
prn   7 doppler  -800.0 metric  1.45 code_offset  222.5
prn   8 doppler  3000.0 metric  1.46 code_offset  488.3
prn   9 doppler   400.0 metric  1.57 code_offset  362.4
prn  10 doppler  3400.0 metric  1.54 code_offset  506.3
prn  11 doppler  1000.0 metric  7.62 code_offset  728.8
prn  12 doppler  -400.0 metric  1.46 code_offset   93.4
prn  13 doppler -2600.0 metric  1.44 code_offset  595.4
prn  14 doppler  -800.0 metric  7.23 code_offset  558.5
prn  15 doppler  -600.0 metric  1.51 code_offset   90.7
prn  16 doppler     0.0 metric  1.43 code_offset  772.2
prn  17 doppler  3200.0 metric  1.44 code_offset  301.7
prn  18 doppler -1200.0 metric  2.20 code_offset  760.5
prn  19 doppler -1600.0 metric  1.59 code_offset  657.4
prn  20 doppler -4400.0 metric  1.50 code_offset  910.4
prn  21 doppler  2200.0 metric  1.42 code_offset  674.6
prn  22 doppler  -800.0 metric  6.54 code_offset  923.6
prn  23 doppler  4200.0 metric  2.08 code_offset   94.4
prn  24 doppler  2200.0 metric  1.55 code_offset  406.4
prn  25 doppler  3000.0 metric  4.29 code_offset  513.2
prn  26 doppler  1600.0 metric  1.47 code_offset  628.4
prn  27 doppler   600.0 metric  1.51 code_offset  135.4
prn  28 doppler   200.0 metric  1.45 code_offset  631.4
prn  29 doppler  1600.0 metric  1.47 code_offset  378.4
prn  30 doppler -2800.0 metric  1.52 code_offset  737.5
prn  31 doppler  3000.0 metric  6.61 code_offset  367.1
prn  32 doppler  2600.0 metric  5.98 code_offset  176.8
prn 133 doppler  1600.0 metric  3.20 code_offset  481.3
prn 135 doppler  1400.0 metric  3.82 code_offset   86.7
prn 138 doppler  1400.0 metric  2.67 code_offset  824.9
$

A plot of these acquisition metrics across the various PRNs:

Here's a summary of the visible signals on L1 after acquisition is done across all the GNSS services:

GPS L1 C/A:      1 3 4 11 14 18 22 23 25 31 32 133 135 138
GLONASS L1 C/A:  (none found)
Galileo E1b:     14
Galileo E1c:     14
BeiDou B1I:      11 14

and on L2:

GPS L2CM:        1 3 25 31
GLONASS L2 C/A:  -2 -1 3 5 6
GLONASS L3I:     (none found)
GLONASS L3Q:     (none found)
Galileo E5bI:    14
Galileo E5bQ:    14
BeiDou B2I:      11 14

My L1/L2 antenna, an AeroAntenna AT2775-42, doesn't quite cover GLONASS on L1. Occasionally a signal on channels -7 or -6 is strong enough to show up, but no luck for this capture. GLONASS L2 is fine though, as are the newer GLONASS L3 CDMA signals (not present in this capture unfortunately). Of course other signals such as L2CL and P will be acquirable and trackable as well, but they are more difficult to acquire blindly.

Just for fun, here are the raw samples from the L1 channel. Clearly not much can be seen from this, but it can be useful as a quick check. Samples are 2 bits (represented on the output stream as two's-complement 8-bit for processing convenience), alternating I and Q, at 69.984 Msa/s.

$ <gnss-3.dat packet2wav | od -Ad -tx1 | head
0000000 ff 03 03 03 01 ff fd 01 ff 01 03 01 ff 01 03 fd
0000016 01 fd ff fd ff fd ff ff ff fd ff ff ff 03 ff 01
0000032 01 03 01 03 ff 03 03 03 01 ff ff ff ff 03 01 01
0000048 03 01 01 fd fd 01 01 03 01 01 01 01 03 01 01 03
0000064 fd fd fd ff fd 03 fd ff ff 03 01 ff ff fd fd 01
0000080 ff 01 03 ff ff ff 03 03 03 01 ff ff ff ff 01 ff
0000096 fd 01 ff ff 01 01 ff ff ff fd 03 fd ff fd ff fd
0000112 01 01 fd 01 ff fd ff 01 fd ff ff ff 01 01 ff ff
0000128 01 01 01 01 ff 01 03 01 03 ff 01 ff 01 01 01 01
0000144 01 fd fd 01 ff 01 01 ff 01 03 ff 01 01 03 01 01

And the raw samples from channel 2, the downconverter channel looking at L2:

$ <gnss-3.dat packet2wav 2 | od -Ad -tx1 | head
0000000 ff 01 fd 01 01 01 01 ff ff ff fd 01 ff 03 01 03
0000016 03 01 fd 01 fd ff ff 01 ff 03 fd 03 fd ff ff 01
0000032 03 ff 01 fd ff fd 01 01 ff 01 fd 01 01 fd ff ff
0000048 ff 01 03 ff 01 fd 01 ff 01 ff 03 ff ff ff ff ff
0000064 ff ff 01 fd 03 01 03 ff 01 fd ff 01 ff ff fd 01
0000080 ff 01 01 ff 03 01 01 03 03 01 01 ff ff ff 03 ff
0000096 ff ff 01 ff 01 ff 01 01 03 01 01 fd ff fd ff ff
0000112 fd 03 ff 01 ff ff 03 ff 01 ff fd 01 01 fd 01 fd
0000128 01 fd ff ff ff fd fd fd 01 01 01 03 ff 03 01 03
0000144 ff 01 ff 01 01 01 01 ff 03 01 01 ff ff ff ff fd

I plan to add the FPGA and software support for the third RF channel (set to cover L5 by default) over the next few weeks while the boards are being manufactured and assembled. I now have a simple helical antenna suitable for L5, so I should be able to do tri-band experiments.

Pointers to the GitHub repositories containing hardware design and software receiver:

https://github.com/pmonta/GNSS_Firehose (contains packet2wav.c)

https://github.com/pmonta/GNSS-DSP-tools (contains acquire-gps-l1.py etc.)

Squaring receiver for Galileo blind search

2014-09-23T02:51:00-04:00

I've been following the drama of the two recently-launched Galileo FOC satellites. To my knowledge, nothing is yet known about the status of the transmitters, nor have the PRNs been revealed, nor does an acquisition search over all 50 codes in the Galileo ICD yield any signals when the satellites are in view (though PRNs 11, 12, and 19 show up as expected).

So if the satellites are transmitting at all, perhaps it's with a nonstandard code. One way to check is to take a trip back in time and revisit one of the very oldest GNSS receiver techniques, that of squaring a BPSK signal to recover a tone, then driving a PLL with this tone. (The Macrometer V-1000 receiver used this scheme.)

Now Galileo E1 when viewed in a 4 MHz bandwidth is not BPSK---it is, I believe, a three-level signal, {-1,0,1}, being the sum of equal-power E1-B and E1-C with negligible contribution in quadraphase from PRS. But squaring still works on a signal of this type, though not quite as well as with BPSK.

Here is a waterfall plot with several satellites visible, and indeed Galileo PRN 11 is one of them. Its identity is confirmed by acquiring and tracking in the conventional way, then verifying that the Doppler is identical (modulo the factor of 2 from squaring).

As of September 20, though, there is still nothing from the new satellites. A predicted Doppler curve can be derived from orbital elements, but there is nothing in the spectrogram at the anticipated Doppler. So we wait.

Code for this "receiver" (all of a dozen lines) is at the GitHub repository (squaring.py). Its output can be piped to the indispensable baudline spectrum analysis tool for interactive viewing.

GNSS stamp collecting

2014-09-16T01:38:00-04:00

Here's a fun montage of the various GNSS signals-in-space. I think this accounts for all extant open-access signals that are likely to remain so (ruling out Galileo E6 for example) and that are intended for systems having global coverage (so no QZSS or IRNSS). A few comments on the signals:

Each waveform is 400 ms in length and is sampled at 1 ms intervals after code and carrier wipeoff
Secondary codes have not been removed
Carrier-to-noise ratios vary. The weakest signals are Galileo E5a-I and E5a-Q; by eye there is not much to see, but the acquisition metric is clearly well above threshold, and the histograms are clearly bimodal. My L1/L2 antenna receives some L5 but with about 15 dB of attenuation (!). I really need an antenna that covers down to L5. The GPS L5 signals must have been blisteringly strong to come through as well as they did.
The pilot signals with no secondary codes, GPS L2CL and GLONASS L2 P, are shown correctly offset from the (undrawn) centerline. I'm not sure much is known about the data modulation on GLONASS P. Apparently L1 has some data at 50 Hz (no secondary/meander code?) and L2 is unmodulated.
So far there are two GLONASS satellites transmitting L3OC CDMA signals. The signals shown are from PRN 30, but PRN 33 is also active and of comparable quality.

The tools for acquiring and tracking these signals are in my GitHub repository:

https://github.com/pmonta/GNSS-DSP-tools

They are command-line-ish and not very polished yet.

Height-based multipath mitigation

2014-09-06T23:22:00-04:00

Here's a crazy idea which I might as well put on the blog.

Multipath is an important error source for GNSS reference stations. Monuments for antennas are nearly always placed close to the Earth's surface, so the ground will act as a reflector with a grazing geometry that generates short-delay multipath. Usually other objects contribute as well (nearby buildings or fences for example).

Many solutions exist for multipath mitigation, both at the antenna and correlator levels. Another possible system technique, though, would seem to be to move the antenna upwards, far enough away from local objects that any reflected signals have delays larger than the support of the autocorrelation function for any signal of interest.

Conceptually, an antenna could simply be placed at the top of a tall tower a few hundred meters in height. The tower would ideally be transparent to RF (perhaps of lightweight dielectric construction). Of course there are many practical problems with this, but the environment around the antenna would be nearly ideal.

Another possibility is to place the GNSS antenna on a UAV, which would keep station above the reference monument and several auxiliary sensors (whose location and stability are not critical). The UAV would simultaneously maintain links with visible GNSS satellites (aided by an on-board inertial system) and with sensors on the ground using any of a variety of accurate (~0.1 mm say) short-range ranging techniques. In this way the pristine airborne GNSS signal environment is transferred to the reference monument despite the relative movement.

The UAV could execute certain maneuvers to continuously calibrate its antenna, similar to robot absolute antenna calibrations on the ground. The craft could spin slowly around the vertical axis, or tilt slightly, or both. The attitude from the inertial system would become part of the observation stream to close the calibration loop. By contrast, there is great reluctance to move ground-based GNSS reference antennas to carry out any sort of ongoing calibration program on them. With flyers, continuous monitoring comes for free.

Small rotations and tilts on an airborne platform are impossible to completely avoid, and high-wind situations may force some loss of observing time. But for most of the time, the environment should permit an accurate tie from UAV track to ground network. Depending on the choice of flying craft, several may be needed, spelling each other for charging or refueling. Automatic fleet management will probably have many good solutions over the next few years.

It's hard to know whether there's a benefit without more detailed study, but the prevailing trends in GNSS system accuracy seem to be increasing the relative importance of multipath. If we assume progressively better satellite orbit and clock estimates and ionosphere and troposphere sensing, then multipath may well loom as the last remaining large, difficult, uncertain systematic error. (Perhaps a UAV could help with estimating the wet troposphere delay as part of normal operation, to the extent that measurements on the very bottom segment of the troposphere are predictive of the full path.)

Finally, I wonder whether UAVs could help with urban canyons or tree-canopy issues. A surveyor might deal with an awkward situation by tossing a UAV into the air and replacing a bad-GNSS-signal problem with a perhaps easier-to-solve UAV-to-ground-sensor problem using vastly stronger optical or RF links.

Semicodeless P(Y)-code processing using high-rate aiding

2014-07-25T23:55:00-04:00

Present schemes for semicodeless P(Y) processing assume an autonomous receiver that estimates W-code bits directly from the received signal. Given the limited C/N0 available, naturally the signals are noisy, resulting in squaring loss.

One simple way around this is to use more reliable estimates of the W bits acquired with a medium-gain antenna. These estimates can be published continuously in near-real-time by a suitable Internet-based service, then used by any client receiver, which could be a conventional real-time receiver or a recorded-waveform software receiver.

This need not be all that expensive. All that's required is approximately one medium-gain antenna per satellite per hemisphere. A one-meter dish of 20 dB gain would reduce squaring loss to practically zero. Of course a reasonable Internet uplink is needed of 480 kbit/second for each satellite. Storage costs could be controlled by retaining the W bits for a limited time (a few weeks or months).

Another possibility, in a world where every receiver is uploading full RF waveforms to a central service, is to sum together the signals from many receivers before estimating the W bits. (If the summing is done prior to detection, this is effectively a phased-array antenna.) Quite a few signals would be needed, though, if each receiver has the usual omni antenna. Better to rely on dedicated medium-gain antennas.

The W-code bits would not be of any use to spoofers since they would be tens or hundreds of milliseconds out of date.

The same trick can be played with other unknown codes, such as the GPS M code or the PRS codes on other GNSS services. The bit rates of the published reference waveforms would be much higher than those of W-code, but perhaps the effort would be repaid by observables that could be obtained in no other way, helping with multipath and ambiguity resolution. In the limit of a totally unknown waveform, this is just VLBI.

Parallel processing of recorded GNSS signals

2014-07-25T23:51:00-04:00

Most GNSS receivers process signals serially. This is natural for tracking loops based on PLLs and DLLs, as they have a feedback structure. If signals are recorded and stored, however, another viewpoint might be more flexible.

Let's regard the recorded waveform as a series of chunks of length, say, 5 minutes. All these chunks can be processed in parallel, though at the cost of ambiguities in whole cycles of carrier phase for each chunk. (Let's assume that acquisition or aiding has already allowed each chunk processor to start with good estimates of code phase and doppler, and that suitable guard intervals allow the tracking loops to converge somewhat in advance of the start of each chunk, so that effectively the chunks overlap a little.) Once all chunks are processed, whole cycles of carrier phase are simply cumulatively summed. This reduces the ambiguity set to the normal case of just a single ambiguity for the whole interval of the satellite pass (assuming no cycle slips or loss of lock).

So an attractive GNSS processing scenario might be:

deposit all waveforms in a central place, such as one of the cloud computation environments like Amazon's S3 and EC2
do all processing of interest in parallel, by allocating as many processors as needed; place intermediate results as annotations on a common scoreboard
coalesce the results, obtain observables, and post-process

By having the entire waveform accessible at once to a common pool of processors, a kind of annotation-based processing becomes possible. First, acquisition might be performed at fixed intervals, possibly aided by a location estimate and orbit estimates from IGS. Once the file has been annotated with acquisition results, each chunk can be tracked as outlined above. Vector tracking, differencing at the correlator level, quality monitoring, etc. can all be included as additional workflow options.

GPS P code exploration

2014-07-08T06:49:00-04:00

As a first step towards obtaining GPS P-code observables, it seems prudent to verify that the P code is detectable in a test recording with high C/N0.

Here's the result with an L1 recording containing a strong signal from PRN 30 (about 50 dBHz). The peak is smeared over an extent somewhat larger than two chips, the result of some residual code doppler. Also the peak is offset by about 1 chip, again the result of residual error from the C/A acquisition (about 0.1 C/A chip). It was great to see it at all though. Certainly it proves out the P code generator.

The recording is about 1.4 seconds long and contains these data bits:

000100010110111101111011110010001011000011000001100010101110010100100100101

It turns out I was a bit lucky and got a complete TOW word at the end:

0001000101101111011110111100
10001011                        # Preamble
00001100000110                  # TLM Message
0                               # Integrity Status Flag
0                               # Reserved
101011                          # Parity
10010100100100101               # TOW Count (inverted: 01101011011011010)

This TOW count corresponds to Wednesday 19:40:12 in the GPS week, so the first bit of the preamble is at 19:40:06. Adding up the C/A code phase and the previous bits gives the time of the first RF sample of the file as 19:40:05.450822469 or 3375955761914 P code chips. That was the offset given to the script that produced the above plot.

I've put the code generators and some preliminary acquisition and tracking software in a new GitHub repository:

https://github.com/pmonta/GNSS-DSP-tools/

I'm sure it's not as efficient as low-level code in C, but it's nice to have concise scripts for prototyping, with everything in the Matlab-like python / numpy environment.

New "GNSS Firehose" board

2014-06-17T22:39:00-04:00

I've finally gotten around to updating the GNSS front-end digitizer. Along with a new Ethernet PHY chip (the old one from Vitesse seems to be no longer available), there is an external clock option, an expanded auxiliary header, and a number of small improvements in signal integrity. The external-clock header can accept an external OCXO or rubidium signal, for example; and multiple boards can be driven with a common clock.

Here's a spectrum at L1. Despite the poor antenna placement (almost surrounded by tall trees), the GPS C/A signal shows up quite well as a broad peak of 2 MHz bandwidth. There is substantial ripple in the antenna's ~35 MHz passband, and unfortunately the antenna filtering cuts off around 1595 MHz, so GLONASS signals are suppressed. The signals near 1557 MHz are probably satellite downlinks, and the peak near 1584 MHz is the receiver's DC spur.

The usable alias-free bandwidth of the system is about 50 MHz per channel. At L1 this is enough to cover all the services, from BeiDou B1 starting at 1559 MHz to GLONASS extending to 1610 MHz.

Here's a C/A correlation peak from this recording (PRN 13). The nice sharp corners are a result of using all of the C/A bandwidth:

Next steps are to clean up the software and HDL and to test the other two channels. See previous blog posts for a pointer to the GitHub repository containing the newly-updated design files.

SMT stencil cutting

2012-12-25T10:56:00-05:00

I've been making some SMT stencils using a Silhouette Cameo craft cutter (vinyl cutter). It's great for fast turnaround time and low materials cost, though the quality is not as high as a laser-cut stainless-steel stencil. Still, they're useful down to 0.5 mm pitch and 0201, and possibly a little better, and that's good enough for many applications.

Here's a stencil cut by the Cameo. The partial QFP footprint is 0.5 mm pitch and the smallest discretes are 0402.

gerber2graphtec examples/test_0.5mm_0402.gbr >/dev/usb/lp0

And a test coupon with QFP pitch from 0.65 mm to 0.3 mm, discretes from 0603 to 01005, and BGA pitch from 1.0 mm to 0.5 mm:

Background

The web page that got me looking at craft cutters was this one:

http://www.idleloop.com/robotics/cutter/index.php#stencil

These results are very nice, but on the software side I wanted something that fits into a normal PCB workflow with no hassle, by working directly from the solderpaste Gerber file as exported by a PCB CAM tool.

In addition, I wanted the best quality possible. Using the cutter in its default mode rounds off corners considerably due to the drag-knife mechanics, so instead I dice all features into individual line segments and draw them separately in multiple passes. Also, machine backlash is an issue, so the software works around that, at the expense of speed.

Fortunately, the low-level protocol for these machines has been documented, and the rest is mere geometry conversion that's considerably helped by existing tools like gerbv and pstoedit. The software can be found here:

https://github.com/pmonta/gerber2graphtec

Also included are some example Gerber files. A test coupon with QFP/QFN and BGA pitches from 0.65 mm down to 0.3 mm and two-pad footprints from 0603 to 01005 is included, as well as a few larger examples.

The generated files run well on my Silhouette Cameo and probably on other similar Graphtec cutters as well.

Materials

Polyester film is a natural choice. It's inexpensive, dimensionally stable, and very available in the form of laser-printer or copier transparency sheets. Thickness of these sheets is usually around 4 mils, close to the IPC-recommended values for fine-pitch work. Other thicknesses can be obtained easily enough from sources like McMaster-Carr.

I'm using Highland 901 sheets (a 3M brand apparently) together with full-sheet Avery labels, number 5353, as an adhesive backing sheet. The adhesive is a little too aggressive and can be difficult to remove cleanly once the stencil is finished. One can use Goo-Gone or similar citrus-oil cleaner to remove all the adhesive, and this results in a squeaky-clean stencil, but it takes a few minutes of extra time. Perhaps it would be better to use the cutter's cutting mat, though cleaning off the small plastic chads is a bother too. Another option might be to use a separate full-sheet double-sided low-tack adhesive to laminate a plastic sheet to a plain paper backing.

Calibration

Two aspects of the machine should be calibrated for best performance: cutting force and the spatial coordinate system.

For force, the software includes an example script that produces 30 small squares, each cut with a different force. Just have a look at the result to see which force settings result in good performance with your material stackup (mylar plus adhesive backing): first, a reasonable initial cut, to score the material, and second, a final pass that aims to cleanly separate the unwanted material from the stencil background.

For axis calibration, a script is provided to cut a calibration artifact. Measure the distance between marks along each direction (x, y, 45 degrees, and -45 degrees), then calculate a matrix to take out the distortion. (Rub in a bit of felt-tip-pen ink to make the marks more visible when comparing against a good ruler. The provided script produces a 17-step vernier against a 1/16-inch ruler; modify this for 11 steps against a 1 mm ruler if you're using a metric ruler.) My machine is pretty reasonable in x, has a rather large 0.6% error in y, and has a skew of about 1 milliradian. After compensation I think the error is down to less than 0.1%. Even this is uncomfortably high: it is still a 50-micron positioning error across half the dimension of a 100 mm board.

Platform notes

So far I've run this only under Linux (Fedora), which provides a device node at /dev/usb/lp0 when the device is plugged in. Other platforms may need different device-driver arrangments. One can always send the output of gerber2graphtec to a file and deal with getting it to the cutter separately. Fortunately no feedback from the cutter seems to be necessary.

Application notes

Perhaps these stencils are best suited to prototyping that needs very fast turnaround. For example, it's sometimes convenient to populate and test only parts of a board, and for this separate stencils can be cut for each region.

I plan to evaluate at some point this source of laser-cut Kapton stencils:

http://ohararp.com/Stencils.html

as well as the various lower-end laser-cut stainless vendors.

Logarithmorum Chilias Prima

2012-06-05T09:54:00-04:00

Here is some analysis of Briggs' first logarithm table of 1617, Logarithmorum Chilias Prima.

The table is available on microfilm as part of the Early English Books series from UMI/ProQuest. The on-line service, Early English Books Online (EEBO), also makes the work available, but the scans are of poor quality and they are not redistributable. Independent scans of the microfilm, however, apparently have no copyright issues, at least in the USA: the "slavish copy" rule applies, and the underlying work is of course out of copyright.

I had originally planned to use a special-purpose OCR algorithm to recover the table entries. That still seems to be the best bet for relatively modern tables such as Sang's or Thompson's. The printing in Logarithmorum, however, is sufficiently geometrically nonuniform that OCR would probably not be more robust than simply typing in the numbers by hand. That's what I ended up doing; fortunately this small table has only 14000 digits. Here is the list of table logarithms:

logarithmorum-chilias-prima-entries.txt

It's now a simple matter to compare these values to those computed by software. Here is a plot of the differences:

The plot shows the expected quantization error uniformly distributed within +- 0.5e-14, owing to the rounding to 14 decimal places in Briggs' table. There are several larger errors at 154, 194, 239, 478, and 863; the largest of these is at 194 with an amplitude of about 3e-14, that is, 3 units in the last place. Also noticeable is a gradual increase in numerical noise in the second half of the table. Presumably this is because these logarithms are derived quantities from previous results. The errors at 239 and 478 are certainly related, since 478 is twice 239 and was doubtless obtained by adding log(2) to the 239 entry. For some reason most of the errors larger than 1e-14 are positive (table value greater than true value).

Finally, here are the microfilm scans. Click on any thumbnail to see a larger, higher-quality version (2544 x 3296 pixels, approx. 442 dpi).

In this instance of the document there are eight pages of handwritten tutorial information preceding the table proper and one handwritten page of auxiliary tables after the printed table. I don't know the history of these additions. Also the core 16-page printed table has been modified with lines dividing the characteristic from the mantissa, low-precision first differences in the margins starting from 500, and a few other things.

It would be interesting to compare this copy (from the British Library / British Museum) with the other extant copies. I've seen this copy at the British Library, and were their scanning policies more liberal, one can imagine making available a very high quality color scan for everyone to view and analyze.

GNSS Firehose

2012-06-04T20:52:00-04:00

Wideband front end for GPS, Glonass, Galileo, Compass

I've long wanted a fully flexible GPS receiver. Starting from the raw RF samples gives complete visibility into the signal processing and estimation algorithms for the observables. Unfortunately, existing commercial products, either in the test-equipment class (e.g. vector signal analyzer, USRP), the L1-only USB dongle class, or the "front-end box driving expensive closed-source GNSS software receiver" class, are either narrowband, expensive, bulky, power hungry, or perhaps all of these attributes together.

Especially after reading this paper I wanted a small, cheap front end that gives access to everything a software receiver could want. From there it's a small matter of programming to derive useful measurements from the sample stream.

Pictured above is a prototype board with two of the three RF channels populated. (Once I have an antenna that reaches down to L5, perhaps a homemade helibowl, I'll solder down the third channel.)

Goals for the project:

high-quality signals from all current and near-future GNSS systems (GPS, Glonass, Galileo, Compass)
wide bandwidth---provides three 50 MHz channels, nominally at L1, L2, and L5
low cost---currently about $170 parts cost in single quantity, ~$110 in qty 100
simplicity of use---emits streams of 2-bit samples to gigabit Ethernet, feeding a downstream software-receiver farm
two baseband clock inputs for use by timing receivers---any combination of 10 MHz, 100 MHz, 1 PPS
tunability typically from 0.7 to 2.2 GHz on each channel independently, for non-GPS applications such as radio astronomy
easy to fabricate and procure parts---4-layer PCB, everything available from friendly distributors such as Digikey and Mouser
free and open-source licensing: TAPR Open Hardware License version 1.0 for hardware, GPLv2 for HDL, firmware, and software

Design files, including schematic, PCB artwork, HDL, and software, are available at my github repository:

https://github.com/pmonta/GNSS_Firehose

Here is a sky recording of L1 and L2 with 2-bit samples at 64 MHz in libpcap/tcpdump format. The github software has a tool to extract samples, but briefly, this file has 20000 packets, each with 1024 byte payload; each byte is {I_L1, Q_L1, I_L2, Q_L2} where each field is 2 bits; samples are encoded as 00, 01, 10, 11 from most negative to most positive; and the center frequencies are 65*fref for L1 and 51*fref for L2 where fref is 24.380952 MHz. (In any given byte the L1 and L2 samples are simultaneous, modulo any small yet-to-be-characterized interchannel biases (of order ~100 ps perhaps).) Thus GPS L1 is offset by -9.341880 MHz plus any particular satellite's doppler, and L2 is offset by -15.828552 MHz plus doppler. Length of capture is 0.32 seconds.

GNSS_Firehose_L1L2.tcpdump

There are some strong L1 and L2C signals in this recording, though my antenna location could be better (trees). Use your favorite software receiver (e.g. fastgps) to acquire and track. For the next spin I may change the TCXO from 40 MHz to 38.88 MHz, since that frequency seems to be more available from the distributors.

I'm still in the process of characterizing the prototype; also some HDL for ancillary functions like AGC needs to be written---this and a few other configuration tasks are currently driven from an external PC, so the board is not quite autonomous yet.

Design considerations

While I considered direct sampling, the overall design ended up as a classical direct-conversion quadrature receiver much like the USRP's DBSRX2 board: LNAs, followed by MAX2112 downconverters with pretty reasonable integrated synthesizers (running in integer-N mode for repeatable interchannel phase), followed by 8-bit ADCs. For clocks I went with a TCXO (or, optionally in a future revision, the external 10 MHz or 100 MHz reference) driving National's LMK03806 low-jitter clock synthesizer.

For output format, Ethernet is attractive. USB might be a little cheaper and a little more convenient for small deployments, but the low data rate of USB 2.0 is a showstopper, ubiquitous and easily-embeddable USB 3.0 is not quite here yet, and the clear trend in radio astronomy at least is flexible commodity networking feeding general-purpose receiver farms. I wanted something that could fit into that mold. An emerging radio-astronomy packet format, VDIF, might be a good way to go; are there GNU Radio sources and sinks for VDIF yet? Currently I'm just using raw broadcast Ethernet packets and tcpdump (though perhaps gulp would be better) for capturing the ~800 Mbit/s stream on a Linux box.

Applications

It would be nice to have a software-receiver chain that gives very high quality GNSS code and phase observables for every open or semi-open signal available. These could be dumped to a RINEX file for postprocessing or used in real time for navigation or timing. Timing, in particular, could benefit from dual- or triple-frequency observables, multi-GNSS processing (especially with the Galileo clocks as they are launched), and the availability of real-time clock information from IGS in the NTRIP format. The usual single-frequency autonomous GPSDO seems a bit limited. I'd like a multi-frequency, multi-system GNSSDO that is getting up-to-the-second clock and orbit data from the net. While I have no direct experience with systems of this type yet, from what I can tell, reliable real-time timing at the few-ns level might be possible (relative to some notional UTC(GPS+IGS/NTRIP+other_metadata) timescale), along with frequency comparisons at the ~5e-15/day level with suitable postprocessing.

Increasingly, open-source software is filling in these areas. Interesting projects include RTKLIB, GPSTk, and GNSS-SDR:

http://www.rtklib.com/

http://www.gpstk.org/

http://gnss-sdr.org/

The only thing missing seems to be inexpensive wideband front-end hardware, including, by the way, inexpensive antennas with full frequency coverage and stable phase center---still thinking about that. Certainly for L5/E5, wide bandwidth is required, and for L1 and L2 as well when going the semicodeless route with the P(Y) signals.

I'll put descriptions of any project updates in future posts.

555 contest entries

2011-02-28T12:00:00-05:00

Here are my two entries for the 555 design contest.

An op-amp made from 555 chips

Digital logic using 555 chips

2011-02-27T12:00:00-05:00

Question: is the 555 complete in the Boolean sense? That is, can any Boolean function be realized as a network of 555 chips?

Answer: yes. Tie the threshold pin high---this essentially disables the 555's internal latch. Now provide inputs to the reset and trigger pins and take the output from either the totem-pole output or the open-collector output with a suitable external load. Here is the truth table:

reset	trigger	output
0	0	0
0	1	0
1	0	1
1	1	0

This is a somewhat unusual gate---it can be interpreted as the negation of the conditional operator, or as an AND gate with one of the inputs inverted. But it is complete: an inverter can be obtained by tying reset high; now using this inverter, invert the reset input and one has a NOR gate made from two 555s; the NOR gate is known to be complete. Of course a given Boolean function will be implemented most efficiently by telling the logic synthesis tool (or human designer) to map directly onto the "555 gate" rather than use the NOR-gate construction; but the NOR is a convenient route to the completeness proof.

Storage elements can be made from cross-coupled gates or, as we will see below, from 555s configured to use their internal latch, which is slightly more efficient.

So we immediately have the whole of digital design available to us. One can imagine various projects---counters, state machines, memories, computers---all of which can be built from a large pile of 555s. Of course the same could be said about a large pile of 7400 TTL NAND gates, or transistors. What sorts of constructions, then, should we pursue that would be most interesting from a 555-chip point of view?

It's just my opinion, but it seems best to try to use as much of the 555 internal structure as possible to implement gates and latches efficiently. For combinational logic, we have the raw "555 gate" and the possibility of using a wired-AND connection with the open-collector/open-drain output and a resistor pullup (at the cost of some static power; "NMOS"). For sequential logic, we need to choose a storage element and a clocking scheme. Below is one such choice together with an example circuit: a 2-bit counter and a 7-segment decoder, enough to serve as a proof of principle.

Here is the breadboarded system, together with an annotated picture showing the location of functional blocks. There are a total of 18 556 packages, equivalent to 36 555s.

Video of the system with the clock set to about 2 Hz:

https://youtube.com/shorts/RS2Q634F5OM

Why two-phase clocking rather than edge-triggered logic in the modern style? Well, edge-triggered flip-flops are somewhat trickier to design and verify. A two-phase clock feeding a pair of transparent latches is almost bulletproof. One has complete control over the duration of non-overlap between the two phases (to control skew) as well as the overall frequency of the clock. Even clock glitches can be tolerated (provided there is no crosstalk between the phases), since a single clock phase is idempotent.

This logic technology should have no trouble scaling up to larger systems. I had hoped to do this small 4-bit CPU:

//
// tiny Harvard-architecture 4-bit CPU
//
// February 2011
// Peter Monta
//

module cpu(
  input clk, reset,
  output reg [4:0] pc,       // program counter
  input [7:0] ir,            // instruction
  output [3:0] addr,         // data address
  input [3:0] din,           // data input
  output [3:0] dout,         // data output
  output wr                  // write signal
);

  reg [3:0] a;         // accumulator
  reg c;               // carry flag

  assign addr = ir[3:0];
  assign dout = a;
  assign wr = ir[7:5]==3'b001;

  wire [3:0] b = ir[4] ? ir[3:0] : din;       // data memory or literal
  wire z = a==4'd0;                           // zero flag

  always @(posedge clk)
    if (reset)
      pc = 0;
    else begin
      pc = pc+1;
      case (ir[7:5])
        3'b000: a = b;                     // lda
        3'b001: ;                          // sta
        3'b010: {c,a} = a + b + c;         // adc
        3'b011: a = ~(a|b);                // nor
        3'b100: pc = ir[4:0];              // jmp
        3'b101: if (!c) pc = ir[4:0];      // jnc
        3'b110: if (!z) pc = ir[4:0];      // jnz
        3'b111: c = ir[0];                 // setc
      endcase
    end

endmodule

but there just wasn't time. Its size (after doing the synthesis manually) is 387 555-chips, or 194 packages using the 556. That would need a PCB; it's too big to wire by hand. Here's a PDF of the schematic and the kicad source files.

Possible future directions:

try for some sort of pass-transistor logic by floating a 555's ground pin and using the open-drain FET in a series mode
dynamic latches (with capacitors as storage elements), precharge schemes, DRAM

An op-amp made from 555 chips

2011-02-27T12:00:00-05:00

Is it possible to make an op-amp out of nothing but 555 chips and passive components? Not a terribly practical question, given the existence of very inexpensive and capable op-amps covering every corner of op-amp performance space; but it has some aesthetic appeal. If you find yourself on a desert island with nothing but a pile of 555s and a need for an op-amp, by all means read on.

The 555 has two comparators, but offers direct access to neither. The "trigger" comparator could conceivably work with feedback from the control pin, but the existence of a 2:1 resistive divider in the feedback path is very awkward. And while the "threshold" comparator sees both the input pin and the control pin directly, unfortunately its output can't flow through the digital portion of the 555: the threshold comparator can only reset the RS latch, not set it.

Even if we could use the threshold or trigger comparators directly, they have the disadvantage that one of their inputs is tied to a resistive bias network, resulting in a very low input impedance on that input (in the neighborhood of 30k ohm for the CMOS flavors of the 555; 3k ohm for bipolar). Potentially tolerable for something like a unity-gain buffer, where a low-impedance output drives the input pin, but not good for a general-purpose op-amp.

So instead we can adopt the following approach:

use two 555s, one for each op-amp input, using the high-z threshold pin on each 555
compare the inputs to a common ramp generated by an auxiliary 555, converting voltage to time
use postprocessing logic (implemented with "555 gates") to compare the PWM signals, generate error pulses, and integrate them

The schematic below shows one implementation. I used the TS555 from ST Microelectronics; it is a CMOS 555 with improved specs over the bipolar original.

First, a conventional astable oscillator generates a sawtooth waveform ranging between 1/3 Vcc and 2/3 Vcc. This is fed to the control inputs of two additional 555 chips serving as analog comparators; their outputs encode the op-amp input voltages as PWM waveforms. The digital gates (implemented with 555 chips, of course, as shown at the bottom of the schematic) compare the edges of the PWM waveforms, generating pulses if waveform A is ahead of waveform B or vice-versa. These pulses are integrated with a capacitor, using diodes to isolate the two totem-pole outputs (I suppose one could dispense with the lower diode and use the open-drain 555 pin instead). Ten 555 chips are used in all.

This is all quite similar to a charge-pump PLL. In fact I built the circuit first without the inverter pairs and wound up with some flaky behavior: hysteresis, distorted waveforms, etc. This is because at equilibrium the edges are very close together and the gates cannot generate pulses narrow enough to represent the tiny phase difference. The solution is the same one the PLL chips use: anti-backlash delays. The inverter pairs introduce enough delay so that at equilibrium, pulses are generated in both plus and minus arms, which cancel once they hit the integrating capacitor. And now small PWM edge movements result in linear net charge to the capacitor.

Speaking of PLLs, another possible op-amp implementation would use voltage-to-frequency converters at the inputs, then compare the frequencies with a sequential ("type-IV") phase-frequency detector, again implemented with 555 chips. But besides being more complicated, one might worry about injection locking. I ended up not trying it.

The test circuit is a simple inverting gain-of-10 amplifier:

Here is the breadboarded system:

and a closeup of the breadboard:

This scope trace shows an input of 100 mV peak and an output of about 1 V peak:

Same thing but with square waves; note the asymmetry in the large-signal response between rising and falling edges:

Smaller amplitude signal, 30 mV in, 300 mV out. Note the "fuzz" on the output waveform; these are the high-frequency steps on the output from the error pulses. Low-pass filtering the output attenuates this fuzz and results in a clean waveform:

Finally, here is a low-amplitude square wave as input (about 6 mV peak), still with the low-pass filter on the output. The output is more symmetrical than in the large-signal example. Horizontal scale is 200 microseconds per division.

Despite the low gain-bandwidth product (about 10 kHz), this op-amp might be usable for some low-frequency applications, such as general-purpose amplification, sine-wave oscillators (e.g. Wien bridge or RC phase-shift), active filtering, or even analog computation.

Possible enhancements:

some way to implement chopper stabilization? The lack of a series switch element in the 555 makes this difficult
dead bug or PCB construction for better signal integrity
556 chip for the two comparators for better matching and possibly lower offset
use the discharge pin on the astable to generate a rail-to-rail RC ramp; maybe would result in larger common-mode range
implement an offset nulling network, perhaps by scaling/offsetting one of the control voltages, or using a variable digital delay

Photographic lunar distances

2009-12-01T12:00:00-05:00

Update, September 2020: I've written some code to estimate the Moon's position against the stellar background on images similar to those below. It's available at my GitHub repository here: https://github.com/pmonta/lunar-astrometry

These images were taken on November 30, 2009 at 08:29:43 UTC. The location is 37d 25' 58" North, 122d 11' 14" West.

The 1537 images are the 1/80 sec exposure and the 1538 images are the 1/5 sec exposure.

Original camera images:

img_1537.jpg (1.8 MByte)

img_1538.jpg (2.2 MByte)

img_1537.cr2 (Canon RAW) (9.5 MByte)

img_1538.cr2 (Canon RAW) (9.8 MByte)

Below is a thumbnail of img_1538.jpg with contast stretched to show the stars. The reddish bright star in the lower right is Hamal; you can see a few dozen others throughout the field. Looking at the raw file is probably better, but the JPEG seems usable.

Checkplot from astrometry.net with detected stars:

Thumbnail of this checkplot:

FITS images (turned 45 degrees with green pixels only), compressed with gzip. The 1538.fits file contains a WCS (world coordinate system) that, together with a FITS image viewer like ds9, gives a (ra,dec) location for each pixel.

1537.fits.gz (5.1 MByte)

1538.fits.gz (6.8 MByte)

Printable Otis King slide rule

2001-01-15T12:00:00-05:00

After looking through Dick Lyon's web site devoted to the Otis King cylindrical slide rule, I decided I had to have one, even if only made of paper. So here's a Postscript / PDF version of an Otis King model L—just cut out the pieces, tape them into paper cylinders, assemble, and start calculating.

Postscript: ok.ps (1.4 MByte)

PDF: ok.pdf (0.3 MByte)

Source code to produce the Postscript: ok.c

After a dozen random multiplications, I seem to be getting around 0.02% rms error, or a little under 4 decimal places accuracy. On stiffer media maybe 0.01% is realistic. Here's the python script that automates prompting the user with random numbers and calculating the errors.