Wired messages received...

[kenzed]

Hi, I'm a sdr amateur in China. Thanks for your work. It receives messages like below. -51045768861c17dc507d16e42403f5121e800a82c2d14ddd449222b8335a9841022d;rs=7; -7d63b423ddeba347932bb8ca85ef9d3fb76ccf597c8ddd5f9457197f7ff93cd71870;rs=7; -cdfed68f56de12477e31a703af1d6aa46ccd6593bf987eea4f55c22f8f1e10021727;rs=7; -91ec89070a6d7151fb767e9134fd9a105b175d1cfc4742d1ecdaadb831e30ac28d49;rs=7; -d3cc9dafb58bab5b771534f575f6fa20f62bfe9d0da2bd04154d4f8fab265e411b03;rs=7; -a369f09c0c59d950d104ece7bf0d82c3b089ea07f2c9ed3d0341c944110b9dc7dc11;rs=7; -47611cc7e9b6c8ac0215cee35a2fba6ac1b59f57153bf8087f7b515593697a69f5c2;rs=7; -84d0cc727081d31644da9aea8b5a12dd8eed472dc5603395c98e0c64718dbb112e19;rs=7; -8e808e8b0c36d901b7a0bce15855b2eea2235d4c2fa910852e52972a644a51c0a950;rs=7; -28c102b4de84f910ab06400518431052fe542b6c9d980bcaa75c2a064ac0d1c464c4;rs=7; -c30e8431a9a12635e7114a597e9c79495cb08fc8e865e6e363041ce652c387018013;rs=7;

-890786e3f202e571fca44083844982ec35cb3e7787702939840278eb4b631940f79f;rs=7;

most of the messages is beacon, and some decode like this: HDR: MDB Type: 8 Address: 611CC7 (reserved (7)) SV: NIC: 3 Latitude: -15.6699 Longitude: +120.9432 Altitude: 81725 ft (geometric) N/S velocity: -2600 kt E/W velocity: -3532 kt Track: 233 Speed: 4385 kt Vertical rate: -10944 ft/min (from barometric altitude) UTC coupling: no TIS-B site ID: 0

HDR: MDB Type: 5 Address: C102B4 (ICAO address via ADS-B) SV: NIC: 5 Latitude: -23.5410 Longitude: -168.2803 Altitude: 24575 ft (barometric) N/S velocity: -527 kt E/W velocity: -543 kt Track: 225 Speed: 756 kt Vertical rate: 19328 ft/min (from barometric altitude) UTC coupling: yes TIS-B site ID: 0 AUXSV:

Sec. altitude: 76100 ft (geometric)

I think the data is wired, so is there something wrong in the decode algorithm? or just somebody sending test frames of UAT? I can upload recorded raw data if you need them. Could the UPLINK_POLY and ADSB_POLY value lead to the this? is there another UPLINK_POLY ADSB_POLY value to use to test?

[mutability]

Hi! If all the messages you see are decoding with lots of RS errors (that's the trailing rs=7) then it does sound like there is a problem with the RS correction.

However, the error correction passes the tests from DO-282B (see fec_tests.c for test data).

It's possible that China's version of UAT uses a different error correction polynomial but I have no information about what that might be.

You could try disabling the error correction entirely (stub out correct_adsb_frame in fec.c so it does not call decode_rs_char, but just sets *rs_errors=0 and returns 1 or 2 based on the frame type) and see if the decoded data looks plausible. Obviously it might be damaged by real errors, but at least the error correction won't be causing further damage!

[mutability]

Also, it's possible that it's a build problem - can you run "make test" and check that all the FEC tests do, in fact, pass on your system?

[kenzed]

fec lib seems to be ok on the mac os x and ubuntu on cubieboard...

[kenzed]

a lot of wired uat message jumps out after adding the following statements to the first part of correct_adsb_frame. *rs_errors = 0; return 1;

Another question, how to cal 'gfpoly' and 'fcr' for func 'init_rs_char' ? I can see rs_adsb_short is using RS(30,18), rs_adsb_long is using RS(48,34) and rs_uplink is using RS(92,72). And in another uat project 391 is used for gfpoly in RS(92,72), why?

Thanks!

[mutability]

If you download the full FEC library from http://www.ka9q.net/code/fec/ it has a manpage that explains the parameters to init_rs_char. Briefly:

       gfpoly  gives  the extended Galois field generator polynomial coefficients, with the 0th coefficient in the low order bit. The polynomial must be primitive; if not, the call will fail and NULL will be
       returned.

       fcr gives, in index form, the first consecutive root of the Reed Solomon code generator polynomial.

391 == 0x187. It is a representation of the primitive polynomial from the UAT spec: p(x) = x^8 + x^7 + x^2 + x^1 + x^0. Bit N is the coefficient of the x^N term so bits 8,7,2,1,0 are set.

fcr comes from the definition of the generator polynomial in the UAT spec (from "i=120")

...

It would be interesting to see your raw RF captures if you can make them available somewhere.

[kenzed]

Oh, sorry to be so rookie to forget the hex sign. I'm trying to run dump978 on a pc ubuntu since there is a line 'The new Intel Macs are not yet supported. Stay tuned.' in the fec lib site. still get 'Vertical rate: 27520 ft/min (from geometric altitude)'

[mutability]

Is it possible that you have I/Q samples reversed? That would lead to trying to decode an uplink message as a downlink message (and vice versa), I think, as the sync words are inverted copies of each other..

[mutability]

(you could test that easily by swapping the values of ADSB_SYNC_WORD / UPLINK_SYNC_WORD)

edit: erp, no, that wouldn't work, never mind..

[kenzed]

It took me quite some time to upload the raw file. It's ok now. url: https://www.dropbox.com/s/5vdwmebtb4er14g/iq_978M%402083334.raw?dl=0 md5( if needed ): MD5 (iq_978M@2083334.raw) = d523579d866403ea0b37b9ec4d946c8f some test before sending the raw file on my intel mac( with rs correction set off ): cat ./iq_978M\@2083334.raw | ./dump978 -2741fe7abe8c3bf6187fcfeef71cfba542aef35d056ab446b06a10f7cbdf92e356a6; -9bff0facf021a0ba9d29011e77d1b9fe302529f68143b7783e21c87d5bf9edb53f3c; -12b4370f28aeccac51bd2893e918057fe9ca981ebe4be2f0f7d2838bdc4ab55cbcce; -b5e5f4f9e6293a9153ba369ede9003f51d2f0bddd558a7ad0df44dff84d0702913fa; -17012c8c4a726829d85f4a9ec9371c23af95d64fbddb6f95ba4814af6ad3ea7b2c16; -186d10d1f80e5edbf5a5a9ff5e78ff88f6f94f7fdca1c657e24f3607bc693b7afb8e;

[kenzed]

I notice that if I set the gain parameter of rtl_sdr to 48 there is the most uat data, gain 40 less and gain 32 more less.

the raw file is captured at gain == 48

[kenzed]

When I tune to some other frequency, there is still sync word having been found...

$ rtl_sdr -f 78000000 -s 2083334 -g 48 - | ./dump978 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 2083334.141630 Hz Sampling at 2083334 S/s. Tuned to 78000000 Hz. Tuner gain set to 48.00 dB. Reading samples in async mode... -cd0357b6800fc34306aba5751561f1a4470488188a6420885bca30b7b0e89d63f93b; -485741611907d36188a0e9404f992d0664381588173cc828b413ec882d9a7c1502e8; -7289c482535182660fd7224f3391554a81640744a3c92e093e095410240301640035; -9a293049096882242f2349e62ab027b0ca53582ea6fb1b261b2fbb55890a687a2028; -d6f23643d82e0c05f4f2cd50f70b20010ce26d20d452592c051196e652882342298b;

I checked my RRE( rtl-sdr run-time environment ) with this: $ ./dump1090 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected) Found Rafael Micro R820T tuner Max available gain is: 49.60 Setting gain to: 49.60 Exact sample rate is: 2000000.052982 Hz Gain reported by device: 49.60 *8d78073499048b1d204e02e35982; CRC: e35982 (ok) Single bit error fixed, bit 78 DF 17: ADS-B message. Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne)) ICAO Address : 780734 Extended Squitter Type: 19 Extended Squitter Sub : 1 Extended Squitter Name: Airborne Velocity EW direction : 1 EW velocity : 139 NS direction : 0 NS velocity : 233 Vertical rate src : 0 Vertical rate sign: 0 Vertical rate : 19

*8d7807345827542322e0392cbecb; CRC: 2cbecb (ok) Single bit error fixed, bit 8 DF 17: ADS-B message. Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne)) ICAO Address : 780734 Extended Squitter Type: 11 Extended Squitter Sub : 0 Extended Squitter Name: Airborne Position (Baro Altitude) F flag : odd T flag : non-UTC Altitude : 6725 feet Latitude : 4497 (not decoded) Longitude: 57401 (not decoded)

[mutability]

OK, I looked at the capture but there just doesn't seem to be any signal in there, you're just decoding noise as far as I can tell. (Throw enough noise at the decoder and some of it will stick..)

Here's what a capture that decodes well looks like (it's all uplink signals):

Here's what your capture looks like:

I mean, maybe there is some sort of periodic signal in there? But it's hard to tell - there's a heck of a lot of noise.

Are you sure there are UAT transmissions on the air to be heard? What sort of antenna are you using?

[kenzed]

I have to say, I'm not 100% sure there are strong enough UAT transmissions over head, I'm about 10km away from the UAT transmissions source, and I use a poor antenna comes with the rtl usb stick. Is there some suggestion on the antenna? I'll go to a place near UAT transmissions source, and try again in days. I will feed back the result. Thanks for all your help!

[mutability]

The whip antenna isn't very good, and you will need line of sight to the transmitter, like with 1090MHz.

An antenna that works well for ADS-B on 1090MHz should also work well for UAT, they're fairly close. Something like a quarter-wave ground plane should be fine.

[kenzed]

Hi, everything goes fine when running dump978 near a uat transmission source. I did the experiment yesterday. The antenna matters much in the reception. That's why I was decoding noise before. Thanks!