search

mutability / dump1090

Dump1090 is a simple Mode S decoder for RTLSDR devices
526 stars 136 forks source link

Non-Mlat Beast output port #56

Closed dschaper closed 9 years ago

dschaper commented 9 years ago

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.

mutability commented 9 years ago

I am reluctant to start plumbing forwarding rules like this into dump1090, it's not really set up for much beyond trivial forwarding. It seems like you can achieve the same thing by telling the mlat client to provide results directly and don't specify --forward-mlat to dump1090.

dschaper commented 9 years ago

Okay, I'll pretend for a second I have a clue as to how to do that . It seems to be getting a bit confusing with mlat in the picture. Now it looks like one of the closed source flight tracking packages is also integrating mlat capabilities into their decoder. I don't think they responded to your inquiries... I'd just like to be able to provide as much useful data to as many sources as I can without having to jump through 15 hoops to do it. (Not a rant on you, I like using the mutability fork for decoding but it seems like things are headed towards an us or them situation.)

mutability commented 9 years ago

I'm not sure if I understand what you're asking here. I thought you were asking for dump1090 to provide two types of output: one with mlat messages, one without. Is that not what you were suggesting?

dump1090 does nothing to generate mlat messages itself, so if you wanted separate output ports for mlat vs non-mlat that implies that there is something external (e.g. mlat-client) that is sending mlat messages to dump1090. But if that's true, why don't you just take the mlat positions directly from that external thing?

mutability commented 9 years ago

(so this is nothing to do with trying to wrap it all up into a closed system - it is just that you can already do this in another way, so why make more dump1090 more complex to do the same thing?)

dschaper commented 9 years ago

I'm very confused then. I wasn't suggesting that you were trying to create a closed system at all. I thought dump1090 did generate the mlat messages. I think I need to figure out the flow of the system. Sorry to make a donkey of myself...

dschaper commented 9 years ago

So in one case, the piaware package takes the beast output from dump1090 and it generates the mlat's. It then sends dump1090 the mlat data on 30004 which allows the dump1090 web interface to display mlat targets. In previous versions of dump1090 the input on 30004 was forwarded on to it's output with identification of mlat target data, but that has changed now and by default will not forward? So the mlat data is a function of the piaware package?

mutability commented 9 years ago

You beat me to it. Yes, that's right. The mlat data is generated by fa-mlat-client which is packaged with piaware.

The missing part of the puzzle here is that fa-mlat-client actually has the ability to generate those mlat messages in a bunch of different ways (e.g. in Basestation format or whatever). But that ability is not yet exposed in an easy-to-configure way by piaware. It's on the list..

So you already have a non-mlat data stream - this is dump1090's port 30005. If you wanted a separate mlat data stream then the way to do that is probably to configure fa-mlat-client to generate results on a separate port (in addition to, or instead of, sending to port 30004).

If you just want one big combined stream including mlat, you can run dump1090 with --forward-mlat and it will forward everything to port 30005, including mlat, like older versions did.

dschaper commented 9 years ago

Thanks for the explanation, I really do appreciate it.

mutability commented 9 years ago

I drew a diagram (this will end up in docs somewhere eventually)

mlat-dump1090

dschaper commented 9 years ago

Extremely helpful!

mgunther68 commented 9 years ago

Very clear and helpful! Would you care to add another section to the diagram to show an additional stand-alone mlat-client which is participating in a private mlat network (separate from Flightaware)? I'm talking specifically about the UK/Ireland MLAT network that you helped to get off the ground. In my case, I have all the items already shown here plus an additional mlat-client talking to a separate mlat-server and feeding back synthetic positions also on port 30004 to the single instance of dump1090.