FlightAware Discussions

Data usage using Flight Aware on a Raspberry Pi B+

Have a ADS-B USB dongle plugged into a Raspberry Pi B+. I’m up and running.

Wondering how much data is uploaded and downloaded just using this setup per month.
Might put this on a Wifi Hotspot if the usage is within a reasonable limits for a remote location.

It depends on the amount of traffic in the area, but I would expect 100-500MB/mo at most sites.

You could approximate it from the number of messages reported by piaware in /tmp/piaware.out - assume around 100-150 bytes/message.
Looks like I average about 45-50MB/day (it’s a busy location)

We bundle & compress the messages, so it’s actually much less.

Mm, are you sure? I see more data going out on the SSL connection than comes in from faup1090:

recv(6, "clock	1416440376	hexid	3C542F	id"..., 4096, 0) = 126
send(5, "\27\3\1\0\240(\2\273\322\306-f=\367m\242c\361%\212\341\326?\303\344r\324w\372\343\5"..., 165, 0) = 165
recv(6, "clock	1416440381	hexid	478115	id"..., 4096, 0) = 332
send(5, "\27\3\1\0p+\2576!\313\v\16\33;\264\327\214\307\223nS\253\300\276\237\366\317_\307\345\346\203"..., 117, 0) = 117
send(5, "\27\3\1\0\240D\326*\234x\36\314\202k\17%\242tL\3657\276\23\5g\275\377\215\265\"\270\336"..., 165, 0) = 165
send(5, "\27\3\1\0\240.fx\26	\314{\226\333
\37E\257\225B\310\252\227)\322\321\344\324+\317t\30"..., 165, 0) = 165

piaware 25098 adsb    5u  IPv4 368149118      0t0       TCP rpi.lxi:58338->eyes.flightaware.com:1200 (ESTABLISHED)
piaware 25098 adsb    6u  IPv4 390258743      0t0       TCP localhost:57386->localhost:10001 (ESTABLISHED)

(those are 1-message and 3-message bursts respectively)

I guess I’ll have to actually measure it properly one day :slight_smile:

I’d definitely be interested in your measurement. PiAware caches and buffers and filters, so you’d need to measure for longer than just a few mesages.

Might be a terminology problem here. That’s what faup1090 does - not piaware itself - right?
Piaware just forwards the datastream from faup1090 over SSL, essentially.
I’m counting messages as seen by piaware - i.e. after faup1090 has done its thing.

FWIW, 9 hours overnight yielded:

20.7MB sent, 0.8MB received on the SSL connection (measured via ntop - I’m not sure if this counts ethernet frame size or TCP payload size)
128961 messages sent (difference between the start + end counts in /tmp/piaware.out)
-> 160 bytes sent per message

Those aren’t raw ADS-B message counts. They’re filtered and aggregated and batched together into single packets to amortize the 64-byte packet header overhead for IPv4 across more messages. Still I don’t think we’re getting the compression of of TLS that we are supposed to, and we are looking into this.

Yes, I understand that. I was just trying to estimate IP traffic based on information that is logged by piaware - and my estimate looks OK.
So the OP can estimate his traffic use by looking at the piaware logging and multiplying by 160 bytes/message (where “message” is “message count logged by piaware”, not “ADS-B message count”).

I’ve looked into this some more and right now the upstream data is not being compressed by the TLS library. There is a flag to enable it but it’s not accessible from the Tcl API which isn’t a huge deal but I have also read of attacks against compressed TLS, that specifically compressed TLS is more attackable than uncompressed, and that in TLS 1.3 they are removing the compression option. (I presume this is due to predictability of the compression preamble or the structure of the start of its data allowing for known-text-type attacks.) I’ve been experimenting the last few days with enabling compression in-band after an uncompressed, TLS-encrypted session has been established. This should majorly shrink the upstream bandwidth used but it’s not working yet (works for a trivial case, doesn’t work for the next-less-trivial case, have reached out to the author, etc).

TBH even 50 MB/day is not a problem for your typical broadband connection. For installs that are bandwidth or traffic limited e.g. on the end of a 3g link, perhaps making the report interval configurable is sensible? Reducing it to say 30s should reduce traffic a lot and not greatly reduce the usefulness of the data?