agrasyuk

Needed a change of pace, put the keyboard away and did some hands on stuff still kind off on CDU topic: testing my approach to making and iluminating CDU buttons. one led per two buttons, letters/numbers are more or less evenly lit. I will need to do several more layers of paint on the sides - was to anxious to try it out and one layer of black on layer of white is clearly not enough to stop the light bleed from the sides.

Several questions about next steps: Keyboard input - Ian, code below does not stop the script, or at least doesn't on my side. since event.poll() stores only the latest event i assumed there were more events that happened after ESC was pressed. I tried looping event.get() with same result. I do have kbd input working in my static screen test script however (can terminate the script gracefully). not yet exhausted and have couple ideas i will be trying out, but any input on this is appreciated UDP vs. TCP before reverting to TCP i tried to feed the parser byte by byte as you suggested with code below. to my understanding this was supposed to take care of things, but it obviously didn't sticking debug points (with print statements) it looked like each incoming message was being iterated properly - 40-60bytes long on average, i was able to capture individual bytes and then ord() them into charcodes. still the display was 24x10 grid of "?" chars (for unrecognized code). i don't insist on using UDP, but at this point i'm simply curious on how this should be properly done. i also wonder if using TCP means there is a limit on numbers of networked devices connected to the server.

i have remarkable ability to waste time looking at less probable approaches and trying less probable solutions first... after i was done messing around sticking debug points around the code, i finally gave up on UDP, looked up the BIOSConfig.lua , created TCP server instead and connected to it from the PI - got the CDU displayed. Turned off mouse pointer. Configured the PI to auto boot and navigate to script folder on start - with the amount of reboots i did this saved some pain. played with character scaling to fill entire screen. apparently despite pygame declaring exactly right screen size for itself raspberry still can default to some strange resolution when going via composite output. overriding resolution in /boot/config.txt solved this. had to adjust overscan to fill stretch the image closer to the screen edges. response time, clicking on UFC buttons and seeing ltters appear in scratchpad, is very very good, almost immediate. characters are very readable and image is quite OK for a being displayed over composite. colors of the cheap rear view 3.5 LCD are obviously washed out but for this application i don't think it matters to much.

Ian, your example didn't work for me out of the box. as i read through your code i noticed that you configure the socket as such: however in my local RPi lister script (tiny script that i use to see whether raw data is being recieved) i have socket configured as when i try to revert my listener to "STREAM" mode as in your code, i get socket.error "connection refused". switching your code to use "DGRAM" also didn't make things work, i guess parser relies on exact type of connection . any input on this is very welcome. PS, not sure if it has anything to do with the fact i run FTP server on the PI( setup so so i can push code to the board faster )

John, good that you decided to post your work here as well. very interesting solution with sandwiched PCBs.

Shhhh! This was announced as "affordabe". Don't give him ideas, :music_whistling: :lol: On a serious note. Hegykc, its great to hear that you figured out a way to keep this financially viable and scale production at the same time. Renders do look good. I'm not sure how you plan on realizing the telescoping extension, but flex is serious concern. Iooking at the renders I don't see how this can be as stiff as solid piece

Ian, following up on our private conv: see attached pic for a quick status update. In short: I now have capability to print CDU lines with actual .TGA font from the game indicatortextures folder. Library that acomplishes rendering the tiled text is located in git repository i forked from you. Now I just need map the chars incoming from the sim. 3am over here now. For those wondering: I'm working on displaying a CDU screen on networked raspberry pi board without any viewports. once the code is finalized i will switch over regular monitor to 3.5" display

Burns, very nice panels. Looks like you are utilizing your space well

Maybe like this? Notice that you have an additional "http://" in your img URL. EDIT: You can always go back and edit your post when that kinda blunder happens.

I mean backlight bleeding through parts of display surface. Like pictured here:http://i.imgur.com/KHbfeLJ.jpg

I'm very tempted to get that monitor as my main desktop (productivity, non-pro photo, and the little gaming I do these days). While i can get better card I'm really worried about reports of hotspots that LG u95 displays in corners.

Let's not get carried away here.

Thanks for the detail. The new cockpit is still in planning stages, can work around that size. I was planning building my own pedals but your product looks like very worthy shortcut. Sign me up.

I'm ready to preorder, when do you intend to start shipping?

So non functional purely aesthetical? do I understand this right? If so then no interest on my part. IMHO the hardest part is actually getting some room for pit framework. When one has that room might as well go all the way.but I guess there can be several opinions on this, some here seemed to like even a quick cardboard solution for a pit.

John, aside the fact that the site required me to register to view, your stuff looks really good :) indeed lit butrons are a must. Very interesting solution with dual PCB. Maybe I'm going overboard, but i really don't like the feel of those small 6mm tact switches. I went with 8.5mm tacts, they have 1.3mm travel and a nice click at the end of range. For lighting I'm testing LEDs positioned on same PCB in between switches (with mid layer of panel designed to accommodate that). At the moment I'm stuck at routing the PCB. Button matrix is designed so letters and numbers on keypad match those the keyboard. Since buttons on CDU are not positioned with ordinary querty keyboard controller in mind and routing is just hell. Density and the fact 8.5 tacts don't provide internal connection for jumping over leads is really not helping. I do wonder however if all this effort is justified though - chances that keyboard controllers are not standart... I'm so close to just make it with proto perfboard and build the connections manually...

and here is some crazy kiCAD button matrix. probably could have been drawn better, (perhaps using named nets) - my first steps with that software. BTW, to those who use kiCAD, is there a way to highlight entire network with all its connections somehow?

So, how do you guys intend to map it?

Ian, for CDU I think the challenge is not electronics (although wiring 60+ buttons is by no means trivial), but to build a sencible construction to house all of those buttons neatly.

I do plan to build something very similar for desktop Sim (for testing purposes). Agreed with Cich, almost everything needed for combat is on the hot as. The panel probably should include AHCP. and landing gear lever will be nice - you will use it twice each flight if all goes right ). Beyond that maybe use functions needed for cold start.

And note, this is just LCD module. You will need to figure out which display driver board to source for it.

Several things you not accounting here in your example. Lets start with fact that 15 hours to design is very conservative. And Its not a fact Joseph had 100% skill on all topics required. He will spend time researching, learning Autocad and kicad, creating mechanical drawings as well as designing the elec circuit and a PCB for it. Joseph will need to either come up with his own software solution to drive his panels (adding time learning programming skill) or partner with someone to do it for him (at cost). Chances are that he will need to build several prototypes and spend more time revisiting his initial design. All those prototype devices also cost materials and machine wear and tear. Speaking of machine, aside of sifnificant upfront cost Joseph will need to learn operating his new machine, potentially making costly mistakes . and this list can go on. I found first hand what it takes to design a simple landing panel that someone other then me will be using. I did sell several even. I would have made more, much much more money if Id simply take overtime hours at work instead of working on it. PS, Im not sure if the HP figure of a vehicle you own adds much weight to your point. exactly that.

There are several levels of "as close as possible". Be prepared for an event where some will find your product still not close enough. :) And IMHO, the hardest part with your endevor is exactly that - setting a price. Good luck with the project and lookin to see those pictures soon :)

I'm offering my help on this project. well that is in case my skills can be of help at all. I am quite senior SQA engineer specializing in test and process automation. i Know "where software comes from", familiar with SDLC and development methodologies. I think i do have some understanding of how DCS works as far exporting/importing. with that all coding i've done so far are from QA perspective, quite a different mindset. i'm not sure i can take on any of the outlined tasks myself, but willing to learn and work under mentor/team-lead, preforming side tasks perhaps.

what can i say, this is very timely. not exactly what i had planned, but i will be following. i'm working on CDU at the moment. mechanical drawings near complete, still need to test if my back light solution is plausible. for interfacing i'm thinking to use raspberry pi: composit vid out, on-board network and USB host (for keyboard). salvaged a keyboard USB controller from a specimen that sticks due to meeting coffee. traced the leads and constructed CDU oriented matrix, now building PCB for this in kiCAD . was thinking to make something like IRIS, capturing a CDU screen area and displaying on 3.5" rear view camera screen, but your export Ian simplifies things significantly. now i just need to study me some Python...