PilotAware
British Forum => OGN-R PilotAware => Topic started by: Admin on January 25, 2018, 05:27:24 pm
-
Hi All
I wanted to open a discussion about the constraints for transmission from the OGN-R stations
There are 2 aspects which we need to consider:-
- legal requirement for broadcast (as per ISM EN300/220 Band G)
- useful information for broadcast (what we decide)
The legal requirements are clearly not up for discussion, and as part of the S/W I will monitor the transmission of data from the OGN-R, and ensure we do not bust the duty cycle restrictions - thats easy, and is implemented today
The best case (practical) range you can expect to get from an OGN-R transmission is 30km
but what is useful for re-broadcast, there are 2 parameters to consider:-
1. Traffic Proximity Range
This refers to when to uplink traffic over the OGN-R. So in other words if Glider G1 is within (TPR) km of PAW P1
transmit information about G1 over the PAW Frequency
2. Station Proximity Range
Only transmit data for (any) Glider Traffic when PAW traffic is within (SPR) km of the station
So for an Active OGN-R transmission to occur both TPR and SPR must be satisfied.
An Active transmission is where an OGN-R transmission occured because TPR and SPR were satisfied for a given PAW equiped aircraft, others may still receive those broadcasts 'Passively'
We still have not decided numbers for TPR and SPR and wanted to discuss this with forum members,
We need to be within certain constraints legally (and these are adhered to in software), but in a perfect scenario what should we consider for TPR and SPR ?
My initial thoughts are as follows
1. Traffic Proximity Range = 5km
2. Station Proximity Range = 30km
These would be for minimum conditions, the legal requirements of duty cycle may bear down on these further.
Up for discussion ...
Thx
Lee
-
Hi Lee,
I think we’ve got used to a somewhat greater TPR than 5km (3 miles). A 90kt machine will cover this distance in 1.8mins, and this could halve if the glider/contact is flying at the same speed directly toward you. Perhaps we should consider RV speeds here.
I would be happier with a TPR of 10km, if possible and would give better forewarning of glider hotspots.
Thx,
Chris
-
Lee,
I concur with Chris. 5Km is pretty close and doesn't give much leeway to allow for poor or intermittent signals. A TPR of 10Km would be much safer, as we need to give sufficient warning to allow PAW pilots to adjust our track to avoid the gliders (especially if there is a concentration around a hotspot), as unless they are also running PAW won't even be aware of our presence and in any case we are obliged to give way to them. The proposal otherwise sounds good.
Regards
Peter
-
I agree with Chris and Pete, 5km is to close. 10km I would accept.
Am I right in thinking that SPR could be reduced if the density of OGN-R stations was high enough? And would it be to much hassle to taylor it station by station, so that high density areas can have a reduced SPR?
-
I'm going to support Lee's original numbers: doubling the TPR from 5km to 10km quadruples the amount of data, making a data rate reduction much more likely. I also challenge anyone to visually acquire a glider at 10km - even at 3km they are nearly invisible in my experience, so 5km gives plenty of notice even at RV speeds.
My only concern is around missed transmissions, and for that reason is prefer the data to be repeated as fast as possible within the legal limits.
-
I tend to agree that 5km is too little - I don't think it allows for much planning time, even assuming the PAW output is frequently in the pilot's scan. Other things being equal, 10km is better.
Maybe there's an algorithm where if it gets busy, the traffic further away is dropped first.
Paul
-
...Maybe there's an algorithm where if it gets busy, the traffic further away is dropped first.
In fact, this is exactly the way it works right now.
The OGN-R creates a prioritized list of what it wants to send - based upon the individual TPR's, then it sends as much data as it should legally fill, in reality, it is constrained to be much less than the legal requirement.
I had a TODO, which was to consider rotating the list so for example, lets say we had 20 critical aircraft we wished to transmit, but we could only fit 10 into the available bandwidth, then should we rotate the list on the second iteration so the repeat interval per aircraft reduces, but all the important data has the opportunity to be sent, but at a slower rate.
Something to consider
Thx
Lee
-
.........In fact, this is exactly the way it works right now. The OGN-R creates a prioritized list of what it wants to send - based upon the individual TPR's, then it sends as much data as it should legally fill, in reality, it is constrained to be much less than the legal requirement.
I had a TODO, which was to consider rotating the list so for example, lets say we had 20 critical aircraft we wished to transmit, but we could only fit 10 into the available bandwidth, then should we rotate the list on the second iteration so the repeat interval per aircraft reduces, but all the important data has the opportunity to be sent, but at a slower rate.
Something to consider
Thx
Lee
Lee, This sounds like the way to go. Certainly better than ‘over restricting’ (IMO) the TPR to 5Km. I’m not disagreeing in any way with Mike about the difficulty in seeing aircraft (especially gliders or fast moving Tucanos) at longer range, but that is exactly why we need PAW / OGN-R.
Regards
Peter
-
Thanks Lee. Interesting thread.
I would rather see the full (10%) duty cycle utilised but where it is likely to be exceeded then prioritise for those closest radius to the ground station. My thinking is that I would rather be getting a longer general view of what is about ahead of me to improve situational awareness as well as the alerts for immediate attention. If OGN-R is normally throttled to only give foreshortened range data it means one has to keep looking down to get an update rather than look out. Worse it may create more gaps between stations where we currently already have poor coverage. There is an inherent assumption in this that one is listening to the closest base station but for some without the benefit of a decent external aerial systems in the plane, the poor placement of the internal aerials means that reception is often patchy; somewhat directional and not necessarily close-by. At the moment at PWRADLEY I'm seeing relatively low utilisation (frequent Benson traffic) although when a swarm of gliders comes over in the summer it all gets more active. In the plane I have benefited from OGN-R transmissions that have highlighted gliders that are in my immediate vicinity and been glad of the warning. Am I right in thinking that two base stations close to each other will tend to transmit over each other or is there a collision detect process built in to the transceiver to limit this?
Keep up the good work.
Thx Chris
-
Thanks Lee. Interesting thread.
I would rather see the full (10%) duty cycle utilised but where it is likely to be exceeded then prioritise for those closest radius to the ground station
Hmm, interesting thought
the difficulty here is deciding the tradeoff, which is more important
TPR=5 SPR=10
or
TPR=10 SPR=5
I am sure you get my point, what is the intersect
My thinking is that I would rather be getting a longer general view of what is about ahead of me to improve situational awareness as well as the alerts for immediate attention. If OGN-R is normally throttled to only give foreshortened range data it means one has to keep looking down to get an update rather than look out.
agreed, if you are not using any kind of audio connection
... Am I right in thinking that two base stations close to each other will tend to transmit over each other or is there a collision detect process built in to the transceiver to limit this?
Yes they will overlap, and in a non-deterministic manner - there is no synchronisation, but measures are taken to randomise an element of the interval periods so that transmission overlay (when encountered) is not repeated
thx
Lee
-
Am I right in thinking that SPR could be reduced if the density of OGN-R stations was high enough? And would it be to much hassle to taylor it station by station, so that high density areas can have a reduced SPR?
The SPR could be made a static configuration option in the installation, but I have a far more cunning plan to make it dynamic ;)
All of the stations talk to the central APRS servers, and I run a Client Admin Application to see what they are saying here is a cut down example output of my data that just captures the S/W version each station is running, and at what time it last reported to the servers
1 PWAldersh (Fri 26 Jan 17:20:48 GMT 2018)
2 PWBalerno (Fri 26 Jan 17:23:23 GMT 2018)
3 PWBidford (Fri 26 Jan 17:21:22 GMT 2018)
4 PWBurn (Fri 26 Jan 17:22:09 GMT 2018)
5 PWDeanlan (Fri 26 Jan 17:23:55 GMT 2018)
6 PWEGBKE (Fri 26 Jan 17:21:18 GMT 2018)
7 PWEGBT (Fri 26 Jan 17:22:23 GMT 2018)
8 PWEGBW (Fri 26 Jan 17:21:00 GMT 2018)
9 PWEGTU (Fri 26 Jan 17:22:33 GMT 2018) v20171114 OGN-R/PilotAware
10 PWEverton (Fri 26 Jan 17:18:27 GMT 2018)
11 PWfenland (Fri 26 Jan 17:20:16 GMT 2018) v20171114 OGN-R/PilotAware
12 PWGuildfo (Fri 26 Jan 17:20:59 GMT 2018) v20170918 OGN-R/PilotAware
13 PWHusBos (Fri 26 Jan 17:23:18 GMT 2018)
14 PWKingsto (Fri 26 Jan 17:24:02 GMT 2018)
15 PWLinton (Fri 26 Jan 17:20:15 GMT 2018)
16 PWMynd (Fri 26 Jan 17:24:36 GMT 2018) v20171114 OGN-R/PilotAware
17 PWNewbury (Fri 26 Jan 17:24:11 GMT 2018) v20170918 OGN-R/PilotAware
18 PWOrwell (Fri 26 Jan 17:20:14 GMT 2018) v20171114 OGN-R/PilotAware
19 PWOrwell2 (Fri 26 Jan 17:22:11 GMT 2018) v20170918 OGN-R/PilotAware
20 PWRadley (Fri 26 Jan 17:23:14 GMT 2018) v20170918 OGN-R/PilotAware
21 PWRedhill (Fri 26 Jan 17:24:44 GMT 2018)
22 PWSALTBY (Fri 26 Jan 17:20:46 GMT 2018) v20170918 OGN-R/PilotAware
23 PWSaxonda (Fri 26 Jan 17:22:21 GMT 2018)
24 PWStoke (Fri 26 Jan 17:23:50 GMT 2018)
25 PWTatenhi (Fri 26 Jan 17:24:45 GMT 2018) v20171114 OGN-R/PilotAware
26 PWThame (Fri 26 Jan 17:22:38 GMT 2018)
27 PWTopclif (Fri 26 Jan 17:23:34 GMT 2018)
28 PWukBER (Fri 26 Jan 17:21:10 GMT 2018) v20171114 OGN-R/PilotAware
29 PWUKEDG (Fri 26 Jan 17:20:45 GMT 2018)
30 PWUKGRL (Fri 26 Jan 17:20:16 GMT 2018) v20171114 OGN-R/PilotAware
31 PWUKKIR (Fri 26 Jan 17:24:21 GMT 2018) v20170918 OGN-R/PilotAware
32 PWUKLSW (Fri 26 Jan 17:21:50 GMT 2018) v20170918 OGN-R/PilotAware
33 PWUKmil (Fri 26 Jan 17:24:36 GMT 2018) v20170918 OGN-R/PilotAware
34 PWUKPOC (Fri 26 Jan 17:22:50 GMT 2018)
35 PWWilmcot (Fri 26 Jan 17:24:34 GMT 2018) v20171114 OGN-R/PilotAware
You will see from this listing, a number of servers are running old releases which did not report their installation software release (which we will talk about at another time), more importantly, additional to this information (but not shown here), I have the following data reported for each OGN-R station
- GPS Location
- All Received PAW Traffic
So it doesn't take a genius to realise that we can deduce when the stations are overlaying each other, and can therefore decide that the SPR should be adjusted, in simple terms this adjustment could be a radial, or it could in fact be a complete bounding box - now that is a very powerful concept, because now we could have a network which dynamically reconfigures itself based upon data received from the OGN-R stations in the network, so if a station goes down, the bounding boxes can be altered accordingly to compensate for the changes
By the way in case it wasn't obvious, the communication through the APRS is bidirectional, so in other words, it would work like this
- The OGN-R stations report information to the APRS servers (which in turn relays to the Client Admin Application - as shown above)
- The Client Admin Application decides the footprints for the transmit of the OGN-R stations
- The Client Admin Application sends data to the OGN-R stations to reconfigure the entire network
Of course the above is only really important once we have significant overlap, but nonetheless, it is an important feature to have in your backpocket, in order to control the network effectively.
One thing we have not yet fully publicised, but I am sure people will start to realise, is the ability to route between the OGN-R nodes in the network, can be complemented by uplinks/downlinks over the P3I RF, for those of you who ever looked at the P3I protocol, there is a small part of the message format for slow speed messaging.
So in effect we can control the entire network of OGN-R stations,
We can pass messages between nodes in the network, and we can send/receive messages over the air.
Not particularly interesting for GA, but invaluable to .... I don't know, maybe a UAV which operates outside of line of sight .....
(think bubbles start to appear ...)
Thx
Lee
-
I like cunning plans :)
-
So do I, especially when I don't understand them but know they're in safe hands!
-
So you could send a message such as "Come in number 9, your time is up." ? Do you think Sky Demon would support it? :o ;D
-
CPDLC. Be like being back at work >:(
-
The SPR could be made a static configuration option in the installation, but I have a far more cunning plan to make it dynamic
I think this is an interesting idea. But I think we need to think a little about the real world use cases. A couple of thoughts:
1. Most Flarm and PAW installations are far from perfect (ie external antennas with good 360 degree views). Coverage can be very directional. I see this often, flying with Flarm - being able to detect another aircraft from further away than very close can be very dependent on relative orientation. The same will, I suspect, be true of PilotAware despite the higher power. The consequence of this is a given ground station may see only one of two close PAW and Flarm equipped aircraft depending on their orientation. Thus, ground stations either need to look at the output of other OGN receivers to see where the Flarm traffic is, or there needs to be significant overlap in coverage. Or both.
2. An interesting use case to consider is a gliding club running a competition. It's entirely possible to have 50-100 Flarm contacts within 10km of the club, and (especially if we start putting PAW in any gliders or tugs) one or more PAW contacts. With possibly several OGNR stations within range all doing rebroadcast. Any scheme needs to handle that gracefully.
Paul