I am irked when people take advantage of a nice friendly “competition” of sorts and try to cheat their way in.
Looking at my stats page I see this guy in the neighborhood that has double of what everyone has in my area. At closer look, I see that it has combined two sites under one location, MLAT obviously doesn’t work. One location seems to be 100-150 miles away from the declared one, based on his stats and concentration of planes.
Am I alone that is bothered by something like this?
Maybe the location is just configured wrong?
Second receiver would have many more hits near the center or another strong field.
Edit: well maybe second location indeed, it’s strange for sure.
If you look at everyone in his “neighborhood” you see nice graphs with more planes close-by and almost equal at the 100-150 distance, and kind of symmetrically spaced. His is nothing like that.
Maybe the aim is to see the results of two receivers on one map?
Well the nearby sites are useful to see what is possible, for me it is not a competition, but hey, people are different 
That’s why I asked here, to see if anyone sees it as a friendly competition or what else.
INTJ type of thing 
No competition at all in hobby pursuits. I already compete for 37.5 hours a week, the last thing I need/want is more competition during my hobby hours.
Improvements, yes, always open to ideas that may increase my enjoyment of the hobby.
Well, that’s what I meant. You look at your “neighbors” and you asses how much you can do in the way of improvements.
If you consider adding a second receiver an improvement, then it’s not ‘cheating’.
The only kind of ‘competition’ I consider sometimes, is how much I can improve on my past performance. Other people have different conditions, skills, financial means. It’s not a level playing field at the best of times.
Then there is ethical behavior, something that is very ‘flexible’ these days.
If anyone adds the second receiver, it becomes a second location.
If you manipulate the data to be “piped” from the second receiver to the first one (in the process obviously MLAT becomes unavail), just to inflate the “scores”, that is cheating IMO.
But again, I can agree that some people don’t see it that way, that’s why I have asked the question to start with.
PS: To view the remote receiver web page, there are other ways to do it, like this one https://www.zerotier.com
How are you able to determine this?
This is not cheating. This is a technical way to reduce mobile traffic, for example. Example here
Either collect data for own purposes and then share it with Flightaware, Flighradar24, RadarBox24, ADS-B Exchange. For example http://planeradar.ru/virtualradar
Why combine two sites under one feeder if is only for reducing traffic? There is no need for that.
Also, like David said, a form of compression is already done:
For normal ADSB on PiAware, an internet packet is sent out when it is filled up with messages OR 10 seconds has passed a partially filled packet will be sent. This minimizes the header overhead. I haven’t looked into how modeSmixer does it’s thing. If it is sending 1 ADSB message per packet I can see how this can run into data usage problems.
PiAware also has some code to limit the number of messages that can go into the packet. Like if a plane isn’t changing altitude or heading then we will block those messages from being sent.
MLAT require all data packets to be sent and the limits are removed. This effectively doubles the data requirements for MLAT site.
For example, for owner needed “merging data from any number of ModeS tcp-sources” & “splitting output data stream for any number of IP-clients”
This is a console (command line) program that can do:
- merging data from any number of ModeS tcp-sources: binBEAST, AVR, AVRMLAT, SBS30006, SBS10001, >MSG and/or physical serial devices - COM*-ports in Windows or /dev/tty’s in Linux to merged output stream. >This stream, in turn, may be issued to the network in various formats simultaneously. Data format of input >tcp-sources is automatically recognized.
Incoming data may be both inConnect (pull from <address>:<port>) and inServer (listen data on >own TCP-port <port>).
- decoding/transcoding the input data to different formats to output: binBEAST, AVR, AVRMLAT, SBS30006, >SBS10001 and MSG as required by user.
- splitting output data stream for any number of IP-clients in the following formats: binBEAST, AVR, >AVRMLAT, SBS30006, SBS10001 and MSG. The output data can be both outConnect (push ><address>:<port>) and outServer (listen request on own TCP-port <port>).