-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICAO with lowercase letters enters sqb database file #95
Comments
The database writer only saves one feed. What is the format of the feed that is being recorded? The database writer plugin would filter those tilde ICAOs out. That filtering code has been in there since at least November 2016 - probably earlier than that, I think Nov 2016 was just when I made it a bit quicker. Was this SQB pre-populated? Were the tilde codes in the original version of the database? Likewise were the lower-case ICAO24s also in there? Also, is there anything else writing to the SQB file? The plugin doesn't convert the ICAO24 to upper-case before it writes it, but I think it should be getting converted to upper-case before it gets as far as the plugin. Not 100% sure, I'd need to go through the code. If the feed format is raw then it will definitely be in upper-case before it makes it as far as the plugin. If the feed format is cooked then there's a possibility that the plugin is seeing the messages from the feed in their original state, in which case if the ICAOs are in lower-case on the feed then they might also be written in lower-case. If that's happening then that wouldn't be ideal, the rest of VRS only deals in upper-case ICAOs and BaseStation.SQB has a schema that is mostly case-sensitive. If that is happening then it would be good to know the format of the feed that's being recorded please. But I think the fact that you have those tilde codes points at something else writing to the file, I can't see how they could have made it through the database writer plugin. |
Hi, Only VRS (and my manual db updates) writes to the SQB. It has been in use by various versions of VRS since 2014 or something like that. But those records were created in the last 2-3 years, and certainly not imported from any other system. The writer uses the combined feed of all receivers, varying formats, raw, basestation & json, so it is certainly "cooked". I would suggest that the lower-case (and maybe the tildes) are entering through a json-format receiver, we are using our own json feed clients into VRS to save bandwidth, and while I have written a converter to upper-case in that feed client, it may have a bug, or something slipping through. Anyway, it would be good to have some checking on the input side, because a faulty feed could make a lot of damage to the database. Tilde-starting ICAOs are also common in the dumo json output unless we opt out of them from FA for example. Maybe this could point you in the right direction, happy to help with any debugging. |
Such HEX was issued by FlightFeeder from flightaware. In this way, they hid secret and military aircraft from being shown in the VRS in the on-line MLAT mode. |
@marcus-aa Sorry for the delay. I'm currently (slowly) porting the BaseStation database code to .NET Core and I noticed in there that one of the functions that gets used to create aircraft records will let lower-case ICAOs through to the database if it gets presented with one. I've fixed that issue in v2 (a6e099e), v3 (139a2e8) and the upcoming .NET Core (7b3cf17) versions but I've not deployed anything yet. |
In some cases this can happen, not sure how or why.
The text was updated successfully, but these errors were encountered: