PilotAware
British Forum => General Discussion => Topic started by: DaveStyles on July 04, 2016, 03:44:49 pm
-
Hi all,..
We now have a nice GUI Post Processor for the track files.
(http://www.pilotawarehardware.com/dl/GUI.jpg)
It's a runnable jar file, so you can just copy it to your machine and double click on it like an executable.
What it tells you :
It looks at the returns from each aircraft you see, and it maps the FURTHEST contact that you have with that aircraft on each heading you see it.
If an aircraft flew in a circle around you, and then towards you, what you would see on the GUI would be the hit that was the FURTHEST from you on each heading.
I want to make it clear that what it does not do is show you a track of other aircraft, but of course, if one flies past you to one side, then this may appear as a track, as it will only fly through each heading once !
Remember, it will show the furthest hit on each bearing, but it only has a resolution of 1 degree, so, out a 20nm, those hits may look a little scattered, rather than a smooth line.
Download from here...
PilotAware Track File Post Processor (http://www.pilotawarehardware.com/dl/PawPostV2.jar)
This is a first version and I am sure will be updated. Lee is already adding extra features to the track files that we can take advantage of in post processing.
-
Thanks for that.
It confirms my maths is OK, furthest seen 23Km (12.4nm) and closest was 2Km (1nm).
-
Hi Dave
How long should this take to load a file, it's been sitting at "loading" for about 10 mins now.
Using on windows 7 pc with previously downloaded .trk files in same folder.
Regards
Alan
-
Hi Dave
How long should this take to load a file, it's been sitting at "loading" for about 10 mins now.
Using on windows 7 pc with previously downloaded .trk files in same folder.
Regards
Alan
How big is the trk file Alan ?
It does seem a little slow at large files, but it does get there ...
-
Hi Lee
It was on a 5.3MB file for about 20 mins. After your response I killed it to try a 354KB file and it has been sitting for about 10 mins again on that.
I've just checked the file ext as they have previously been opened with Notepad but it is still showing .trk
Regards
Alan
-
Over to Dave then I'm afraid :o
-
For reference I opened a 53Mb track file with it in around 6 seconds, using a MacBook Pro.
-
20 seconds for me for a 6.15mb file using Windows 7
-
Wow, had to install Java on my Windows 8 {virtual} machine but the same 53mb file took 1m 53s to open compared to 6 seconds on the Mac. Odd as the VM I use every day for software that is only available on the Windows platform.
-
Mmmm
Still sitting at loading well over and hour later after I went away to have my evening meal and that's on a tiny file.
I must be missing something. :-\
Alan
-
Firstly, Dave, Great piece of work, thank you, allows so much visibility of the data we have in the track files.
Some enhancement thoughts:
- showing some stats about the file loaded, file name, start time, end time, etc
- showing some more stats about each aircraft as clicked on - 1st point time, last point time.
- showing some info about altitude of each point - colours?
- option to show all points - very useful to see more about when the aircraft *stops* being seen.
It is interesting to think about interpreting the data - it is more about what data *can't* you receive, the idea of trying to create a 'polar' plot is great, but has its limits when trying to think about the relative blind spots of a moving aircraft vs a base station.
Alan - Does the file your loading have any aircraft points in it? I have one 50Mb file that has no aircraft in it (ADSB antenna was not connected and it was on the ground) and I didn't realise it had actually loaded, as it has nothing to show.
An interesting piece of data I found in one of my track files:
$ cat 2016-07-02_10-23.trk | grep BSRI | grep '#G-BSRI#' | wc -l
114
$ cat 2016-07-02_10-23.trk | grep BSRI | grep '#GBSRI#' | wc -l
114
$ cat 2016-07-02_10-23.trk | grep BSRI | grep 'G-BSRI' | wc -l
676
$ cat 2016-07-02_10-23.trk | grep BSRI | grep 'GBSRI' | wc -l
592
I doubt BSRI really has 2 transponders and 2 PAW's, with G-BSRI and GBSRI configured respectivley. A bug somewhere?
Cheers
Kev
-
I saw something similar. The aircraft had ADSB/Mode S ES out and I was picking up that signal before the PilotAware one, then as it got further away dropped back to the stronger ADS-B one. So both appeared in the log.
-
$ cat 2016-07-02_10-23.trk | grep BSRI | grep '#G-BSRI#' | wc -l
114
$ cat 2016-07-02_10-23.trk | grep BSRI | grep '#GBSRI#' | wc -l
114
$ cat 2016-07-02_10-23.trk | grep BSRI | grep 'G-BSRI' | wc -l
676
$ cat 2016-07-02_10-23.trk | grep BSRI | grep 'GBSRI' | wc -l
592
I doubt BSRI really has 2 transponders and 2 PAW's, with G-BSRI and GBSRI configured respectivley. A bug somewhere?
Showing your Linux prowess now Kev ;)
OK, What does this mean, firstly I presume your PAW is set to alternate between FlightID and REG
that explains the alternating G-BSRI (Reg) and GBSRI (Mode-S FlightID) - a flight ID cannot have the character '-'
the '#' brackets, only appear after PAW has received un-interrupted set of frame based packets.
If you remove the 'wc -l', you would see that all of these hits should have the same ICAO code.
Remember that important information is sent in a single P3I packet - less important is framed over a sequence,
so if there is a break in the sequence, the checksums fail. At the moment the only data sent as part of the frame
sequence is the GroupID
so once PAW has 'learnt' that G-BSRI is part of your group, it remembers that information until powered down.
Make sense ?
Thx
Lee
-
Wow, that needs a clear head to understand.
In the mean time I will write 50 lines of "I must not assume I understand"! :)
Thanks for taking the time to explain.
Cheers
Kev
-
OK, next question for whoever feel up to it.
I've just managed to open the 25Mb track file for the day I drove from Edinburgh to Harrogate with PAW running in the car. It reports a Mode S only aircraft, which I am familiar with, and later plotted our relevant positions using a combination of the track file with a text editor and FR24 at the various alert levels I received, but the track file says:- "closest 987 m & furthest 1082 m, mainly south, above and west of your position". Where does this info come from on a bearingless Mode S contact. it bears no resemblance to my plotted calculations. Also received a Mode S alert from:- "TYPHOO45", Closest 69 m Furthest 1067 m, mainly south, level and west of your position. Another interesting contact is "PIRATE15" he was 282 m & 2686 m. These of course are all meters.
This was as i was passing the plethora of RAF stations around N Yorkshire.
Non of these showed any plots in the square box.
Any clues guys?
Alan
-
Hi Alan,
Good point, I don't think modeS was considered, too busy working out the 3 dimensional maths for the other targets.
We'll discuss the track files with Lee. I think it's fair to say that's a loophole in the current post processor. We wanted to get it up as people are beginning to get PAW to PAW hits and it's an easy way to see who, where and what sort of distances.
Plenty of refining to be done, but OK for a first release.
-
No problem Dave,
as yourself and others are saying it is useful in its current form, especially when looking for known contacts. I was just curious where it was taking info from to give any indication of Mode S position & direction when the fields in the $PFLAA sentences are effectively blank. I would have only expected a possible altitude comparison.
As you say, a work in progress. Be assured my comments were not intended as a criticism.
Regards
Alan
-
all feedback is good feedback ! Glad you pointed it out tbh
regards, Dave.
-
I haven't much time to analyse it full but I did two flight yesterday from Enstone with PAW running in our group PA17 G-AWKD. The first in the morning only went a short way to the north west. The second in the afternoon was across to Daventry area. I used the audio alerts rather than checking the screen, as I only had an iPhone.
The Track Log shows I got an other PAW at 19Km, which came as close as 12Km. Not close enough to trigger an alert. Which showed to be an Eurofox. First contact 14:21UTC
Had quite a lot of 'Danger' Mode S alerts at my level, but saw nothing. It did pick up a Puma on converging course, almost Head on, a just a few 100 foot above me. But was just a split second before I saw it, approx. 3 miles away.
Dipole antenna was velcored to rear cabin bulkhead (a fabric panel).
Need to chew the data a bit more.
-
Hi Ian,
What Mode S range setting are you using? Also what vertical separation do you have selected? I suspect most of the Mode S contacts which you 'weren't seeing' were probably high power transponders e.g. CAT. Unfortunately this is an issue we have to live with, with Mode S, though reducing your separation level to say +/- 1000ft removes most of these. Changing to a shorter 'Range' would also help, but might have meant you saw the Puma before you got the alert. Just a question of balancing your settings to flying conditions.
Regards
Peter
-
Why is this contact showing as nearly 8 million metres away? Probably 8km?
-
Hi Ray
Why is this contact showing as nearly 8 million metres away? Probably 8km?
I think I would like to see the entry in the .trk file first, it could be the post processor which is wrong, it could also be the input data.
These are the messages sent to the NAV tool, I could imagine if the GPS was bad at this point it would think a received signal was further than it really was.
If you can provide access to the track file, I will take a look at some point.
Thx
Lee
-
Thanks Lee, have emailed the trk file to support address
Regards, Ray
-
Why is this contact showing as nearly 8 million metres away? Probably 8km?
I'm waiting for someone to ask which antenna you are using to get that range !
-
Hi Ray,
Why is this contact showing as nearly 8 million metres away? Probably 8km?
The A/C in question G-PYPE, does this have an ADS-B in addition to PilotAware fitted ?
Also what version of PilotAware is being run ?
Thx
Lee
-
Yes he is broadcasting ADS-B OUT from a Funke Xpdr. I believe he is running latest release albeit on a B+ 1. He's disappeared off to France but I'll email to confirm release level.
Regards, Ray
-
Hi Ian,
What Mode S range setting are you using? Also what vertical separation do you have selected? I suspect most of the Mode S contacts which you 'weren't seeing' were probably high power transponders e.g. CAT. Unfortunately this is an issue we have to live with, with Mode S, though reducing your separation level to say +/- 1000ft removes most of these. Changing to a shorter 'Range' would also help, but might have meant you saw the Puma before you got the alert. Just a question of balancing your settings to flying conditions.
Regards
Peter
Hi Pete,
I had +/- 2000, and off the top of my head the medium setting. I am away from Home not until Sunday, so cannot be more precise. Today took the range to the next shorter (not the shortest Ultra Short) and could see an approaching mode S only helicopter blasting through the circuit, at circuit height ::),but he was less than a Km away before PAW spotted him. I also did not see the Reds who passed to the south, close to Enstone, visually :-[ or on PAW.
One thing I did notice is the OSF motor glider, which is S only kept appearing and disappearing from my Skydemon screen. We were doing circuits at the same time.
-
Hi Pete,
I had +/- 2000, and off the top of my head the medium setting. I am away from Home not until Sunday, so cannot be more precise. Today took the range to the next shorter (not the shortest Ultra Short) and could see an approaching mode S only helicopter blasting through the circuit, at circuit height ::),but he was less than a Km away before PAW spotted him. I also did not see the Reds who passed to the south, close to Enstone, visually :-[ or on PAW.
One thing I did notice is the OSF motor glider, which is S only kept appearing and disappearing from my Skydemon screen. We were doing circuits at the same time.
Hi Ian,
Alan G and I usually run with the Medium or Short Range Mode S settings these days. We developed 'Ultra Short' to deal with close proximity to high-power CAT Mode S or high power CAT ground radar signals, which otherwise swamp the Mode S triggers, causing continuous Danger Alerts, but would only use this setting if operating from or very close to a big CAT airfield - not likely in a flexwing, but you never know. Generally Zone Transits, including through the overhead, can be done quite satisfactorily using Medium or Short Range.
WRT the Reds - they may of course not have been transponding.
In the circuit, Mode S (or PAW for that matter) are more susceptible to being blocked by both your engines/bodies/ bodywork/whatever. You won't of course get any specific position information for Mode S anyway, but they will generally be visible for enough of the circuit so you know they are there. The signals are, however, often reliable throughout the circuit. It depends to a fair degree on the construction of each aircraft and the quality of the installation.
Best Regards
Peter
-
I could not find the messages where the breaking of the Post processor was discussed.
I have tracked it down to sentences that have no hex code or call sign. e.g.
$PFLAA,2,0,0,1022,1,,,,,,0*44
I assume this was an attempt include Mode A/C targets? If the line was changed to something like the sentence below, then it will work again.
$PFLAA,2,0,0,1022,1,ModeAC!ModeAC,,,,,0*44
Cheers
Ian
-
I think the issue is the sentences which incorporate
$PAWRT, ....
This is a hint to the post processor to indicate what data is received for the A/C
Mode-C
Mode-S
Mode-S (ES)
P3I
Flarm (from Flarm-IN)
Thx
Lee
-
Hi Lee, I think those sentences are ignored at the moment. it is $PFLAA ones without a hex!callsign that cause the issue.
I used Excel to modify just those fields by inserting abcde!abcde, then opened it in the post processor and all was good. Obviously all mode A/C aircraft will have the same ID, and location will always be level, above or below us.
Parsing of the $PAWRT will need to be read and used to modify those $PFLAA messages so that the Post Processor shows them for what they are. I guess the only options it currently has is to show max an min threat level, which is pretty meaningless.
Not really sure how PFLAA and PAWRT relate to each other. Initially I thought the hex bit paired them, and there are matches. But not sure what to do with those with no match. Is there going to be an explanation for us on the PAWRT sentence?
-
Aha,
The message without an ICAO, or callsign was specifically for SkyDemon, I need to check my information, but I recall SkyDemon got upset when given the "ICAO!REG" for a bearingless target.
Regarding the PAWRT message, this is work in progress but the intention is to provide additional hints to the post processor about the type of messages received for the given ICAO.
Format
$PAWRT,<ICAO>,<Mode-A>,<Mode-C>,<Mode-S>,<ADS-B>,<P3I>,<Flarm-IN>
the ICAO is a 6 digit hex code, each of the other fields are booleans indicating
0 - no message received
1 - message received
so for example
$PAWRT,AABBCC,0,0,0,0,1,0 // P3I received
$PAWRT,012345,0,1,1,1,1,0 // Mode-C, Mode-S, ADS-B & P3I received
$PAWRT,404040,0,0,0,0,0,1 // Flarm-IN received
thx
Lee
-
Hi Lee, I was thinking that the post processor filled in the blanks when it read the track file. After all this is a topic about the post processor :)
Understand the sentence now, but where will the Mode A/C ICAO hex code come from?
-
Understand the sentence now, but where will the Mode A/C ICAO hex code come from?
Quite!
These are the issues with Mode-C
At the moment (internal build) the ICAO is auto-generated based upon unused Codes, apparently no codes begin
0xFxxxxx
So I am allocating those, and simply using a reg of Mode-C.
I think the differing threat levels will be applied to ICAO something like
0xF00001 // level 1
0xF00002 // level 2
0xF00003 // level 3
eg Mode-C only
$PAWRT,F00001,0,1,0,0,0,0 // Mode-C
TBH, not sure how useful this is to the post-processor, but it makes the data format more complete/rigorous
Thx
Lee
-
Thanks Lee and all the best in trying to get mode A/C captured.
As far as the post processor is concerned, I don't think there is a great deal of value in trying to analyse the directionless messages. It would be nice to be able to verify the threat levels against actual range, but that is near impossible for Mode S and impossible for mode A/C. Convincing everyone to fit a PAW would be easiest :)
-
There are people who will not invest in PAW. These are the people I want to avoid so Mode C is a winner.
I have 2 new PAW's with Pi 2, I am still using an engineering version with mode C/S detection and am happy with the results.
Steve
-
Steve,
I think you misunderstood my comments. I am all for getting alerts regarding Mode A/C/S Bearing less target during flight. It is the display in the post processor that is of debatable value.
-
Is there any news when the updated Post Processor will be ready for a run with the new TRK files.....?
Kind regards
Brinsley
-
Being quickly checked by the engineering team. We'll release it tomorrow hopefully.
regards
Dave.
-
http://www.pilotawarehardware.com/dl/PawPostV2.jar
download from here....
enjoy...
-
Thanks Dave. Quick test on recent file worked fine.
-
Looks good to me too
Thank you
Brinsley
-
Just used the processor to look at a log from recent flight, am I correct in believing I had a P3i signal from 106Km !
-
I suspect a glitch or code error there. Just one ping at the distance, nothing in between. Not sure that 4F.... is a valid hex ID, perhaps one of the PAW generated ones out of the box?
Without the track log I cannot tell which.
-
I am having trouble understanding the 'track' display. These are the first and last records for aircraft 405091 :-
$PFLAA,0,-5754,17710,-488,1,405091!405091,288,,40,,8*5F
...
$PFLAA,0,-18121,-7692,147,1,405091!405091,295,,38,,8*58
I think this says that the aircraft was to the south, tracking from east to west, and becoming more southerly, all relative to my position. This tallies with the textual description "mainly south, level and east". However, the graphic display is all to the west, and mainly north. It looks as though the N-S and E-W axes have been swapped?
-
Hi Dave,
I have found another glitch, sorry :(
After a flight I was surprised to see a PAW contact missing from the post processor, yet is in the track log. I can send you the log, or part of it?
-
Yes, please do !
If it's not too big can you email it to pilotawarehardware@gmail.com please, otherwise can you Dropbox it or something similiar so that we can pick it up.
Many thanks.
-
https://dl.dropboxusercontent.com/u/57195501/2016-08-29_13-11.trk
G-CIJO is the reg
I only went out to warm the oil for an oil change, honest!!
-
For info
Checking the log from last weekend, 3 PAW contacts and was pleased to see the very good range that these were detected at:-
#401BF0# Nearest 27 to furthest 29KM
#D5EB66# Nearest 29 to furthest 30KM
#G-BWMB# Nearest 12 to furthest 32KM.
ATB Deker
-
Hi Deker,
Really good range for P3i contacts. Guess you have your antenna setup pretty much perfect. Great feedback and proves the worth of the Post Processor.
Regards
Peter
-
Hello Peter,
A very useful tool the post processor, excellent for verifying how the setup is working.
I was using the standard dipole antenna supplied with PAW sat on the dash.
Does show how far 0.5w can go.
Deker.
-
Hi Ian,
G-CIJO is my plane.
Were you flying last Monday, I routed from Sandy Bedfordshire to Gloucestershire Airport.
I was using my PAW to provide gps into my Funk transponder so would or should have ben ADSB.
Brian
-
I was Brian, in G-AWKD.
Flew west from Enstone to Gloucester and back without landing at Glos. just to get some heat into the oil before an oil change.
-
Hi
Having just flown around Europe for a few days with 2 other aircraft I thought I would have a play with the logs. I didn't have much luck with the post processor (sorry Dave) so did some analysis the hardway. Would be interested to see if I am interpreting the logs correctly:
The general gist of the command is:
Take all tracks for the trip, search for 1 specific ICAO code, only use PFLAA sentences, only use P3i sentences (#G), work out the distance from me for each sentence in KM's, and print out the number of sentences logged for each distance.
kevin@quota Tracks$ cat 2016-09-2*.trk | grep 160XXX | grep PFLAA | grep "#G" | awk -F, '{ printf("%3.0f\n", sqrt($3*$3 + $4*$4)/1000) }' | sort -n | uniq -c
7933 0
6879 1
1393 2
325 3
122 4
181 5
35 6
84 7
1 8
1 392
There are a couple of lines of data that have to be corrupted in the log here - 392km P3i range, I dont think so :)
kevin@quota Tracks$ cat 2016-09-2*.trk | grep 404XXX | grep PFLAA | grep "#G" | awk -F, '{ printf("%3.0f\n", sqrt($3*$3 + $4*$4)/1000) }' | sort -n | uniq -c
5727 0
12557 1
6846 2
3723 3
1006 4
402 5
225 6
117 7
51 8
2 9
Given that both aircraft were generally following me, and that the second (404XXX) was generally the furthest away from me - clearly 404XXX has a better antenna setup is my first conclusion.
The conclusion that is very hard to make is at point does p3i reception become unreliable - you cant see the data that I *didn't* receive - thoughts on how to show that appreciated :)
Cheers
Kev
-
Hi Kevin,
Probably being a bit thick here, but my reading of your figures is that you were only receiving PilotAware P3i signals from your colleagues from between 0 - 8, and 0 - 9 Km respectively. Am I interpreting your figures correctly?. If so, this is a much shorter range than I have experienced personally during extended testing and much shorter than the maximum ranges (in excess of 30 Kms), which we noted during operation of our Ground Station at the recent LAA Rally - bearing in mind of course that air to air detection range should in fact be higher than air to ground.
Although we have had several reports of PilotAware P3i signals being received from well over 30Kms - in purely practical terms I usually advise prospective users that P3i is extremely reliable at up to 10 Miles minimum, and often well beyond - which is significantly beyond the range of normal human visual acuity and beyond the range you appear to be reporting.
If I am reading your figures correctly, you might want to re-evaluate your antenna type/location, though to be fair you do say your colleagues were generally behind you - which is the lowest collision risk approach position (lowest closing speed = longest time to receive warning of aircraft approach) and therefore the position from where I would be least concerned at reduced contact range.
Regards
Peter
-
Hi Peter,
Correct, max distance seen (across 10 flights and 13 hours total flying time) is 8km and 9km respectively for all log entries with a #. The 3 aircraft setups are:
CTSW - with PAW on the coaming in front of me, P3I aerial as supplied directly on the unit, powered by an Anker branded cigarette lighter style adapter.
CT2K (160XXX) - with PAW Tuned Low Profile Antenna mounted just below the engine, behind the front nose wheel leg, but mounted with a piece of aluminium very close to the vertical aerial that might be causing a problem.
Eurostar (404XXX) - with PAW on the parcel shelf, P3I aerial as supplied directly on the unit, powered by a battery pack
Now generally speaking we were flying in close proximity on this trip, but the Eurostar certainly went 30 miles + away from us on his trip back home
Cheers
Kev
-
I have been trying to think about identifying points that we *didn't* receive packets,
I assume that every time I get a GPGGA I move on to a new time period (typically 1 second);
I assume that in a perfect world I should get a P3I log entry for the aircraft I am close to every new time period;
So this give us something like the below:
[kevin@quota Tracks]$ cat 2016-09-2*.trk | awk -F, '{ if ($1 == "$GPGGA") printf "."; else if ($1 == "$PFLAA" && $7 ~ "160XXX" && $7 ~ "#G") print; }' | head -3
........................................................$PFLAA,3,4,11,53,1,160XXX!#G-TOXX#,0,,0,,8*2C
.$PFLAA,3,7,8,56,1,160XXX!#G-TOXX#,0,,0,,8*12
.$PFLAA,3,8,6,56,1,160XXX!#G-TOXX#,0,,0,,8*13
We start off with no reception (whilst we wait for both units to get a GPS signal), and then get a PFLAA sentence every GPGGA time period (represented by 1 full stop).
Building from that, acknowledging that we dont need a perfect world to still give us saftey - lets assume that actually we only need a log entry once every 5 seconds;
And then lets count how many times we get a gap of more than 5 seconds in PFLAA packets for that specific aircraft across various distances between units:
kevin@quota Tracks$ cat 2016-09-2*.trk | awk -F, '{ if ($1 == "$GPGGA") printf "."; else if ($1 == "$PFLAA" && $7 ~ "160XXX" && $7 ~ "#G") printf(" %3.0f\n", sqrt($3*$3 + $4*$4)/1000 ); }' | grep -F ..... | awk '{ print $2; }' | sort -n | uniq -c
25 0
27 1
11 2
2 3
1 4
1 5
1 7
Thats about 70 times that P3I has been lost for 5 seconds or more - which includes 10 new flights and a few reboots, etc - lets call it 50 times we lost signal.
and for the other aircraft:
[kevin@quota Tracks]$ cat 2016-09-2*.trk | awk -F, '{ if ($1 == "$GPGGA") printf "."; else if ($1 == "$PFLAA" && $7 ~ "404XXX" && $7 ~ "#G") printf(" %3.0f\n", sqrt($3*$3 + $4*$4)/1000 ); }' | grep -F ..... | awk '{ print $2; }' | sort -n | uniq -c
7 0
3 1
2 2
2 3
2 4
1 6
Thats about 17 times that P3I has been lost for 5 seconds or more - which includes 10 new flights and a few reboots, etc - I think that's close to zero.
Do we think the code is accurately interpreting the log data?
Cheers
Kev
-
For completeness, the same analysis on the track logs from the Eurostar, which was generally at the rear of the formation:
kevin@quota CCTracks$ cat 2016-09-2*.trk | grep 160XXX | grep PFLAA | grep "#G" | awk -F, '{ printf("%3.0f\n", sqrt($3*$3 + $4*$4)/1000) }' | sort -n | uniq -c
5706 0
2938 1
531 2
202 3
30 4
16 5
1 111
1 17129
kevin@quota CCTracks$ cat 2016-09-2*.trk | grep 401XXX | grep PFLAA | grep "#G" | awk -F, '{ printf("%3.0f\n", sqrt($3*$3 + $4*$4)/1000) }' | sort -n | uniq -c
2610 0
4578 1
530 2
216 3
97 4
kevin@quota CCTracks$ cat 2016-09-2*.trk | awk -F, '{ if ($1 == "$GPGGA") printf "."; else if ($1 == "$PFLAA" && $7 ~ "160XXX" && $7 ~ "#G") printf(" %3.0f\n", sqrt($3*$3 + $4*$4)/1000 ); }' | grep -F ..... | awk '{ print $2; }' | sort -n | uniq -c
9 0
5 1
1 2
1 3
1 4
1 5
kevin@quota CCTracks$ cat 2016-09-2*.trk | awk -F, '{ if ($1 == "$GPGGA") printf "."; else if ($1 == "$PFLAA" && $7 ~ "401XXX" && $7 ~ "#G") printf(" %3.0f\n", sqrt($3*$3 + $4*$4)/1000 ); }' | grep -F ..... | awk '{ print $2; }' | sort -n | uniq -c
3 0
10 1
3 2
1 3
1 4
The main thing I think to note from that, is that the Eurostar lost reception from the CT2K (160XXX) far fewer times that I did, in fact well within the number of times I would expect given the number of flights it was across.
It's all a game of statistics and interpretiation :)
Cheers
Kev
-
Hi Kev
I am on a mobile device and so cannot see the command lines too well.
Just wanted to point out that the # char does not appear instantaneous on the reg
This is because the group info is sent over a number of packets.
If a packet is missed/lost, it needs a full refresh cycle again
Could this be affecting your stats ?
Thx
Lee
-
Hi Kevin,
My limited experience matches yours. With two Skyrangers, PAWs mounted on the coamings, kit antennae directly attached, contact would be lost at around 2 km or less in a stern chase. There was no problem if the antennae could 'see' each other, but we were no more than 11 km apart. Both of us got about 70 pings from another PAW equipped aircraft 60 km distant, pretty we'll on the nose, so it's all about antenna location. ISTM that we need two external antennae, one above and one below the airframe.
I have also experienced the spurious > 100 km pings, which hamper track file analysis.
Richard
-
Should I be able to load PawPostV2.jar on a Linux Mint laptop? I'm a Linux noob these days. Or point me to further advice...