Station Transmission Constraints on Re-Broadcast

[Admin]

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

[Moffrestorer]

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

[exfirepro]

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

[Ian Melville]

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?

[T67M]

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.

[PaulRuskin]

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

[Admin]

...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

[exfirepro]

.........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

[Winged_Jaguar]

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

[Admin]

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

[Admin]

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

Code: [Select]

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

[Ian Melville]

I like cunning plans 

[Mike Mold]

So do I, especially when I don't understand them but know they're in safe hands!

[Paul_Sengupta]

So you could send a message such as "Come in number 9, your time is up." ? Do you think Sky Demon would support it? 

[PaulSS]

CPDLC. Be like being back at work