Generating the pseudo-random codes that measured distance to Apollo spacecraft | Hacker News Reader

Generating the pseudo-random codes that measured distance to Apollo spacecraft

righto.com

85 pointszdw18 comments

This page is the companion to my article on the ranging codes yesterday: https://news.ycombinator.com/item?id=31136285 In any case, I'm here to answer questions.

Related is Apollo s-band communications being restored by geniuses that hang out with “curiousMarc”

https://youtube.com/playlist?list=PL-_93BVApb58SXL-BCv4rVHL-...

the person linked in this submission is one of said geniuses.

>The actual ranging system had an accuracy of about ±1 meter

This ignores continuously changing atmospheric issues which screw with signal timing quite significantly, and is the main cause of why normal GPS is accurate to about ±10 meters but RTK GPS (where solely atmospheric errors are reduced via local knowledge) gets accuracy down to about ±0.1 meters.

I'm guessing signal propagation through space after the atmosphere is much more predictable.

> ... but RTK GPS (where solely atmospheric errors are reduced via local knowledge) gets accuracy down to about ±0.1 meters.

My understanding is this is also possible with GNSS receivers which can use satellites on more than one system or on more than one frequency band (e.g., the GPS L1 and L5 signals) at the same time, as this allows any atmospheric issues to be taken into account when making positioning calculations.

I don't know if any of the cheap, commonly available "multi-GNSS" receivers actually make such adjustments / corrections or if one would need to "upgrade" to one of the (much more expensive, naturally) "RTK-capable" receivers.

(My interest is primarily in timing so I mostly stick with GPS-only units which support fixed position mode, so I haven't bothered to keep up with the newer stuff, such as RTK.)

None of the non-rtk ones approach this accuracy solely because without knowing the varying local atmosphere error you cannot, even in theory, get that accuracy from GPS.

All the GPS and RTK systems I've been working on use all possible signals from all the GNS systems (except I disable Russian GLONASS at the moment due to war fueled sketchiness). To get them to work well you need good antennas that capture them all, and good wiring to keep phases clean. Noise kills precision here.

Find a textbook that does all the math and physics behind all the GNS systems, and you'll find a chapter on errors introduced by atmosphere.

RTK gets around this by having a known nearby (and hence nearly identical atmosphere path) point also get all the GNS signals, do the same computation, and send correction data in realtime to your RTK receiver.

There's also some neat stuff about signal phase that adds a little more precision over standard GPS.

I've now built multiple complete RTK and multi-RTK systems, and have been up and down all the stacks from many angles, working on pushing things to the limit, for industrial uses.

RTK really goes beyond anything I've seen in GPS, at any price. There's simply no way to realize all your signals are delayed or bent by local ionized or magnetic storms causing signal delay without some other truth data.

Other limitations in GNSS accuracy are that the satellite clocks drift and that the orbits are not perfectly know in real time. GNSS operators regularly publish correction files for the clock and orbits. This allows post-correcting the recorded data a few days after recording. Atmospheric effects are calculated and corrected for by using dual-band receivers (usually L1 + L2 for professional gear). The ultimate accuracy of such a post-corrected measurement is a few mm after a few minutes of averaging.

L1 and L2 can post correct ionosphere noise, as they travel differently there. They cannot post correct troposphere differences because they travel the same there. Without RTK, which measures the time varying local errors, you cannot undo that error with current GNS systems. It's precisely this reason RTK was developed.

> ±0.1 meters.

Nit pick as I use RTK. It's ±0.01 meters. Unless some miscreant moves the base station.

Whoops, correct. And one often gets few mm precision using all bands and all available info, even for sub $300 parts.

I was under the impression that this technique was used commonly today.

Why not an incrementing sequence?

With this primitive type of system, pseudorandom is your best chance to get accurate correlation. You want each burst to differ in as many of the positions for maximum discrimination. If you're just incrementing, every other pair of messages will differ by just 1 bit, meaning it's difficult to tell them apart in a noisy situation.

Edit: Also this circuit is simpler than an adder, since there's no carry

Edit: Also this circuit is simpler than an adder, since there's no carry

Which is interesting in itself on occasion. If you need to count to a particular binary power on an FPGA, an LFSR for that word width is the most parsimonious way to do it AFAIK.

> If you're just incrementing, every other pair of messages will differ by just 1 bit

That's not true.

000

001

010

011

100

101

110

111

Plenty of multi-bit changes in just that short sequence. It just isn't guaranteed that more than one bit will change, in about half that will be the case, in the remainder there will be multi-bit changes.

The parent poster said every other pair, which is perfectly true (in English that means for a half of the transitions, i.e. those from even numbers to odd numbers), so your correction is false.

Ah I see now what he means. Ok, that could have been worded a bit clearer but fine, yes, if you only consider the pairs then it makes sense. 0->1 1 bit, 1->2 2 bits, then 2->3 one bit again, 3 to 4 three bits, and so on.

So the better way to phrase it would have been: 'on even to odd transitions the difference will only be one bit'.

> "... to prevent PRN code duplication and avoid using codes with poor properties that may interfere with receiver performance." (https://www.gps.gov/technical/prn-codes/)

Reply on news.ycombinator.com