Anyway, both bias circuit and the LNA’s output have a kinda’ DC filtering, though with limited performance.
1 Like
Things have been running smoothly. I rarely have to intervene with anything on my set up these days.
Here’s my maxima graph that is pretty much all using an airspy mini. I switched to it in summer 2019:
The peak message rate is incorrect on that due to some spikes caused by a rogue feeder client causing double counting messages. The overall peak message rate is 3413/s, and message rates during busy times of 3250/s to 3300/s are not uncommon. The average message rate seems to be still slowly increasing. Not sure if that’s a long tail of covid recovery or just the continuation of increasing traffic from prior to it.
One thing that is very noticeable with the new decoder is that it gets extreme range targets a lot more reliably:
The beginning of 2022 saw a consistent increase in the maximum ranges recorded and I didn’t make any hardware changes around that time. I see a similar effect on @keithma receiver as well.
3 Likes
These graphs are very useful. I would really like to see if the max messages/sec will converge to some sensible value due to the saturation of the airspace. For now the trend is clearly up.
1 Like
Yeah i think it also includes mlat results … that rate shouldn’t be super large but still.
The positions per second seems to be rather static and somewhat independent of the aircraft count which is curious.
My station is pretty terrain limited so make of that what you will:
1 Like
I’m getting bogus range readings due to the GPS spoofing affecting some transponders even after they leave the area.
You might get some of that as well.
And it’s really hard to filter out as some of those transponders sending a completely bogus position still send very good position fidelity markers … which is concerning.
Positions per Second on my station approaches, sometimes reaches the value of 150 → but the further increase in the number of detected aircrafts no longer results in even higher rate of decoded positions.
The value of around 150 is not really closely related to the number of planes either. In my opinion, the location/constellation of the aircrafts can be an important factor in this case.
Yeah that timing is coincidental with a certain other event that lead to a rise in GPS shenanigans so a definite possibility. I hadn’t considered that it might be causing effects this far west, but I suppose it’s possible. The furthest east my reception gets is roughly the German/Belgian border, which is well over the radio horizon of the likely location of jamming transmitter.
Perhaps if there is some ducting present the effect is much wider spread than might be obvious. Looking at flightradar24’s jamming map, there are sometimes affected segments as far west as Denmark. It is odd if the transponders are reporting a good fix while still affected though.
There is a quite strong inverse correlation between aircraft numbers and received position reports:
Other message types don’t show this pattern, particularly DF0 and DF16 TCAS messages and DF4 altitude responses, whereas DF20 and DF21 CommB, and DF11 all call replies do. It’s possible that’s just the shorter messages having less chance of being garbled (apart from DF11s where there are so many that they are probably just getting garbled anyway).
3 Likes
You misunderstood, some transponders go into a faulty mode somehow (it’s really a badly programmed GPS unit or transponder).
See this example with position jumping back and forth until landing in London: https://adsb.lol/?icao=80158c&lat=50.322&lon=6.034&zoom=6.3&showTrace=2024-06-09×tamp=1717958482
It’s bad software in the GPS units of the 787 in particular.
Possibly the pilots could reset it during flight but they don’t seem to do so.
Seen a youtube video where the GPS spoofing also changes the planes clock and the pilots resetting it after asking ATC for the time.
It’s clear that dealing with GPS spoofing was not an engineering goal when developing for at least some planes / modules out there.
Now this particular example might not have affected your range but i’m sure i could find one that would.
Those messages increase with the plane density while DF17 is sent at a constant rate by each plane. (at least that’s my understanding)
Seems you need to split your receiver into multiple sectors 
But to make that work with MLAT you’d need to synchronize the timestamps or feed separately.
Actually thinking about it … you could synchronize the timestamps in software if the PPM isn’t too far apart. Basically do what mlat-server does … just constantly keep adjusting an offset between the two receivers by assuming some DF17 position message has arrived at the same time. If you write some more fancy code you can also compensate for PPM.
But that would be pretty fragile and rely there always being aircraft that are received by both receivers.
To be honest i should also check the number being plotted there.
414 # Position counts
415 posCount = stats['total']['cpr']['global_ok'] + stats['total']['cpr']['local_ok']
Hmm that seems to be correct.
And you said the DF17 count is proportional to the position count. So that’s good.
The position count (the cpr stats) at least with readsb (dump1090-fa is a different story) won’t include MLAT results, just checked.
Yeah there’s definite scope that that to cause problems. It’s quite an oversight that the avionics doesn’t seem to be able to recover reliably when out of range of the jamming.
Yeah I have considered it, but it would need some thinking about. There aren’t many options for antennas at reasonable prices though so it might need a custom design. Most of the yagis available have far too narrow a beam width. Ideally something about 90-120 degrees would be ideal, for 3-4 sectors.
I’m not sure it would be worth it trying to do mlat across sectors. If it’s busy enough for sectors to provide an advantage, then it’s likely that a suitable synchronising aircraft will be in view anyway.
Don’t suppose you still have the setup to spin up a separate readsb to compare versions?
If you do, just spin the comparison up with the readsb version I’ve pushed today vs what you’re running currently.
Otherwise just update readsb and see how it goes i guess
Added a heuristic to allow time between odd and even CPR to be longer depending on speed.
Which means the two CPRs can be apart in time typically 20 seconds instead of only 10 seconds. (those 10 seconds assume < 1000 knots pretty much so there is room for improvement for things that aren’t as fast)
This means much better chances to get a position for aircraft you get a low message rate for. At least if you don’t know a position yet, if you already know the last position this improvement probably doesn’t help. But it should help for aircraft coming into range or passing on the outskirts of coverage.
For my very terrain restricted receiver it’s minimal but for others there might be some improvement.
This will also not help for aggregators as they do their own position calculation from the odd / even CPR messages.
The thing about odd / even CPRs is that you can’t combine them if they were created for 2 positions too far apart as that will shift the position a long way on the CPR grid and produce a bad position.
Thus there is a slight risk to get bad position decoding but at least in my testing the parameters i’ve chosen are good enough for this not to be an issue.
Oh the new version also excludes aircraft for the max range and outline calculations if they aren’t indicating good position fidelity.
This probably won’t really bump the position rate but getting a location earlier for aircraft coming into range or getting a position at all for position on the outskirts of coverage doesn’t sound bad to me
2 Likes
Although I only have one set for the purpose of adsb decoding, the available statistics for the past period have the consistency in daily operation, which allows me to have more than intuition or estimation in experimental observation after a few days.
Here, https://github.com/wiedehopf/airspy-conf I can see ver. 2.2-RC30
Is there something fresh / had I missed some?
I’ve updated to the new version and will see if there’s much difference.
1 Like
Nope still 2.2-RC30 for quite some time.
I was talking about readsb.
See CPR decoding: https://mode-s.org/decode/content/ads-b/3-airborne-position.html
That takes two DF17 CPR messages and makes a position from them.
Tried to somewhat explain it in the previous post but that’s what i meddled with.
1 Like
Ah, okay. Thanks.
It looks like an interesting project.
Probably nothing noticeable
Maybe i’ll tweak it some more at some point.
In other news, added a new compile for bookworm with a bit less CPU usage.
Might run on bullseye, maybe someone could test that (library versions).
Oh new compile only for arm64 because for other architectures i need to jump through some hoops.
Maybe i’ll do that regardless.
2 Likes
Hi,
I have to upgrade from bullseye to bookworm first - so, l need to pick some free time for making the necessary changes.
…then, I take a chance on the new version.
I’ll sign when I find some noticable difference…
Nothing that jumps out in the stats.
Don’t worry about it, i’ll probably rebuild for bullseye as well.
2 Likes
In Formula 1 (F1) category, even 0.01sec better circle time does matter! 
This is why “nothing” IS something at this level. Namely, when you can not really do much for getting the theorethical max result - being almost there.
1 Like