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.
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)
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.
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?