Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Your layout looks nice and compact. Make sure you leave enough space to operate the switches and dials comfortably and quickly. As for wiring, I took a look at the listed parts and some did not have an obvious way to access the data sheets so a pin-to-pin wiring diagram is not feasible. Here are some general guidelines that may help you (you may already know this): Each switch and encoder will need one pin connected to ground. You will set the Arduino to pull-up the digital lines you are using and closing the switch will then bring the input pin down to 0V. You need to find out which pin needs to be grounded. For instance, on the two position 6 post switch the two central pins are probably the common and should be connected to ground, while the four outer pins are the contacts that are connected when the switch is closed. To wire this up, you would choose one side of three pins, connect ground (GND) from the Arduino to the center pin and connect each of the two outer pins to a digital input on the Arduino, for instance inputs 2 and 3. I would avoid Inputs 0 and 1 on the Arduino as they may be used in the USB serial communication and there are plenty of others The rotary switches work in a similar manner to the DPDT switches. Identify the common and connect to ground, then connect each of the remaining pins to a digital input. The rotary encoder will require 5V and GND, as well as a digital input for DT, CLK and SW. SW will be the push button switch input, just like all the other switches and DT and CLK will need to be decoded in order to identify the rotation of the dial. The three position toggle is the most complicated. Looking at the data sheet, you want to connect the ground to pin 5 and your outputs to the Arduino will be on pins 4,1 and 3. You also need to connect pin 2 to pin 6 and pin 8 to pin 12 in order for the connections to work properly for the three positions. If you are making a USB HID, you don't need to track which pin is connected to which input unless you are very fastidious. Just make sure your are monitoring the correct range of pins in the sketch. When you assign joystick inputs in DCS, you can just press the correct button and the absolute identifier won't matter. If you are using DCS-BIOS, then you do need to keep[ track of which switch pin corresponds to which Arduino input so you can properly code the switch to the function you desire. You can daisy chain the ground from one switch to the next. You might want to give the rotary encoders their own ground lines to minimize the chances of glitches. Hopefully this helps. Once you wire up one switch and get it working, I think it will become obvious how to do the others.
  2. David, Thanks for sharing your implementation. That looks great. I especially like how compact and out of the way your damper is. You managed to fit it in nicely even though it needs significant throw. I orientated my collective base the other way simply for ease of mounting. When I have time I will post a picture of it mounted to the chair.
  3. David, Mine also had the Leonardo board. I never even thought to try reprogramming. I saw the orientation of the Hall sensor and the magnet and figured it wouldn't work. Glad I was wrong for your sake. I'm excited to put my buttons through their paces. Hopefully you'll find some time to add to yours. I really wanted to print a more accurate handle shape but I don't have the skills to draw it myself and I got impatient waiting for someone else to be generous.
  4. Tundra, I definitely stole the idea for a handbrake from somewhere. Could have easily been you. My collective is light enough that friction is holding it in place very well right now, but if it loosens I will look into adding a damper. I'm pretty lazy, so I don't do more than is needed for what I have, which can come back to bite me. My handle is painted PVC and I didn't like the feel of the paint on my hand, which is why I went to the wrap. It was easy and feels good.
  5. I have always loved the Apache and have played most of the simulations of that aircraft going back to the Commodore 64. When ED announced the new module, I was thrilled. I am planning on piloting it with my son as CP/G, but when I saw the Collective I was concerned. I have a Thrustmaster Warthog stick and throttle, and I felt like the throttle wasn’t going to do that massive two position collective justice. So, I decided to build my own. I started from an Amazon generic handbrake. I wasn’t satisfied with the Hall effect sensor they had because it gave more of an on/off effect rather than a true sliding scale, so I replaced it with an Arduino Micro with my own Hall effect sensor. I removed the spring and installed a plastic washer on the axle which provided the friction I needed to keep the collective in place. Next I drilled some holes in a pair of plastic bud boxes for all those beautiful switches. I installed four 3-way tactile switches, four five way tactile switches, a three-position switch and four buttons. I left off the chop and BUCS switches since I was running low on inputs on the Teensy 4.1 microcontroller I was planning on using. I also added a 3DS controller for the Cursor Controller. My son 3-D printed out hats from a Thingverse entry for the tactile switches (2- / 3- / 4- / 5- Way HAT POV Switches for HOTAS). Finally, I used 1” PVC pipe for the collective handle and glued the bud boxes in position using some plastic epoxy. Some heat from a heat gun allowed me to bend the PVC to the desired angle and it was bolted to the handbrake controller. I wire-wrapped all the switch connections and installed the Teensy in one of the bud box lids. A little black paint and some silicone wrap on the handles and the collective was finished. I mounted the whole thing to my desk chair using 8020. It turns out there are multiple sizes of 8020, and I way overshot my needs but at least it will be sturdy. The collective shows up as two USB joystick controllers, one with a single axis and the other with two axes and 39 buttons. After a little programming to assign everything to the proper pins I was in business. The collective works great. I am getting used to pulling to go up and pushing to go down but everything is working. It does feel slightly fragile, and I may have been better off attaching the bud boxes in a different way. I think a little care will keep me safe. I plan on assigning the top controls to (Clockwise from Upper left) FCR Scan, FCR Scan Size, Sight Select, Cursor Controller, Cursor Display Select and FCR Mode. The red button on the stick is for Cued Search and the button behind that can't be seen is the Cursor Enter. On the bottom controls: Polarity/Boresight, Search/Landing Light, Search/Landing Position, Stabilator Control, TADS/PNVS Select with the Jettison Button on the side. I have tried it on several helicopter modules especially the Black Shark. But I really excited to see it shine on the Apache. I have been encouraged over the years by all the excellent work I have seen here and wanted to share my efforts with the group even though my polish is not as fine as most of you.
  6. Glad it all worked out. Have fun with your UFC.
  7. wereferret, Good news. You have not wasted your money. Looking at the datasheet from the Mouser link above, the KB15SKW01-A switch is a single pole, dual throw, on/momentary on switch. This means one pin is normally on and turns off when the switch is depressed and the other pin is normally off and turns on when the switch is depressed. The momentary() means that the switch does not latch in the second position, but instead automatically returns to the first throw position. Again referencing the data sheet, I believe you want to connect one wire to pin 2, which is the common pin, and the other side of the circuit to pin 1. This will give you the momentary on action you are looking for. It appears you may have connected to pins 2 and 3, which is the wrong throw of the dual throw switch. This is detailed in the Poles and Circuits section of the datasheet on page D26 of the Mouser datasheet. Hope this is helpful.
  8. And that's how you stop getting help, but I will try one last time. The pieces of a connector that actually make a connection are called pins and sockets, depending on which gender they are. It would be a bad idea to try to make the connection with only pins and sockets inside the extension because it would work loose over time. The pins do not have enough friction to hold. The metal and plastic piece that holds the pin/sockets is called the shell. This is the part that actually holds the connector in place. The larger plastic piece at the back of the shell is called, appropriately, the backshell. This usually provides strain relief for the wire coming out of the connector as well as a place to hold the connector when plugging/unplugging. You asked for any help available. The folks above suggested that you use one of multiple connectors without a backshell. When you purchase a connector it comes disassembled so you can access the back of the pins/sockets to attach the wires. Once the wires are attached, you typically attach the backshell. In your case, the others suggested using only the shell and not attaching the backshell which will make the connector as short as possible. I hope this helps.
  9. Really nice draken152. I especially appreciate the cable management effort you put in behind the panel.
  10. Does anyone know if there will be a separate entry in the control bindings for the RIO similar to the Game/Sim choices on some aircraft so we can have a specific control mapping when flying as RIO?
  11. What do you do first when the tomcat is available? I like to think of this as trying to park directly on the hanger deck by way of the transom
  12. Thanks Quick. This looks very useful for rapid testing of panels. I really appreciate it when folks share what they have done to help others.
  13. Exactly. The MAX 6956 and AS1130 are the Integrated Circuits (ICs) in the chain.
  14. Petardo, Thermal had the idea. A network attached USB hub. As I said in the earlier post, this is a slightly different approach to what you asked since I am not controlling any panels directly from the RPi. The Arduino is currently plugged directly into the RpPi, and you are correct there are only four USB portson each RPi. I plan to use multi-port USB hubs on the RPis as required to expand the number of Arduinos each RPi can support. Each Arduino requires its own instance of socat, so I have a shell script that instantiates them and is called at bootup. I have aliased the Arduino USB ports on the RPi by serial number so they stay constant over power cycles. I have built a small PCB that hosts a Nano and uses a MAX6956 to provide 28 I/O ports using I2C. I have also designed a similar board using an AS1130 for up to 128 LED pins but I have not fabricated it yet. The boards are stackable and use external power, so I can have one Nano control up to four of each board type. The software to interface to DCS-BIOS is still under very slow development. I don't have good diagraming software, however the diagram is simple: SimPC --Ethernet-> RPi --USB-> Arduino --I2C-> ICs The RPi could absolutely support SPI or I2C directly. Both provide the capability to control multiple devices on one bus. Both will have limitations in terms of supported cable length for reliable communications(<< 1m). I chose I2C for my implementation because it does not require a chip select line for each device like SPI, so I still have most of the pins on the Nano available for direct I/O in addition to the MAX6956 and/or the AS1113.
  15. I have implemented an RPi with DCS-BIOS. I use the RPi to connect over Ethernet to the UDP listening socket of DCS-BIOS. I use socat on the RPi to pass the DCS-BIOS messages between the USB-attached Arduinos and the simulation computer. This is similar to what is implemented in the standard direct connection method of DCS-BIOS, except there is an RPi instead of a loopback. I decided to use the RPi because I hope to have a full simpit someday and I wanted to use Ethernet and RPis to distribute the data rather than either running several USB connections or using RS-485. It seemed simpler. This may not be exactly the implementation you are asking about, since I did not write code for the RPi to implement DCS-BIOS functions directly. I am still relying on Arduinos to interface with the hardware. So far I only have the armament panel implemented.
  • Create New...