ModeSDeco2 and ModeSMixer2 - console programs for RTLSDR and transcoding

[sergsero]

Hello ytsejam,

I'll try to check it soon. The device number is read in response to the request to the specific device instance.

If you reliably know the true serial number of each dongle and what kind of antenna is connected to each, could you also test in real conditions - which of the programs correctly determines this number?
In this case, the numbers that the system assigns (0,1,2...) can changing every time for each dongle, while the serial number is constant.

Thanks,
sergsero

[sergsero]

Hi IanH,

At this stage of testing filter it's important be convinced in effectiveness blocking of duplicates.

The filtering algorithm is analyzes and uses a variety of factors.

The filter continuously monitors the data stream and selects the adjacent pair with icao24 addresses that differ by ±1 (hex), and mark them as potentially positive for duplicate.
Further in the each selected pair will be determined Callsign and Squawk (and additionally transponder type). If they are the same, then the pair is passed to the second filter that counts the number of received messages from each instance in the pair. Also monitored altitude and vertical speed. These parameters are collated with the duration of observation. And so on for a number of other signs. As a result the pair can be recognized as duplicates.  One of her instances as real aircraft and its data will be presented at the output. While the ghost will be blocked.

However, I evaluate calculation value of efficiency the filter about 80% and in specific cases errors can reach 20%. And field experiment gives real estimate.

Regards,
sergsero

[ytsejam]

Hello ytsejam,

I'll try to check it soon. The device number is read in response to the request to the specific device instance.

If you reliably know the true serial number of each dongle and what kind of antenna is connected to each, could you also test in real conditions - which of the programs correctly determines this number?
In this case, the numbers that the system assigns (0,1,2...) can changing every time for each dongle, while the serial number is constant.

Thanks,
sergsero

Hi Sergsero,

Thank you very much, I do understand that I can use --device-serial to specify the device to use, that's why I was not quite sure if it is a bug.

I was in the impression that the index should be the same with rtl_sdr, and recently while I try to figure our the ppm error by rtl_test, I realized that the device ID used in modesdeco2 is not the same with rtl_sdr.

However, on my system, ARM Linux based, the index arranged by rtl_sdr is always the same and is in the same order with USB ports.
For example, the dongle in UBS port 1 is always assigned with ID 0, and USB port 2 is ID1.
Just think that it will be good if modesdeco2 has the same behavior.

Regards,
Ytsejam

[sergsero]

To remove the duplicates, you need to add

Code Select Expand

--filter-dup to command line

Probably, for enhance the result, you can optionally add the second option that may affect this issue: --disable-correction

[spotter.ssol]

sorry the Map dont work. I try FF, Chrone.

WTF on the IE work the Map?! 

Hit Ctrl+F5.

[Radio2.0]

Chrome -> dont work
IE -> work



@sergsero
Which Format is needed for the Position ? WG48 or how the called?

[IanH]

OK - looks like you already considered the possibility of real icao24 addresses that differ by 1.

I will continue testing 

[Radio2.0]

i dont know why the do it?!


Can someone tell me what exactly the Aircraft send out for Data??? 
There are many websites about but the dont tell it exactly.

[sergsero]

Hi ytsejam,

I did a comparison of both programs on identity in determination of index device and its serial number.
According to information received discrepancies not identified.

Please, see attached screenshot.

In the test were used 2 dongle.
Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
  1:  Realtek, RTL2838UHIDIR, SN:


The first based on Rafael Micro R820T tuner with SN: 00000001 and the second based on Elonics E4000 tuner with SN: (without number).
This was determined  in program rtl_sdr.

Alternately running the program for the device with index 0 and 1 you can see the difference in tuner chip.

ModeSDeco2 has issued, in its turn, the same indexes and serial numbers.

[Attachment deleted by Admin to save file space]

[ytsejam]

Hi ytsejam,

I did a comparison of both programs on identity in determination of index device and its serial number.
According to information received discrepancies not identified.

Please, see attached screenshot.

In the test were used 2 dongle.
Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
  1:  Realtek, RTL2838UHIDIR, SN:


The first based on Rafael Micro R820T tuner with SN: 00000001 and the second based on Elonics E4000 tuner with SN: (without number).
This was determined  in program rtl_sdr.

Alternately running the program for the device with index 0 and 1 you can see the difference in tuner chip.

ModeSDeco2 has issued, in its turn, the same indexes and serial numbers.

Hi sergsero,

Much appreciated for the testing.

Actually in my case, both RTL dongles are the same with R820T2 tuner.


I also took a look at the rtl_sdr source code.
I think rtl_sdr uses libusb to determine the index of devices.

<----- In librtlsdr.c

int rtlsdr_get_device_usb_strings(uint32_t index, char *manufact,
               char *product, char *serial)
{
   int r = -2;
   int i;
   libusb_context *ctx;
   libusb_device **list;
   struct libusb_device_descriptor dd;
   rtlsdr_dongle_t *device = NULL;
   rtlsdr_dev_t devt;
   uint32_t device_count = 0;
   ssize_t cnt;

   r = libusb_init(&ctx);
   if(r < 0)
      return r;

   cnt = libusb_get_device_list(ctx, &list);   <-----  device list is created here in the same oder determined by libusb

   for (i = 0; i < cnt; i++) {
      libusb_get_device_descriptor(list, &dd);

      device = find_known_device(dd.idVendor, dd.idProduct);

      if (device) {
         device_count++;

         if (index == device_count - 1) {
            r = libusb_open(list, &devt.devh);
            if (!r) {
               r = rtlsdr_get_usb_strings(&devt,
                           manufact,
                           product,
                           serial);
               libusb_close(devt.devh);
            }
            break;
         }
      }
   }

   libusb_free_device_list(list, 1);

   libusb_exit(ctx);

   return r;
}


<------ The order reported by lsusb should also determine the order of devices in rtl_sdr


root@ADSB:/opt/adsb# lsusb
Bus 002 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 004 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@ADSB:/opt/adsb#

root@ADSB2:/home/cubie# lsusb -v -d 0x0bda:0x2838

Bus 001 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x2838 RTL2838 DVB-T
  bcdDevice            1.00
  iManufacturer           1 Realtek
  iProduct                2 RTL2838UHIDIR
  iSerial                 3 00000004   <-------------- The frist one is SN#00000004
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          4 USB2.0-Bulk&Iso
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              5 Bulk-In, Interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              5 Bulk-In, Interface
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      2
Device Status:     0x0000
  (Bus Powered)

Bus 003 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x2838 RTL2838 DVB-T
  bcdDevice            1.00
  iManufacturer           1 Realtek
  iProduct                2 RTL2838UHIDIR
  iSerial                 3 00000003  <----------- The 2nd one is SN#00000003
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          4 USB2.0-Bulk&Iso
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              5 Bulk-In, Interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              5 Bulk-In, Interface
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      2
Device Status:     0x0000
  (Bus Powered)
root@ADSB2:/home/cubie#

<------ rtl_sdr follows the same order ID#0 = SN#4 and ID#1 = SN#3

root@ADSB2:/home/cubie# rtl_test
Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000004  <----
  1:  Realtek, RTL2838UHIDIR, SN: 00000003  <----

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
lost at least 136 bytes
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 25
Segmentation fault

<------ But it seems modesdeco2 will sort the devices by serial number first before determine the device ID.

root@ADSB2:/home/cubie# modesdeco2 --device-list
2015-12-29 09:06:22.724  INFO     ModeSDeco2 v.20151226

Available RTL Devices:
0 mnf: Realtek prod: RTL2838UHIDIR serial: 00000003  <----
1 mnf: Realtek prod: RTL2838UHIDIR serial: 00000004  <----

No Available AirSpy devices.
root@ADSB2:/home/cubie#


Regards,
ytsejam

[sergsero]

Hello,

The possible use of the new options in ModeSMixer2 v.20151226 when testing it.

--add-reference-point <Lat:Lon:Label>
The option creates on the map an alternative point to '--location', as the reference point for calculating distance and azimuth to the selected aircraft. This new value will be displayed in detail.
This reference point can be the only single with arbitrary name. Usage - mark out the runway threshold.
Usage: --add-reference-point 54.2446:82.7991:RW.



--add-points <Lat:Lon:Label [Lat1:Lon1:Label1 Lat2:Lon2:Label2]>
The option creates on the map one or several points with given coordinates. Near the points will be displayed the distance from the selected aircraft.
You can specify one or several points, their coordinates and the name must be separated from each other by a space.
Usage - mark out Initial/Final approach waypoints (IAWP/FAWP) or LOM/LMM for approach path observation: --add-points 54.2882:88.0451:LOM 54.4557:89.3456:LMM



--inServerId <Port:Label>
Option allows you to assign a name to the listening input server(s).
Usage: to indicate the aircraft, data for which come from third-party sources, for example, from reverse MLAT channel: --inServerId 30104:MLAT.


I will be grateful for your feedback.

Thanks,
sergsero

[rtlsdr_SCN]

@sergsero Please don't forget the OpenWRT builds!  (if you can of course)

Best regards!.

[ytsejam]

Hello,

The possible use of the new options in ModeSMixer2 v.20151226 when testing it.

--add-reference-point <Lat:Lon:Label>
The option creates on the map an alternative point to '--location', as the reference point for calculating distance and azimuth to the selected aircraft. This new value will be displayed in detail.
This reference point can be the only single with arbitrary name. Usage - mark out the runway threshold.
Usage: --add-reference-point 54.2446:82.7991:RW.



--add-points <Lat:Lon:Label [Lat1:Lon1:Label1 Lat2:Lon2:Label2]>
The option creates on the map one or several points with given coordinates. Near the points will be displayed the distance from the selected aircraft.
You can specify one or several points, their coordinates and the name must be separated from each other by a space.
Usage - mark out Initial/Final approach waypoints (IAWP/FAWP) or LOM/LMM for approach path observation: --add-points 54.2882:88.0451:LOM 54.4557:89.3456:LMM



--inServerId <Port:Label>
Option allows you to assign a name to the listening input server(s).
Usage: to indicate the aircraft, data for which come from third-party sources, for example, from reverse MLAT channel: --inServerId 30104:MLAT.


I will be grateful for your feedback.

Thanks,
sergsero

Hi sergsero,

That's the feature I was looking for a long time. Thanks a ton for the great feature, I've been using it for two days with all the AERO Waypoints and VOR/DME points, works well.



[Attachment deleted by Admin to save file space]

[larsras]

--add-reference-point <Lat:Lon:Label>
The option creates on the map an alternative point to '--location', as the reference point for calculating distance and azimuth to the selected aircraft. This new value will be displayed in detail.
This reference point can be the only single with arbitrary name. Usage - mark out the runway threshold.
Usage: --add-reference-point 54.2446:82.7991:RW.



--add-points <Lat:Lon:Label [Lat1:Lon1:Label1 Lat2:Lon2:Label2]>
The option creates on the map one or several points with given coordinates. Near the points will be displayed the distance from the selected aircraft.
You can specify one or several points, their coordinates and the name must be separated from each other by a space.
Usage - mark out Initial/Final approach waypoints (IAWP/FAWP) or LOM/LMM for approach path observation: --add-points 54.2882:88.0451:LOM 54.4557:89.3456:LMM

Great features :-) But does not work on Safari OSX, which i use. I dusted of an old PC to test my setup, and here my points were displayed in IE.

[larsras]

So tried to clear the browser cache, and then i was hit by the problem with aircrafts located on the upper left corner of the map. After endless retries of refresh and clear cache (started last night but gave up, and retried some times this morning), i finally got the map working again, and my points are also displayed now.
I may say that this is the first time i observe the map problem here, and i'm quite surprised how difficult it is to get it working again.
But great feature now it is working.

What about the possibility to define the CTR/TMA areas? ;-)