Re: Another failure of decoding UAT

I'm assuming the GDL 39 is airborne when receiving -- there's no guarantee of ground-based coverage, and unless you're close to a transmitter or have line-of-sight due to elevation you might not have any signal to work with. I think the first thing you should do is verify some sort of signal is present, using osmocom_fft or whatever, and then record some samples you can work with offline to decode. Maybe go for a flight near the uplink, verify there's a signal using both the GDL 39 and the RTL dongle, and record some nice strong samples to hack on later. I haven't looked into decoding UAT with any seriousness apart from reading DO-282B, but 2 samples per symbol should be enough to work with. Maybe I'm being clueless here, but I don't see justification for saying the RTL dongles can't sample fast enough for UAT. The usual noncoherent method -- a differential quadrature demodulator -- should be fine, and saves you from having to phase- and frequency-synchronize with the baseband signal. I haven't looked closely at your code, but your description sounds pretty close to that. You'll see (up to) 312.5kHz deviation on a '1' bit, and (up to) -312.5kHz deviation on '0'. You can probably get away with open-loop clock recovery since the packets are so short, but you'll still have to estimate the center of the bit so you can sample and slice. Personally, as a registered GNU Radio fanboy, I'd be using GR to at least get started demodulating UAT. It gets you graphical sinks to work with and a set of proven signal processing blocks, so you don't have to worry as much about an ad-hoc approach being valid or not. --n On Wed, Jan 22, 2014 at 8:54 AM, Pete Zaitcev <zaitcev(a)kotori.zaitcev.us>wrote;wrote: