Dump1090 exits on failed 'global-dist check'

[chrislanzara]

Hi, I'm using an RTL-SDR receiver with Dump1090 and on the latest version I see two things:

1. No lat/long coordinates are displayed in interactive mode
2. After about 45 seconds, the application running inside the VS debugger quits from rtlsdr_read_async() with the exception: The I/O operation has been aborted because of either a thread exit or an application request

I have tried using an older commit (96fef15) and this version gives the lat/long display and does not throw the same exception, so I don't believe this is a hardware related issue.

What alerted me to this was the debugger stopping on line 3320 with an "invalid handle was specified" error.

Going further up the call stack, the above is called from modeS_cleanup() in dump1090.c on line 4595:

Best I can tell, the rtlsdr_read_async call on line 1119 receives a negative response and then logs to STDERR with the message: rtlsdr_read_async(): rc: 0/995: The I/O operation has been aborted because of either a thread exit or an application request.

Environment: Windows 11 with latest patches applies. Visual Studio 2022 with latest patch.
Testing environment: Dell XPS 13 and Dell XPS 15, both 11th gen intels with 8GB/32GB RAM respectively.
RTL-SDRs: tried with one generic ADS-B SDR, and also a FlightAware Pro Plus stick (the blue one)

[gvanem]

No lat/long coordinates are displayed in interactive mode

Probably since you have not set a valid homepos = lat, lon in the .cfg-file. Or if you use the Windows Location API
(location = true), it gives you a wrong position. Hence the airplanes lat/long will also be wrong and not shown.
Check what dump1090.log says about this.

with an "invalid handle was specified" error.

I've seen this on some rare occasion. I do not know the reason but you could disable the call to softagc_init();.
And rebuild. Also there is a race-condition in _beginthread() that could be the cause. Maybe I'll switch to
CreateThread().

[chrislanzara]

Probably since you have not set a valid homepos = lat, lon in the .cfg-file.

Ah sorry, I missed this. I've set it and can now get coordinates.

As for the error I was getting, I've tried with a different USB adapter and this issue is no longer occurring even with the latest build and has been running fine for 5 minutes and longer. The same adapter with the previous version worked okay, which feels odd, but I'll put this one down to a me issue and close this.

Thanks!

[gvanem]

As for the error I was getting, I've tried with a different USB adapter and this issue is no longer occurring

Strange, but not all sticks are of the same quality. Overheating or other WinUSB issues may also be the reason
the loop in rtlsdr_read_async() exits prematurely. All these:

• WinUsb_GetOverlappedResult()
• WinUsb_ReadPipe()
• WinUsb_ControlTransfer()

may set dev->async_cancel = 1. It would be nice which one was the cause in our case.

[chrislanzara]

I think this was a case of "famous last words", I've just had another exception thrown. I'll do some more digging but at the moment I'm trying to work out why the vertical rate and squawk are coming out as base-10 values when they should be coming out as hex values (i.e. a squawk for TOM6JK is coming out as 21281 when it should be displayed as 5321).

[gvanem]

squawk are coming out as base-10 values when they should be coming out as hex values

To the network client it's sent as ",\"squawk\":\"%04x\"", a->identity);.
But I guess (with your PR in mind), you mean the SBS-output. I've not used that much.

Back to the original issue. Can you test with your original bad dongle and do:

set RTLSDR_TRACE=1,winusb
dump1090.exe --raw

Post the trace at the end when rtlsdr_read_async() fails.

[chrislanzara]

Just to say that I've been trying to replicate this issue but it's not doing it again, even with the same hardware setup I had previously. I'll keep trying and will post the trace as requested once it fails.

[chrislanzara]

Hi, I've just been able to find time to re-test this, and using the env var as requested, and --raw option, I see this after about 45 seconds. Note though, that the homepos is set inside my cfg file, so I don't know why I'm seeing the comment about Fix your "homepos = lat,lon" to continue. below.

*5d3c6662c193cd;
*5d40660e88aa5d;
*5d40660e88aa5d;
*5d4866df1d9963;
*5d3c6662c193d4;
*5d3c6662c193cd;
*5d40660e88aa5d;
*a00017190000000000000098fbbc;
All aircrafts failed 'global-dist check' (1, sum: 1).
Fix your "homepos = lat,lon" to continue.
librtlsdr.c(2900): WinUsb_GetOverlappedResult() failed with 995: The I/O operation has been aborted because of either a thread exit or an application request.
librtlsdr.c(2965): rtlsdr_cancel_async(): r: 0, dev: 0x000001EF0DA50BC0, state: RTLSDR_RUNNING -> RTLSDR_CANCELING
librtlsdr.c(2654): rtlsdr_free (0x000001EF0DA50BC0, 2921): overlapped: 0x000001EF0DC997B0, xfer_buf: 0x000001EF0DC99870
rtlsdr_read_async(): rc: 0/995: The I/O operation has been aborted because of either a thread exit or an application request.
librtlsdr.c(2965): rtlsdr_cancel_async(): r: -2, dev: 0x000001EF0DA50BC0, state: RTLSDR_INACTIVE -> RTLSDR_INACTIVE
librtlsdr.c(1332): rtlsdr_deinit_baseband(): r: 0
librtlsdr.c(2725): rtlsdr_close(): loops: -1, state: RTLSDR_INACTIVE -> RTLSDR_INACTIVE
librtlsdr.c(2654): rtlsdr_free (0x000001EF0DA50BC0, 2728): overlapped: 0x0000000000000000, xfer_buf: 0x0000000000000000
librtlsdr.c(3318): softagc_close(): killing thread: 592
No mem-leaks detected.

C:\Dev\Dump1090>

Hopefully this helps?

[gvanem]

All aircrafts failed 'global-dist check' (1, sum: 1).

Seems this bad (?) dongle gave you only 1 message with a position and that cpr.c does:

  if (Modes.max_dist > 0 && Modes.home_pos_ok)
  {
    double distance = geo_great_circle_dist (&Modes.home_pos, new_pos);

    if (distance > Modes.max_dist)
      ...

Not sure what to do with this. You could try a Modes.max_dist = 0; in dump1090.c.
Or I could make that into a .cfg-setting.

I can simulate your situation with location = false and homepos = 89.30527, -15.30484 .
But then I get:

*a0001718c6500030a4018042c7e3;
*a0001718803dcf3ae004f9d842c7;
All aircrafts failed 'global-dist check' (117, sum: 117).
Fix your "homepos = lat,lon" to continue.

Far more than 1.

[Dis3ntr0py]

Currently experiencing the same issue. Ran dump1090 with --raw and output is identical to @chrislanzara. By setting max-distance in dump1090.cfg to 0 the code no longer exits unexpectedly!

[gvanem]

I just renamed the issue title to Dump1090 exits on failed 'global-dist check' .
Since that's the cause of the exit. Not RTL-SDR - I/O operation has been aborted which is a side-effect.

@Dis3ntr0py

By setting max-distance in dump1090.cfg to 0 the code no longer exits unexpectedly!

To not be able to calculate a reliable distance to the plane(s) is pretty bad. But I could make an exception for it.

[mufaka]

I was getting this error as well after connecting a 1090 specific antenna whereas with a different antenna I wasn't. I am testing on rtl-sdr v3 and v4 dongles. My homepos is correct.

All aircrafts failed 'global-dist check' (28, sum: 28).
Fix your "homepos = lat,lon" to continue.

Looking at the logs, I noticed a lot of planes past the max distance of 50km.

15:34:10.209: CPR: A5502B: global distance check failed (33.449,-118.133), max dist 50.0km, actual 54.4km
15:34:10.264: CPR: C004F3: global distance check failed (33.188,-117.722), max dist 50.0km, actual 52.3km
15:34:12.120: CPR: A5502B: global distance check failed (33.448,-118.137), max dist 50.0km, actual 54.8km
15:34:13.486: CPR: A54299: global distance check failed (33.131,-117.804), max dist 50.0km, actual 60.5km
15:34:14.194: CPR: C004F3: global distance check failed (33.196,-117.726), max dist 50.0km, actual 51.6km
15:34:14.194: CPR: A5502B: global distance check failed (33.446,-118.141), max dist 50.0km, actual 55.3km
15:34:15.342: CPR: A54299: global distance check failed (33.134,-117.806), max dist 50.0km, actual 60.2km
15:34:16.107: CPR: C004F3: global distance check failed (33.199,-117.728), max dist 50.0km, actual 51.2km

It seems that the default config is set as

max-distance     = 50000

Which seems to be one zero short of the value that is defaulted in code. I set mine to match the code default of

max-distance     = 500000

This resolved the issue for me.