Raisuli

Yeah...the clickbait image and (worse) opening line was almost enough for me to avoid the entire channel. I did ignore this for quite a while but watched it eventually. One thing that raised an eyebrow was the bit about Soviet ships having to steam in port due to the lack of shore facilities (power/water/CHT). I haven't heard that from any other source, but it would be interesting to be able to confirm/deny it. Of course there are other things that explain the state of the Soviet Navy, and specifically the state of the Soviet Nuclear Navy, which I have understandably more interest in. I'm not a fan of the term 'systemic', but there were/are systemic problems involved. I would dearly love to tour some of those old Soviet boats/ships and see how they compare to what I'm used to. Two completely different approaches to the same problem.

An exploit like an aircraft carrier on the Georgia map? Ok, at least with Georgia it's realistic; not sure how we're going to portage a CV into a puddle. The Montreux Convention makes a carrier in the black sea highly unlikely. Geography makes it even less likely. The Kuz is an 'Aviation Cruiser' for a reason.

I read somewhere that BRC can change in the middle of recovery without any warning as the boat adjusts course to keep the wind over the deck, which means the pilots have to adjust their landings accordingly. They must be professionals or something, because I'm lucky to get down when the boat isn't twitching around on me. I did a bunch of touch and gos and let the group get to a turning point once. That was ugly.

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!

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

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)

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...

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...

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.

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.

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.

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?

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.

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

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); }

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.

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); }

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.

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).

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); }

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.

Sweet! Thanks! That just saved me a bunch of time!

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?

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 };

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.