ModeSDeco2 and ModeSMixer2 - console programs for RTLSDR and transcoding

[IanH]

You could also quote the rest of my reply

I don't care what the source is - I just want to see the whole picture
Having used modesmixer2 since 2014, the initial version did what I wanted and so I didn't pay much attention to what has been added since

I DON'T CARE - it does what I need

And that is my final response on this topic.

Bye

[sergsero]

Hello,

Maybe I'm not quite sure I understand the issue.
However, input data format is detected automatically in any income channel and in any mix of formats. If aircraft's label was created based on DF=18/CF=2 data, it will be displayed separate green label. If you use *Id option for receiving piaware back channel you can specify the name of the source at your option.

Version modesmixer2_rpi2-3_20161216.tgz for RPi2/3 was added. I would be very interesting to know how much the CPU utilization on ARM devices in areas, where high intensity of ADS-B/Mode S air traffic and additionally exists MLAT data - I'll grateful for the feedback message.
p.s. But I still want to work with code for better optimize for ARM processor.

/sergsero

[Giurap]

You could also quote the rest of my reply

I don't care what the source is - I just want to see the whole picture
Having used modesmixer2 since 2014, the initial version did what I wanted and so I didn't pay much attention to what has been added since

I DON'T CARE - it does what I need

And that is my final response on this topic.

Bye

You may don't care, but if it wasn't for those chaps reporting this issue, proving that mlat wasn't working whit the pi3 data, you wouldn't have the fixed version today, and you wouldn't have figured that it wasn't working correctly. This thread help sergero to debug the app, if every of us wouldn't care, the app couldn't progress.
Bye.

[Giurap]

Hello,

Maybe I'm not quite sure I understand the issue.
However, input data format is detected automatically in any income channel and in any mix of formats. If aircraft's label was created based on DF=18/CF=2 data, it will be displayed separate green label. If you use *Id option for receiving piaware back channel you can specify the name of the source at your option.

Version modesmixer2_rpi2-3_20161216.tgz for RPi2/3 was added. I would be very interesting to know how much the CPU utilization on ARM devices in areas, where high intensity of ADS-B/Mode S air traffic and additionally exists MLAT data - I'll grateful for the feedback message.
p.s. But I still want to work with code for better optimize for ARM processor.

/sergsero

Not much traffic atm (9 aircraft):

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                         
  444 dump1090  15  -5   28284  10076   2052 S  12.3  1.1 183:23.18 dump1090-mutabi                                                                                                     
  920 root      20   0   37524   9052   6520 S   3.3  1.0  30:01.32 modesmixer2

Same traffico with new version:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                         
  444 dump1090  15  -5   27784   9256   1840 S  14.8  1.0   0:07.72 dump1090-mutabi                                                 
  921 root      20   0   37128   8164   5708 S   2.6  0.9   0:01.14 modesmixer2     

[sergsero]

Maybe I will be better to write this in Russian

The reason that the modesmixer2 has stopped working with back channel data in PA3, that in PA2 used the standard BEAST binary format. And the data are encoded in ADS-B DF=17 (or TIS-B DF=18 with CF=0,1 or 6 which processing is identical to DF=17). In PA3 was used a different kind of TIS-B: DF=18 with CF=2, which in reality now yet are not widely used in the world. In addition to this uses with modified format of BEAST.

Similar changes were made by PA3 authors in the ASCII MSG format, when in a new single message "MLAT,3" were merged data which accordance with the SBS Kinetic standard should to be in two messages: "MSG,3" and "MSG,4".

But anyway, I agree with the opinion that it contributes to the development of the program.

[Giurap]

I confirm mlat is working now, but it does something odd with the labeling.
I have the two ports identified as "RECEIVER" and "MLAT" on the map, when the mlat data is received on its port, the airplane on the map is labeled "MLAT", but just for 1 second, then it switches to "RECEIVER".
I think it's due to the fact that the airplane is both received on the RECEIVER port (MODE-S) and on the MLAT port (data streamed back from FlightAware), so MM2 gets a little "confused" on how to label it.
It would be possible to add a new label specifically for the mlat? So you don't have to identify the data by just the port. Thanks.

EDIT: never mind, I figured that the MLAT airplanes are painted "green".

On RB Pi3 with 12 ariplanes and two MLAT:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
442 dump1090  15  -5   28040   9720   2064 R  14.9  1.0   3:58.28 dump1090-mutabi
921 root      20   0   37260   7848   5708 S   4.0  0.8   0:46.89 modesmixer2   

[spotter.ssol]

Many thanks, sergsero! Will test RPI version ASAP!

Edit: Working 100%! Thanks again for your attention and time!
Edit 2: The map you've posted is very familiar! 

ModeSMixer2 version 20161216 for testing



Added capability to decode of TIS-B messages with DF=18 CF=2, which are used in piaware v.3+ reverse data channel


Windows: modesmixer2_windows_20161216.zip https://drive.google.com/open?id=0B7NYXizl0U6iNnB6MXg5MHB4Ukk

Raspberry Pi 3: modesmixer2_rpi2-3_20161216.tgz https://drive.google.com/open?id=0B7NYXizl0U6iYklBNFplWmRVckE


I would like to express my gratitude to spotter.ssol for help with the his data source.

[Radio2.0]

so I ask again its possible to run 2x Software on an Pi2?

[Giurap]

so I ask again its possible to run 2x Software on an Pi2?

Two instances of dump1090 ? Yes, there shouldn't be any issue.
What you want to do exactly? Place two dongles with two antennas in different spots?

[ktso44615]

ModeSDeco2 version 20161214

+ fixed option "--airspy-rfbias" for powering a preamplifier directly from Airspy by injecting DC

Hello Sergsero,

Thank you.   I can confirm that the --airspy-rfbias option now works.

However, the --airspy-packing option does not work now.   The --airspy-packing option does not exist / is missing from the help screen, and if I try to add --airspy-packing on or --airspy-packing 1 it will not start.   This is Windows version 20161214.

Mike

[ktso44615]

An apology wouldn't go amiss.

Read the posts (fully) and be serious. Also, I invite you to not derail this thread with a flame (that is against the forum rules, since you talked about them), here's we're talking about technical matters, I'm not here for kids fight or trolling. Thank you.

This forum has operated peacefully for 5 years and I'd like it to continue this way.  So I've taken the unusual step of putting Arctic "on ice" for 7 days. 

You know, this all stems from so many of us having different primary [first] languages.    The meaning can be misinterpreted.

Code Select Expand

As you see, the evidences aren't needed because we don't trust you, but because we need exact data (not guessed) to understand exactly what's going on or we'll never set the point.

When I read this response, I understood it immediately.   He was really saying "We trust you.   We aren't asking for evidence because we do not trust you, but rather because we need exact technical data to understand exactly what is going on so that we are able to let Sergsero know exactly what the issue is."

The issue Arctic and I were attempting to bring up, and which Sergsero undertood, was this:

Modesmixer2 was properly passing FA MLAT data in/out, but there was absolutely nothing showing up on our Modesmixer2 web interfaces when that FA MLAT traffic was passing through ModesMixer2.    And I believe I had noticed the same thing with ADSBExchange MLAT data.    If I tried to feed FA / ADSBEX MLAT data into Modesmixer2, it was converting / passing the data in and out just fine.  But if I pulled up the web interface,it would show 0 planes.   Sergsero has made some modifications in the past day or so that have fixed that issue.

I completely understand how some people took Arctic's words the wrong way, but I'm confident that he in no way meant to insult anyone -- The translation of the comment between languages / dialects was the only issue.

Mike

[ktso44615]

ModeSMixer2 version 20161216 for testing
Windows: modesmixer2_windows_20161216.zip https://drive.google.com/open?id=0B7NYXizl0U6iNnB6MXg5MHB4Ukk

Sergsero,

Thank you so much for making the necessary modifications.   The ModesMixer2 web interface is now (a) showing FA and ADSBEX MLAT and (b) showing it in a way that was very well thought out.   I think the way you have made the web interface display the MLAT data is beautiful.    Great job!      Thanks for your efforts, and those of others who helped gather data for you.

Mike

[Radio2.0]

What you want to do exactly? Place two dongles with two antennas in different spots?

Yes 1 Areal + 1 Yagi
And you got an PM. 

[Giurap]

What you want to do exactly? Place two dongles with two antennas in different spots?

Yes 1 Areal + 1 Yagi

I see, do you want to have more range towards a certain direction? I'm asking because installing two dongles in the same place on the same frequency (1090) is convenient on a very limited number of situations. What's the reason behind your decision? Maybe a different setup (or a different single antenna mounting) could be better than investing in an additional dongle.

And you got an PM. 

I got it.

[ktso44615]

Here is what ModesMixer2 20161216 looks like now with MLAT.

I have four inputs, with IDs attached (using --inConnectID)

RPI-DATA:  RPI3+Dump1090 providing BEAST data on TCP 30005
WIN-DATA:  WIN+ModesDeco2 providing BEAST data on TCP 30005
ADSBEXMLAT:  MLAT results in BEAST format from ADSBExchange
FAMLAT:   MLAT results in BEAST format from FA

WHITE planes = ADSB Fixes
GREEN planes = Mode S + MLAT

What I really like is that while the MLAT planes always stay green, the source ID on them changes depending upon whether the last update heard was a Mode-S update or an MLAT update.   So it is possible for a green MLAT plane to show one source ID one minute and another source ID the next.

Very very cool.

Mike


[Attachment deleted by Admin to save file space]