Posts by ussiowa


    "correct landscape colours" depend on many, many factors:

    Daytime, date, blue sky - scattered clouds with shadows - overcast sky, degree of humidity in the air, seasonal vegetation, even the latitude on earth. Perhaps many more ...


    And most definitely Camera and screen gamuts, dynamic range and white balance settings and capabilities.

    Since both are shown on the same monitor, it's fair in that sense that the display is somewhat taken out of the picture (pun intended), but the camera used to take the real picture and the screenshot may have a different white balance. I can take real picture that look just like the aerofly pict in your example.

    You may also notice that in the two examples you provided (beginning of thread and last post), the "real" pictures have very different characteristics. In the first one the shaded part (real pict) is essentially the same saturation and about same color temp as FS2 just a bit less exposure (normal, in the shade), the sunny part is warmer, (normal too, sun makes it warmer in colors). To me, it's all normal and fine as FS2 doesn't have the sunny/shade contrast like this so FS2 is in the right middle, because it doesn't have the sunny/shady effect, and it's probably really hard to do. In that case, to my eye, FS2 looks like the right saturation, a bit less contrast, and a mid level white balance (not sunny, not full shade), so just about where I'd expect it.

    Case in point, cameras have different white balance settings for either case, because they just cannot do justice to both at the same time like our human eye can. So in your first case I wouldn't adjust the FS2 pict as either way (towards shade or sun) would make the other one even worse.

    Now the second picture, which clearly show a general difference, the main difference between the two picts (real/FS2) right now is color temperature (i.e. white balance to simplify), it may also be slightly more saturated for the "real" one. I would be really careful there, as the difference between looking with your eye (which on top is different for different people) and a camera is already very hard to judge. If you don't believe me, look outside your window and take a picture, now compare the two. Now tweak white balance, saturation, tint, exposure, etc.. until you think it's exactly the same SIDE by SIDE (picture to real view with your eye), that should take some time, if one ever finds an answer. Most likely the best will always be some kind of compromise.

    So the point here is that it will be very difficult to have anything look satisfactory to everyone and in every conditions. We all have different sensitivity, and the human eye is always more capable than any camera.

    One could, justly so, argue that it is irrelevant in the sense that the same person/eye looks at real scenery and at artificial scenery, but it makes it difficult however to have artificial scenery be the same feeling for everyone. I can make artificial scenery that looks just like real to me, and someone else will find it different because their eye is more sensitive to something else (color balance, saturation, light, etc..).

    Here as I thought, I had to make it way cooler and a very slight increase in saturation. I still didn't get the blue right (water) as they are fundamentally different. If I get a similar blue the rest of the colors will be completely off. Personally, I wouldn't want FS2 to look like this (way too "blueish"). Now does FS2 have the perfect white balance and compromise (contrast, temperature, tint, saturation), maybe not. It may be slightly too warm for most people and slightly undersaturated (what you refer too as "greensish", but is more "reddish"), but if so, not by much at least to my taste.

    FYI the "real" picture to me, with a somewhat trained eye, looks way too cold in white balance and undersaturated. It's part subjective, part experience, and part the conditions of the picture (could be the camera, would be atmospheric conditions, could be the glass filtering, or any combination thereof). On the other hand the FS2 pict is too warm, and slightly undersaturated also.

    Both could use a bit more contrast too, but that's expected with atmospheric haze, so I'd say in that sense it's a good match and a good setting.

    The point here is that, to me, neither look real, they both look like a picture taken of real scenery through a camera that has slightly off settings for the conditions (everything is too blue, blue greens, greys are too blue on the "real" one, too warm for the other). I'd say something in between looks "real".

    I put "real" in quotes, because it really is a representation of real, though a certain camera with its particular settings and performances. We don't have a real reference here, and we can't no matter what we do, it will always be through a camera.

    Another point, it may just be that the setting of anybody's particular display (screen or otherwise) is off too. Just like cameras, displays (screens or otherwise) have a certain setting, and that influences picture colors perception. Not the case for you as one pict is too cold, the other too warm, but just be aware of the issue when speaking of colors. It also means that a given color set, doesn't render the same for two different people with two different displays.

    I have a substantial part of Jura geo converted if you're interested. all the way to Bresse and maybe as far north as Dole or maybe further. It's not working right so far (flickering) but I think the latest version of FS2 may have fixed that (I haven't had time to try). I haven't "cultivated" it yet, but since it seems both of us are interested in a similar region, we should probably only do it once.


    OK thanks.

    Some app would be needed for FS2, got it. I would start with a generic FFB (no ties to any particular of the flight), then maybe find a way to interpret flight data broadcasted. Not great but that's the best I can think of until we have access to more airplane parameters.

    Since you have now an arduino controller with some software, the best would be to continue with that, and like you say provide input info for the existing system. I don't have any solution at this point. I'll look more into it eventually.

    You lost me. All I get is you have some code already written on an arduino due, and it works for FFB software. Great, then it's done.

    I know nothing of existing FFB or directX.

    So no, no idea where to start with "the app" which I don't get what it is since you're saying you already have it.

    And now I'm thinking but that's a bit more farfetched although not much that since FS2 can broadcast flight parameters to a port, it is probably possible to tune the FFB to said flight parameters (speed, altitude, weather, plane, etc..) and relatively easily.

    OK I have to read more about the FFB mechanical concept. IONI board can torque control motors, but otherwise it seems some shortcuts have to be used to convert motion/position into force.

    I looked more into that simucube and Ioni drive thing.

    Ioni drives are really nice.

    Simucube is also a good thing, as it seems to somewhat simplify the development. However my understanding is that it supports only one axis.

    Prices are 1 IONI drive (€150) plus 1 Simucube (€170) and that gives one channel of FFB

    The solution for 3-4 channels of FFB is the IONI cube 4 axis (€150) plus 3 or 4 IONI drives (€150 each) but the IONI cube 4 is not directly controllable as a HID unit, so I'm not sure what it means in terms of in between boards or systems. (they have kits too)

    It's controlled through a C library (SimpleMotion V2)

    While a nice set of hardware, it seems higher price and more complicated to use.

    I think a Raspi, 3 of the controllers, a bit of node red programming and voila a solution for less than $100. Remains the interface between Raspi and HID USB input

    OK it gets better. With a bit of research, the Raspi3 or actually any but the 0 cannot be set up as HID slave. So the one to use is the raspi 0 W, which can be set up as HID, then 3 of the controllers (can use the same programming and plugging as a regular Raspi). The raspi zero W (wifi) is $10.

    I think and hope the zero can handle the load and requirements, it looks like it can from a brief overlook.

    So in conclusion and in theory a Raspberry Zero W, with node red installed, turned into an HID unit with 3 Cytron controllers and you have a full system for controlling 3 axis, you can do all the calculation combining, mixes, etc.. you may wish for $50. The raspi can also handle many switches and toggles and LEDs. It would need something else to handle digital I/O though. Programming is probably 1-2 days at the most using a mouse to move blocks^^. Oh and it could report on a web page, just as easily so you can also monitor or control stuff on it from a tablet or cell phone on the same wifi network, it's trivial to program. (yes I mean a tablet can read FFB or any parameter and for example increase force with a slider, or whatever you set it up to do as you're using the system)

    I'm not sure of all the details at this moment (mostly how to read/write the USB HID data from the node red blocks, this maybe, or this), but it looks like it should work.

    Yes that looks like part of a solution. I don't think it can handle 5A so you'll need another board. This one has 2 DC, but probably low amps, it doesn't say.

    I2C is good enough, with documentation you can do pretty much whatever with node red, I couldn't find the doc though.

    This one looks more like it. It can handle 2 DC but only 5A total if I understand well.

    I guess you just plug it and use the GPIO to control it, that may work just fine with Node red.

    The advantage of I2C is that you can control pretty much as many as you need. This later one I think you're limited to one as it takes the whole GPIO connector. I couldn't figure out if more can be stacked or not.

    I see you have 2 DC so that would most likely be enough for this yoke. My project I have 5 axis (pitch, roll, yaw, throttle and collective)

    Another thing, is I don't know yet how to get the raspi recognized as an HID object, so that once connected through USB it will see the whole thing as a joystick.

    OK let's start from the beginning then. It may be trivial or redundant to you but here was my thought process in creating controllers:

    - Hardware, never mind, it's done and that's where we can do (I'm mechanical engineer too, so that part is easy)

    - The big main issue IMO is getting an interface with window that is easy and usable, so for that it has to feature HID connection (whatever that really is)

    - The processor or board has to have all input output needed for the project.

    Raspi doesn't have digital input output so much, so it's not great, but it can be coupled with some systems (arduino or others), but that takes over some simplicity it is now a compound system, more headaches.

    Teensy is what a lot of people seem to be using and has the right I/O but it's back to C programming. The one you linked (STM32F4) also seems very interesting and perfect but also in C programming as far as I can tell.

    Now for you project (FFB) it needs a bit more advanced stuff like motor controllers. so that's one more level of complexity.

    Simcube is great, seems all done, I can't find what or how to program it though.

    Following the links I found IONI controller

    And it seems to connect to all kinds of "brain" (PC, microcontroller, Raspi) but it's a PCI board, so not sure how that works.

    and then if I understand it requires "granity' software to configure, another thing to figure out. The interaction is controlled via simplemotion V2 another SDK to learn;(

    Let me explain my view of C programming before people flame. I've done some programming for years, so I don't have a fundamental problem with C programming (or C derivatives). I just don't know C and the syntax is the major problem of learning a new language. C syntax is not obvious, and not very flexible, so I would try to avoid it if at all possible for a more flexible language (easier to tinker with). Like you I don't want to spend a lot of time learning a programming syntax.

    - Therefore my next point: relative ease of programming. For that I like node red for sure but it may have limitations I have not yet figured out, and so far that I can tell it may not have all the functionality needed. Any block can be programmed so technically it's possible, but it's now Javascript, another language again. I would keep it in mind as first try for its utter simplicity to use, but it may not work in the end. I've found step motors controllers blocks, and some kind of DC controller, all sensors and reporting is easy.

    If node red cannot do it, My next programming effort would be Python or Ruby, more complex, but still not too bad I think. Python seems to be the more accessible with this kind of hardware, but I haven't yet found the whole chain easily implemented.

    More specific to your question:

    - Raspi is probably plenty powerful, it's basically like a full computer. It can handle all calculations and be programmed in all kind of ways (node-red, python, etc..). The problem is I/O, it has some, but not the one we need for FFB, so drivers need to be found and interfaced, and therein lies the issue I think.

    - There are microcontrollers and boards that can do the trick, and are programmable in some form of Python (Micropython, or Circuitpython), but they may not be powerful enough for this application. More research needed.

    - STM32 and other boards (teensy, etc..) that have direct motor controllers (simcube) are great in that sense, and seem directly designed for the application, but they all seem to be programmable in C or derivative, so it's just about learning that programming. Although there may be a micropython implementation for STM32 that may be of help.

    - Modifying existing FFB solutions, I don't know.


    You may want to consider different hardware, like rasberry pi or some micropython featherboards. It's a bit simpler to program I think since it's python versus C.

    I don't want to start a programming language, or a microcontroller debate, but python is a bit more approachable in syntax for non professional coders, it offers file management and math on micropython that I think arduino doesn't offer, or as simply anyway. If push comes to shove (absolutely need an arduino hardware) there is a solution to slave an arduino to a raspi and program everything in python too. I've been looking into all this, just never had the time or urgent need enough to finalize it.

    There is also "node red" on raspi that is completely simplistic to use and create stuff, one can do advanced stuff with just dragging blocks, you may want to look it up if programming is your only limitation.

    I have converted essentially the same area (50 miles X 50 miles WNW of Geneva) in imported 0-level 9-14 except 10 and I've had quite a few problems, which so far I've attributed to my limited knowledge and experience of the tool:

    - Patches of terrain do appear as I fly over them not all at once, before they appear it's the standard very loose color patching where there is no DLC terrain.

    - It seems that in some places I can't get them to appear. When I fly at the edge of the converted area, it doesn't appear a a perfect square, yet the imported scenery was a perfect square. I haven't checked yet where the difference is if any.

    - It seems (but to be confirmed) that as I fly away some that have appeared (in high def) disappear again, only to reappear as I fly over. But some are persistent. There doesn't seem to be any rime or reason for this persistence or lack thereof.

    - On areas of multiple sources (where the DLC has good terrain like Ferney Voltaire airport, etc..) it's switching as you fly over, sort of a blinking effect, not sure why (to be confirmed but I can't fly until Oct). My guess it's similarly switching between my geoconverted info and the original (the DLC content)

    - I'm not sure it has an effect on 3D trees, I've had no time to check so far.

    I was under the impression that the software automatically picked the highest definition available for any tile, isn't that the case?

    Is it something I did incorrectly in the conversion process

    Is it something particular to that area? Or has it to do with being on the edge of DLC?

    Reading Antoine's post in more depth, I haven't applied a "border" mask between the two, should that be done?

    Was all of this an original problem that will be solved in the future versions of the converting tools?

    OK so yes I didn't have trees in geoconverted areas (Hawaii), so how the heck did one get trees? That has been figured out apparently.

    My guess is that the current tree "populator" looks at the green on the ground image and depending on green patches implements a density of populating, but placement is kind of arbitrary, so that's how we end up with trees where they don't really belong.

    There is a patch of vegetation in Socal in LA where there is no trees *where I fly RC), it's mostly bushes. In FS2 it's covered with trees.

    Virtual roundup (no advertising intended) is what we need, that we can apply locally on the vegetation. Better a 2 step tool::

    Trees to bushes

    Bushes to nothing

    Also for areas where there are a lot of buildings (like a city) there may also be a lot of trees. And when the only thing populated are trees and zero 3d building, then yes it looks completely weird.

    I don't know IPACS, but I will tell you this. Developing such a software is difficult (otherwise a lot more folks would do it) requires tremendous expenses, time and effort, and it has a limited return as it's not a wide market audience.

    The price of this software is reasonable, and while I would agree that the price of the ORBX expansions is high for just one airport, one is always free to buy or not.

    I find IPACS very communicative as they are present on this forum and in general answer questions, requests and so on, that is on top of the work that has to be done. They also often have to put up with many time the same question, so they are very patient.

    So while it is OK to wanting to know and ask questions and suggest left and right, and while I also understand that complaining is in fact asking to remain a customer, I think we have to empathize a bit more. If they delivered half on what they announced, they would be a "bad guy", if they over delivered, there would be people complaining that they under announce it. If they don't announce it's bad, if they over announce (like say it's coming and it takes more time than anticipated) it's bad.

    So I'd say be happy with what you have, make a decision on buying on what you have and what you want, make a decision on further buying based on previous experience (although it's not always a marker of future experience), and finally be happy that iPACS is doing something, whatever that is, and that they remain in communication with us. I hear that's not the case for every company.

    The key here is what YOU HAVE, not what could be. I get it, we all want more, but honestly what we have is at the top of today's technology or close enough and it's not that expensive relatively. We easily pay a few hundred dollars for a joystick and Throttle that is infinitely easier to design and make, and we don't usually expect the joystick company to evolve the product every quarter.

    So look at what you have, decide if it's worth it (perfectly OK to decide it's not) and enjoy flying. One day clouds will be awesome, water will be water, the whole earth may be populated, vehicles may be moving, etc.. or it will not and we'll maybe have another software to go to instead.

    YOU also have the option to develop your own perfect version of a flight sim and everyone will buy it, then more power to you.

    We have something which I personally think is great. They have proven their ability to deliver great stuff. They're busy at work, so what's not to like.

    They sold us a product, not a guarantee of communication and answer to every customer whim.