ADS-B DIY Antenna

Status
Not open for further replies.

PeterPlane

New Member
http://www.ebay.com/itm/ADS-B-omni-...621?pt=LH_DefaultDomain_0&hash=item2c9779db3d

I don't think I am running that..

I would say so far it is picking up more planes then my 8 Legger antenna. From when i looked to see how many planes I was picking up before I changed it out to this antenna. It would be a easy 40 more planes total or more. So It is helping so far. I will see what my stats show. I put it in the same place as the 8 Legger.
How many weeks did it take for the antenna to arrive? I have one on order too.
 
Last edited:

jepolch

Active Member
You didn't let dpkg update the javascript when you upgraded. Please run:
Code:
sudo apt-get -o Dpkg::Options::="--force-confask" --reinstall install dump1090-mutability
and when it asks if you want to install the package maintainer's new version of the various javascript files, SAY YES.
Is there a way I can run 'sudo dpkg-reconfigure dump1090-mutability' with the '--force-confask' option (I guess I could have tried that), or could you build that function into the reconfigure so it will ask if I want to replace the conf files? Thanks.
 

obj

New Member
Is there a way I can run 'sudo dpkg-reconfigure dump1090-mutability' with the '--force-confask' option (I guess I could have tried that), or could you build that function into the reconfigure so it will ask if I want to replace the conf files? Thanks.
It's a function of the package upgrade, not the reconfiguration.

The javascript/html are marked as "config files" so that user modifications are preserved. They don't actually hold config information and they are not touched by dpkg-reconfigure at all.

When a new version of a package is installed, dpkg looks to see if (a) the config files have changed between the two package versions and (b) whether the current version of the config file is different to the original "old" version provided by the package, i.e. has been edited by the user. If both are true (I think that's the rule, anyway) then it will ask you what you want to do about it. If the config files haven't changed, or if you haven't made modifications, then nothing is asked and the files are left untouched. If the config files have changed but there were no user modifications, then dpkg installs the new version without asking.

Further complicating things is that when you turn a non-config-file into a config-file, that looks to dpkg like the file was user-modified. So when I made that change, everyone got a prompt asking what to do about those files.

The problem arises when you say "no don't update the file". At this point you've taken on responsibility for making it work with the new version. But invariably that doesn't happen and I get a bug report.. At this point merely reinstalling the same version doesn't help because condition (a) above isn't satisfied - if you're reinstalling the same version, the config files haven't changed between versions at all. That's what the --force-confask on reinstall is about - it overrides the first condition and asks you again about every config file.

The alternative for the user is to go and find the new copy of the config file, which dpkg will have left as <filename>.dpkg-new, and use that. But it's simpler from my point of view to just have a magic command that fixes it rather than trying to explain how to find and rename the right file.

The other way to solve this problem is not to mark the files as config files at all. Then installing a new version of the package will unconditionally replace the existing files with the new copies - regardless of if you made changes. That's easier for me but not so friendly for users as it seems like modifying the webmap is a popular pastime..

TL;DR: supporting packages when your target userbase has no knowledge of system administration is a right pain..
 

jepolch

Active Member
It's a function of the package upgrade, not the reconfiguration.

The javascript/html are marked as "config files" so that user modifications are preserved. They don't actually hold config information and they are not touched by dpkg-reconfigure at all.

When a new version of a package is installed, dpkg looks to see if (a) the config files have changed between the two package versions and (b) whether the current version of the config file is different to the original "old" version provided by the package, i.e. has been edited by the user. If both are true (I think that's the rule, anyway) then it will ask you what you want to do about it. If the config files haven't changed, or if you haven't made modifications, then nothing is asked and the files are left untouched. If the config files have changed but there were no user modifications, then dpkg installs the new version without asking.

Further complicating things is that when you turn a non-config-file into a config-file, that looks to dpkg like the file was user-modified. So when I made that change, everyone got a prompt asking what to do about those files.

The problem arises when you say "no don't update the file". At this point you've taken on responsibility for making it work with the new version. But invariably that doesn't happen and I get a bug report.. At this point merely reinstalling the same version doesn't help because condition (a) above isn't satisfied - if you're reinstalling the same version, the config files haven't changed between versions at all. That's what the --force-confask on reinstall is about - it overrides the first condition and asks you again about every config file.

The alternative for the user is to go and find the new copy of the config file, which dpkg will have left as <filename>.dpkg-new, and use that. But it's simpler from my point of view to just have a magic command that fixes it rather than trying to explain how to find and rename the right file.

The other way to solve this problem is not to mark the files as config files at all. Then installing a new version of the package will unconditionally replace the existing files with the new copies - regardless of if you made changes. That's easier for me but not so friendly for users as it seems like modifying the webmap is a popular pastime..

TL;DR: supporting packages when your target userbase has no knowledge of system administration is a right pain..
Well, then, you must be a glutton for pain. :D Thanks for the explanation. I have a better understanding of it now, as well as a better understanding of what you're doing to help us. Thanks!
 

giacomo1989

Member
Local receiver:

65917 sample blocks processed

0 sample blocks dropped

0 Mode A/C messages received

5125598 Mode-S message preambles received

1779426 with bad message format or invalid CRC

3081675 with unrecognized ICAO address

259306 accepted with correct CRC

5191 accepted with 1-bit error repaired

-12.8 dBFS mean signal power

-2.1 dBFS peak signal power

2201 messages with signal power above -3dBFS

CPU load: 24.2%

597173 ms for demodulation

231488 ms for reading from USB

42806 ms for network input and background tasks

Do you think this is acceptable?
 

jepolch

Active Member
@obj:
Here is a screenshot for command "top". The RPi is currently using microSD card #3 (i have purchased a bunch of class10, 8Gb cards when i found a local store selling these at $5.99 each in special offer).

The microSD card #3 has Wheezy from RPi site, dump1090 from Malcom Robson fork, piaware data client from Flightaware site. In addition I have installed FR24 data feeder, and Planefinder data feeder + node.js (needed to run planefinder client). The two biggest CPU user are dump1090 & node!

The screenshot is small as it is taken on my phone. I am away from home, and SSH my RPi on internet/phone's data network. (Posting this reply from phone, difficult to type & upload, but works. Better than nothing.)

View attachment 1204
Yeah, node (python)'s a killer. 44% CPU vs. Piaware's 2%. PlaneFinder needs to come up with something a lot leaner!

node load.jpg
 

jepolch

Active Member
Sure do. Have it logging the case temperature as well using a DS18B20 1-wire sensor as it gets quite hot here.

View attachment 1210
Definitely a cool addition to the Pi, but kinda quirky. Did you have to install it twice before it "took"? I did on both my Pi's. Weird. Also, I am frustrated by trying to figure out how to install addons. It's almost like the author takes a perverse pleasure in giving hints on how to do so, rather than clear instructions. :mad: Or is it just me?

rpim.jpg
 

xforce30164

Active Member
http://www.ebay.com/itm/ADS-B-omni-...621?pt=LH_DefaultDomain_0&hash=item2c9779db3d
I would say so far it is picking up more planes then my 8 Legger antenna. From when i looked to see how many planes I was picking up before I changed it out to this antenna. It would be a easy 40 more planes total or more. So It is helping so far. I will see what my stats show. I put it in the same place as the 8 Legger.
I got the same antenna in the post just today, but need some more cables before I can connect it and hook it up to my RTLSDRs
 

jepolch

Active Member
I have already sent my cpu usage screenshot by email to "support@pinkfroot.com", pointing out excessive cpu usage by "node". You may also do the same.
I wrote them and sent this screen shot with a request that they re-write the app without using python. Note: I know dump is also running a high load. I'm sure it's different for everyone, depending on how many messages per second it has to process. I found the "sweet spot" for my dump config by using gain setting of "-10" instead of agc or max. I get the best number of msgs/sec, but the load is a bit high. I can lower the load by changing the gain, but the msgs/sec count suffers.

node load.jpg
 

obj

New Member
I found the "sweet spot" for my dump config by using gain setting of "-10" instead of agc or max.
FWIW, "agc" is identical to -10 (if you say "agc", the init script turns that into --gain -10 !)

AGC seems to be a good choice for unamplified antennas at the moment - it is not the autogain part that it useful, it's that the total gain in that configuration is actually slightly higher than what you get with "max". (I need to find some time to sort out librtlsdr and fix that oddity so you can get direct access to the higher gain setting).
 

jepolch

Active Member
FWIW, "agc" is identical to -10 (if you say "agc", the init script turns that into --gain -10 !)

AGC seems to be a good choice for unamplified antennas at the moment - it is not the autogain part that it useful, it's that the total gain in that configuration is actually slightly higher than what you get with "max". (I need to find some time to sort out librtlsdr and fix that oddity so you can get direct access to the higher gain setting).
I guess I'm confused. I thought you wrote on another forum that agc and max worked about the same when using a DVB-T dongle. My mistake then. My antenna is amplified.
 

jepolch

Active Member
node is a javascript engine, already not python? :)
OK, you're right, that's why it's called "node.js". Again, I'm mistaken. So I wonder why the pfclient installs python. And do you suppose it's such a hog because it uses javascript (not python)?
 

jepolch

Active Member
I managed to somewhat tame the node beast by changing its nice level to 19 in the pfstart.sh script. My load level has dropped from the high 2's to high 1's. I'll keep an eye on PlaneFinder to see if this has any ill effect on my feed levels. Now I wonder why that @obj guy starts up dump1090-mut with a nice level of -5. I'm sure I'll find out. :)
 

obj

New Member
I guess I'm confused. I thought you wrote on another forum that agc and max worked about the same when using a DVB-T dongle. My mistake then. My antenna is amplified.
It's complicated! I only worked out exactly what was going on recently.

There are three stages of controllable amplification in the dongle: the LNA, the mixer, and the IF VGA - that amplify the signal, in that order.

When you set manual gain, that sets the LNA and mixer gain to max, and sets the IF gain to a fixed value.

When you ask for AGC, that puts the LNA and mixer gain under the control of the AGC, and sets the IF gain to a different - higher - fixed value compared to what you get with manual gain. Then the AGC ramps all the gain that it controls - that is, the LNA and mixer - up to maximum because it doesn't deal with ADS-B signals very well.

So in both cases, the LNA/mixer gain settings end up the same. But because the IF gain is set differently in the two cases, the total gain that you get when you ask for AGC is slightly higher than what you get when you ask for max manual gain.

Really, librlsdr should be smarter about how it sets the IF gain, and let you increase it if you need to. I have some work along those lines to merge.. but a project for another day :)
 

obj

New Member
Now I wonder why that @obj guy starts up dump1090-mut with a nice level of -5. I'm sure I'll find out. :)
It's to reduce the chance that dump1090 starts dropping samples if there is other stuff running that's competing for CPU. For example it helps while you're running a package upgrade or similar. If the package upgrade is short on CPU it just runs a bit slower. If dump1090 is short on CPU then you start losing data. Negative niceness does what you'd expect - it makes a process "not nice" and more likely to get CPU :)
 
Status
Not open for further replies.
Top