V5.0.5-airspy dump1090-fa with native AirSpy support now available

I’m not hard core enough to try and compile this but i’d thought i’d check my airspy_adsb if it spits out any duplicate messages …
(none as far as i can see)

But i’m curious what you would get, this is some code for decodeModesMessage() in mode_s.c:

    static char lastMsg[MODES_LONG_MSG_BYTES];
    static int64_t lastTimestampMsg;
    if (mm->timestampMsg != MAGIC_MLAT_TIMESTAMP
            && memcmp(lastMsg, msg, MODES_LONG_MSG_BYTES) == 0
            && (imaxabs((int64_t) mm->timestampMsg - lastTimestampMsg) < 10e-6 * 12e6)) {
        // discard duplicates with receiver timestamps closer than 10 us (somewhat arbitrary)
        // this might not work with Radarcape as the timestamps don't use a 12 MHz timebase (not sure about it)
        // Modes.stats_current.messages_rejected_dupe++;
        displayModesMessage(mm);
        return -2;
    }
    lastTimestampMsg = mm->timestampMsg;
    memcpy(lastMsg, msg, MODES_LONG_MSG_BYTES);

Instead of increasing the stats counter an fprintf should also work provided it’s low frequency enough.
Was just thinking about this with oversampling and stuff … might be interesting to check.

I’ll probably remove that code from my readsb again as in most situations it’s useless overhead :slight_smile:

The ADC is the same, the rest of circuitry is a bit different.

R2 runs a 20 MHz clock the mini runs a 24 MHz clock.
They derive native 20 MSPS and 12 MSPS rates from that. (dividing a clock by 2 is easy)

It’s really all in his previous posts in this thread ?confused?
(or rather in the posts linked)

1 Like

R2: 20MSPS Real
Mini: 12MSPS Real

The way the detection is implemented in airspy_adsb, the messages cannot be duplicated even if the pulses splatter over time spans larger than the nominal pulse time. It’s easy to check with the MLAT clock.

Gotcha. Sorry, I wasn’t keeping up with the discussions in that thread and the product pages seemed to conflict a bit.

Yeah excuse the 1 in 12000 … my code wasn’t making sure it’s not looking at synthetic MLAT.

There is no notion of detection “offset” to begin with. This is only useful for low sample rates with some extrapolation. ie. RTLs.

Was the duplicate message thing directed at me? That code doesn’t exist in dump1090-fa, at least not any more.

It never did, i just added it to readsb out of curiousity.
Also adjusted the code slightly to just display the message, see the previous message.
I figured you’d just make it work (anyhow do another copy paste, it properly ignores MLAT now).

It’s not meant to be there permanently either, just for testing :slight_smile:

Ha! I gotcha. It’s still early in the morning for me.

With your change I get these a few times a second…

*;
CRC: 000000
Score: 12 (UNRELIABLE_KNOWN)
Time: 18611181.17us
DF:0 addr:000000 VS:0 CC:0 SL:0 RI:0 AC:0
 Short Air-Air Surveillance
  ICAO Address:  000000 (Mode S / ADS-B)

Maybe 100 out of 20000 messages.

The zero messages are filtered anyhow in decodeMessage place the code below that filter :slight_smile:

Totally forgot that i can just use your decoder without recompiling as i’ve already tried … and also check for dupes in my forthcoming chain (which i don’t change anyhow).

Not seeing any dupes.

Oh … i’m stupid this is probably a bad place to check this to actually see the message content.
displaymodesmessage doesn’t work at that point as the message hasn’t been decoded yet.

You can put it before the return 0 in decodeModesmessages though.

    static char lastMsg[MODES_LONG_MSG_BYTES];
    static int64_t lastTimestampMsg;
    if (mm->source != SOURCE_MLAT
            && memcmp(lastMsg, msg, MODES_LONG_MSG_BYTES) == 0
            && (imaxabs((int64_t) mm->timestampMsg - lastTimestampMsg) < 10e-6 * 12e6)) {
        // discard duplicates with receiver timestamps closer than 10 us (somewhat arbitrary)
        // this might not work with Radarcape as the timestamps don't use a 12 MHz timebase (not sure about it)
        displayModesMessage(mm);
        return -2;
    }
    lastTimestampMsg = mm->timestampMsg;
    memcpy(lastMsg, msg, MODES_LONG_MSG_BYTES);


    // all done
    return 0;
}

Oh and if you want some statistics, just add

 Modes.stats_current.remote_received_modeac++

That should be as good as any of the other counters to abuse for this particular testing case.

note that it’s actually “normal” to see real duplicate messages on the air - DF11 is the most obvious case (for a given aircraft, there’s almost no variable content in there)

25ms seems very long. If you’re looking for the same message being decoded repeatedly with slightly different sampling points then 5us should be more than enough?

Yeah probably :slight_smile:

I wasn’t thinking too hard about it.
As not let bad code lying around … i just changed it to 10 us.

Do you want to test the verbatim message or the corrected version?

Huh?
I was just looking for duplicate rate that comes out … as it might skew numbers for the stats comparing multiple decoders.
Anyhow be sure to reduce the allowed time difference.
While i didn’t see any duplicates so short after each other, what obj is saying makes sense :slight_smile:

testing corrected messages (mm->msg vs in) and 5us, …
155 dups out of 19983 usable (60 seconds)

Almost all are DF-4 Altitude replies

Score: 12 (UNRELIABLE_KNOWN)
Time: 50488940.50us
DF:4 addr:A5B3AD FS:0 DR:0 UM:0 AC:3767
 Survelliance, Altitude Reply
  ICAO Address:  A5B3AD (Mode S / ADS-B)
  Air/Ground:    airborne?
  Baro altitude: 22775 ft

with a smattering of DF-11

Score: 23 (DF11_ACQ_KNOWN)
Time: 51315559.50us
DF:11 AA:A9E4BB IID:0 CA:5
 All Call Reply (reliable)
  ICAO Address:  A9E4BB (Mode S / ADS-B)
  Air/Ground:    airborne

and DF-16

Score: 12 (UNRELIABLE_KNOWN)
Time: 49964448.50us
DF:16 addr:a9e4bb VS:0 SL:0 RI:0 AC:5762 MV:50B422CC67BED6
 Long Air-Air ACAS
  ICAO Address:  A9E4BB (Mode S / ADS-B)
  Air/Ground:    airborne?
  Baro altitude: 7400 ft

Maybe put a check like this in before handing messages to decodeMessage in your part of the code?
Just to not skew the stats.

Anyhow your code seems to work nice :slight_smile:
Don’t think i get any difference but it’s really hard to tell in my location.

I could but the message hasn’t been error corrected at that point, just scored. That was just like putting it at the top of decodeModesMessage().

EDIT:
I could put it in decodeModesMessage() just after the call to correctMessage() and return a -3. I’d also have to add a new entry to the stats and update both demod_hirate and demod_2400 to check for teh -3 and increment the new counter.

I don’t really know where it would fit best or how you would best be able to check for it, was mostly a remark in regard to statistics.
Just nice to have no dupes in there.