Messages

16

Technical Support / Re: OGN-R uplink typical range

« on: August 22, 2020, 10:33:34 am »

Lee,

Thank you, but I would still be grateful for a answer to the question! Am I being unreasonable? Like the power question it can be determined by experiment if necessary.

Alan

17

Technical Support / Re: OGN-R uplink typical range

« on: August 22, 2020, 09:28:46 am »

OK, so the power output is a big secret! Another question:

A few people have kindly sent me track files in order to evaluate their uplink performance. One set in particular is surprising as the installation is known to have a good downlink but the uplink is apparently dire. Pending a test flight, could someone tell me whether the appearance (or not) of a ground station in the track log, and hence on the Aircrew playback, is affected by the horizontal and/or vertical filter settings for aircraft targets? Similarly, the appearance or not of tower symbols and the OGN-R label on the radar display?

If they are filtered from the log, I would suggest that they should not be, as this precludes post flight analysis.

Another suggestion: I just realised that the log doesn't seem to include the ownship ID, is that on purpose? It seems it would be handy to have.

Alan

18

Technical Support / Re: OGN-R uplink typical range

« on: August 19, 2020, 12:50:10 pm »

I'm doing various range tests, ground and air, in both directions to try to figure out why I see relatively poor performance despite what I think should be a good antenna installation. I thought I should first check my bridge is working OK. According to my test gear, mine is outputing a little over 200mW. Is this correct? I imagine it is as we should be allowing for some antenna gain to remain within the 500mW ERP limit.

TIA
Alan

19

Technical Support / Re: OGN-R uplink typical range

« on: July 31, 2020, 03:43:31 pm »

Sorry, it's a Classic. And it's secondhand so before you say anything that obviously that gives rise to a line of thought! But the fact that it has received an aircraft at 30km but can't receive a ground station at > 3km or so makes me think it's not a basket case. Also, not wishing to add further confusion, but I did dabble with the SoftRF DIY project last year with very similar results. It's this conflicting evidence that is making diagnosis difficult.

Alan

20

Technical Support / Re: OGN-R uplink typical range

« on: July 31, 2020, 02:40:21 pm »

Thank you all again.

Peter, your 70mm measured length for the PAW antenna sounds good. Mine, with a different construction, worked out at 66mm. I will have to quiz my chum on the provenance of his long ones, but I’m sure he said they came from PAW. I’ll recheck my own antenna tuning and post a couple of VNA plots later for interest.

I was working on a loss of a little under 2dB for my (perhaps temporary) RG174. But even CFL200 would be 0.6 dB so I’m probably less than 1.5 dB worse. You’d expect this to cause only a 15% loss of range so surely this is not really a major factor here? Of course the RG174 is not so well screened against interference but I don’t think this is the issue either. For test purposes I can probably reduce mine to only 30cm so will give that a go anyway to rule it out. My earlier tests using the directly mounted sleeve dipole were also similarly poor.

I was probably within 10km of PWUKWRM for 15-20 minutes. There were no GPS failures, looking at Skydemon and PAW logs. I have a mode C transponder, antenna is probably 1 m away. I’m fairly sure it isn’t affecting things since I did at one stage pinch its antenna to feed PAW for a quick test!

I see the groundstation antenna gain is +7dBi, I thought it would be more. So the uplink will be at most 3-6 dB worse off than the downlink i.e. uplink range should be at least half the downlink. Certainly not what I'm getting! I agree something is well off in my system.

Alan

21

Technical Support / Re: OGN-R uplink typical range

« on: July 31, 2020, 09:54:14 am »

Thank you Peter and Steve.

The HexID is F4406A, flight yesterday from Elmsett EGST about 16:50.

I appreciate there are many variables but I think it’s safe to say it should be better than 2nm? I imagine my setup is fairly ideal, being an external monopole on the bottom of a metal aircraft. Currently for convenience using 2m of RG174 so would expect a small reduction in performance but not the drastic result I am seeing.

I’m quite confident about the antenna as I have a VNA for tuning and which I use for other 868MHz activities. Although on a slight tangent, I did measure both the official PAW and ADSB antennas on another RV6 for comparison and found them both surprisingly over-long. The ADSB was 71.5mm compared to a standard transponder antenna at 56mm (measured from where they emerge from the metal base). I would have expected them to be the same. The PAW was 86mm which is the ideal freespace length but I would have expected less in an actual antenna.

Thank you for the pointer to the gliderradar site. I mentioned UKWRM in error yesterday, it should be PWUKWRM of course. It’s clear from the coverage maps that that PWUKWRM is a relatively poor performer compared to PWUKTIB. It’s also poor compared to UKWRM which seems odd given the much higher airborne power of PAW but perhaps this is due to the SDR receiver for UKTIB performing better than the PAW hardware receiver.

Back to the main subject, these maps are as you say air to ground and I wondered to what extent they reflect the performance in practice in the other direction? I assume the PAW base station power output is adjusted compared to a normal aircraft PAW to give the same max legal 500mW ERP allowing for the base station antenna gain? In which case, as the aircraft doesn’t have the benefit of a gain antenna, I assume the uplink performance is inevitably going to be significantly worse?

I will try to borrow another PAW for my next flight but with 30 degrees forecast today I think that will need to wait!

Alan

PS just seen Peter's later mention of OGNRange, I thought that had packed up but will take another look.

22

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!

23

Technical Support / Re: Installing 20190621 - SDFormat and Software upgrade

« on: July 21, 2019, 11:23:36 pm »

Nowhere could I find a minimum size specified for the SD card for this upgrade. The talk here is all of 8GB or more but I seem to have upgraded my old Classic 4GB successfully. Will this be OK?
TIA, Alan

24

Technical Support / Re: Altimetry oddities

« on: April 29, 2019, 12:54:47 pm »

Finding this quite an interesting topic, I've been intermittently doing some more work on altimetry. The main thing I have learned is that, not being test pilot material, it really needs two people to fly accurately enough while writing stuff down! Until that happens I don't want to publish any more data but what I have seen so far has been quite an eye opener. For example, it appears that in my RV6, accelerating from 90 to 160 kts causes the discrepancy between GPS and baro height to change by about 100 feet at 2000 feet and 130 feet at 4000 feet. What's more, and rather surprisingly, this affects both the PAW sensor and the baro instruments driven by the official static which obviously raises several questions.

Now that the temperature is more ISA-like than when I first posted, the effects due to that are not so noticeable but as summer comes on I presume they will return in the opposite sense.

When I get some presentable data I'll report further.

Alan

25

Technical Support / Re: Altimetry oddities

« on: February 05, 2019, 09:57:51 pm »

Yes, it is indeed the MPL3115 and another look at the data sheet left me no wiser about interpretation of the "temperature compensation". However I found a really good app note at:

https://www.nxp.com/files-static/sensors/doc/app_note/AN4528.pdf

which explains it really well. It seems the compensation is for the internal mechanics of the MEMS sensor, to ensure an accurate pressure measurement over a wide range of temperature, it's not to handle atmospheric deviation from ISA. The altitude readout is therefore an "indicated altitude" with reference to 1013.2mb and assuming 15 degC. Considering the intended applications for the device, it seems this raw value would be more useful than a compensated one in most cases (e.g. if you wanted to make an actual altimeter with it, you'd need to undo the temperature compensation to get the same indicated altitude that everybody else is using).

This interpretation also gives the closest match to what I saw in flight. If the readout was compensated (true) altitude then (after adjusting for QNH) it would be even further in disagreement with the GPS and (nearly identical) altimeter indicated altitude.

That still leaves the matter of the increasing error with height on my unit. It's possible to individually calibrate the sensors, overriding the factory values, but I doubt PAW does this, nor would I have thought it was necessary to do so to get much better accuracy than what I am seeing. It may yet turn out to be cabin pressure, I'll investigate further.

Alan

26

Technical Support / Re: Altimetry oddities

« on: February 05, 2019, 11:21:35 am »

I gathered some more data this weekend. This time l flew at stepped heights and the results are attached (it seems you need to log in to see them). There were various points of interest (well to me anyway).

1)   Taking Graham’s hint on the need to compensate for temperature, I corrected my altimeter reading (post-flight) accordingly (first table, column 4). Encouragingly the resulting calculated true altitude is a very good match to the GPS altitude (column 5). Whew!

2)   Next I looked the $GPRMZ data which seems to be the QNE (altitude referred to 1013mb) from the internal pressure sensor. The data sheet for the sensor is a little ambiguous as it talks of temperature compensation, but I don’t think this compensation is in the altimetry sense. So I think this is an indicated altitude, just as you would see on an altimeter. I therefore converted this to QNH by adding the appropriate offset for the day (300ft) and then calculated the difference between this and the altimeter reading. I would expect this to be small and fairly constant but in fact the PAW altitude sensor reading seems to increase too quickly – an error of about 130 feet at 3000 feet. The 1000 and 2000 foot data are a bit anomalous but maybe just noise in my data.

3)   I noticed while flying that PAW displays a QNH value on the home page. This was correct on the ground but  varied hugely during the flight. I assumed this must be back-calculated from the GPS altitude and the QNE from the pressure sensor. I also assumed the PAW cannot not know the deviation from ISA temperature. The second table shows my calculation of the QNH without temperature compensation and it matches what the PAW displayed (I only noted the QNH display at 1000 and 3000 feet). So I think my assumption is correct.

4)   Finally for fun I did the same QNH calculation with temperature compensation (table 3). This is better but still quite a bit out. This is just another effect of the (apparent) over-reading of the pressure sensor (in my case anyway).

Conclusions, based obviously on my experience only:

The displayed QNH value is not, and cannot be accurate even if the internal presusre sensor was accurate. I don’t think this is used for any other technical purpose so probably doesn’t matter hugely provided you know about it as it is confusing and obviously you wouldn’t want to be using it in flight!

My pressure sensor altitude is out by about 130 feet at 3000 feet. I suppose it’s not a lot (within tolerance I believe for certified transponder reporting) but it seems well outside the specified tolerance of these sensors and should be better. I doubt the sensor is wrong so my only other idea is cabin pressure difference. I would expect that to be dependant only on speed, which doesn’t match my data, although I didn’t actually record my airspeed. I suppose I could work that out from the log.

To do next: either find somebody with a balloon, or a mountain to take it up. The former is probably easier in Suffolk. Meantime, if anybody has a transponder with altitude display it would be interesting to hear how this compares at height with the QNE figure on the PAW homepage (it’s in the pressure sensor data).

Alan

27

Technical Support / Re: Altimtery oddities

« on: January 31, 2019, 08:34:37 pm »

Thanks, Graham.  Your first two points pretty much confirm my understanding of how it should all work, and in particular the sort of errors to be expected due to deviation from ISA. They are more than I had expected but still much less that what I saw. Assuming ground temperature of 5 degC, that's 10 less than ISA I believe, and would by your figures result in an overreading of 40 feet at 1000 feet, whereas I was seeing more like 100 feet per 1000 feet.

Regarding your third point, I think the Geoid correction is handled correctly as the GPS altitude very closely matched the airfield elevation. On the last point, I didn't fly for long at any set altitude so can't comment. Next time I'll fly some stepped heights to see how it compares to the altimeter.

Ian, I wondered about that but in that case I'd expect a fairly constant difference once I'd accelerated, but in this case it seems mainly dependent on height rather than airspeed. Actually I should probably plot the curve to see. I have used probably the same type of sensor in helium balloon trackers, and they are simply absolute pressure sensors, and in my experience very accurate. Any conversion to altitude must be done in the app.

Alan

28

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

29

General Discussion / Re: PAW ID changing when viewed via Glidertracker

« on: September 26, 2018, 05:37:09 pm »

Hi Lee,

I think we did discuss it before but maybe it wasn't wise to deal with more than topic per posting and I was wondering if it had been forgotten about! I see now that this probably doesn't explain Phil's original issue though, I was really following up on MoffRestorer's observations as they matched my own.

I'm not totally convinced this should just be ignored, even though things generally seem to work at the moment. I suppose the worst case scenario would be if a corrupted position caused a ghost aircraft to appear right in front of somebody else, like a Klingon battlecruiser uncloaking. Unlikely, but quite high impact for the person involved. More generally I can't help but feel having corrupt data floating around will sooner or later trip something up, possibly a function not yet thought of (and I believe the protocol is meant to be extensible). Flarm, for example, is used in the gliding world for automatic fleet logging and it would be a pain to have to filter out these ghosts from a PAW source.

Whatever the purely logical view, I think there is a reputational risk involved. I don't think an 8 bit CRC is really what the industry would use here, although I feel your pain at the thought of changing.

Alan
 

30

General Discussion / Re: PAW ID changing when viewed via Glidertracker

« on: September 26, 2018, 03:27:25 pm »

Is this not (one of) the issues we discussed a few weeks ago on the OGN forum, whereby corrupt packets are occasionally not detected due to the use of only a single byte checksum? At the time we were talking about occasional jumps in an aircraft's path due to corruption of (usually single) digits of latitude or longitude. But of course any part of the packet could be corrupted and I have recently noticed spurious "orphan" aircraft being left behind on a track for presumably this reason. It looks really scrappy on the tracker but the big question is whether it really matters for the primary purpose of the product? Personally I think it should be sorted if only to avoid criticism that the system has shaky foundations. This would really need the protocol modified to use a longer checksum (Flarm, I believe uses 16 bits) which would be logistically tricky with so many systems already in the field. A possible interim mitigation would be to compare consecutive messages from the same aircraft and reject implausable changes. To cope with the orphan problem, on first contact at least two messages with the same ID would be required before the new aircraft is recognised.

Alan