Mode S - can one loose it?

Hi All,

I’m seeing a significant proportion of Mode S reports. They appear to always be incomplete, and I don’t think they show up on the map, but I may have missed that when it happened.

I found out how to loose the MLAT stuff, but I can’t see how one can loose the Mode S.

Is there a way or am I just stuck with it?

I’d prefer to concentrate on good, solid and complete data, and not spend cpu cycles on any other sort.

I seem not to be allowed a signature
Cheers,
Ian

Seeing where?

Skyview.

If I was logging then I’d guess they might turn up there too.

Why do you ask?

I asked because it wasn’t clear where you were seeing Mode S data.

Skyview doesn’t currently have a way to filter out Mode S-only data.

Note that ADS-B itself uses Mode S, so the distinction is a bit fuzzy - by “Mode S” do you mean “never heard an ADS-B message” or “didn’t hear a recent ADS-B position message” or something else? e.g. some aircraft will send some ADS-B messages, but not the position ones…

Thanks for some handy insight!

Will Skyview ever be able to filter it out? Is that a big ask? I simply have no idea about writing software these days, so is it even something that can be done in today’s world?

Bottom line; if there isn’t the data to put it on the map, I don’t need to waste any CPU cycles on it after finding that fact out.

In case it would make it easier to solve, how about 1090-fa not even bothering to pass incomplete stuff on? I mean that would get it. It may be a bit harsh, but I see incomplete messages as having junk status really. Optional of course, but that would save loads of wasted CPU cycles.

Cheers,
Ian

You could certainly change dump1090-fa to ignore everything except DF17/18 messages and not much would break, but the CPU cost in decoding the extra Mode S messages is fairly tiny - most of the cost is in preamble detection which you have to do regardless - and you wouldn’t be able to multilaterate anything interesting. I don’t see the point.

A filter for skyview to exclude positionless aircraft is do-able.

Yeah, that all seems fair enough. I’m just interested in anything which saves a few cycles here and there; I got a home brew weather station on my LAN and this item as well as 4 other Raspberry PIs doing stuff. So cutting back network & CPU use for anything is always helpful. Less heat generated all around is nice too, because I can’t have air con either! :wink:

But being practical, yes, I suppose filtering in sky view is a good call, esp while the jury is still out on where MLAT might be sitting just now (but this is not the place for a bigger mention than that :wink: )

OK, so who do we pester? :laughing:

Cheers,
Ian

OK, I’ve thought this over a bit more.

I’d like to explore the “change dump1090-fa to ignore everything except DF17/18 messages” option. I only want details of aircraft where they are complete and unadulterated sets.

So, what is the file to edit, where does it live in PiAware, and what should I be looking to change?

I guess I’m looking for quality over quantity.

I explored the SD card via secure FTP, but can’t see things that look like the ones I would probably need to examine.

Cheers,
Ian

You will need knowledge of C, and to rebuild dump1090.

Probably the best place to ignore messages is around here: github.com/flightaware/dump1090 … ack.c#L519
(then they will be demodulated / decoded / forwarded to piaware, but not tracked locally in skyview)

Oh well, that’s not going to get me where I want to be.

I want to get clean data and only share clean data. I don’t want to share anything spurious as you seem to have your hands full with what ever you are getting now. If we were to reduce noise by not bothering with inadequate data then everything could run smoother by not having junk to mess about with and filter and correct for. I can’t understand why this is not something to strive for? :confused:

Cheers,
Ian

Why do you think Mode S data is “junk”? It has useful information that is not carried in ADS-B messages. We do not want to throw it away.

The object of the exercise was to grab plane data using antenna and plot that on a map. Mode S does not allow that. Actually I’m not against Mode S I’m not in favour of any incomplete data that can not provide an entry on the map. Having got it on the map I am happy to share that, because I can see it has value.

I’d like it that way, that is how I’d like to spend my bandwidth, (which is capped by the way) I’d also like to get a UDP feed to support Globe-S but I bet I can’t do that because modemixer no longer works. I doubt PiAware can help in that dream either. So really I’m no better off and might as well go back to plain old dump1090 for all the difference it would make.

I know none of this is affecting anyone else, so it will not be seen as valid, but hey!

Cheers,
Ian

Still having trouble understanding what you’re trying to do and why bandwidth / CPU comes in to it.

Are you trying to plot positions on a machine that’s physically remote from the receiver?

Is your Pi (assuming you’re running dump1090 there) actually running short on CPU?

Are you looking to build your own software to do this, or use something out of the box, or adapt existing software?

Yeah, I get it and thanks for the time you’ve taken.

We both have a different mindset and different things to worry over. I got a 2mbit internet connection because the internet is just cherry picking over here. Every upload makes a difference, just in the handshaking over head, up is not capped, but down is. I get 1 Gb 09:00 to 00:00 then 2Gb for the night and into the next morning. If I go over then it’s a £6 perMb fine. I live in what’s called fuel poverty, so anything less is good, I’m twice the rate to fall into that category, it’s 25% of income, and mine is 50% of income. I try to not use power if possible. I got old eyes and I’d like to use Globe-S when they are tired, because that used to help.

About 50-60% of the planes I got here are solid good ones that will plot, I can’t see any point sharing any other kind as for me it’s just burning a budget I don’t really have. I bought all my own gear by saving, I know that’s a bit old fashioned for many, but that’s me. I’d like to have it how I need it as it wasn’t that cheap.

I’m looking to find software for this that can fit with my circumstance. I found Virtual Radar Server and that let’s me filter some, so that helps. I could go over to that full time, but then I would not need PiAware and could just use the Dump1090 I always did before. I don’t need to MLAT anything. So if there was this sort of choice with PiAware then it would be interesting, but there is not. Hence my thought that I can just go back to Dump1090, and VRS. You won’t need to burn any time on it, and heck you probably won’t even notice a 2000 planes a day feed going missing.

I plot planes on may main desktop. I get the messages via PiAware right now, but maybe Dump1090 soon. I could no more build my own than I could fly! :wink:

VRS can’t make like an RLT1090 feed, but no idea if PiAware could, so for me, if it could, that could be a bit of a must have or killer feature but other than that it’s about 50-50 with both systems.

I’ve explained it all I can now, and I hope it’s enough for you to get it, but if not then at least I tried. :laughing:

Cheers,
Ian

First step if you are bandwidth limited is to disable mlat entirely. It looks like you found that option OK.

For non mlat data, piaware summarizes the raw data before uploading. The summary for a non-ADS-B aircraft is minimal and relatively infrequent - typically <100 bytes every 30 seconds. hexid, squawk, altitude, callsign. It is more than zero but considerably less than what an ADS-B aircraft will upload.

The piaware feeder is not massively bandwidth hungry with mlat off (especially if you’re not metered for upload - then it’s only protocol overhead in the download direction, with mlat off there is almost no data flow from FA back towards the feeder). But it’s still not great for metered connections so you may want to entirely disable the upload to FlightAware. The UK has very dense coverage anyway so as you say, one less receiver is not going to put a hole in things. You can still run skyview etc to view local data without having to uploading it. Obviously we’d like you to upload, given the choice, but it’s up to you whether you think the enterprise account features + warm fuzzy feeling is worth what it costs you to run.

Starting from a piaware sdcard image you can disable the upload part from the command line by masking the “piaware” service, which will prevent it starting on boot:



$ sudo service piaware stop
$ sudo systemctl mask piaware


Or you can install just the dump1090-fa package (follow the package install instructions, but skip the step to install piaware itself) onto a Raspbian install if you’d like a more general-purpose system.

Or like you say you can go back to a different dump1090 + VRS. I’m biased here :wink: but I think dump1090-fa is a good choice even if you’re just running it standalone for feeding to VRS only.

Yeah, it’s tricky for sure. I’d feel bad using your PiAware image but not uploading, that seems too cheeky for words, so I’d be unlikely to do that.

VRS brings me some filtering right there in the map options, which PiAware can not at present, so that counts for something for certain.

As I said and or hinted earlier, I’ll use whatever is freely available, and gives me the options I feel I would find useful.

I’ll give it all some thought for a week or so, then make some kind of decision. I can do without being in limbo, and enduring this feeling of no hope for it’s future as it stands.

When all is said and done, I and others run weather stations which myself and another designed, and we just see aircraft as another aspect of the weather. It seemed like a good idea at the time, but it’s being rather time consuming and somewhat inflexible to be all that viable for the longer term. We have given this a good shot in a short space of time, and it’s only about 3 or 4 PiAware feeds, so as you say, not even noticeable in the wealth of coverage you already have across the UK.

Oh well, we tried.

Thanks very much for your time.