Jump to content

Raisuli

Members
  • Posts

    818
  • Joined

  • Last visited

Everything posted by Raisuli

  1. Seriously? F-4, F-15E, A-7, F-4U, Kfir, Kola, Sinai...does DCS have any idea what they're doing to my household budget? Do they even care? Heartless, I tell you!
  2. Update has to come first or the game doesn't know about the module. Updated, bought the module, started DCS, and it was in the module manager as a downloadable module. I was hoping someone would say the cockpit smells like snails or something bad like that to save a few bucks, but no such luck. It was still a first day buy on the first day
  3. This opened with the Spasskaya tower, which says Eastern Front '42-'43 to me... Just sayin...if you took it as far as Stalingrad or even up to the Kyubishev bend that would be perfect! (NOW you see how rumors get started)
  4. Of course that required a test, and you, sir, are correct! For some reason it never occurred to me to correlate the (not terribly common) times I actually turn off the USB hub with the lights coming back on when I start the machine. Since I re-engineered the pit the throttle is in a powered hub now, so that was the big change. Thank you! I use the stick cover to minimize the risk of damage when I get into the simpit. Back when I used to fly F-13s off the USS Senator Pork Barrel we did back-flips into our aircraft. At my age, and physical condition, it's a pretty sketchy evolution. I should buy a helmet. The throttle cover says 'Virpil' and covers a Thrustmaster, which still sounds like a bad porn production company. That's mostly dust mitigation. If they make covers with their new logo I might have to get a new set and eat the shipping costs...
  5. Every time I reboot my computer the first thing I do is fire up TargetGUI and turn the backlights off on the Throttle. It doesn't matter if I turn down the brightness, use unpleasant words in French (or German or Russian or English) when I do it. On the next reboot I have to turn the back lights off again. Short of a surgical procedure is there a way to make that change permanent? Sure, on the grand scale this is a pretty pathetic problem to complain about, but it would be nice if I could complain about something even more trivial after this is solved...
  6. Have you tried to alt-tab out of DCS and back in again? Mine starts up like this, and that works every time. Not sure I've run into the problem in flight. I should point out my extra monitors are extra monitors, and no voodoo is involved. That might make a difference.
  7. Yeah, well. I used to think a meter was pretty close! Seven controllers was too many to manage when configuring controls. DCS is hands down the best, but there is another sim and that control setup isn't as nice. Given the working code is mostly loops most of it is copied from one sketch to another with no edits...only the encoders and specialty buttons (master caution and eject) need any kind of attention, and that's only because the variable names change. Okay, the setup stuff needs attention...maybe I should just number encoders and put them in a loop, too...I'll do that for the last set and have it ready to go for the next iteration. And I have pins left over. I'd have more pins left over if I wanted to add I2C chips. Those make life really, really easy. I start out with 58 digital and 27 analog. 23 analog shares space with digital, but with 8 axis in DirectX I only lose 4 digital pins to analog. 2 more of those digital pins are lost to SCL and SDA, so net 52 digital are still available after I hook up 8 axis and I2C. The sketches runs around 100 loops/sec just because that seems like a nice number. The delay is set to keep that rate, and now that I think about it the delay should be dynamically set on the fly. Hrm... First set of panels done, tested, and installed in the pit! (I refuse to include the clip from Willow). 128 buttons, 8 axis, 1 controller. Button 1 is Master Caution, button 128 is 'Fuel Select ->RESVR'. Second set of panels needs some re-work; a new backplane and I have to change a remote keypad into digital switching. Once it's done 126 buttons and 8 axis, 1 controller. Should only take a couple days. Then on to the third set, of which only one panel needs work. 110 buttons, 8 axis, 1 controller. When I tackle DCSBios Ithat Arduino Mega I've had forever comes out of it's box. That's for later. Once I'm done with v2.5 there are other projects that have priority over DCSBios. Like flying. The wife's monitor stands. Vacation. More flying. Might finally build that mantle for the fireplace if I come up with a design I like.
  8. Learned something new last night after a few hours of troubleshooting. Keypads (switch matrix) in Arduino/Teensy don't like long cables, and for the purpose a meter is a long cable. For v2.5 of my pit I'm using 16 port I2C chips to go from 7 controllers to 3, which involves a controller on every other panel (or so), and ran into keypad problems. A little troubleshooting, followed by a little DuckDuckGo, pointed out the problem. Now I'm abandoning keypads and using those momentary switches as digital inputs. Turns out I2C, encoders, analog, and digital don't mind the long wires as much. Analog might care a little; I've had to calibrate my axis in joy.cpl to make them all work right. Still looking to see if there's another option; if not a backplane may need rebuilt to add another I2C to the next set of panels, but we'll see how many pins I have left. Not sure anyone else is as crazy as me, but thought this was interesting.
  9. Stupid Licensing Question Part II: Every once in a while it tells me someone else has logged into my account and boots me out the door. My gut is it does this when my IP changes, because the only other machine I could log in with is shut down. Does the IP switch annoy the licensing $dieties and do I need to worry about BigNewy showing up in the middle of the night to claw my face off?
  10. I've never used the Constellation. Virple should send one to me so I can try it out and maybe love it more than the MongoosT. Love my MongoosT-50CM2. Have it center mounted on an extension with a right hand cant so it fits my hand angle perfectly. With the extension on a WarBRD base there is exceptionally fine control, which allows me to easily, and repeatedly, fail to catch the basket during air to air refueling. It was a beast sitting on the desk, though. You really need a mount unless your desk starts out too low.
  11. THAT is a brilliant question, and I don't have an answer. Mostly because I won't use a browser written by an advertising company and haven't gotten into DCS-BIOS. For now I just use joystick inputs mapped in DCS. The advantage, maybe, is I can use controls to do different things in each aircraft, because my pit isn't dedicated to a single aircraft. The REAL downside is mapping 300+ controls in every aircraft, and I have them all, is a PITA. Probably part of the reason only a handful get flown. The other downside is I don't get feedback from DCS and can't do cool things like mirroring UFC displays in my pit. My gut is eventually I will have a combination of DCS-BIOS for communication from DCS to the pit and and joystick inputs. That's a guess at this point. Some day my throttles will move when I use auto throttle (assuming I live that long), but...small steps. Some day my panels will be illuminated like yours, but not this iteration
  12. the encoders I use are 4/indent. This is the code I came up with to do single click per indent #include<stdDisclaimers.h> long encoderPosition = 0; void loop() { // Let's look at the encoder first long newPos; newPos = encoder.read(); if (newPos != encoderPosition) { if ( (newPos - encoderPosition) >= 4) { Serial.println("Click Right!"); Joystick.button(clickRightButton, 1); encoderPosition = newPos; } else if ( (newPos - encoderPosition) <= -4) { Serial.println("Click Left!"); Joystick.button(clickLeftButton, 1); encoderPosition = newPos; } } else { Joystick.button(clickRightButton, 0); Joystick.button(clickLeftButton, 0); }
  13. Oh, and PLEASE don't take this critically, but you will love yourself later if you clean up your wiring. Trust me. One of these days I'll send a picture of the far messier wiring I allowed to persist on the last iteration of my pit, and it was a major pain in my posterior. Worse, I already knew better, so that was all on me.
  14. Try adding a delay in your loop. As always the disclaimer is I don't code for actual Arduino, so the syntax might be slightly different (I really should dust off my Arduino and write a couple sketches for it)... void loop() { DcsBios::loop(); delay(25); }
  15. The reason I went with Teensy over Arduino originally was the outrageous number of digital pins it had. You can use I2C to make up for the lack of pins, though. 8x16 port I2C chips is 128 buttons, which is all you get with DirectX anyway. 128 buttons and 8 axis/sliders. Speaking of which, I need more 16 port I2C chips. Welcome to the wonderful world of Panel Creep(tm), where you originally decide all you really need is landing gear and master arm, but you end up with the Starship Enterprise... Without actually adding everything together I'm over 300 button positions and around 20-ish axis. Not counting throttle, stick, pedals, and 3 Cougar MFDs.
  16. Download and install the Arduino IDE. There's all kinds of documentation there as well. Here again, never programmed a genuine Arduino (I use the IDE, though).
  17. The code looks like this. One button is always down; either one of the two real buttons, or a third 'ghost' button that's active any time the others aren't. I wrote it with arrays so adding new button sets would be easy. Tested in DCS, and it looks like a 3 position switch. Of course I wrote this for Teensy; Arduino might look a little different; even if it does the idea would still be the same. /* * This is a test to turn an ON-OFF-ON switch into an ON-ON-ON switch */ const byte switch3PNumber = 1; // Number of ON-OFF-ON switches to manage int switch3PPins[switch3PNumber][2] = { //Pins the two 'real' switches are attached to {7,9} }; int switch3PButtons[switch3PNumber][3] = { // Buttons to 'press' depending on the switch position {50,51,52} }; void setup() { Serial.begin(9600); for (int i = 0; i < switch3PNumber; i++) // Set the pullup resistors on the actual ports { for (int x = 0; x < 2; x++) { pinMode(switch3PPins[i][x], INPUT_PULLUP); } } Joystick.useManualSend(true); } void loop() { for (int x=0; x < switch3PNumber; x++) { if (digitalRead(switch3PPins[x][0]) == LOW) // If button 1 in down then press it { Joystick.button(switch3PButtons[x][0], 1); Joystick.button(switch3PButtons[x][1], 0); Joystick.button(switch3PButtons[x][2], 0); //Serial.println(" 1, 0, 0 "); } else if (digitalRead(switch3PPins[x][1]) == LOW) // If button 2 is down the press it { Joystick.button(switch3PButtons[x][0], 0); Joystick.button(switch3PButtons[x][1], 0); Joystick.button(switch3PButtons[x][2], 1); //Serial.println(" 0, 0, 1 "); } else // If neither button is down push the ghost button { Joystick.button(switch3PButtons[x][0], 0); Joystick.button(switch3PButtons[x][1], 1); Joystick.button(switch3PButtons[x][2], 0); //Serial.println(" 0, 1, 0 "); } } Joystick.send_now(); delay(25); }
  18. I've decided to wait on DCS-Bios; partly because that's a much bigger task, and go with v2.5 of my pit. Started soldering today, in fact. Using 3 teensys, which are basically a clone of the Arduino configured as serial/KB/Joystick/mouse along with, roughly, 15x16 port I2C chips (5 per controller). ~128 buttons and 8 axis each. Total of 6 panels, with controls for the F/A-18, F-16, some F-14 bits, and even a P-47 switch or two. With all that there isn't much that can't be done. Air Force and Navy with a dash of WWII. They mostly follow patterns. For my purposes I use ON-ON, (ON)-(ON), and ON-ON-ON NKK switches, some 1-10 position (adjustable) rotaries, and a bunch of ON-(ON) push buttons. There's actually a LED or two that will be wired in anticipation of DCS-Bios being ready for me (or vice versa; right now Chrome is the deal breaker). ON-OFF-ON will work if the DCS controls are configured right; not all of them are. Otherwise you need a software layer, or you could probably make them ON-ON-ON in code if you worked at it. I just wrapped up the code to make the eject button light up briefly when you push it, and played with it until if you wait until it goes off to push it again you'll never eject. It's not good for much, but it was a fun problem. Maybe I'll work on that; I do have a couple ON-OFF-ON switches laying around. One thing with <that other sim> you'll need to know button numbers, which is why I also made the boards serial. I can use Serial.write to kick out diagnostic and informational messages. I can neither confirm nor deny that lives on a different drive and I'd like to get the pit set up for that as well. If you need details you came to the right place; lots of people on here that are way smarter than me and can help you solve your problems.
  19. Sweet! Thanks! That just saved me a bunch of time!
  20. Downloaded DCS-Bios for Flight panels, followed the setup guide with no issues until I got to step five; the bit about Chrome which does not nor will ever exist on any computer I control. Ignored that part, totally failed to understand step nine (socat folder), and ignored that part. Figured I'd run into problems. Tried to open control_reference.html in Firefox, which does exist, get a blank page. Is this mess salvageable?
  21. Thanks for the advice! I'm curious what happens when you push the fuel duration/range estimate button? I do, however, confess to being SO the year before the year before last. I used to be able to read punch cards by looking at them. Never got that good with paper tape, though... Renaming is done in a .c file with the same name as the sketch in the same folder. Maybe Arduino works differently, but they seem to program the same. Heck, you have to have Arduino loaded to program a Teensy. This is from one of the Rev1 attempts; really just a button box I used before I bought the dedicated game machine. In this case RMon meant the box lived under the right monitor. IIRC errors compiling with the added .c were nagging struct issues, but I always got it to work. Now I don't remember the nags, though. I'm sure I'll have to solve this again, too. #include <usb_names.h> #define MANUFACTURER_NAME {'P','i','c','c','o','l', 'o'} #define MANUFACTURER_NAME_LEN 7 #define PRODUCT_NAME {'R','M','o','n'} #define PRODUCT_NAME_LEN 4 struct usb_string_descriptor_struct usb_string_manufacturer_name = { 2 + MANUFACTURER_NAME_LEN * 2, 3, MANUFACTURER_NAME }; struct usb_string_descriptor_struct usb_string_product_name = { 2 + PRODUCT_NAME_LEN * 2, 3, PRODUCT_NAME };
  22. I use matrix setups quite a bit, but only for momentary switches. In fact, all of my momentary switches are put into a matrix; the current UFC has 40 buttons on 13 pins. It works out that the majority of the switches I use are toggles, and you can't put toggles in a matrix due to the multi-press limitations. There's a little bit of voodoo to do a matrix right, but I use bounceless NKK switches and just know not to engage more than one at a time, so I don't bother with it. I also don't use any third party drivers or software, simply because every layer increases the failure cross-section and muddies up the underlying OS. Windows is fragile enough without help. That, of course, changes when I use DCS-Bios, but it will mostly be used for feedback rather than input. My current rig only depends on the standard Windows USB HID drivers and the controls are mapped directly in DCS. I haven't read all the details of this post, but will; I'm always in the market for better ideas and will absolutely go through it. Thanks for the link! One of the other nice things about Teensy is you can (and I do) name them. DCS doesn't see the name, but I can edit device names in DCS. Windows does see the name, so they're easy to sort in the OS. That might be possible with Arduino, but I haven't bothered to look yet.
  23. Teensy 3.6 has 57 digital and 6 analog pins that cannot also be used as digital. If you're willing to sacrifice digital pins there are three I2C channels, 26 analog, a bunch of SPI, and a choir singing Christmas carols. The only advantage I saw over Arduino when I first started was the outrageous number of digital pins, because I wasn't smart enough to use I2C back then. I ran out of pins on more than one panel, and used a couple Teensy LCs when I couldn't pawn off the extra pins on to a different board. This is why I have a box full of Teensy 3.6 and LC boards, a Teensy 4.1, and an Arduino Mega. Hence my Teensy bias; absolutely nothing against Arduino. For my next trick the plan is to leverage DCS-Bios and do the simply impossible, which is have a mater caution button that actually LIGHTS UP when there is a Master Caution. Ok, I'm starting small, but I have some big ideas. I've never used BCS-Bios before. What is really going to kill me is the labels for my illuminated panels. All my work has been done in Visio, because I have it and know how to use it, and that ain't gonna cut it. The only tool I have is a pretty generic Chinese CNC, and making the base panels won't be hard. It's the engraving that scares me, so I'm putting it off and doing the electronics.
  24. Thank you, sir! 79 modules available. Sheesh. Who said this was free? With all the new stuff coming out it's just going to get worse...
  25. I've started work on the next iteration of the homepit, which should have some extra bells and whistles. Much to my horror I realized all the sketch code for the existing pit got lost, so I've had to start from scratch on a few things. One of the problems I want to solve is the need for far too many boards. The obvious solution is to use I2C, which isn't the most intuitive thing in the world, but by using MCP23017 I2C chips and an Arduino/Teensy board (I use Teensy) you can get 128 buttons on 4 wires (2 data, +3.3V, GND). 128 is the limit allowed by DirectX. Then again, you can also add six axis and two sliders, but that's a different post. I haven't figured out if DCS can handle the sliders yet; it reads all 6 axis. Some people have asked for the sketches I use, so I'll go ahead and post the test setups. Combining multiple components would obviously require merging the test code and setting pins and button numbers correctly. For the I2C I can map ports on chips to specific button numbers. Here is the (lightly commented) sketch I put together tonight, and tested with good old fashioned joy.cpl on windows 10: /* * Use the 16 bits of a MCP23017 as digital pins for switch contacts. This reads the I2C bus and converts the ports on the chip * into joystick buttons. If using multiple chips change deviceCount, add the address to device[], then add the rows to portState * and portButton. You can address up to 8 chips, but that's 128 buttons, which is the limit for a joystick. The address pins * are 15, 16, and 17. The SLC and SDA wires connect to all the chips, as does power, ground, and !RESET * * Much of this is from https://teensyhauptwerk.wordpress.com/2014/01/17/more-switches-i2c-example/ with the rest from me */ #include <Wire.h> const byte deviceCount = 1; byte device[deviceCount]={0x20}; const byte GPIOA=0x12; //IO pins, port A (pin 18) const byte GPIOB=0x13; //IO pins, port B (Pin 19) const byte GPPUA=0x0C; //pull up resistors ,port A const byte GPPUB=0x0D; //pull up resistors ,port B int portState[deviceCount][16] = { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1} //Set all the ports to defalt high (unpressed) }; int portButton[deviceCount][16] = { {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16} //Joystick button numbers associated with each port }; void setup() { Wire.begin(); Serial.begin(9600); Joystick.useManualSend(true); for(int y=0; y < deviceCount; y++) { seti2cbyte(device[y],GPPUA,0xFF); //enable pull-up resistors on port A seti2cbyte(device[y],GPPUB,0xFF); //enable pull-up resistors on port B } } byte geti2cbyte(byte address, byte ptr) { Wire.beginTransmission(address); Wire.write(ptr); Wire.endTransmission(); Wire.requestFrom(address, 1); // request one byte of data from MCP20317 byte inputs=Wire.read(); return inputs; } void seti2cbyte(byte address, byte ptr, byte value) { Wire.beginTransmission(address); Wire.write(ptr); // set MCP23017 memory pointer to GPPUA address Wire.write(value); // enable pull up resistors Wire.endTransmission(); } void loop() { for(int i = 0; i < deviceCount; i++) { byte port_a = geti2cbyte(device[i],GPIOA); //get status of pins 1-8 byte port_b = geti2cbyte(device[i],GPIOB); //get status of pins 21-28 int tester=1; //test each binary bit of "port_a" to see if pin is LOW, so 0 // use binary AND to do this with a mask 1,2,4,8,16,32,64,128 for (int x=0; x<8; x++) { if ((port_a & tester) == 0) { //the BIT is LOW, so check the current stored state for that bit. If the current state is different, send the appropriate joystick command if (portState[i][x] == 1) { Serial.print(x); Serial.println(" is pressed!"); Joystick.button(portButton[i][x],1); portState[i][x] = 0; } } else if (portState[i][x] == 0) { //The bit is high, or unpressed Serial.print(x); Serial.println(" has been released"); Joystick.button(portButton[i][x],0); portState[i][x] = 1; } //then do it all over again for the other 8 bits on the chip if ((port_b & tester) == 0) { //the BIT is LOW if (portState[i][x+8] == 1) { Serial.print(x+8); Serial.println(" is pressed!"); Joystick.button(portButton[i][x+8],1); portState[i][x+8] = 0; } } else if (portState[i][x+8] == 0) { Serial.print(x+8); Serial.println(" has been released"); Joystick.button(portButton[i][x+8],0); portState[i][x+8] = 1; } tester=tester*2; } } Joystick.send_now(); //Send control states delay(5); } My first recreation was a way to use a five pin rotary encoder with a push button. I use several on my current pit and they're a pain the way I set them up; the indents are not 'single press', so you turn one indent and the 'button' is pushed several times. Think 'Channel select' on the F/A-18's radios, and then try to settle the encoder to the right channel in between the indents. The push button bounces, as well. Also if you turn them too fast they can appear to go backwards. As long as I had to re-invent that wheel I made each indent one push of the button and got rid of the bounce on the push. The backwards trick is still there, but you have to work harder for it. This is the sketch I used to accomplish all that: /* * Addicore encoder turned into basically three buttons, one for a click to the right, one for a click to the left, and one for push * Also, the push button bounces BADLY, so special handling * * Type: Serial, Keyboard, Mouse, Joystick */ #include <Encoder.h> #include <Bounce.h> const int encoderButtonPin = 0; // Pin number for the SW contact const int clickRightButton = 10; // Button number for a clockwise turn const int clickLeftButton = 11; // Button number for a counterclockwise turn const int clickPushButton = 12; // Button number for a push // Change these pin numbers to the pins connected to your encoder. Encoder encoder(2, 1); // Pin numbers for CLK, DT; in this order clockwise is positive and counterclockwise negative. The encoders I have count 4 between indents Bounce encoderButton = Bounce(encoderButtonPin, 10); // 10 ms delay void setup() { pinMode(encoderButtonPin, INPUT_PULLUP); Joystick.useManualSend(true); Serial.begin(9600); Serial.println("Addicore Encoder Test:"); } long encoderPosition = 0; void loop() { // Let's look at the encoder first long newPos; newPos = encoder.read(); if (newPos != encoderPosition) { if ( (newPos - encoderPosition) >= 4) { Serial.println("Click Right!"); Joystick.button(clickRightButton, 1); encoderPosition = newPos; } else if ( (newPos - encoderPosition) <= -4) { Serial.println("Click Left!"); Joystick.button(clickLeftButton, 1); encoderPosition = newPos; } } else { Joystick.button(clickRightButton, 0); Joystick.button(clickLeftButton, 0); } //Then the button if (encoderButton.update()) { if (encoderButton.fallingEdge()) { Serial.println("Click Button"); Joystick.button(clickPushButton, 1); } else { Joystick.button(clickPushButton, 0); } } Joystick.send_now(); // Send control states delay(25); // This will also keep buttons pushed. You can be too quick on a button when you're sending them programmatically } I'll add posts as I solve some of the other Arduino/Teensy problems. There is some coverage for those, but it seems not that much.
×
×
  • Create New...