ModeSDeco2 and ModeSMixer2 - console programs for RTLSDR and transcoding

[Rockwell]

Hi Tim,

Thanks much for your help.
You explain my problem so much better.

Regards, rockwell

[dfroula]

I am reasonably sure the zoom steps are a function of Google Maps and cannot be changed/controlled by the software using the API.

I notice the same issue with coarse zoom levels on lightningmaps.org, which overlays lightning strike data onto Google Maps.

Best,

Don
WD9DMP

[Rockwell]

Hi Don,

Strange enough google maps has no slider, only +/- button or scroll wheel on mouse.
But google maps used in modesdeco2 has also a slider.

[sergsero]

Hi,

Sorry for the delay!

Tim, thanks for your clarification, now I understand what Rockwell asked.
Unfortunately indeed, as Don said, current version of Google Maps API does not allow to change the size of zoom step. And we do not consider non-API methods: scaling properties of browsers, or gradually CSS-zoom the map canvas and use a cluster algorithm.

There is no way to zoom in using smaller increments. The  number of steps to zoom a map is fixed depending of the area your are looking on.

"The Google Maps API could not possibly load all map imagery at the higher zoom levels that are most useful; instead, the Maps API breaks up imagery at each zoom level into a set of map tiles, which are logically arranged in an order which the application understands.
By dividing the pixel coordinates by the tile size and taking the integer parts of the result, you produce as a by-product the tile coordinate at the current zoom level."

zoom = 1   =>   tiles = 2^1 * 2^1 = 2 * 2 = 4
zoom = 2   =>   tiles = 2^2 * 2^2 = 4 * 4 = 16
zoom = 3   =>   tiles = 2^3 * 2^3 = 8 * 8 = 64
etc.

Increasing the zoom level (in the range from 1 to 17 or 18, in few regions up to 21) by 1 doubles the level of detail. The zoom level is an integer value. It corresponds to the discrete value of the slider control on Google maps.

Suppose you show map at zoomLevel = 6. Now you want to increase a bit the zoom, say to 6.2. The message is: you cannot do that; you have to increase to 7. And if it is too detailed you need to keep the zoom at 6. There are no intermediate levels between 6 and 7.

Regards,
sergsero

[sergsero]

Hi,

I'll be grateful for help in testing this new test version of ModeSMixer2:

Windows: modesmixer2_windows_20150715_test.zip https://drive.google.com/open?id=0B7NYXizl0U6ic3k4TUd5SWJPMDQ
Raspberry Pi 2: modesmixer2_rpi2_20150715.tgz https://drive.google.com/open?id=0B7NYXizl0U6iTW1NelhTdnJuYzA

+ fixed the "top-left corner" bug on Google Maps (requires additional testing on different browsers)
+ fixed main menu on mobile devices
+ additional optimizations to reduce CPU load (requires additional testing)
+ improved work with serial port
+ no longer required wmm.cof file
+ fixed same bugs

Regards,
sergsero

[Attachment deleted by Admin to save file space]

[fat-tony]

@sergsero,

Don (post #421 above) and I have been doing quite a bit of testing with modesmixer2 on the RPi2 in conjunction with Guenter's Beast as input and Planeplotter server and MLAT. All is going well and we have been fine-tuning the shutdown and re-boot of the RPi to ensure modesmixer2 and ppup1090 start sequences are correct etc.
Both of use have noticed that when a kill command is issued to terminate modesmixer2 there seems to be a lot of SD card activity (while it updates basestation.sqb presumably?). You do refer to this in the notes, but I would have expected only a couple of seconds, perhaps. It seems to take upwards of a minute or more. I have reduced the flight-expire-time parameter to 600 seconds from the default on my setup. I haven't rebooted since but will do some tests later today. I think Don has just turned off basestation.sqb processing and that has resolved the issue for him. Do you have any indication as to how long database commits should take when shutting down modesmixer2 on the RPi?

Joe

[sergsero]

Hi Joe,

Both of use have noticed that when a kill command is issued to terminate modesmixer2 there seems to be a lot of SD card activity (while it updates basestation.sqb presumably?). You do refer to this in the notes, but I would have expected only a couple of seconds, perhaps.

Indeed, when sending a signal (by "Ctrl+C" or "kill") to stop the program will be intensive activities with memory card.

The algorithm works with a database like this. When the aircraft comes in range of your station and was received at least one message from him (any, including without coordinates), a new entry is created in a database file.
You can check it, if make a copy of the basestation.sqb file when modesmixer2 runs. In table "Flights" you find incomplete records for all current aircrafts in the air.

After that, all subsequent incoming data from the aircraft will be stored in program memory. Until you are receiving messages from him.

When the aircraft leaves the coverage area of your radar and the flow of data was interrupted, the program is expecting them for some time. By default, it is 3600 sec (1 hour), and can be changed by option "flight-expire-time".

After this time interval modesmixer2 makes decision that the aircraft finally left the coverage area, writes all his data from memory to the database file and removes the session of this aircraft from memory.

It seems to take upwards of a minute or more. I have reduced the flight-expire-time parameter to 600 seconds from the default on my setup. ...Do you have any indication as to how long database commits should take when shutting down modesmixer2 on the RPi?

In my testing I usually use "Transcend Class 10 microSDHC Flash Memory Card", a speed of 10MB/s. The delay time for database closing does not exceed ~2 seconds (for 100-120 aircrafts). However, with less high-speed SD cards the delay time to keep data safe in the database file should not exceed 10 sec. You can check this time for your device, if run the program in console by hand and then to stop it by Ctrl+C.

Also I think needs considering in the script, that in console "Ctrl+C" - the interrupt signal, sends SIGINT to the job running in the foreground. And when the program is running, in memory there are several related processes and the SIGINT signal needs to be sent to the parent.


Regards,
sergsero



[Attachment deleted by Admin to save file space]

[larsras]

FLARM decoding, is this possible?

[larsras]

Hmm.. Just discovered that FLARM is on another frequency :-) Hoped it could be decoded together with all the other good stuff that comes out of Deco2/Mixer2 :-)

[dfroula]

Also I think needs considering in the script, that in console "Ctrl+C" - the interrupt signal, sends SIGINT to the job running in the foreground. And when the program is running, in memory there are several related processes and the SIGINT signal needs to be sent to the parent.

Thanks for that explanation! Very helpful.

I have a push button wired to three of the GPIO pins in the Pi v2, along with a daemon to monitor the button state. A short press of the button initiates an interrupt and "/sbin/poweroff" command. A press >= 2 seconds initiates a reboot with a "/sbin/shutdown -r now" command. I believe that both commands cause the "stop" portion of my /etc/init.d/beast.sh script to run as part of the shutdown/reboot process.

The beast.sh script issues a "killall modesmixer2" command, which I believe will send a SIGTERM (rather than a SIGINT) to the modesmixer2 parent process. It appears that the SIGTERM initiates the database writes, just as a CTR-C/SIGINT signal would do. Can you verify that both signals are detected by the code and act the same?

I checked, and I am using a Class 4 HC microSD card, which likely accounts for the 70+ second write time with 140 or so Mode-S aircraft tracked at 130 Mode-S messages/sec..

Best regards,

Don
WD9DMP

[dfroula]

I'll be grateful for help in testing this new test version of ModeSMixer2

Thanks for adding the RPi2 version. I just noticed it!

The menu issue while in map view seems fixed for both Safari and Chrome on my Iphone 6 with latest OS updates. However, the plane icons are still collapsed in the upper-left corner on all of the map views, despite clearing the browser data on both apps.

EDIT: After killing the Chrome and Safari apps completely on my Iphone 6, the maps display perfectly on both browsers. Thanks!

My Nexus 7 tablet running latest Android OS works fine with the new version, as does Chrome on my desktop computer.

Regards,

Don
WD9DMP

[fat-tony]

@sergsero - thanks for the reply. Like Don, I am using a class 4 SD card for the moment. I did try to do an image copy to a new class 10 card in the past week, but the RPi2 would not boot with it! It's the same size (8GB) but a different manufacturer - Sandisk vs Kingston. I may just try to build a new image from scratch and see how I get on. I've reduced to flight expire time to 600 seconds, so there does not seem to be such a large backlog of data to be written in any case, so that is working ok for me at the moment. Off to a local airshow just now, so will test your new version of modesmixer2 later!

Joe

[jensnds]

Hi,
i 've tried the  modesmixer2_rpi2_20150715 on Raspi2 and again we habe the "Google Maps Problem". Testet with many other Users. We've only the Problem in Firefox.

Maybe problem in the Google API?

@sergsero

What you think about the idea to use OpenStreet Map?

Greets Jens
EDVE

[sergsero]

Hi,

I think that your time interval from "Ctrl+C" to moment of close program is longer for some reasons.

I recorded a 30 sec video (avi) from my desktop: modesmixer2_delay-db-time.zip https://dl.dropboxusercontent.com/u/79709204/Pictures/20150718/modesmixer2_delay-db-time.zip
Program stop by "Ctrl+C" at 08:06:20.246 and start procedure of closing database session. It ended in 08:06:21.240, or DB phase duration of ~1 sec.
To the basestation.sqb file were recorded data from ~100 aircraft. Perhaps that message rate is not important here, since to the database is written only initial and final values of every flight.

Regards,
sergsero

[dfroula]

I noticed that the "Stats" web page of modesmixer2 does not seem to report DF18 messages. I was wondering if it would be possible to  add this, as well as decoding and displaying position reports encoded in DF18 messages?

DF18 messages are not widely used outside of the US. Within the US, they are often used for the TIS-B service on 1090MHz. This service is broadcast from some ground stations to send traffic positions to a specific capable aircraft when it is interrogated. Coverage is limited to a defined area around the aircraft and persists only as long as the aircraft is within range of the ground station. The TIS-B data sent includes positions from non-Mode-S aircraft received by conventional ground radar. It also may include ground vehicle traffic and repeated data from UAT-equipped aircraft operating on 978MHz.

I can occasionally receive DF18 messages from nearby ground stations when a capable aircraft flies within range and activates the TIS-B broadcast. The Mode-S Beast can decode them, but I believe Mode-S mixer just ignores them on its web interface, although they do get decoded and displayed by PlanePlotter receiving its data from modesmixer2.

Regards,

Don
WD9DMP