junzis/the-1090mhz-riddle

The book about decoding Mode-S and ADS-B data

the-1090mhz-riddle's Issues

ICAO addressses can be changed in military aircraft

the-1090mhz-riddle/content/ads-b/1-basics.tex

Line 56 in 90643ba

\section{ICAO address}

In the linked section it indicates that

A unique ICAO address is assigned to each Mode S transponder of an aircraft and serves as the unique identifier for each aircraft

However, as this report states military aircraft clearly often have a capability to modify the ICAO address.

It might be worth noting at this point that military aircraft can transmit non-assigned ICAO addresses. Potentially they could transmit anything else in the message, but I'm not sure that is important.

\0 and \1 not rendered in HTML version

The codes for \0 and \1 aren't rendered in several places of the HTML version of the book.

For example, in the introduction https://mode-s.org/decode/content/introduction.html#mode-s-replies

the source text:

The \0 bit is reversed compared to the \1 bit

is rendered as:

The bit is reversed compared to the bit

while it is rendered correctly in the PDF version:

About 1090MHz ES ，I

reference documentation/bibliography

I do not know how to do it in .rst files / or with .rst toolset (pandoc?), but I find that it could be useful to have bibliographical references to the standards or other relevant docs...
(Bear with me if these are already mentioned somewhere in the doc and I have not spotted them)

please re-instate "edit on github"

I think that the "edit on github" facility was a big way to lower the barrier for feedback and review/correction contributions.
Without it, the time needed to set things up is just increasing the time/burden and lowers the probability to get any feedbacks both from (somewhat) skilled geeks and aviation knowledgeable people.
My 2 cents. 😄

ADS-B uncertainty parameters table not rendered correctly on the website

In Chapter ADS-B > 9. Uncertainty > Terminology, the table for the ADS-B uncertainty parameters is not rendered correctly on the website. On the PDF version, however, it is shown correctly.

Let me take this opportunity to acknowledge your great work with this book.

Regards,
Álvaro

Wrong sign in the vertical rate formula

Hi,

I implemented some decoding functions based on your great book but I noticed that the formula of the vertical speed (7.1) has the wrong sign. The formula is written as VS = (2S_vr - 1) * 64 * (V_r - 1) but this conflicts with the meaning of S_vr = 0 is climb. Also the examples 7.2 and 7.3 have this mistake.

Br, Andreas

Decode guide about about DF4 DF5 D16

Hi,
The book is pretty comprehensive, however,It’s a pity that the book does not mention the decoding instructions for DF4 DF5 DF16，I sincerely hope that Dr. Sun can provide guidance in this field.I really hope to get your help and look forward to your reply

Question about about message rates and UTC synchronization

Hello,

i'm diving into the world of ADS-B / Mode S and of course, I'm using the precious resources you have made available.

I have to say I agree with your comment at the beginning of the ADS-B versions chapter, about official documentation user-friendliness (or lack of...)

Now the question, which is about message rates and UTC synchronization.
When the 1 bit UTC time sync is set, the "F" field then carries an extra meaning than odd/even, i.e.
the 0.2s steps to UTC TOS (top of second) with F=0 matching an even TOS.
With this description, I understand that the broadcast rate of those position report extended squitters should be exactly 5Hz when the UTC time sync bit is set.
This is compatible with the maximum 6.2 message/s (from ICAO 10.IV 3.1.2.8.9), but the ICAO Doc 9871 Table C-35 which states a broadcast rate of 2 per second for such squitters, which I believe is incompatible with the UTC synced behaviour. What do you think ? By the way, this C-35 rate table is only found in annex C, and therefore applies only to ES version 2.
The only behaviour I could see that somehow respect both would be a 0.6s time interval wich would fit a n*0.2s, the specified datarate and an odd/even frame alternate.
From your experience, do some existing equipment use this time sync feature ?

I only have edition 2 of the 9871 and edition 4 of the ICAO annex, so maybe those have changed...

Table 16.4

Hi junzis.

I believe the ending bit for the threat identity data is 88 not 86. See anex 10 volume 4 page 57 3.1.2.6.6.1.

Best,

ElSabio97

Citation not rendered in chapter "Airborne velocity" on website

This is a snapshot of the web page at https://mode-s.org/decode/content/ads-b/5-airborne-velocity.html

it is missing the citation between the words "in has".

This is a snapshot from the PDF at https://mode-s.org/decode/book-the_1090mhz_riddle-junzi_sun.pdf

This is the corresponding source text:

For instance, the study in \cite{stone2015} has made use of the later information to

Possible copy and paste error in description of NACv (V1,2)

the-1090mhz-riddle/content/ads-b/7-uncertainty.tex

Line 50 in ff8c461

& Vertical figure of merit (95\% horizontal accuracy - v) & VFOMr \\ \hline

I think that this should refer to "vertical accuracy", not horizontal.

Relationship between callsign and ASCII codings

An alternative to using the following lookup table, it seems to me that one could add 64 to any value that is lower than 32 and use ASCII.

#ABCDEFGHIJKLMNOPQRSTUVWXYZ#####_###############0123456789######

These are the indexes of the table.

A - Z :   1 - 26
0 - 9 :  48 - 57
    _ :  32

And these are the indexes in ASCII

A - Z :  65 - 90
0 - 9 :  48 - 57
Space :  32

The seventh bit (64) in 7-bit ASCII is simply cut off. With that assumption, we could technically fill out the rest of the lookup table with ASCII symbols (though they are probably not in use anyway).

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ !"#$%&'()*+´-./0123456789:;<=>?

Note that I put a space at index 32, instead of representing space with an underscore, because there's an actual underscore at index 31 because it has index 95 in ASCII.
This lookup table assumes that the 7th bit is 1 when the 6th bit is 0. They can't both be 1 or both be 0. But those cases aren't all that interesting anyway. The ASCII symbols where both bits are 0 are hardly useful outside of filesystems or network communications and the symbols where both are 1 are mostly just lower case letters.

Of course, I'm not saying that these other symbols are ever used, but I figured that this little tidbit would be interesting to someone.

wake vortex category seems to be invalid

In the book

1. tc=-2, category=1; Surface emergency vehicle
2. tc=2, category=3; Surface service vehicle <- should be category 2
3. tc=2, category=4–7; Ground obstruction <- ground obstruction is category 3; categories 4-7 are reserved

In ICAO doc 9871, 2nd edition, table A-2-8, p. A-31

1. tc=2, category=1: surface emergency vehicle
2. tc=2, category=2: surface service vehicle
3. tc=2, category=3: ground obstruction
4. tc=2, category=4-7: reserved

Table 6.2 Ground Speed

Table 6.2 (and code) shows the lower speed in the range being <= and the upper being < yet DO-260C Table 2-13 has the opposite convention i.e. the lower is < and the upper is <=. This results in the ground speed under reading.

Preamble Detection

Hi,
Thanks for compiling an amazing book on understanding the ADSB signal architecture and its decoding procedure. The book is pretty comprehensive, however, I couldn't find the preamble detection method used to identify an ADS-B signal. I want to know exactly:

• how the raw received data is first converted into binary
• how to implement preamble detection, before the adsb message could be decoded.

Any help will be highly appreciated.

Thanks
Bisma

The checkout command for dump1090 is incorrect

The text has the command as git checkout https://github.com/flightaware/dump1090.git it should be git clone https://github.com/flightaware/dump1090.git .

Missing target: mode_s_uplink_pulses

The Quick Start Guide has a link which does not successfully resolve to the stated target:.
#fig:mode_s_uplink_pulses
Specifically the HTML I'm referencing is at view-source:https://mode-s.org/decode/content/quickstart.html#fig:mode_s_uplink_pulses:

Given that a Mode S bit consists of a pulse cycle of 0.5 ms (see Figure <a href="#fig:mode_s_uplink_pulses" data-reference-type="ref" data-reference="fig:mode_s_uplink_pulses">[fig:mode_s_uplink_pulses] </a>), the minimum SDR sampling rate required for Mode S is 2 MSPS.

I found a PDF that looks to be what is desired to be linked to and it is at:
https://github.com/junzis/the-1090mhz-riddle/blob/master/figures/intro/mode_s_uplink_pulses.pdf

Clicking the link in the Quick Start Guide to view the mode_s_uplink_pulses results in no action, the reader is not taken to a figure.

I'd try to fix and submit a patch, but I'm not clear on how the deployment of PDFs are integrated into the staged HTML. Hope this helps.

More formatting could be added for "Note" and "Try it out" labels in HTML version

The word "Note" is rendered near to the following text, which reduces legibility compared to the PDF version. I think that appending ":" would be enough.

This is the HTML version:

This is the PDF version:

unsupported theme option 'sidebar_collapse' given

When I run make html I get the error

unsupported theme option 'sidebar_collapse' given

I can build the HTML docs if I remove from conf.py the line with that option.

I did a fresh git clone and installed the package python-sphinx (1.6.6-2) on Debian GNU/Linux testing (buster) which pulled the following dependencies:

Start-Date: 2018-02-11  13:27:04
Commandline: apt-get install python-sphinx
Requested-By: daniele (1000)
Install: docutils-common:amd64 (0.14+dfsg-2, automatic), python-markupsafe:amd64 (1.0-1+b1,
 automatic), docutils-doc:amd64 (0.14+dfsg-2, automatic), python-docutils:amd64 (0.14+dfsg-2,
 automatic), python-alabaster:amd64 (0.7.8-1, automatic), python-jinja2:amd64 (2.10-1, automatic),
 python-roman:amd64 (2.0.0-3, automatic), python-imagesize:amd64 (0.7.1-1, automatic),
 python-babel-localedata:amd64 (2.4.0+dfsg.1-2, automatic), python-babel:amd64 (2.4.0+dfsg.1-2,
 automatic), python-sphinx:amd64 (1.6.6-2), sphinx-common:amd64 (1.6.6-2, automatic),
 python-typing:amd64 (3.6.2-1, automatic)
End-Date: 2018-02-11  13:28:11

Is there a way to identify BDS code from mode-s message itself ?

When SSR interrogates aircraft, a BDS code is included in request message ( Uplink Format - UF 4, 5, 20, or 21). This BDS code are then used by the aircraft transponder to register the type of message to be sent. But when the downlink message is transmitted, its BDS code is not included in the message (because the SSR knows what kind message it requested).

If the bds code is not included, how do I decide what is the message type ?

Typo found in ehs.tex : {Ehanced Mode-S}

ehs.tex:1:\chapter{Enhanced Mode-S}

;)

Exponent of 2^17 not rendered correctly

This line

the-1090mhz-riddle/adsb/airborne-position.tex

Line 98 in e627276

Since CPR latitude and longitude are encoded in 17 bits, 131072 ($2^17$) is the maximum value.

renders as

Question about inferring the comm-B downlink parameters

I have read your article and had a look at your library pyModeS. I have a question:

• The function common.icao() , for message of type Comm-B, I see that just implement the ICAO address recovery logic. So, the resulting ICAO may be incorrect when message is corrupted or when ICAO adress is overlaid with the BDS code. Nevertheless, I see in your article an interesting method to check the veracity of the ICAO address, using the ADS-B data and the Squawk code. Is this implementation available in the pyModeS library?

Spelling errors in figures

I found two errors in figures:

in file figures/adsb/cpr_simple_1.pdf
s/positon/position/

in file figures/mode_s/bds44_example.pdf
s/avaiable/available/

校验码处是否是错误的？

Introduction - Incorrect unit conversion

On line number 15 of the introduction page source it incorrectly says eight pints [17kg] of water

8 pints of water is roughly ~4.5 liters (that is if you used UK pints, or ~3.7 liters if you used US pints) and roughly the same in kilograms. But in the text mentioned above it incorrectly states 17kg

The error is repeated again on line 18 where it says ...the average adult human has 17 kg blood and... (I also believe there should be no space between 17 and "kg" as it is a quantity with its unit of measure. Lastly, I suggest saying "of blood" instead of just "blood")

Suggest to improve position decoding part (by Savolt)

update position decoding guide on NL and other common functions

Errata: Caption Figure 5.2; "1) ACAS related bits" in Section 16.1

the-1090mhz-riddle/content/ads-b/3-airborne-position.tex

Line 68 in 54a87f6

\caption{Simplified CPR position coding (all position possiilities)}

• Current: Figure 5.2: Simplified CPR position coding (all position possiilities)
• Must be: possibilities

the-1090mhz-riddle/content/mode-s/6-els.tex

Line 52 in 54a87f6

72|71 37|36 0|0: RTCA/DO-185 (pre-ACAS)

72|71 37|36 0|0: RTCA/DO-185 (pre-ACAS)

• Current: 37|36
• Must be: 40|39

the-1090mhz-riddle/content/mode-s/6-els.tex

Line 264 in 54a87f6

0 & 1 & Multiple threats, RA is intended to provide vertical separation blew some threats and above some other threats \\ \hline

• Current: blew
• Must be: below