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.
Pages: [1]
2
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
3
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
4
Technical Support / OGN-R uplink typical range
« on: July 30, 2020, 09:08:53 pm »
Short question: up to what range should I expect to receive OGN-R uplink data?
Long version: Since I am based in rural East Anglia it can be rare to see enough PAW airborne traffic to make useful assessments, so in the past I have tried to use ground stations as a more repeatable test. I think this is probably more important anyway as the uplink is becoming the unique advantage of PAW.
Having had disappointing results last summer with internal antennas in my RV6, I decided it was time to drill a hole in my bottom and fit a proper one. My results today were a bit contradictory. In the hangar, I had intermittent contact out to 27km on a PAW target which was encouraging and gave confidence in my home-made antenna.
However, on the test flight, I didn’t seem to pick up the UKWRM OGN-R station beyond about 2 nm, which is pretty much what I found last year with the internal antenna, and clearly not a lot of use. This is based on: the appearance of the OGN-R label on the RADAR screen; the appearance of the UKWRM ground station icon on the RADAR screen; and on the reporting of MLAT traffic on the radar and in the track file (I think).
Is this a valid test? How are those indicators controlled? I believe the ground stations transmit a beacon every 15 seconds or so regardless of the detection of any nearby PAW aircraft. Is that correct and if so, is that used to drive the OGN-R flag, station ICON etc?
What else would give rise to this contradictory performance? Is it possible UKWRM is just broken? Last year I had similar results from UKTIB so I suspect not.
BTW looking at the datasheet for the PAW radio module, my calculations suggest free space range should be about 150km which seems an awful lot more than is seen in practice even air to air. Am I missing something?
Alan
PS no voltage or throttling issues!
Long version: Since I am based in rural East Anglia it can be rare to see enough PAW airborne traffic to make useful assessments, so in the past I have tried to use ground stations as a more repeatable test. I think this is probably more important anyway as the uplink is becoming the unique advantage of PAW.
Having had disappointing results last summer with internal antennas in my RV6, I decided it was time to drill a hole in my bottom and fit a proper one. My results today were a bit contradictory. In the hangar, I had intermittent contact out to 27km on a PAW target which was encouraging and gave confidence in my home-made antenna.
However, on the test flight, I didn’t seem to pick up the UKWRM OGN-R station beyond about 2 nm, which is pretty much what I found last year with the internal antenna, and clearly not a lot of use. This is based on: the appearance of the OGN-R label on the RADAR screen; the appearance of the UKWRM ground station icon on the RADAR screen; and on the reporting of MLAT traffic on the radar and in the track file (I think).
Is this a valid test? How are those indicators controlled? I believe the ground stations transmit a beacon every 15 seconds or so regardless of the detection of any nearby PAW aircraft. Is that correct and if so, is that used to drive the OGN-R flag, station ICON etc?
What else would give rise to this contradictory performance? Is it possible UKWRM is just broken? Last year I had similar results from UKTIB so I suspect not.
BTW looking at the datasheet for the PAW radio module, my calculations suggest free space range should be about 150km which seems an awful lot more than is seen in practice even air to air. Am I missing something?
Alan
PS no voltage or throttling issues!
5
Technical Support / Altimetry oddities
« on: January 31, 2019, 10:16:57 am »
I flew for the first time yesterday with my PAW classic and was a bit puzzled by the altitude logging in the track file. I wonder if somebody can help me understand what's going on? See the attached spreadsheet data. The $GPGGA columns are the MSA altitude from the corresponding records, in meters and then converted to feet for comparison with the figure from the $PGRMZ records, also in feet. I presume the $GPGGA records are just copies of the GPS, and the PGRMZ seems to be calculated from the onboard pressure transducer. The remaining columns are the calculated altitude difference, the corresponding pressure difference using 30 ft / mb, and finally the back-calculated QNH.
The first line is on the ground and everything here is perfect - the airfield height is 246ft, matching very closely the GPS altitude, and the calculated QNH is exactly as given by local ATC.
However as I climb the altitude difference changes drastically and in proportion to height. Obviously this is not going to match exactly due to the various altimetry subtleties, but a discrepancy of over 200 feet in 2000 feet seems excessive. What am I missing? My understanding is that the pressure altitude is used for collision avoidance so this seems quite important.
Alan
The first line is on the ground and everything here is perfect - the airfield height is 246ft, matching very closely the GPS altitude, and the calculated QNH is exactly as given by local ATC.
However as I climb the altitude difference changes drastically and in proportion to height. Obviously this is not going to match exactly due to the various altimetry subtleties, but a discrepancy of over 200 feet in 2000 feet seems excessive. What am I missing? My understanding is that the pressure altitude is used for collision avoidance so this seems quite important.
Alan
6
General Discussion / Is the bridge still available for self buld?
« on: September 03, 2018, 09:12:49 pm »
Sorry if this has been covered but I couldn't see anything. Do you still sell a bridge alone for self-builders? Does the original hardware store still function? It seems live and features the old bridge but it doesn't seem possible to buy one. In any event presumably one would want to buy the new one, although the difference isn't terribly clear to me?
TIA, Alan
TIA, Alan
7
General Discussion / Bridge antenna / power consumption questions
« on: May 17, 2016, 11:17:08 pm »
Am I right in thinking the bridge does not come with an antenna as it is not mentioned or shown? If so what should I get and from where?
What is the continuous power consumption of the entire unit with the various models of RaspPi? I have seen 0.6/0.7 amps mentioned, presumbly at 5v, but it is also specified that a convertor capable of 2A is required. Is this just to cope with power-on surge?
TIA, Alan
What is the continuous power consumption of the entire unit with the various models of RaspPi? I have seen 0.6/0.7 amps mentioned, presumbly at 5v, but it is also specified that a convertor capable of 2A is required. Is this just to cope with power-on surge?
TIA, Alan
Pages: [1]