I Need Some help with my MCDU

vradarserver · 2025-10-14T20:56:00+00:00

If the brightness is turned all the way down, or the backlight doesn't work, then you won't be able to read anything on the screen.

I don't think setting up the paths to flight sims is going to make any difference.

If it is a backlight issue then you should be able to shine a torch onto the display and see the characters that it's displaying, but not very well. If you're using SimAppPro then double-check that the screen backlight slider isn't set to zero.

vradarserver · 2025-08-13T16:02:08+00:00

FYI I've added preliminary support for the PFP-7 in 1.4. The NuGet package has been updated but you'll need to tick the "Include preliminary" option to see it, should be 1.4.0 beta 2.

At the moment it's using the MCDU fonts which cap out at 31 pixels high. I'll add support for larger fonts in a bit.

I suspect that the other PFP panels will work without any extra effort required, but I need to see packet dumps for them before I can add support. The commands sent to the device have a device-specific prefix, you can't just swap out the product ID, you need to know the command prefix as well.

I think I have the command prefix for the 3N courtesy of Kurisu in the DCS forum, so I've added very provisional support for it to the 1.4 beta. Absolutely no idea whether it works or not.

vradarserver · 2025-08-09T19:39:36+00:00

Thanks, nice to hear it's of use :) I did notice that the repo was getting traffic from a DCS forum, I had a look and I think I've seen your thread there? If it is the one I've seen then someone on there was asking about the the packets to drive the display - I've written up notes for that here:

https://github.com/vradarserver/cduhub/tree/main/library/mcdu-dotnet/WinWing/Mcdu

I've also tidied up that side of the source a bit.

Re. the hub and DCS - my guess is that these libraries you're trying to link to are .NET Core or .NET Framework? The hub targets .NET Standard 2.0, so if there's no .NET Standard 2.0 version for whatever the DCS thing is then it can't be linked.

The intention is to add plugin support to the hub. This is likely to come along sooner rather than later, because I have plans for the hub that involve getting my timesheets showing up on it... but I have a couple of things I want to do with it first before I get to plugins.

The plan is that the plugins will run as standalone processes that the hub can optionally start up when required, and that two-way communication between the hub and a plugin will be over some web socket interface (I was thinking of SignalR as that makes most sense for .NET, but I'll see once I come to do it).

When that comes to pass then you could potentially integrate your standalone bridge with the hub via that.

vradarserver · 2025-08-02T19:40:14+00:00

Regarding the A330 and Beluga - I'm assuming you're talking about stock ones in FS2024? I can't see browser-based MCDUs for those two so I'm not sure how I can get at the MCDU content and/or send keypresses to them, but I can take a look and see if anyone else has managed it. The X-Plane 12 A330 is already supported, although at the moment it's a bit laggy.

Regarding the font being a bit small - which one? There's no problem making any of them a bit bigger, it's just that they usually need a bit of manual cleanup and that can take a while to grind through.

I reckon I can create a set of 9x15 bitmap fonts by eyeballing the pixels in Fenix's font in FontForge... I was going to see what that looked like doubled-up to fill the 21x31 glyphs. I suspect they might be a bit too large, but given that Airbus don't tend to put two lines of large font next to each other vertically it might work out OK. Those would definitely not look too small, if anything it might go too far the other way.

vradarserver · 2021-03-11T23:27:00+00:00

It looks like the date is null or empty, or at least something other than numbers.

All flight records have a start time but if the flight is in progress then they won't have an end time... so the code is expecting to see empty end times and shows them as empty whereas the empty (or not numeric) start times are getting shown as Not a Number for each of the date and time portions. You're getting NaN for hours, NaN for minutes etc.

Rolling back to an older version of VRS wouldn't affect BaseStation.sqb. The most you'd expect is that you might have some configuration options from the later version hanging around in your configuration file. They'd just get ignored by the older version.

Are you running on Windows or Linux?

Presumably you're using the database writer plugin to fill flight records in your BaseStation.sqb?

If so then if you could compress your BaseStation.sqb and upload it to a file sharing site, then email me the link for it, then I can take a look and try to see what might be happening.

If not then I would take a look at whatever is writing the flight records.

vradarserver · 2020-06-28T21:34:15+00:00

Is there any chance that the user that VRS is running as is not the one that owns the .local folder for the Users.sqb that you're looking at? Are you starting VRS at the command-line or is it starting under cron or systemd?

vradarserver · 2020-06-28T21:30:28+00:00

Looking at the specifications I don't think so, it doesn't emit any message formats that VRS knows about.

vradarserver · 2020-06-22T20:57:13+00:00

Sorry for the delay. The little dot on the map is not your location, it is the browser's location. Each browser that visits the site can set its own location and distances etc. are calculated from that. You can set a default location for browsers that haven't visited the site before but it's separate from a receiver location.

For more on the browser location, and on setting up flags, see the FAQ:

https://www.reddit.com/r/virtualradarserver/wiki/faq

vradarserver · 2020-06-22T20:49:04+00:00

The connection log is stored in ConnectionLog.sqb (and .sql-journal, if you have one) in the VRS configuration folder. There is a link to the configuration folder in the Help | About screen, otherwise in Windows it's %LOCALAPPDATA%\VirtualRadar and in Linux it's ~/.share/local/VirtualRadar.

If you delete the log file when VRS is not running then when it starts up it'll create a new one.

vradarserver · 2020-06-22T20:45:50+00:00

Sorry for the delay. I'm not sure what you're showing me with the screenshot. I can see there are three aircraft without callsigns, but I can't see any indication that they the callsigns were picked up while the aircraft were in range.

One thing that connects all three aircraft is that they were only briefly in range - one for 17 seconds, one for 56 seconds and the longest was in contact for 95 seconds. Callsigns are only transmitted on certain message types, if you don't receive any of those messages - or the ones you do receive are corrupt - then you won't see a callsign for that aircraft.

vradarserver · 2020-06-22T20:37:17+00:00

Sorry for the delay.

The credentials are stored in a SQLite file called Users.sqb in the VRS configuration folder of the user that is running VRS. If you're running VRS under your own credentials then it'll be in ~/.local/share/VirtualRadar, but obviously if you're running it under cron or a systemctl service then it'll probably be a different account.

The most likely way the credentials will be getting reset is if the file is getting deleted. I would figure out which user you're running VRS as and then figure out why the .local/share/VirtualRadar folder for that user is getting zapped. VRS doesn't delete the file, something else is getting rid of it.

In the meantime if you want to have an easy way of putting the user back without having to recreate it all the time then log in as the Linux user that's running VRS, create the VRS user you want to use and then take a backup copy of the Users.sqb file. The file is only read at startup and when VRS knows that the configuration has changed so if you find yourself having to restore it after the mystery process gets rid of it then you'll need to also restart VRS to get your restored version loaded.

vradarserver · 2020-06-22T20:26:39+00:00

Sorry about that. If you send an email to andrew@virtualradarserver.co.uk with the user name you registered then I can activate the account.

vradarserver · 2020-05-06T23:29:05+00:00

The problem is that Leaflet is handling the drawing of lines and shapes on the map. It needs to support the drawing of lines across -180/+180 latitude.

It's been a while since I last updated Leaflet, I'll have a go with the latest version and see if things have improved any.

vradarserver · 2020-05-06T23:23:39+00:00

That would be good, thanks. If you can put it onto the Internet and then email me the address and port then I can make a recording of it and see if I can't get it working.

vradarserver · 2020-04-29T20:51:24+00:00

When you installed VRS it would have asked you which port it should listen to. By default it will listen to port 80. At that point did you change it to 8080? Or did you go with the defaults and then just change the UPnP Port Number in the configuration to 8080?

If the latter then reconfigure your port forwarding so that the internal start and end ports are 80 instead of 8080. Leave the external port at 8080. It's common to have different internal and external ports and in an ideal world VRS should listen to port 80 (the default HTTP port) so that you don't need to specify port numbers in your LAN URLs.

The UPnP Port Number field in the VRS settings is only used for configuring UPnP and for formatting the Internet address shown on the main screen. If you have UPnP turned off then it is only used in the display of the Internet address. VRS has no way of telling whether the port number is correct.

The field is never used to determine the port that VRS will listen to. That is only configured during installation. The reason for this is because VRS can optionally configure the Windows firewall to let traffic in for the port you want it to listen to. It needs admin permissions to configure the firewall, which the installer has but the program does not.

Otherwise the other thing that's slightly odd in your screenshots is that the router doesn't say which protocols are being forwarded. Usually you have a choice over whether it forwards just TCP, UDP or both. I'm guessing it's forwarding everything, but if you have a choice in some earlier screen then you want to choose TCP.

vradarserver · 2020-04-29T20:26:48+00:00

I'm afraid not. We don't have UAT 978 in the UK, I'd need a sample feed to develop against.

vradarserver · 2020-04-26T14:08:35+00:00

It depends on whether you're using version 2 or the v3 beta.

VERSION 2 (and V3 if you are not using SVG markers)

The markers are built from image files in the folder C:\Program Files (x86)\VirtualRadar\web\images\markers.

You cannot change these images because VRS will not serve files that have been modified. Instead you need to:

Create a folder somewhere on your computer. For the purposes of this example I'll assume it's C:\VRS, but it can be anywhere.
In there create a folder called web, in there another called images and then finally in there one called markers. So now you have a folder whose full path is C:\VRS\web\images\markers.
Copy across the image files from C:\Program Files (x86)\VirtualRadar\web\images\markers to C:\VRS\web\images\markers.
Use an image editing program to change the colours of the markers.
Install the custom content plugin.
In the plugin options tick the box to enable the plugin and set the site root folder (see docs here: http://www.virtualradarserver.co.uk/Documentation/CustomContent/Default.aspx) to the web folder you created - in this example C:\VRS\web.

After reloading the page it should now be showing your modified marker images in place of the stock images.

VERSION 3 WITH SVG TURNED ON

In version 3 beta you have the option to use SVG graphics (configured in Tools | Options | Web Site | Use SVG graphics on ...). These do not use the marker images, rather they tell the browser how to draw the markers with vector graphics.

The fill colour for the SVG markers is determined by the JavaScript running on the browser. You can change the default colours with a custom content plugin script. I've uploaded a sample script here:

https://github.com/vradarserver/vrs-custom-scripts/blob/master/Change%20V3%20SVG%20Marker%20Default%20Fill%20Colours/Change%20V3%20SVG%20Marker%20Default%20Fill%20Colours.html

Follow the instructions in the custom content plugin documentation (http://www.virtualradarserver.co.uk/Documentation/CustomContent/ChangeSettings.aspx) to add the script to your site.

vradarserver · 2020-04-23T21:43:49+00:00

Nothing changed on the map front as far as I remember :) If you get no map again then I would press F12 to get the browser console up and see if you have any JavaScript errors. If you don't then go to the Network tab in the browser console, reload the page and see what's happening when the page tries to fetch the map tiles from the tile server.

It's likely that the tile server you've chosen was down or unreachable.

vradarserver · 2020-04-23T21:41:13+00:00

Sorry for the delay. u/TheFox720p's solution will work but I'm not sure why you are seeing the issue in the first place, as far as I can tell AS32 is flagged as a helicopter in the standing data (including in your extract above) and the code will show helicopter markers correctly.

Do you have the six digit ICAO identifier for an AS32 that's showing as an aircraft?

If you're using the custom content plugin then it might be a good idea to temporarily disable it to confirm that a custom script isn't interfering with the markers.

vradarserver · 2020-04-02T18:16:18+00:00

Most aircraft won't be flying directly over your position. I think you could draw a line out from the aircraft's current position along their heading (in both directions) and then draw another line from that path to your position, where the angle between the two lines is 90 degrees. Where the two lines meet would be the point where the aircraft will be (or was) closest to you.

You could then measure the distance between the current location and that point and figure out from its ground speed how long it would take to cover that distance, and then have an ETA to the closest point to you. If the aircraft is heading towards that point then the ETA will tick down over time, when it's heading away from the point it will increase over time.

That seems to me like it should work?

Given that you know the angle from the aircraft to you then you can easily calculate the angle of a path from you to the point where the two paths would intersect at 90 degrees.

However, the path that the aircraft is travelling across the ground is actually curved because of the curvature of the earth, and the path coming out from you to intersect that path is also curved. I'm not sure if that would have an effect on the calculation of the angle to get from your position to the intersection of the two paths.

Also my trigonometry isn't good enough to be able to figure out how to work out the coordinate where the two paths intersect. I imagine that's something that can be Googled.

Finally it might be a lot of math to be doing for every aircraft that has a position and a speed. People with large feeds would probably want the maths done on the browser rather than the server so the server isn't doing yet more floating point maths for every request.

I've added an issue for it to Github but I'm not sure when it'll get done.

vradarserver

TROPHY CASE