PeterPlane
New Member
How many weeks did it take for the antenna to arrive? I have one on order too.
Last edited:
ADS-B DIY Antenna
- Thread starter Mukundan
- Start date
- Status
How many weeks did it take for the antenna to arrive? I have one on order too.
Sjacket99
Member
It was shipped Jan 30th. Per what ebay and tracking # said. I got it yesterday (Monday).. East coast of the U.S.
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..
ab cd
Senior Member
Antenne PCB 1090 MHz / 1090 MHz PCB antenna
Source: http://f5ann.pagesperso-orange.fr/AntennePCB-1090MHz/index.html
Source: http://f5ann.pagesperso-orange.fr/AntennePCB-1090MHz/index.html
Last edited:
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?
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
Yeah, node (python)'s a killer. 44% CPU vs. Piaware's 2%. PlaneFinder needs to come up with something a lot leaner!
jepolch
Active Member
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.
Or is it just me?
xforce30164
Active Member
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
ab cd
Senior Member
I have already sent my cpu usage screenshot by email to "[email protected]", pointing out excessive cpu usage by "node". You may also do the same.
jepolch
Active Member
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.
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).
node is a javascript engine, already not python?
Yep, that looks fairly normal.
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.
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
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 CPUNow I wonder why that @obj guy starts up dump1090-mut with a nice level of -5. I'm sure I'll find out.
- Status
