1
General Discussion / Rosetta FX
« on: January 05, 2024, 01:54:21 pm »
Mid-December has come and gone! Is there any news on Rosetta FX launch and availability?
Alan
Alan
Show Posts
You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.
2
Technical Support / Re: OGN-R uplink typical range
« on: January 09, 2021, 09:04:23 am »
Chris, I'll have a better look at your track later today when I'm on the train, but I can see you had several uplinked targets apart from the glider, but oddly no groundstations displayed. I wonder if you did not have the "Display Ground Stations" box ticked in the PAW configuration?
Alan
Alan
3
Technical Support / Re: OGN-R uplink typical range
« on: January 08, 2021, 10:03:50 pm »
Chris, I would say those GPU targets were uplinked. Did you see any groundstation tower symbols in the replay? I think a tower only appear on the map if at least one beacon has been received from it during at some point during the flight. If so did none of them display green rings around the tower as you got near? This happens for a short time after each beacon packet is received.
I'd be keen to haev a look if you want. You can make your flight public on the replay site and PM me the link (or post it here) or better still just PM me me the file.
Alan
I'd be keen to haev a look if you want. You can make your flight public on the replay site and PM me the link (or post it here) or better still just PM me me the file.
Alan
4
Technical Support / Re: OGN-R uplink typical range
« on: January 08, 2021, 05:27:56 pm »However if the uplink range is poor / variable then I could be missing B) traffic completely and my PAW radar screen would only be showing me traffic from A)?
Is there any way of determining this, either in-flight or afterwards by analysing track files?
Hi Chris,
That is the absolute nub of this rather protracted bit of thread. If you download your track file from your PAW, and upload it to this tool:
https://aircrew.co.uk/playback/
then from the comfort and safety of your armchair, rather than peering at your screen in flight, you can see exactly what went on. You will see when you received beacons sent from each of the groundstations (about every 15 seconds unless the GSTN is saturated with other traffic). My caveat (also on the RVSQN) was that with the PAW software in use back in August, these GSTN beacons were filtered out from the track file the same as aircraft, so if you were not careful about how you set the filters (assuming you use them at all) then you might conclude the uplink range was less than it really was. Following that post I realised that the PAW track file now uses a different method of logging the beacons, so what I said about filtering may no longer be true. I'm hoping Lee will answer one way or the other to clear this up, since I can't check it experimentally at the moment for obvious reasons.
Alan
5
Technical Support / Re: OGN-R uplink typical range
« on: January 08, 2021, 11:28:17 am »
Lee, going back to my last question which you perhaps missed, and avoiding internal techie details if you prefer, I still think it is of interest to any user to know whether, if they replay their flight in the Aircrew tool, they will see the in-range uplinking groundstations regardless of the range filter settings?
Alan
Alan
6
Technical Support / Re: OGN-R uplink typical range
« on: January 08, 2021, 08:37:04 am »
Hi PaulSS, no it's just the display/reporting of the groundstation itself that's filtered, not the aircraft it is uplinking.
Alan
Alan
7
Technical Support / Re: OGN-R uplink typical range
« on: January 07, 2021, 07:00:09 pm »
Great, thank you. But at the moment then, with the current software version, if using the Aircrew replay tool to view the uplink range (which is really the only way a user can readily do so), will that be affected or not by the filters?
Alan
Alan
8
Technical Support / Re: OGN-R uplink typical range
« on: January 07, 2021, 05:52:51 pm »
Thanks Lee, but we may be at cross-purposes as I think you are describing filtering of aircraft? I was asking about groundstations. Back in August, we agreed (I think!) that the range and height filters also affected groundstations, so that if somebody set filters at plausible values of, say 5nm/1000feet, then groundstations outside that range would not be seen at all, not in the PAW radar, nor Skydemon nor the groundstation post-flight analysis. This would lead to very pessimistic and incorrect evaluation of uplink range.
I recently repeated that information to somebody but then realised the PAW software was changed radically in Spetember, so wondered if it is still correct? In particular I was interested in the Aircrew replay, as it seems to use the new $PALOG RF entries which may no longer be range filtered?
Hope that's clearer now.
Alan
I recently repeated that information to somebody but then realised the PAW software was changed radically in Spetember, so wondered if it is still correct? In particular I was interested in the Aircrew replay, as it seems to use the new $PALOG RF entries which may no longer be range filtered?
Hope that's clearer now.
Alan
9
Technical Support / Re: OGN-R uplink typical range
« on: January 07, 2021, 10:40:04 am »
Lee,
I have been asked about the display and reporting of groundstations being affected by the PAW height and range filters, as we discussed on this thread back in August. Is this still the case with the latest software and new log format? There are three questions really:
Do the filters affect the in-cockpit display of groundstations on PAW itself?
Do they affect the groundstation reporting to e.g. Skydemon?
Do they affect the groundstation display on the Aircrew track replay utility?
Unfortunately I can't really check it out myself at the moment!
TIA
Alan
I have been asked about the display and reporting of groundstations being affected by the PAW height and range filters, as we discussed on this thread back in August. Is this still the case with the latest software and new log format? There are three questions really:
Do the filters affect the in-cockpit display of groundstations on PAW itself?
Do they affect the groundstation reporting to e.g. Skydemon?
Do they affect the groundstation display on the Aircrew track replay utility?
Unfortunately I can't really check it out myself at the moment!
TIA
Alan
10
Technical Support / Lat/Long swapped on uplinked traffic (warning, geeky)!
« on: December 22, 2020, 12:37:43 pm »
I was doing some tests on Sunday which involved monitoring the radio traffic between PWUKTIB and my PAW, and (on later analysis) noticed the following oddity.
Here's a normal packet of uplinked FLARM data from a club glider:
TIME S ID LONG LAT ALT TRK SEQ KTS AC CS
144127 24 a9e1dd 6076933f 9bc35142 e401 d100 00000000 1900 11 7c
But here's some more data from two other aircraft:
TIME S ID LONG LAT ALT TRK SEQ KTS AC CS
144026 24 765f40 5f185242 8a1f933f f300 5301 07000000 5d00 1e c6
144458 24 dc1640 4b195242 1ceb8a3f f300 9d00 02000000 4c00 1e 90
It appears the longitude and latitude are swapped. Looking at the track file I have entries labelled "INV" at exactly these times, which I guess means invalid. Nothing appears on James's replay app. Sleuthing around a bit, it seems these were MLATed aircraft that passed close to Tibenham.
Hope this is of interest!
Alan
Here's a normal packet of uplinked FLARM data from a club glider:
TIME S ID LONG LAT ALT TRK SEQ KTS AC CS
144127 24 a9e1dd 6076933f 9bc35142 e401 d100 00000000 1900 11 7c
But here's some more data from two other aircraft:
TIME S ID LONG LAT ALT TRK SEQ KTS AC CS
144026 24 765f40 5f185242 8a1f933f f300 5301 07000000 5d00 1e c6
144458 24 dc1640 4b195242 1ceb8a3f f300 9d00 02000000 4c00 1e 90
It appears the longitude and latitude are swapped. Looking at the track file I have entries labelled "INV" at exactly these times, which I guess means invalid. Nothing appears on James's replay app. Sleuthing around a bit, it seems these were MLATed aircraft that passed close to Tibenham.
Hope this is of interest!
Alan
11
Technical Support / Incorrect time in Aircrew replay if GPS unlocks.
« on: August 28, 2020, 02:19:13 pm »
In the course of using the excellent Aircrew track analyser quite a lot recently, I came across an oddity whch is fairly obscure and does not affect the normal use of PAW but worth mentioning as it had me very confused until James and I got to the bottom of it. It's not a fault as such with PAW or James's program, but a combination of the two, which is why I mention it here. Probably both ought to be tweaked!
The visible effect was that the time displayed in the tracker at various points in the flight was not correct, and got worse as the flight progressed.
On investigation, it turns out that (I think) James only reads the actual time at the start of ther flight, and then assumes it advances by one second every time a $GPGGA messge is logged in the track file. Now as it it happens, on this flight my GPS was dropping out from time to time, mainly in steep turns, due to poor antenna positioning (I was trying something else out). It seems that when there is no GPS lock, PAW writes the GPS messages to the track file 4 times per second instead of the normal 1. This therefore causes the displayed time in the Aircrew analyser app to run fast by a factor of 4 when the GPS is unlocked.
I have checked the GPS itself and it continues to send messages only once per second at all times as expected. Also, the GPS message counter on the PAW home screen always advances at the same rate. So it is the PAW that for some reason is doing the repeat logging and I can't imagine it is intentional.
Of itself it doesn't seem a big deal but maybe needs a look at the PAW end in case it's a sign of something else not right? Also I imagine a fix at the Aircrew end would not be too hard to do.
The other thing James noticed, was that the time in the GGA messages jumped forward by exactly 3600 seconds for the first message received after GPS lock was restored. This doesn't affect the Aircrew app, or hopefully anything else, but again indicates something not quite right in this department.
Alan
The visible effect was that the time displayed in the tracker at various points in the flight was not correct, and got worse as the flight progressed.
On investigation, it turns out that (I think) James only reads the actual time at the start of ther flight, and then assumes it advances by one second every time a $GPGGA messge is logged in the track file. Now as it it happens, on this flight my GPS was dropping out from time to time, mainly in steep turns, due to poor antenna positioning (I was trying something else out). It seems that when there is no GPS lock, PAW writes the GPS messages to the track file 4 times per second instead of the normal 1. This therefore causes the displayed time in the Aircrew analyser app to run fast by a factor of 4 when the GPS is unlocked.
I have checked the GPS itself and it continues to send messages only once per second at all times as expected. Also, the GPS message counter on the PAW home screen always advances at the same rate. So it is the PAW that for some reason is doing the repeat logging and I can't imagine it is intentional.
Of itself it doesn't seem a big deal but maybe needs a look at the PAW end in case it's a sign of something else not right? Also I imagine a fix at the Aircrew end would not be too hard to do.
The other thing James noticed, was that the time in the GGA messages jumped forward by exactly 3600 seconds for the first message received after GPS lock was restored. This doesn't affect the Aircrew app, or hopefully anything else, but again indicates something not quite right in this department.
Alan
12
Technical Support / Re: OGN-R uplink typical range
« on: August 28, 2020, 01:53:35 pm »
Lee,
Thank you for that detailed reply earlier regarding the filtering out of ground stations in track logs. Unfortunately I can only agree with a little of it. Of course I sympathise with your support loading, and clearly if you can automate some of it that would be a good thing, but by depriving people of an easy way to sort out their own installation I’m not convinced you are making it any easier for yourself.
Clearly I can’t tell from your rather general description what you’re actually proposing to provide from the telemetry you’re gathering. I’m sure it will be very useful for general system performance monitoring and presumably will provide metrics like “78% of users have contact with a groundstation for 82% of the time” or “your installation scores 7 on a scale of 0 to 10” etc.
I really can’t see how this helps individuals, with all the variability of individual installations and performance of local groundstations to know what they are actually getting, and what to do about it, and I wonder how long it will be before this is publically available in an automated form.
I strongly disagree that allowing people to self-analyse is in any way difficult or undesirable. There is no need to wade through large text files as you suggest. James Roses’ fantastic track analysis tool allows you see in the simplest possible way how well an individual installation is performing in terms of range on various bearings etc. etc. I have suggested to him that it would be even better if the track colour could be changed to indicate where in the flight the uplink was working or not. What could be easier than that? I have made good progress with my own installation, on which I will report in due course, due to this tool.
I really can’t see how some online tool, especially relying on secondary data via the downlink rather the raw data in the track filter, can be any easier or better. People are either interested in knowing how well it works and fixing it, or not.
I cannot see a single good reason why the ground stations should be filtered, and so I do wonder why you are doing it? It doesn’t affect me at the moment as I am using Skydemon audio and set my filters wide, but many people will want to use PAW audio. Why deprive them of the ability to use this facility, for no positive reason?
Please reconsider before your upcomong release! I'm sure it is a trivial mod!
Kind regards,
Alan
Thank you for that detailed reply earlier regarding the filtering out of ground stations in track logs. Unfortunately I can only agree with a little of it. Of course I sympathise with your support loading, and clearly if you can automate some of it that would be a good thing, but by depriving people of an easy way to sort out their own installation I’m not convinced you are making it any easier for yourself.
Clearly I can’t tell from your rather general description what you’re actually proposing to provide from the telemetry you’re gathering. I’m sure it will be very useful for general system performance monitoring and presumably will provide metrics like “78% of users have contact with a groundstation for 82% of the time” or “your installation scores 7 on a scale of 0 to 10” etc.
I really can’t see how this helps individuals, with all the variability of individual installations and performance of local groundstations to know what they are actually getting, and what to do about it, and I wonder how long it will be before this is publically available in an automated form.
I strongly disagree that allowing people to self-analyse is in any way difficult or undesirable. There is no need to wade through large text files as you suggest. James Roses’ fantastic track analysis tool allows you see in the simplest possible way how well an individual installation is performing in terms of range on various bearings etc. etc. I have suggested to him that it would be even better if the track colour could be changed to indicate where in the flight the uplink was working or not. What could be easier than that? I have made good progress with my own installation, on which I will report in due course, due to this tool.
I really can’t see how some online tool, especially relying on secondary data via the downlink rather the raw data in the track filter, can be any easier or better. People are either interested in knowing how well it works and fixing it, or not.
I cannot see a single good reason why the ground stations should be filtered, and so I do wonder why you are doing it? It doesn’t affect me at the moment as I am using Skydemon audio and set my filters wide, but many people will want to use PAW audio. Why deprive them of the ability to use this facility, for no positive reason?
Please reconsider before your upcomong release! I'm sure it is a trivial mod!
Kind regards,
Alan
13
Technical Support / Re: OGN-R uplink typical range
« on: August 25, 2020, 12:33:26 pm »Quote
Urgh, this is Android right ?
An Android update came out which caused this - it is fixed in the release to be put out literally within a week or two.
Yes, so that's great news, although it's a 2013 Nexus 7 with a very old Android version so maybe not the same issue. Look forward to the new release.
Quote
Regarding the track file, it is not really intended as a full diagnostic tool.
We are adding lots of telemetry data in the next release to help do that across the board.
It may not be the intention, but if you did then it would be a very powerful diagnostic tool and I can't see any downside at all. How else is one to assess what's going on other than by staring at the screen during the flight? Will your new telemetry be available in detail to each user for their own aircraft or will it be for internal use for overall statistical purposes? If not then that would of course still be very interesting from a system point of view, but really serves a different purpose and is presumably dependant on the downlink. It seems quite a fraught way to achieve something that would be directly available in the log file for each user.
Quote
Obscuration plays the biggest part here which is what we have determined.
If you PM me with your flight details I can take a look at our records
Thanks, will do.
Alan
14
Technical Support / Re: OGN-R uplink typical range
« on: August 24, 2020, 09:52:56 pm »
JC: Super, thanks, so all as expected on the power front.
On the filtering issue, I had a test flight today (actually 2 flights, as when I tried to change the config in the air the dreaded "Http: Get request method not supported" struck again. I had a lot of trouble with that initially but it seemed to have gone away).
I'm now pretty sure that:
1) Range filter settings do NOT affect the label showing the number of OGN-R stations displayed.
2) They DO control whether ground stations are displayed on the RADAR screen.
3) They DO control whether the ground station uplink status is recorded in the track file and hence are available for post-flight analysis.
I think (1) is obviously fine, (2) is a matter of taste, but (3) is surely not what's wanted?
Despite not changing anything, I do now seem to be getting better range performance, although it is inconsistent. I'll write more later when I have gathered more data.
Alan
On the filtering issue, I had a test flight today (actually 2 flights, as when I tried to change the config in the air the dreaded "Http: Get request method not supported" struck again. I had a lot of trouble with that initially but it seemed to have gone away).
I'm now pretty sure that:
1) Range filter settings do NOT affect the label showing the number of OGN-R stations displayed.
2) They DO control whether ground stations are displayed on the RADAR screen.
3) They DO control whether the ground station uplink status is recorded in the track file and hence are available for post-flight analysis.
I think (1) is obviously fine, (2) is a matter of taste, but (3) is surely not what's wanted?
Despite not changing anything, I do now seem to be getting better range performance, although it is inconsistent. I'll write more later when I have gathered more data.
Alan
15
Technical Support / Re: OGN-R uplink typical range
« on: August 23, 2020, 10:02:54 am »
JC: I agree with your numbers and conclusion, thank you. My trusty HP8594E has not been calibrated for a very long time, but it gives the "expected" answers for my FLARM, SoftRF and various balloon telemetry units I've built myself so I am pretty confident in it. Be good to get confirmation though, if you get a chance.
Lee: the question I was referring to was about the filtering of groundstations by range/height difference in the log. My filters are set very broad at the moment and I appear to see a log entry for every packet received from groundstations which is surely all that is required to fully analyse the performance of my own equipment? What am I missing? However if the groundstations are filtered, as I suspect, then that would explain why I see such poor uplink results on other peoples' logs and why I suggested they should not be filtered.
Alan
Lee: the question I was referring to was about the filtering of groundstations by range/height difference in the log. My filters are set very broad at the moment and I appear to see a log entry for every packet received from groundstations which is surely all that is required to fully analyse the performance of my own equipment? What am I missing? However if the groundstations are filtered, as I suspect, then that would explain why I see such poor uplink results on other peoples' logs and why I suggested they should not be filtered.
Alan