No transatlantic flights?

[Jah]

Hi there,

I just wanted to get on route from EICK (Cork) to KBOS (Boston), its a route Norwegian is certified to fly under the ETOPS180 rules. So no problem for the IXEG

But as soon as i want to put in the DEST Airport the FMC says "APT not in Database" but of course it is, I flew there several times from TNCM for example.. even the waypoints right in front of the main door of Boston are no problems for the FMC, but as soon as I want to put in the airport.. no chance. 

Is this a Bug or is this just normal behaviour because of the missing ETOPS certification of the classic airliner?

 

Thanks for your help

Cheers

Steffen

[Tom Stian]

I think the range between the airports are too far. IXEG have some limitations there I think.

Done some tests, and it seems the max range is 2000nm between the airports. Correct me if im wrong IXEG.

BIKF - KPWM - 2018nm - failed

BIKF - KBGR - 1926nm - OK

Not sure what the max range on this model is. But seems its often refered to 2255nm fully loaded. 

My longest trip so far was BIKF - CYQB - 1898nm ^^

 

 

Edited June 23, 2016 by Tom Stian

[Jah]

Hmm okay so its the systemlogic... I found some technical papers on the internet that says that the 737-300 is capable of about 2950nm ? 

I looked trough the docs which came with the aircraft, but I couldnt found data about the exakt seating capacity or the range and cargo load... this would be great if we get a sheet with the technical data about our specific model?

 

 

[Tom Stian]

This one says 1635nm design range (dont know if that is the same as max weight?) with the 20k engines.
http://www.boeing.com/resources/boeingdotcom/company/about_bca/startup/pdf/historical/737-classic-passenger.pdf

Wiki says 2270nm
https://en.wikipedia.org/wiki/Boeing_737_Classic

 

maybe it was this you saw? its say 2300-2900KM (not nm)
http://www.airlines-inform.com/commercial-aircraft/Boeing-737-300.html

 

[Jah]

10 hours ago, Tom Stian said:

This one says 1635nm design range (dont know if that is the same as max weight?) with the 20k engines.
http://www.boeing.com/resources/boeingdotcom/company/about_bca/startup/pdf/historical/737-classic-passenger.pdf

Wiki says 2270nm
https://en.wikipedia.org/wiki/Boeing_737_Classic

 

maybe it was this you saw? its say 2300-2900KM (not nm)
http://www.airlines-inform.com/commercial-aircraft/Boeing-737-300.html

 

Hmmm okay.. would love to hear what the devs tell us about the range?

10 hours ago, Tom Stian said:

 

 

[Litjan]

It has been a while, but I think we limit the navigational database not with absolute mileage but with a certain "maximum allowable difference in latitude and longitude". Therefore the database will be bigger around the equator, smaller towards the poles. The reason we did this is performance. The database has to be accessed all the time, and having too many entries will slow down searches a lot. This does not only affect FMS entries, but we also need to check if a certain fix is on the map to display it... this quickly becomes a burden.

The maximum fuel load is about 16.000 kgs. Under favourable conditions (light aicraft, good winds) this will let the plane fly about 3.300 NM (no reserves). A more realistic range, which the plane will be able to do with reliability is ca. 2200 NM (normal load, average winds, reserves).

Most airlines have databases in the FMS that covers their area of operation - there can be quite a difference in memory available.

I will add the request for a larger database, but we have to check how performance holds up for that...

Jan

[Jah]

5 hours ago, Litjan said:

It has been a while, but I think we limit the navigational database not with absolute mileage but with a certain "maximum allowable difference in latitude and longitude". Therefore the database will be bigger around the equator, smaller towards the poles. The reason we did this is performance. The database has to be accessed all the time, and having too many entries will slow down searches a lot. This does not only affect FMS entries, but we also need to check if a certain fix is on the map to display it... this quickly becomes a burden.

The maximum fuel load is about 16.000 kgs. Under favourable conditions (light aicraft, good winds) this will let the plane fly about 3.300 NM (no reserves). A more realistic range, which the plane will be able to do with reliability is ca. 2200 NM (normal load, average winds, reserves).

Most airlines have databases in the FMS that covers their area of operation - there can be quite a difference in memory available.

I will add the request for a larger database, but we have to check how performance holds up for that...

Jan

Hi Jan,

 

thanks for telling the numbers, this is something I can work with  I think it was a good idea to shorten the range of the database with the performance in concern! I don't want a plane which always loads for ages when I click on the FIX button if I do only want to see the nearest ones.... but just give it a try - maybe its no real lack on performance?

 

Cheers

Steffen

[Tim013]

I hope you look closely at the performance impact of expanding the database.  I think it's a very small minority of people that fly 2200 NM flights.  Most systems are already stressed with the 737, HD mesh, cloud/weather textures, and feature rich airports. 

All I'm saying is this could have a huge impact on people that have already bought the aircraft and are running it fine on marginal computer systems as is.  Maybe this should be a feature that is a year or two down the road to take advantage of more robust computer processors, and graphics cards coming down the pipe.

 

Tim

[Tom Stian]

24 minutes ago, Tim013 said:

I think it's a very small minority of people that fly 2200 NM flights.  Most systems are already stressed with the 737, HD mesh, cloud/weather textures, and feature rich airports. 

Well.. I would expect to be able to program a route for the distance the aircraft is certified for. And it should not have that much impact on the performance ? 

24 minutes ago, Tim013 said:

Maybe this should be a feature that is a year or two down the road to take advantage of more robust computer processors, and graphics cards coming down the pipe.

We have been on the moon, so I think the current hardware should be able to handle this. 

 

 

The fmc from this "real"-simulator dosent look that responsive. So we should expect a bit delay on the input 

 

 

Edited June 24, 2016 by Tom Stian

[Fabio Pittol]

Actually, laggy as hell!

This videos from Baltic Aviation Academy are from a simulator, not a real aircraft, aren't they? If so, the simulator uses the same avionics/computers to process the systems?

 

I'm sure Jan can state how laggy the real FMS installed on Classics are. 'Cause videos from real (& newer) aircraft - not necessarily 737's - show it a lot more responsive than that.

 

[Litjan]

The real FMS were a bit laggy - but we got some CPU upgrades in late 90´s and that made it a bit faster. The problem is that in the real plane - the FMS runs on one system, the outside visuals and the airplane runs on another system (reality!!) - so even if the FMS is laggy, the visuals and aircraft will stay crispy . Or as someone once put it: Life is a stupid game, but the visuals rock!

In X-Plane, everything runs on one computer, so if your FMS becomes laggy due to a too large database, chances are that the rest of the simulator comes down with it...

Jan

 

[Vantskruv]

Practically no, it is all about programming. Creating different executing threads for purposes. I.e. I was in a similar problem when developing my Android app. Loading up or searching the database did take time and freezing the application. I did solve this with redoing the interface between database-handling and front-end mechanic. Though this required a remake of the code (but it wasn't too entangled and complicated in stage of development to do). Handling the database was managed in its own thread and instance, and communicating with the frontend where via messages (like SMS on a telephone). Almost like running two apps in one app.

I guess this gets rather more complicated when running under X-Plane, and of course if this approach would be utilized now, I think much code has to be rewritten.

[Fabio Pittol]

Just to be crystal clear, I was talking exclusively about the video posted.

The database limitation, and current performance of the FMS on IXEG's 737 is completely fine for me!

[Eddie]

I don't think it's a huge deal in the current iteration of the product, but I think it's worth noting that other products with custom nav databases and FMCs have no issue with lag despite being able to program routes over 2000 nm, so it's not impossible nor impractical to do so in the future.

[daemotron]

23 hours ago, Vantskruv said:

Practically no, it is all about programming. Creating different executing threads for purposes. [...] Handling the database was managed in its own thread and instance, and communicating with the frontend where via messages (like SMS on a telephone). Almost like running two apps in one app.

I guess this gets rather more complicated when running under X-Plane, and of course if this approach would be utilized now, I think much code has to be rewritten.

You hit the point - normally you would go for multiple threads or even spawn a child process to do the dirty work (threads are a lot quirkier when working for several platforms). However, from inside X-Plane that's not perfectly easily done. It can be done if you work on the C/C++ API directly, but you have to use standard library stuff (semaphores etc.) to control it (there are no xplm_ functions that would do this for you) - and these are platform-specific again, so you will end up with a lot of #ifdef in your code. If you go with Gizmo (like IXEG) instead, you can use multi-threading by using the Lua coroutine feature; however I'm anything but sure you really end up with parallel thread execution (not being a Lua programmer myself; I only know there are some limitations in other scripting environments due to stack tracing or similar technologies).

Edited June 26, 2016 by daemotron
fixed some bracket positions

[Iain]

Was planning a transatlantic soon, normal route is Glasgow to Manchester.  Good fun in the PMDG, limit the bags a little and you get there with enough fuel to spare, as long as the winds are behaving.  Distance around 2600nm, roughly the same as Cork - Boston.

Hopefully this is possible in the future with this great bird, I would be more than happy to put up with some database delays if it meant it was possible 

 

 

Edited June 26, 2016 by Pinky Ponk

[BW901]

Interesting discussion. Transatlantic ferries on the Classics are quite common, we've done them both across the North Atlantic and between Africa and Brazil. The last a few months ago was straight across from the EU's Westernmost extremity (not the UK to correct a German newspaper's recent front page map ) to Gander. They're possible because we're not having to think of commercial operations restrictions and ETOPs considerations.

Maybe a possibility for IXEG is optional additional fuel capacity? There's a modification which received approval this year which offers a modular system of tanks mounted in the cargo bays. A 450USG master tank can be hard installed into either or both baggage compartments with all the fuel transfer and management systems and is plumbed into the aircraft fuel system. Slave tanks can then be easily added or removed in a couple of hours. I'll have to dig out the paperwork but I think overall the system can offer up to 2000USG additional on a -300. A simple Aux Fuel Transfer panel is added in the cockpit.

Then spend $1m to add winglets, make your airframe and operation (120) ETOPS capable and you've turned your Classic into a bit of a beast on the cheap.

[daemotron]

@Pinky Ponk EGPF - EGCC is a transatlantic now?
I might be wrong but I think this route could just be within limits for the 733

Hm, could have been also KGGW - EGCC, but that one is >3,600NM and definitely out of range for a 737, no matter which model...
So I guess you were referring to EGPF - KMHT...

Technically, a 733 can cross the Atlantic on most common routes (e. g. EINN-CYQX is just 1,700NM, which is not much more than EGCC - GCTS). Unless I'm much mistaken, the 733 modelled by IXEG would not be allowed to do so - it simply lacks redundancy for the FMC, which would prevent you from getting an ETOPS-120 clearance...

[Iain]

KMHT of coarse   

 

[heinz92]

Sorry to bring up an old thread - with Cross The Pond coming up and people wishing to use IXEG for a transatlantic flight, could you propose any workarounds to solve this issue? Such a shame as it would be possible in the real thing. Willing to mess around a bit as necessary. 

[Litjan]

8 hours ago, heinz92 said:

Sorry to bring up an old thread - with Cross The Pond coming up and people wishing to use IXEG for a transatlantic flight, could you propose any workarounds to solve this issue? Such a shame as it would be possible in the real thing. Willing to mess around a bit as necessary. 

The only workaround I could think of would be to hit the "reboot gizmo" button during flight. This should reload the current location database. Of course you would need to regain control of the airplane (AP defaults to OFF), but it can be done. I do it all the time, the plane is still at the same location and you just need to enter the rest of your flightplane while you fly on HDG for a few minutes... I would recommend practicing this first instead of flying for 5 hours and then messing it up.

We are still working on enlarging the size of the loaded database for one of the next updates.

Jan

 

[skiselkov]

On June 24, 2016 at 1:39 AM, Litjan said:

In X-Plane, everything runs on one computer, so if your FMS becomes laggy due to a too large database, chances are that the rest of the simulator comes down with it...

In general, this is actually something that can be worked around in a rather straightforward manner. Unfortunately, X-Plane's API makes creating multi-threaded plugins fairly non-trivial and my guess is that when Gizmo was created, the dev went with the "let's keep it simple" approach and made everything single-threaded. Works ok for relatively constrained projects, but as soon as you get into writing anything approaching appreciable size, you can start running into walls. I started hitting that even on a project as small as when I was writing X-RAAS in FlyWithLua and that's a laughably small 4.5k lines of code. If I ever find the time to do a 2.0, I'll be redoing it in C and threading all the heavy lifting.

[skiselkov]

On October 1, 2016 at 8:49 AM, Litjan said:

We are still working on enlarging the size of the loaded database for one of the next updates.

Why selectively load stuff in the first place? The full AIRAC (excluding SIDs/STARs), even using fairly inefficient Lua data structures is probably not going to take up more than 40-60 MB of memory. RAM is cheap. Just load it all in one fell swoop at startup and index by airport/waypoint/fix ID. Lua table indexing is a hash lookup, it's essentially constant time. Alternatively, if you are really that concerned with memory usage, please at last swap the lat/lon filter at load time for something a bit more sensible (like actually measuring object distance). I have pre-made Lua code for that if you want it.

Edited October 17, 2016 by skiselkov

[Ben Russell]

9 hours ago, skiselkov said:

In general, this is actually something that can be worked around in a rather straightforward manner. Unfortunately, X-Plane's API makes creating multi-threaded plugins fairly non-trivial and my guess is that when Gizmo was created, the dev went with the "let's keep it simple" approach and made everything single-threaded. Works ok for relatively constrained projects, but as soon as you get into writing anything approaching appreciable size, you can start running into walls. I started hitting that even on a project as small as when I was writing X-RAAS in FlyWithLua and that's a laughably small 4.5k lines of code. If I ever find the time to do a 2.0, I'll be redoing it in C and threading all the heavy lifting.

Gizmo is muli threaded async where appropriate. Eg; Curl.

Loading huge data structures into Lua is a stupid idea.

- Takes ages to process.

- Stops the sim dead while you do it.

- Shared RAM pools.

- Garbage collection.

- It's an artists tool. It's not meant for creating anything more than proof sub systems that get ported to C/C++ once we figure out what we need.

- Even something as trivial an OBJ8 parser is horrifically slow.

 

My official advice for large data sets is "figure out what you need then bring it to me so we can integrate it into the XPL properly."

 

Edited October 17, 2016 by Ben Russell

[skiselkov]

On October 17, 2016 at 11:53 AM, Ben Russell said:

Gizmo is muli threaded async where appropriate. Eg; Curl.

Loading huge data structures into Lua is a stupid idea.

- Takes ages to process.

- Stops the sim dead while you do it.

- Shared RAM pools.

- Garbage collection.

- It's an artists tool. It's not meant for creating anything more than proof sub systems that get ported to C/C++ once we figure out what we need.

- Even something as trivial an OBJ8 parser is horrifically slow.

My official advice for large data sets is "figure out what you need then bring it to me so we can integrate it into the XPL properly."

There's already a several second pause when loading the aircraft. As long as the pause is properly positioned and predictable, people can generally tolerate it. Another thing is that it's an ideal target for backgrounding in a separate thread. Just loading in a file to build Lua data structures shouldn't access X-Plane's API, so multi-thread away! Admittedly though, LuaJIT might not be easy to modify to be multi-threaded on execution.

Not sure what you mean by "Shared RAM pools" - shared between what? Do you mean as some sort of an IPC mechanism?

As for the garbage collector: might be a bit of an issue. Depends on the collector's design. It shouldn't be too hard to mark a piece of lua data to mark as "don't bother trying to collect for now".

As for the complexity of Lua code, isn't the IXEG 737 FMC (and pretty much all of its logic) written in Lua on top of Gizmo? The pausing when modifying a route in flight, or even on the ground, 2000 nm load limit for airports, etc. None of this would be an issue if the code could run on a separate thread.

Finally, though, I'm not talking about some hypothetical project in the far future. I'm talking about solutions to an already existing project which is substantially written in Lua/Gizmo and most likely won't be rewritten any time soon. Please don't take this to mean I think Gizmo is badly designed or written. For all I know, the IXEG 737 might be abusing Gizmo's internal facilities to an absurd degree, hence the performance problems.