Jump to content

Ground Radar plugin 1.4 beta 4


Juha Holopainen

Recommended Posts

Juha Holopainen

Beta 4:

Main changes from beta 3:

  • Settings added to close a specific runway for all arrivals or departures
  • Bugs fixed

 

Edited by Juha Holopainen
  • Like 1
Link to comment
Share on other sites

Ricardo Sousa (1110850)
6 hours ago, Torben Andersen said:

I'm getting this error on start:GRplugin.png.e2df31f6abcd005bbe13e27f4e81bb50.png

Any ideas?

labels aren't defined that way, for some time too, dev guide chapter 3.6.4 explains how to do them

Link to comment
Share on other sites

Bjoern Helge Smaavollan (1055999)
On 12/02/2021 at 17:49, Francesco Baiocchi said:

I can't figure out how to add the airport stand list, is it somewhere or do I have to create it from the beginning?

 

You have to fill in the "GRpluginStands.txt" with data for your airport in order for the stands list to be populated. If this is done you can open the list by going to Window --> Stands List.

0

Link to comment
Share on other sites

Bjoern Helge Smaavollan (1055999)

Yesterday a question about the Pro mode was asked, in regards to if it works or not. When I started looking into it I found that with Pro Mode on the radar raw video disappeared.

With Pro Mode off:
All aircraft corrolated right away - as normal
Radar raw video visible - as normal

With Pro Mode on:
Standby aircraft not corrolated, only Primary circle showing - as normal
Aircraft squawking "C", corrolated, square symbol - as normal
Raw video not showing at all. For neither corrolated or uncorrolated.

To my knowledge GrPlugin isn't reliant on the radars in the .ese file to display raw video, which seem correct as i get the primary symbol despite the primary radar being offline at this time.

Edited by Bjoern Helge Smaavollan

0

Link to comment
Share on other sites

Ricardo Sousa (1110850)
8 hours ago, Bjoern Helge Smaavollan said:

To my knowledge GrPlugin isn't reliant on the radars in the .ese file to display raw video

It is, you need to add a primary radar like the one below

image.thumb.png.43396c00ced40d21e3caedddcb66d863.png

image.thumb.png.009d07c38ae847259c52e5234b69f429.png

Link to comment
Share on other sites

Juha Holopainen

Currently the raw video does take into account the ESE file radar data (so if an airport has areas with buildings blocking the SMR signals, it can be modelled by creating radar holes). The primary only track symbols and labels are however displayed regardless of ESE data to avoid tracks being completely hidden.

The plan for this is to provide airport-specific settings to govern which data is shown. The options will be either to disregard EuroScope radar data, use it, or assume the data to be available even if not defined in EuroScope. There will be different settings for primary raw data, primary tracks, mode A data and mode S data. The default behavior will be to use the EuroScope data.

Link to comment
Share on other sites

Bjoern Helge Smaavollan (1055999)

Okay. 

It would be neat if you make the radar options similar to topsky radars. So we can set different blindspots for each radar, regardless of the .ese file. For instance on ENGM there will be four PSRs available, however only three are surface radars, and the last one is air surveillance. 

Would be nice to mask out the buildings and set the masks for each ground radar 😊

0

Link to comment
Share on other sites

Juha Holopainen

I don't think there's much benefit from developing a completely custom SMR signal propagation code over what can be done with radars and radar holes in the ESE file. The only real benefit from radar-specific obstacle masking would be when simulating one or more radars inoperative, and that doesn't really happen often enough to justify the amount of coding necessary. For a longer term outage, the radar holes in the ESE can be adjusted accordingly.

Link to comment
Share on other sites

Bjoern Helge Smaavollan (1055999)
On 18/02/2021 at 10:28, Juha Holopainen said:

I don't think there's much benefit from developing a completely custom SMR signal propagation code over what can be done with radars and radar holes in the ESE file. The only real benefit from radar-specific obstacle masking would be when simulating one or more radars inoperative, and that doesn't really happen often enough to justify the amount of coding necessary. For a longer term outage, the radar holes in the ESE can be adjusted accordingly.

I partly agree.

I don't know how your programming is, if it could be possible to reuse the part from topsky where you could add the NOTERRAIN or masks so that the ground radars disregard the ese holes. Because the difference would be that the air surveillance radars usually are angeled upwards, and the surface are angeled straight or a little down.

Again as the PSR in Oslo is actually blind to most of the airport. Our radar holes are based on a 10m DEM and LOS calculations in GIS. And our ground radars are now programmed like this:
RADAR2:SURF_OSL_1:N060.11.52.152:E011.04.28.884:1:801:1:0:801:1:0:801:1

Enormous cone of silence and very short range.This way the ground radars aren't looking up in the sky outside around the airport, and therefor don't show too much air picture.

Also ENGM is the only airport with ground radar and a PSR. ENZV and ENBR only have ground radars.

 

Off course if it's too much hassle to code and not reusable, we'll cope, I just based my suggestion on your post and toughts for future versions :)

0

Link to comment
Share on other sites

  • Juha Holopainen locked and unpinned this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

When visiting this site, only cookies that are strictly necessary for you to use the website is being used, unless you have provided further consent. Read more in our Privacy Policy