Re: ADSBSpy Output format

jdow
 

On 20180409 02:04, Support@... wrote:
RE : Divide by two does NOT and CANNOT provide an intrinsic 90 degree phase shift. So there is little or no sensible reason to do this that I can see. If it uses a factor of two divider the intent may be simply to get a clean square wave from a sine wave generator. I repeat, a simple divide by two gives you two signals 180 degrees out of phase. These are not directly useful for generating I and Q signals. A divide by four will work for generating I and Q, however.
That may or may not be true - but since I didn't write airspy.dll there is nothing I can do about it. All I can tell you is that sdrsharp uses the output from airspy.dll as a 10MSPS I/Q stream and the *ONLY* input to airspy.dll is a 20MSPS stream of real 12 bit samples. The source for airspy.dll (and the Linux equivalents) are available at the link I posted. If you are saying that a 20MSPS real stream cannot be converted to a 10MSPS I/Q stream then you'll have to take that up with Yousef.

The basic problem I have with that is presuming the 20 MHz means 50 ns when you get I and Q at 10 MHz. I alone and Q alone don't give you a meaningful time.


RE: The statement you took exception to was part of a cut and paste from the most informative ADS-B decoding site I found on a quick search. Argue with that person. _http://mode-s.org/decode/adsb.html_ specifically this page paragraph 1.1.4: _http://mode-s.org/decode/adsb/introduction.html_
I'm not arguing with anyone. I was informing you - assuming that you wished to know - that the statement "IF CRC not 0: MSG is corrupted" is at best incomplete, and at worst just wrong. I have the actual ICAO specifications in-front of me.
RE: The point, however, is that you have sufficient data to calculate your own CRCs. So that is not an issue, or should not be.
Yes, I can and do calculate my own CRC's. But as I've explained several times, these aren't reliable for DF-11's. Once you accept that the CRC's aren't the answer, you have to go back and attempt to reduce the number of invalid frames being produced by the decoder, and stop trying to rely on the CRC to catch them.
RE: The time stamp issue is probably an issue in the code which may not be at all easy to fix without potential clock drift since there is nothing in the world that says a decode will occupy precisely 1280 samples. That only happens if oscillators (temporarily) line up fortuitously. A one count (or two count depending on filters) error can become quite large over time. Furthermore the code that provides the time stamp probably has no knowledge about the state of the demodulator/decoder. So time gets lost there. Add the microseconds to the message stamps yourself. (Or find a way to convince ADSBSpy to request (much) smaller buffers.
I can't explain it any simpler than "The issue is *NOT* with the timestamps. The timestamps are spot on +/- a few ppm to 50nS granularity". I am the author of large parts of Dump1090 - I know how the timestamps for that are generated, and I therefore am pretty sure how airspy_adsb generates them. The issue is that the decoder is producing an ADSB frame starting at sample offset N in the buffer, AND at offset N+1, AND at offset N+2 AND occasionally at offset N+3, AND that these 3 or 4 decodes are all different.
RE: Or build your own version of ADSBSpy starting with some open source software.)
Yes that's an option - but I'd rather not re-invent the wheel if I don't have to. airspy-adsb does almost everything I need, but that's not to say it can't be improved.
Argue with Youssef. Are you absolutely certain that the multiple packets do not represent multiple transmissions?

{^_^}

Join airspy@groups.io to automatically receive all group messages.