mutability / dump1090 Goto Github PK

Should be impossible; maybe there's an edge case in beast format I/O?

Is it planned version for Windows?

Upgrading from 1.13 package to to 1.14:

pi@raspberrypi ~ $ sudo apt-get install dump1090-mutability
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  dump1090-mutability
1 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Need to get 213 kB of archives.
After this operation, 10.2 kB of additional disk space will be used.
Get:1 http://repo.mutability.co.uk/raspbian/ wheezy/rpi dump1090-mutability armhf 1.14 [213 kB]
Fetched 213 kB in 0s (408 kB/s)         
Preconfiguring packages ...
(Reading database ... 74717 files and directories currently installed.)
Preparing to replace dump1090-mutability 1.13 (using .../dump1090-mutability_1.14_armhf.deb) ...
Unpacking replacement dump1090-mutability ...
Setting up dump1090-mutability (1.14) ...

Configuration file `/usr/share/dump1090-mutability/html/script.js'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** script.js (Y/I/N/O/D/Z) [default=N] ? y
Installing new version of config file /usr/share/dump1090-mutability/html/script.js ...

Configuration file `/usr/share/dump1090-mutability/html/planeObject.js'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** planeObject.js (Y/I/N/O/D/Z) [default=N] ? y
Installing new version of config file /usr/share/dump1090-mutability/html/planeObject.js ...
Installing new version of config file /etc/init.d/dump1090-mutability ...
adduser: The user `root' already exists. Exiting.
dpkg: error processing dump1090-mutability (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 dump1090-mutability
E: Sub-process /usr/bin/dpkg returned an error code (1)
pi@raspberrypi ~ $ 

I might be missing something, but how do I enable the builtin HTTP server from the command line?

Also I'm considering running this on a non-Debian system (OpenWrt), are there any potential incompatibilities compared to MalcolmRobb/dump1090?

Thanks!

It would be nice to see type of aircraft (B737 vs C206H...) either on the table or on selection, just like on FlightAware. May be there is a DB mapping for ICAO Aircraft Registry which could be leveraged here. May be there is another fork with this capabilities which someone can direct me to !.

Thanks to Malcolm, Oliver and everyone here for doing a fantastic job on home-brew ADSB trackers. I have piped the signals from this with dump978 on another dongle with great results. Also I have another pi with Oversample Turned off so ModeAC works which feeds the Primary/Production Pi.

Proudly feeding FlightAware, PlanePlotter, FlightRadar24, LiveATC.......... and Stratux if you are interested in coupling with your iPad/ForeFlight app (https://github.com/cyoung/stratux) all with dump1090-mut/dump978.
Tailwinds !

The rx thread can block waiting for the USB device to reconnect, we want to keep running the main loop while that happens, make the condition wait a timed wait

Catch SIGTERM as well as SIGINT for graceful shutdown.
Also log about both so it's obvious when dump1090 is killed by external intervention.

Files such as markers.js contain content released under a license that is not covered by the debian/copyright file.

Hi,

Thanks for this great fork. I've been playing with a manually compiled version and decided to try the package today.

Installing latest with:

root@beaglebone:~# apt-get install dump1090-mutability
[...]
Setting up dump1090-mutability (1.14) ...
adduser: The user `debian' already exists. Exiting.
dpkg: error processing dump1090-mutability (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
dump1090-mutability
E: Sub-process /usr/bin/dpkg returned an error code (1)

Obviously, I already have a user 'debian' on the system.
Manual configuration fails with:

root@beaglebone:~# dpkg-reconfigure dump1090-mutability
/usr/sbin/dpkg-reconfigure: dump1090-mutability is broken or not fully installed

Is there a way around this?

Thanks,

Martijn

If we see ES position messages, then rely on them for AOG status, ignore other message types for AOG.

Should be able to collect signal power stats in 2MHz, too, even if that code is all a bit horrible.

The message queueing code gets confused by Mode A/C messages because the mode A/C code can reset the message count to 1 in circumstances that I don't fully understand the significance of, which results in an extra duplicate of the original (identical!) mode a/c message being sent. This is mostly harmless, except for mlat which is unhappy about seeing messages with very out-of-order timestamps.

There's no point in queueing mode a/c anyway, so we should just bypass the queue for those messages always.

Just in case:

Creating cronjob in /etc/cron.d/dump1090-mutability to periodically update the aircraft database..
Updating aircraft database now..
Sun 30 Aug 2015 11:12:52 PM CEST Checking VRS server for an updated database..
/usr/share/dump1090-mutability/update-aircraft-database.sh: line 49: curl: command not found
Aircraft database update failed. It will be retried periodically from cron.

when installing the package, thus a depends on curl would be a good one to have.

The is_number regex used to check the lat/lon fields rejects negative values between -1 and 0, e.g. -0.1 or -0.99. The problem occurs with any number beginning "-0".

Derive it from the ME type.
Store the effective NUCp in aircraft state (min of even/odd for global CPR, min of ref + new for local CPR)
Maybe export it via JSON.

Will come in handy for reasonableness checks - if we get an "unreasonable" positions, comparing NUCp will tell us whether to discard the old position or the new position.

http://discussions.flightaware.com/post156117.html#p156117

Shouldn't emit non-ICAO addresses in SBS format output.

It would be nice to see the ICAO country flag/icon in the table and selected view to attract more attention to rare flights.
I've implemented this on my own already but it'd be nice to see it incorporated in a future release.

Count messages for short periods with different gain settings and accumulate the results, display the results in a table, suggest the best gain value to set.

steve-m/librtlsdr@d892279

Allow setting bandwidth for R820T

This improves SDR performence for nearby channel interference.
As a sideeffect also improves dynamic range becase ADC is not overloaded
by unwanted singles.

Add Plane Finder link https://planefinder.net in Dump

The following changes have been made in the files and gmap.html and script.js

script.js

if (selected.flight !== null && selected.flight !== "") {
  $('#selected_callsign').text(selected.flight);
  $('#selected_links').css('display','inline');
  $('#selected_fr24_link').attr('href','http://fr24.com/'+selected.flight);
  $('#selected_flightstats_link').attr('href','http://www.flightstats.com/go/FlightStatus/flightStatusByFlight.do?flightNumber='+selected.flight);
  $('#selected_flightaware_link').attr('href','http://flightaware.com/live/flight/'+selected.flight);
  $('#selected_planefinder_link').attr('href','https://planefinder.net/flight/'+selected.flight);

gmap.html

<span id="selected_links">
   <a id="selected_fr24_link" href="" target="_blank">[FR24]</a>
   <a id="selected_flightaware_link" href="" target="_blank">[FlightAware]</a>
   <a id="selected_planefinder_link" href="" target="_blank">[PlainFinder]</a>
   <a id="selected_flightstats_link" href="" target="_blank">[FlightStats]</a>

It would be wonderful to support this! :-)

Don't trust AOG flag from non-ES messages if our last altitude put us >X ft (X=10k?)

Could you include rtl_test in your librtlsdr deployment ? its mentioned in your install documentation.

If you do a clean install it would help to have this available so you can do ppm offset calculations without having to install and compile it yourself.

http://discussions.flightaware.com/post155862.html#p155862

As a feature request, would it be possible to optionally display either or both of [numbers of aircraft messages per second] in the browser tab label similar to the way VRS displays aircraft count?

Once #2 exports the information to the map code, we could use different icons for e.g. light vs heavy vs rotocraft

Looking at the table, when a plane looses mlat but is still seen the row reverts to white but retains its position in the table. I'd suggest assigning the row to a lighter shade of the mlat color (in my case it's yellow because the violet looks grey on my laptop). Or drop it down to where the other planes with no location information are listed.

Just a suggestion,
Dino

Avoid getting stuck with the loading screen up if config.js is borked.

A non-icao address (with ~ at the start) ends up trying to request ~.json which always fails.
We should catch this earlier.

With ICAO addresses that differ by only one bit, it's quite common for messages protected by AP to get misattributed to the wrong aircraft if there's a single-bit error in the AP field (assuming both aircraft are in receiver range at the same time).

This might be a cause of the jumping-altitude problems sometimes seen.

It would be good to try to work out a solution for this. #33 may help here, as we could ignore most/all AP-protected messages after we know we will be receiving ES.

Currently, icons for planes where position is derived from feedback by mlat-client and/or fa-mlat-client point north (0 degrees). Perhaps it is possible to derive track info from previous positions and point the icon accordingly.
Example:

Can we add a feature request for an option for non-mlat beast output on a separate port? That way we have both mlat and non-mlat feed capability from one decoder.

It uses the scaled signal/noise values which are fine for calculating SNR but no good for an absolute power level.

Should be able to do simple loop detection by periodically synthesizing and sending a ModeS message with a unique payload to all net clients; if we ever receive that same message from a net client, there's a loop, and we should discard input from that client for a while.

A DF17 ES with all-zero ICAO and the ME type that's reserved for bench tests (+ unique bits as payload) should do the trick and not run the risk of being interpreted as a valid off-the-air message.

Hi All

Seems that the software hangs on my RPi and can only be restarted once I conduct a ctrl-c. The web interface dies as well as any decoding. No errors appear and I don't get any CB messages.

If the application is ended when running ok, I get the stats output...not if it's truly hung.

The hang can occur between 5m and 1h after initial startup.

I wonder if this could be in anyway attributed to an overheating of the rtl-sdr? It's on a mast on the end of a ten meter USB hub (separate usb hub psu and running a 2A PSU on the RPi). If it was power I would usually see the CB 1 message I believe.

The dongle is on the mast in a container but is foil wrapped...do wonder if I am experiencing an overheat...if so, I would how I can tell?

Any advice or thoughts greatly appreciated.

Nigel

We should forward "would be valid if I had seen this ICAO before" messages in --net-verbatim mode, but not in regular mode.

We should never forward "invalid format" messages

BAW2741 was reporting TAS with no heading information:

*8d406b599b0000b43870003de83c;
CRC: 000000
RSSI: -24.1 dBFS
Time: 182316300585.75us (phase: 180)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+, airborne)
  ICAO Address   : 406b59
  Extended Squitter  Type: 19
  Extended Squitter  Sub : 3
  Extended Squitter  Name: Airborne Velocity
    Heading status    : Unavailable
    Heading           : 0
    Airspeed status   : Valid
    Airspeed          : 416
    Vertical status   : Valid
    Vertical rate src : 1
    Vertical rate     : -1728

But VRS seems to be getting a heading from somewhere - presumably from successive position updates.

That's not a silly thing to do.. just need to make sure that any directly-reported heading overrides it (for a while)

Merge my local changes back to the package and make the niceness level configurable, -5 is probably a good default.

Should test the IMF flag in DF=18 (depending on CF) to decide whether the address is ICAO or non-ICAO.

In prep for the eventual (probably?) migration to Systemd can we have the daemon create it's own pid file and instead of reading the config out as arguments from the sysv initscript, allow the daemon to directly read a config file with built in defaults? I've got dump1090 running on Arch and have most of the tarball and PKGBUILD written with the files going to their Arch counterparts, but writing the systemd service unit file is a bit unwieldy.

ES identification should take priority over BDS2,0 - track it with a new flag.

http://discussions.flightaware.com/post155900.html#p155900

Lots of TIS-B retransmissions with CF=5 anonymous addresses, it would be useful to show them differently on the map.

dump1090 does not listen on AF_INET6 for any communications.

As a workaround I end up installing apache to handle IPv6 client requests to view my local site.

It's useful to know exactly when dump1090 is trying to do stuff over USB disconnect/reconnect so we can see the timeline when it goes wrong.

If sample blocks are dropped, the 12MHz clock is corrected by (dropped samples * 6).
This is only correct for the 2MHz demodulator; for the 2.4MHz demodulator it should be (dropped samples * 5).

Extra_Args are already defined as EXTRA_ARGS="--dcfilter --measure-noise". When running dpkg-reconfigure, debconf fails after 'dump1090 can log all messages' question with error

"Invalid option "--dcfilter --measure-noise"
debconf: dialog output the above errors, giving up!

Right now it's 10s, which is OK for airborne but wrong for surface. We should look at surface speed etc and choose 25/50s appropriately.

The Beast output path unconditionally byteswaps the timestamp.
This is only correct for little-endian hosts.

Seems like there's a fair amount of modification going on here, might be worth marking them all as conffiles.

I don't want to have to support modified versions though, so maybe work out a way of hashing them so a modified version is noted.

Much like we do on local CPR.

Needs NUCp from #16 to avoid getting stuck with a bad position.