Touch Portal

[hiran]

Seems like you are focusing currently on the hardware side.

Yes an no. I think in such project you have to keep a eye on the both sides. I learned programming in the times of magnetic core memory ( ) and the "Wang 2000". So I keep every time an eye of the capacity of the hardware. And so I asked myself which capacity abuse the detour if you can´t make the thing direct. In the side of programming the detour is very much easier. Perhaps. But for an Arduino it´s very easy take out the serial information directly. Okay let´s see:
Oolite - MQTT - MQTT - Raspberry - (Arduino) - display
This - in my perhaps false opinion - costs capacity cause of the detour.

For me that is strange. If you want to spend a raspberry - why not drive the display and the buttons directly?
A raspberry has enough power to run a full linux distribution so it is the second computer you mention.
Otherwise you have a full PC in front of you with more compute power than Oolite requires. Another process is required anyway to get data in/out of Oolite, so this process could drive your addons via USB directly.
Less components usually mean less room for failure.

The capacity of Mousenoabs-Micro controllers. It is economical thinking. If you have a big realistic project with realistic landscape and more. You will need a second computer to make it. So I think with a game like OOlite and some funny looking displays depends what do you want but one or two Arduinos are mostly enough. This is the combination of an Mega and a Leonardo/Micro(Pro). If you have a typical project one display and a button box mostly the Arduino pro micro seems the best. (It is to build a Joystick with 56 buttons).(And this are not the costs, calculate one button with 50 cents (50 x 56 buttons (28$), the Arduino Pro I bought for 5 Dollars!)



My concrete questions:
1) How many capacity costs the detour with using the debug-file and MTT in the computer? (I have two Raspberrys here.)
2) Is there a way with f.e. javascript and OXP to write the variables I need directly to the serial port (like to the monitor)?

Happy New Year!

So you want to optimize the solution. For a custom build I believe the main cost are development cost. The one-time hardware purchase is neglectible.

So I'd throw in some processing capacity to keep development cost low. By using an ESP32 controller (e.g. integrated into a D1 mini board) I know I have WiFi, TCP/IP and can run MQTT directly. Communication to a PC is really easy, and the gateway process for Oolite already exists as Cholmondely had found out. If you like you can still use serial ports and USB.

What I still see as a challenge: I have no clue whether that ESP32 has enough power to drive a display, especially if you want touch capability. And I would not know how to wire the pins to support a joystick (well that would be a few analog pins) with 56 buttons (that exceeds the number of available pins so some better logic is necessary).

If I were to reuse available Raspberry's that would even ease development further as you do not have to code in C but can choose the language. Some time ago I bought the [https://www.raspberrypi.com/products/ra ... h-display/]official touch display[/url] to build a nice little appliance. The touch is a bit odd when programming yourself. But as soon as you run X everything comes in naturally and you can focus on the application displaying your gauges and receiving touch events. It could be a nice way to add features later to your cockpit.

But also the Raspberry does not provide enough pins to connect joystick and 56 buttons directly, so the wiring problem remains. But solutions exist anyway.

[Cholmondely]

Happy New Year!

And to you too!

[Mausnoab Williamston]

Hello!

A raspberry has enough power to run a full linux distribution so it is the second computer you mention.

I love this fellow raspberry-guy!

Otherwise you have a full PC in front of you with more compute power than Oolite requires. Another process is required anyway to get data in/out of Oolite, so this process could drive your addons via USB directly.

All that I know is that You need to send the information serial to the USB-Port (serial). I don´t know much about this (in this moment) but I guess the debugging control use this way. But why not directly to the USB.

Less components usually mean less room for failure.

Yes!

So you want to optimize the solution. For a custom build I believe the main cost are development cost. The one-time hardware purchase is neglectible.

Of sure. Obvious. But this is the part of fun. I can make it MY way.

So I'd throw in some processing capacity to keep development cost low. By using an ESP32 controller (e.g. integrated into a D1 mini board) I know I have WiFi, TCP/IP and can run MQTT directly. Communication to a PC is really easy, and the gateway process for Oolite already exists as Cholmondely had found out. If you like you can still use serial ports and USB

.

I will look for an ESP32, because there are interesting ways with it. The most bridges of flight simulators use the arduino. The most one work directly.

What I still see as a challenge: I have no clue whether that ESP32 has enough power to drive a display, especially if you want touch capability. And I would not know how to wire the pins to support a joystick (well that would be a few analog pins) with 56 buttons (that exceeds the number of available pins so some better logic is necessary).

With the buttons we speak about multiplexing. There are several ways to solute it. I prefer the matrix.

Power depends of what You want or better what You can make. I prefer (my example) the easy and good to handle ProMicro. This little thing serve: Analog axis X-Y-Z and the throttle. Then you have 14 Pins left. This are 49 buttons. (Okay, okay). You can work in different ways. I made a solution with a pseudo-MFD and twelve buttons. I use a Uno for the display and a ProMicro for the communications with my computer. And I have a lot of pins and power left. Over the serial is now enough power for inputs for my computer.

If I were to reuse available Raspberry's that would even ease development further as you do not have to code in C but can choose the language. Some time ago I bought the [https://www.raspberrypi.com/products/ra ... h-display/]official touch display[/url] to build a nice little appliance. The touch is a bit odd when programming yourself. But as soon as you run X everything comes in naturally and you can focus on the application displaying your gauges and receiving touch events. It could be a nice way to add features later to your cockpit.

If You want a touchscreen there a several ways. I prefer the Helios with a second Monitor. Even wit this solution we have the problem get information out of OOlite. Look here what is possible with flight simulators: https://www.digitalcombatsimulator.com/ ... s/3302014/

Their are very flexible and beautiful solutions with this. Flight simulators send their data directly to Helios. Here are some beautiful examples: http://www.captzeen.com/helios/downloads.asp

But we still have the problem. Make a easy way to get out the data from Oolite.

But also the Raspberry does not provide enough pins to connect joystick and 56 buttons directly, so the wiring problem remains. But solutions exist anyway.

There are several ways for multiplexing. They are easy. In the end you can manage with two pins millions of choices. (Telefon - solution). You can connect some controllers with I2C. If you want although a raspberry with an arduino and so on. So you can use several platforms together. Put we have to send the dates from Oolite in the most direct way to the USB-Port.

An idea of a bordcomputer is this guy (or something like this...my fantasy):



In addition to a joystick a "lookalike" of the Apollo-DSKY...

[hiran]

All that I know is that You need to send the information serial to the USB-Port (serial). I don´t know much about this (in this moment) but I guess the debugging control use this way. But why not directly to the USB.

Grant. So the data has to come from Oolite and go via serial port, and the same way back.

But we still have the problem. Make a easy way to get out the data from Oolite.

All that Oolite offers is the Debug Console Protocol.

So you would have to write your own Debug Console. There are implementations out there you can use as base. All you need to add is the serial port support.

I only hope you do not play on an Apple Mac, as there seems an additional quirk.

An idea of a bordcomputer is this guy (or something like this...my fantasy)

In addition to a joystick a "lookalike" of the Apollo-DSKY...

That is a nice one. Interesting implementation, especially when you hear how they designed the software...
https://www.youtube.com/watch?v=B1J2RMorJXM

Any Arduino should be more capable of that today. And then Arduino comes in different flavours. The Arduino Nano 33 IoT one has WiFi and Bluetooth already.

[Mausnoab Williamston]

Hello!

I am a little bit unhappy today. I want to start my easy button box, because they deliver me not the correct print to start it. I can´t start it .....I like to become physical ....

Grant. So the data has to come from Oolite and go via serial port, and the same way back.

You got it!

All that Oolite offers is the Debug Console Protocol.

So you would have to write your own Debug Console. There are implementations out there you can use as base. All you need to add is the serial port support.

It looks great but I have to check it out.

I only hope you do not play on an Apple Mac, as there seems an

The times Apple uses the Motorolla-Processors are gone.... Bye, bye...

That is a nice one. Interesting implementation, especially when you hear how they designed the software...
https://www.youtube.com/watch?v=B1J2RMorJXM

Yeeeees! Great one. It shows a good way to manage much commands and displays with several buttons. Like a MFD. In the end you can have a lots of different commands.

Any Arduino should be more capable of that today. And then Arduino comes in different flavours. The Arduino Nano 33 IoT one has WiFi and Bluetooth already.

WiFi with Arduino doesn´t cost very much. Unless I get sick ideas of abuse my Raspberry.... Okay, but i have to be realistic with my possibilities...

[hiran]

I am a little bit unhappy today. I want to start my easy button box, because they deliver me not the correct print to start it. I can´t start it .....I like to become physical ....

Been there, done that. I know that itch.
But I also have to admit electronic components have become small enough today it is no more fun soldering them together.
And designing a PCB is a totally different discipline...

Yeeeees! Great one. It shows a good way to manage much commands and displays with several buttons. Like a MFD. In the end you can have a lots of different commands.

Well, when I heard about operating it just by codes this reminds me of machine language directly. But at that time there was no language, not even an assembler. They wove the software directly into the ROM. You don't want to make an error there, won't you?

WiFi with Arduino doesn´t cost very much. Unless I get sick ideas of abuse my Raspberry.... Okay, but i have to be realistic with my possibilities...

Well, if you switch from serial protocol to TCP it is different. But you would still have a send and a receive channel. And you would have to deal with the bytes coming in. But bandwidth is considerably higher, and you could multiplex the connection, cover bigger distances etc. Even Over-The-Air firmware updates are possible (check OTA).

Maybe not directly necessary for your project. I used it since I used the ESP32 as illumination controller. Once you get it mature you install it somewhere in your house - and for an acceptable WAF it is hidden with no physical access possible any more. But when the firmware changes... OTA is a real lifesaver!