AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: neroon79 on May 28, 2011, 07:05:35 AM
-
Did anyone else notice this misbehaviour?
(http://i192.photobucket.com/albums/z157/neroon79/Airnav%20RADAR%20Box/28-05-201108-24-56CL60TACTICALBug.jpg)
The following "highlighted" AC is in the DataBase as stated below, but in my flights list it is shown as Airline: US - Air Force and Type: Tactical Code - Various F15 Aircraft
3F4AFC TACTICAL CL60 Tactical Code - Various CL60 Aircraft Germany - Air Force N/A
Is this a known issue or one that wasn't noticed yet. What's the problem here?
-
Yes that is a known issue for Airnav that was reported to them in February, and reinforced with extensive research for them in March.
The panel next to the photo is not tied to hex but to registration. It just displays the first occasion of TACTICAL it finds in the Navdata (an F15 code) regardless what is against the actual hex in the Navdata. You will find the same thing on duplicated military serials. For example the US Coastguard Gulfstream with serial 01 will always display next to the photo as the SAC C-17 serial 01.
It is of course for airnav support to let us know, how much longer these reported bugs will continue to endure before the patch is released to cure them.
-
I would like to think that this and other known bugs will be covered in the next Radarbox version as we were told nothing could be done with the cuurent version as complete re-write of the software was required.
Alan
-
Maybe the database update team should stop using TACTICAL as the registration until Airnav change the way the photo/details are looked up in the database.
-
Do you mean just leave the registration details blank like it used to be. If we left the registration blank there would be lots of threads started requesting the identity of the aircraft as its registration is blank , heads we win tails we loose scenario.
Its one of those ones that we as updaters cannot win on but at least the myflights is showing correctly in that it is a CL60 of the German Air Force and as they always use tactical codes which change on every flight hence we have no idea which one it is.
At least it is not difficult to identify which part is giving out the incorrect info as the aircraft in question is giving out a German hex and is using a GAF callsign which to most people would give them an idea it is not USAF.
Alan
-
Alan
You can type fater than me!!
I was mid reply when yours winged in
Couldn't agree more with your comments
By removing TACTICAL, we would be reverting to the dark days of a year or so ago,prior to when the team initially tackled this unresolved issue
As ever keep up the good work guys - it's incredible to see the continued efforts of the team,and the massive improvement in the standard of information that we the users are now party to.
It's a great pity that these minor issues,and the ongoing photo issue still detracts from the overall enjoyment of our hobby.
Rgds
Rich
-
I must be unusual in that I dont let these minor annoyances become a distraction. I only want to be able identify which aircraft is making that trail in the sky or identify for me the aircraft which has just flown overhead and if it lets me know that information that is more then enough for me.
I dount that there is any software out there which ticks all the right boxes for everyone and is completely bug free but as I stated earlier hopefully this and other minor annoyances will be written out in the upcoming new version of Radarbox.
Alan
-
Do you mean just leave the registration details blank like it used to be.
No, I definately don't mean that. As I've said in the past, much better to use the ModeS hex code instead of "TACTICAL" for aircraft where the registration is unknown.. I use T-xxxxxx, where xxxxxx is the hex code. That ensures a unique value in the the AR field, and ensures that the photo/details data always matches the aircraft.
I just don't understand why anyone chose to use a non-unique value like "TACTICAL" when we know that causes problems.
-
Thanks Chris, I havent seen the use of TACTICAL discussed previously but I have only been on here for 2 years. I will discuss this with my fellow updaters and to assist in advising users that it is a TACTICAL code we could insert in the CO tab like we do with miscodes otherwise some may possibly think the info in the AR is a serial.
Alan
-
It was a decision taken by the team,back when I was a member.
To be honest,at the outset ,we got fed up of the lethargy from the forum/user community when asking for guidance and concensus of opinion.
To move the whole project forward, decisions had to be taken, which may not ultimately be to the liking of every individual!
If people want to display things differently, then that's their choice,but I don't think it's hard to understand why the choice was made - after all,we're talking about a handful of enthusiasts here, dealing with what at the time was a gargantuan problem.
At the time,this was a sensible decision to take given the more obvious issues that needed to be dealt with
What are we gaining by not using TACTICAL, when we know that the hex code is passed around between airframes on a frequent basis??
If we don't know the identity,we don't know the identity - simple!
Displaying the hex code in this field,only serves to duplicate the info on the screen, and given that it's the registration that governs selection of pictures to the majority of users, we're gaining little?
-
Also the problem should disappear with the next version, hopefully.
Alan
-
To be honest,at the outset ,we got fed up of the lethargy from the forum/user community when asking for guidance and concensus of opinion.
Sorry I couldn't participate at the time, I was not available. Doesn't mean we can't correct it now.
If we don't know the identity,we don't know the identity - simple!
Okay, but if you don't know the identity, then don't put things like "Germany - Air Force" and "Various CL60 Aircraft" against a registration of "TACTICAL" when not all the aircraft in the database with AR=TACTICAL are CL60s in the GAF.
I'll carry on using T-xxxxxx in my database. The few cases where the hex code is passed around between airframes is easily dealt with by keeping the AC, AT, and AN fields generic to the airframes that share that hex code. It's very rare for the German and US airforces to share the same hex code!!
Attached is the SQL to replace the current "TACTICAL" entries in the aircraft table to "T-xxxxxx" registrations.
(http://farm4.static.flickr.com/3546/5768355044_b91c4ca091_m_d.jpg) (http://www.flickr.com/photos/tarbat/5768355044/sizes/o/in/photostream/)
http://www.flickr.com/photos/tarbat/5768355044/sizes/o/in/photostream/
-
Hi guys
This is another frustration that will hopefully be resolved in a new issue but even more of a frustration is not knowing how long we will have to wait for it.
Every time a new user finds one of these anomalies someone has to explain on the forum.
Come Airnav stop hiding behind the 'we don't want to let the opposition know what we are doing' and 'the development of other products have priority' please give us firm commitment as to when we can expect a new issue.
Thanks hopefully
Brian
-
Tarbat
The other reason TACTICAL was chosen is that it is used on the SBS system and is recognised by the log parser system on the multi-platform Mode S Yahoo group.
I am not sure T-3F49F0 would pass the passer. This may cause the exeptions on the Yahoo group parser to increase hugely for Radarbox logs:
Here are two from last nights parser where people entered their own versions US-MIL and LN-F15 in the registration field:
B1A425 => mismatch restated: found as TACTICAL F15; you indicated LN-F15 <= B1A425
AE070B => mismatch restated: found as TACTICAL F15 ; you indicated US-MIL <= AE070B
Without Kai-Jens adding them all the T-Hex codes you suggest as allowed codes on the parser, your suggestion may well come out as on all uploaded Airnav logs as:
AE070B => mismatch restated: found as TACTICAL F15 ; you indicated T-AE07 <= AE070B
The bug with the data next to the photo that Airnav can fix is not only with tactical and ground stations, but also with a few military aircraft. We have multiple military aircraft on the navdata for the following military registrations - to name a few
01 GLF5 & C17
02 CL60 and C17
016 GLF5 & C295
017 GLF5 & C295
018 GLF5 & C295
020 C295 and PC12
045 CN35 and YK40
etc - These are all affected by the same bug
I don't think us modifying our behaviour to fit a bug is the correct way round. Airnav of course did this when they launched 4.03 without fixing the ICAO bug and named the 3D models to fit the bug affected ICAO codes like A380, A300 etc, such that when our team gave the correct A388, A30B designation in the Navdata, everyones 3D models for these types did not display! The bug should always be patched as a priority not worked round.
Airnav know the solution - to put the data next to the photo as tied to hex not registration. Despite knowing of the problem for some time, it appears they have chosen that development of other products takes priority over the required patch. That is their decision and we must continue to wait for them to action the patch for all the bugs within the work schedule they have.
Regards ACW367
-
ACW367,
I understand all the arguments against using T-xxxxxx for these so-called tactical registrations. But:
The other reason TACTICAL was chosen is that it is used on the SBS system and is recognised by the log parser system on the multi-platform Mode S Yahoo group.
The vast majority of SBS users get their registration details from GAS, which does NOT use the words TACTICAL in any registrations. So, where did this use of TACTICAL in the Yahoo group come from - not SBS users. It's a flawed solution. We should be looking for a solution that works for all Radarbox users, not just the few that contribute to a SBS Yahoo group.
The bug with the data next to the photo that Airnav can fix is not only with tactical and ground stations, but also with a few military aircraft.
Sure, the 449 <GND> registrations, 9 "VARIOUS", and other duplicates are a problem that can be fixed by appending a unique differentiator or sequence number. For example, 01(GLF5) and 01(C17), 02(CL60) and 02(C17), etc. I've fixed my own database in this way, and it works.
I'm just trying to get a pragmatic solution in place that fixes the problem for everyone, without having to wait for Airnav to make a software fix sometime in the future. Simple changes to the database could FIX this problem within a matter of days, rather than the days/months/years (select your own guess) it will take waiting for a software change. Ultimately it doesn't bother me, I'm able to change my own database to make it work correctly with Radarbox.
-
ACW367,
I understand all the arguments against using T-xxxxxx for these so-called tactical registrations. But:
The vast majority of SBS users get their registration details from GAS, which does NOT use the words TACTICAL in any registrations. So, where did this use of TACTICAL in the Yahoo group come from - not SBS users. It's a flawed solution. We should be looking for a solution that works for all Radarbox users, not just the few that contribute to a SBS Yahoo group.
Tarbat - don't know which it comes from for other systems and it is kind of not important in the points I am making. All I know is TACTICAL, <GND> do not trigger the parser. Individually tailored registration IDs would. The opinions that have been expressed in this thread do show that the use of TACTICAL does work for the majority of users and are happy with how it is presented in their Mylogs and reporters. However, they are campaigning alongside us updaters to get the bug fixed so they can then also become happy with how the photo and data next to it gets presented.
Sure, the 449 <GND> registrations, 9 "VARIOUS", and other duplicates are a problem that can be fixed by appending a unique differentiator or sequence number. For example, 01(GLF5) and 01(C17), 02(CL60) and 02(C17), etc. I've fixed my own database in this way, and it works.
I'm just trying to get a pragmatic solution in place that fixes the problem for everyone, without having to wait for Airnav to make a software fix sometime in the future. Simple changes to the database could FIX this problem within a matter of days, rather than the days/months/years (select your own guess) it will take waiting for a software change. Ultimately it doesn't bother me, I'm able to change my own database to make it work correctly with Radarbox.
You are not suggesting a fix, you are suggesting a workround. That was my point, doing a workaround to bypass a bug, and then having to redo that work back to the old way when the bug gets (eventually) fixed, is completely the wrong way to do things.
The only thing that is required is an Airnav bug patch. Whether it is in a new version or a standalone patch doesn't matter, but it is very long overdue.
At the moment the myflights and reporter produce exactly what is in our Navdata. The data next to the picture (and the picture itself) ignores what is in the navdata for the hex due to bugs. If airnav fix those longstanding bugs, problem is solved.
For example, 01(GLF5) and 01(C17), 02(CL60) and 02(C17), etc. I've fixed my own database in this way, and it works.
You have not fixed your database, you have amended your database to work around a bug. When the bug is fixed you will need to un-amend all those records. Again this method would foul the parser, so are you suggesting that those users that do then upload logs to the Yahoo group users then use another seperate work around for their reporter logs as they upload them to the mode S group.
I understand all the arguments against using T-xxxxxx for these so-called tactical registrations.
You say "so-called" tactical registrations. The ICAO docs on 24-bit codes enshrines that while civil aircraft must have a unique hex, to aid national security States can allocate serial batches for tactical allocation to military and government aircraft - hence the widespread usage of the phrase tactical. It comes from ICAO descriptions. I know quite alot about this as I work for the military and have access to the CAA docs that detail the tactical usage policy. I have also in the past seen copies of the US 3rd AF database that allocates this type of code on a rotational basis to USAF Squadrons in Europe. The CAA has allocated the entire 43D*** serial batch to the MOD for exactly this purpose, thankfully apart from occasional exercises the UK military have not started making extensive usage of them yet.
--
Hope this all helps explain and soon?? Airnav will produce the overdue bug fix (as you say insert your own day/month/year). They are working to whatever timescales they are working to, and we are not privy to them. All we can do is keep asserting how important their implementation is to our user experience and how these frustrations make their product less attractive to use (or recommend to others).
Collectively that is still being done, lets keep up the pressure.
-
You have not fixed your database, you have amended your database to work around a bug. When the bug is fixed you will need to un-amend all those records.
I don't understand why I will "need to un-amend" anything. The fix I've applied will continue to work okay even if Airnav do change how the aircraft details are displayed.