ModeSDeco2 and ModeSMixer2 - console programs for RTLSDR and transcoding

[Anmer]

Is everything OK now?

[Radio2.0]

Does the ADSB,Mode-S not contain the registration code? 

[Anmer]

Does the ADSB,Mode-S not contain the registration code? 

No.  See:

https://mode-s.org/decode/adsb/introduction.html

[radioman1511]

who can me help,why modesmixer2 not search all airplane pictures from internet? grts radioman1511

[garry72]

Hello Sergey, can you build the latest mixer for CuBox-i4Pro (Freescale i.MX6Q SoC, 4x ARM® Cortex ™ -A9), ARMBIAN BOOSTER?

[StudioMaX]

@sergsero
Could you please clarify if there is any big difference between ModeSMixer2 for the same architecture and operating system version, but for different types of devices.
What I mean - The download page now has the following versions for these ARM platforms (I may be wrong about the architecture of these devices, since I haven't actually used them and I don't know the details):

• ARM 32 bit; Debian 10 - Raspberry Pi 4 Debian 10 Buster (Broadcom SoC BCM2711 ARMv8 Quad Core): modesmixer2_rpi4_deb10_20190413.tgz (Raspbian GNU/Linux 10.0 (buster))
• ARM 32 bit; Debian 9 - Raspberry Pi 2 / 3 / 3+ Debian 9 Stretch (Broadcom SoC BCM2836/37/73 ARMv7 Quad Core): modesmixer2_rpi2-3_deb9_20190413.tgz (Raspbian GNU/Linux 9.4 (stretch))
• ARM 32 bit; Debian 9 - Raspberry Pi B+ Debian 9 Stretch (Broadcom SoC BCM2835, ARM1176JZFS): modesmixer2_rpi1_deb9_20190413.tgz (Raspbian GNU/Linux 9.4 (stretch))
• ARM 32 bit; Debian 8 - Raspberry Pi 2 / 3 / 3+ Debian 8 Jessie (Broadcom SoC BCM2836/37/73 ARMv7 Quad Core): modesmixer2_rpi2-3_deb8_20190413.tgz (Raspbian 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux (jessie))
• ARM 32 bit; Debian 8 - Raspberry Pi B+ Debian 8 Jessie (Broadcom SoC BCM2835, ARM1176JZFS): modesmixer2_rpi1_deb8_20190413.tgz (Raspbian 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux (jessie))
• ARM 32 bit; Debian 8 - BeagleBone (RadarCape) (AM3358 ARM 32‑Bit RISC Processor Cortex-A8) modesmixer2_bbone_deb8_20190413.tgz (Linux radarcape 4.1.30-ti-r69 #1 SMP Sun Aug 14 11:23:09 UTC 2016 armv7l GNU/Linux)
• ARM 64 bit; Debian 9 - Orange Pi PC 2 (AllWinner H5 SoC Quad-core 64-bit Cortex-A53): modesmixer2_orange-pi-pc2_aarch64_deb9_20190413.tgz (Debian 9.11 (stretch))

There are also builds that are not on the official download page but have been mentioned in this thread, for example (You might want to publish it on the downloads page as the Raspberry Pi OS 64-bit grows in popularity):

• ARM 64 bit; Debian 10 - Raspberry Pi 4: modesmixer2_64bit_rpi4_Raspberry_Pi_OS_20200426.tgz (Debian 10) (From this post)

My goal is to run ModeSMixer2 on Raspberry Pi 4 with Raspberry Pi OS 64-bit in a Docker container. The most popular container is mikenye/modesmixer2. But according to its source code, it tries to find a suitable archive for each architecture from the downloads page, but for Raspberry Pi 4 with Raspberry Pi OS 64-bit it will use a completely unsuitable version from Orange Pi PC 2, since only that is ARM 64-bit.

From this the question follows, is it possible to get rid of a builds for specific device/SoC and make universal binaries for the same architecture/OS?

[garry72]

https://github.com/abcd567a/mm2/blob/master/README.md

[abcd567]

https://github.com/abcd567a/mm2/blob/master/README.md

Thanks garry72 for posting link to my Github page.

My above Github page provides bash scripts for indtallation of ModeSMixer2 on many differrnt OS, and one of these is for 64-bit Raspberry Pi OS, as required by StudioMax.

However in that Github page I have not given the dowmload link to Raspberry Pi OS 64-bit for Pi4, assuming reader has already downloaded and installed the OS image.

However if StdioMax or anyone else wants to download the latest 64-bit image for RPi4, here are te the links:

Direct Download (current latest image)
2020-08-20-raspios-buster-arm64.zip

Check for latest version here
https://downloads.raspberrypi.org/raspios_arm64/images/

.

[ramonk]

Hi -- I have been a long-term peruser of this forum, even though I haven't really posted anything.

I have been running MM2 for a few years now on my RPi3B+ (and more recently also on RPI4B, and there are 2 issues with the installation that I have been trying to clean up. I actually think that @abcd567's (further excellent) install scripts don't address this, so maybe this could be a potential improvement.

It started with me noticing a file in my root called /distances.json, owned by root:root. After some sleuthing, I found out that this is a file updated hourly by MM2. Writing to my root directory, and actually having "untrusted" non-open-source programs run as root, are both security no-no's for me.

Here's what I did to improve this:

1. Updates to /usr/share/mm2/mm2.sh

These updates make sure that mm2 is executed from /run/modesmixer2, so any files it writes to its home directory are dropped there. The red code is what you should insert:

#!/bin/sh
CONFIG=""
while read -r line; do CONFIG="${CONFIG} $line"; done < /usr/share/mm2/mm2.conf
if [ ! -d "/run/modesmixer2" ]
then
   mkdir /run/modesmixer2
fi
cd /run/modesmixer2

/usr/share/mm2/modesmixer2 ${CONFIG}


2. Create a user and group for mm2 to run in
This actually has 2 parts. During the installation (in @abcd567's installation script), we should also do the following:


# create a user 'mm2:mm2' for mm2 to run as:
sudo useradd -U -r -s /bin/false mm2


Then, also add this to the [Services] section of the systemd service file (/lib/systemd/system/mm2.service). Again, the actual additions are in red:


[Services]
User=mm2
Group=mm2


That's all that needs changed when you do your initial installation

Now, if you want to make this change to your existing setup (after you already installed MM2), you can do this:

a. Edit the files manually
Make the changes shown above using sudo nano /usr/share/mm2/mm2.sh and /lib/systemd/system/mm2.service. Exit the editor with ctrl-x y <enter>.

b. Type this on the command line:

sudo useradd -U -r -s /bin/false mm2
sudo chown -R mm2:mm2 /run/modesmixer2
sudo systemctl daemon-reload
sudo systemctl restart mm2

Now, your MM2 instance should have restarted and is running as user mm2 and writes to /run/modesmixer2/distance.json rather than to the root directory. This is a lot cleaner and more in line with linux security recommendations.

Last -- a quick note -- relevant ONLY if you are running the mm2 website on a reserved port, like --web 8787.
By default, "regular" users aren't allowed to bind to some of the lower TCP port numbers. So if you changed your mm2.conf file to bind the web page to (for example) port 80 rather than the default port 8787, you will see an error. You can fix this by creating an exception for mm2 by giving this command on the command line:

sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/share/mm2/modesmixer2.

[Oldfella]

Hello there, I need some assistance has to how to refresh the outline of the maximum range shown on the map with ModeSMixer2. I'm using abcd567 automated install program on a Pi4 and from memory this outline was stored in "distance.json". However, can't remember where this file is now located. Any help or ideas would be gratefully appreciated.

Many thanks.

Noel

[abcd567]

@Oldfella:
For mm2 installed before today using my script, the file distances.json is located in root partion. You can see its contents by following command:

sudo nano /distances.json

If you want to clear the max range plot, first stop the mm2 so that it dumps its data to this file and clears its inner cache. Then only delete the file. After deleting restart mm2, and it will create a new blank file /distances.json



For installations done from now on, distances.json will be inside the folder /usr/share/mm2/

[abcd567]

@ramonk
Thank you for pointing out shortcomings in my mm2 install script.

I have now modified the script to create a user mm2 and added this user to service file.

However creating file distances.json in volatile memory /run/modesmixer2 is not good as on restart / reboot, this folder gets deleted and then fresh blank folder is created . This will clear the range curve built previously, and is not desirable.

I have therefor modified startup file so that this file is created by user mm2 in folder /usr/share/mm2/ which is non-volatile. As a result the max range persists between restarts/reboots. If user intentionally want to clear the max range curve, he can stop mm2, delete file distances.json manually, and then restart mm2

[Oldfella]

Thank you, thank you, thank you abcd567 for your great service and keeping us old fellas happy  and to you ramonk for your input.

All working as per your instructions.

I should have looked again at the earlier posts to see the info on distances.json, not distance.json that I searched for.

Thanks again.

[abcd567]

@Oldfella
If you have followed instruction of @ramonk, they are good from security point of view, and conform to Linux safe practices. However they have one drawback: the maximum range curve will be non-persistant. It will reset itself on restart / reboot. Just try it.

[abcd567]

@ramonk
Thanks again for your suggestions. I modified my mm2 install scripts at Github yesterday, accomodating most of your suggestions, but made some changes to make max range data persist during reboots.

The changes are shown in red color:

(1) Installation script issues following extra commands:
sudo useradd --system mm2 
sudo chown mm2:mm2 -R /usr/share/mm2 


(2) Changes in service file
/lib/systemd/system/mm2.service

[Service]
User=mm2
RuntimeDirectory=modesmixer2


(3) Changes in file
/usr/share/mm2/mm2.sh

#!/bin/sh
CONFIG=""
while read -r line; do CONFIG="${CONFIG} $line"; done < /usr/share/mm2/mm2.conf
cd /usr/share/mm2
/usr/share/mm2/modesmixer2 ${CONFIG}