lesthegrngo

After replacing the TM Warthog joystick base with the CM2 I'm very happy with the smooth movement and general feel, plus the sensitivity, it has definitely improved my experience. However I use it with a 150mm extension, and the original Warthog grip. Due to the mass and the extension tube, it means that if you move the stick and let it go, it's nearly 15 seconds before it stops wobbling about. I believe a couple of dampers (or maybe three in a triangle) would help this, and wonder if anyone has tried anything. I think I can come up with something using RC car suspension dampers but if there is something preexisting I'm interested Cheers Les

Hi all, on the A10C module I used to have a set of the Saitek Pro pedals, and while they were a bit wobbly until they broke, at low speeds and during takeoff I was able to control the ground steering without any issues. However with the MFG Crosswind pedals, despite going to controls > tune axis and setting it to have a curve with very low sensitivity around the center, if you just touch the pedals the steering really dives off in that direction I've tried reversing the curve, and played around with it all, but it seems to have no effect in game, almost like it is being overridden by some other setting. In the air its fine, but on the ground its awful I can only see one rudder axis that applies to both nosewheel steering and the rudder; i know you also have the separate toe brakes, but this is the rudder axis causing issues Has anyone seen this and has some workaround? Cheers Les

Now I have to open 6 com ports for the ESP32 and Megas each time, I really need to be able automate it as it's a pain to have to do every time. There was an earlier iteration of DCS Bios that actually had a Web based interface that did this, but the Flightpanels fork seems to have dropped it, which is a shame as it was very convenient. Is there any way that this can be used? If not, then a guide on setting up the SOCAT thing would be helpful, as what comes with it is not very easy to understand. It's probably quite simple but the way it is written is clearly for people who have some prior knowledge, so a 'SOCAT for Dummies' would be appreciated Cheers Les

For completeness, I can confirm that I was able to use a Mega for all the switch inputs for the A10 CDU in RS485 slave mode. All are simple two position switch callouts and bar one duff SMD switch that seemed to have partial contact even when unpressed it worked straight away Les

Just seen this topic after seeing exactly the same with my MFG Crosswind pedals on the A10. During taxi, if I breathe on the pedals it will veer that way. The old Saitek pedals were nowhere near as sensitive. I've tried adjusting the axis in controls, adding a curve with very little sensitivity around d the center but it seems to make no difference in game So there is no way to set NWS sensitivity as a separate parameter? Les

Yes, I went that way a while back after we had discussions over my setup, where I was saying about the way to deal with making the RS485 setup for me was to have a mega using three slaves, on each for the side consoles and one for the dash instruments - here's the discussion we had https://forum.dcs.world/topic/208455-dcs-bios-over-rs485/page/7/ I found that it really helped my setup and worked well, of course as we know now up to a point. Having said that, the extra Mega has simply cured all my issues with RS485, so while it may not be the most elegant solution, I am happy with how it works. I expected the two Megas to interfere with each other, so that was why I didn't think it would work If I was younger and could get my head around all the electronics stuff better, I probably could have devise a way better setup, but like most of us (I suspect) I just kept trying things and when it worked I kept it, but the next thing learned from the prior issues. As a result there is a lot of sub optimal stuff on my rig that would not be done like it is if I ever did this again Les

****edited as the basic issue is resolved, just leaving the discussion for reference**** All, this thread https://forum.dcs.world/topic/318814-increasing-the-sensitivity-of-ir-digital-position-sensor/#comment-5290335 shows what I have done so far, but I am being frustrated by the fact that I am not happy with the whole altimeter. The zeroing works great, as soon as you power up it will zero immediately and correctly. However once the gauge is used via USB in game it is not so good, with despite playing around with the stepper config max steps it never really matches the pointer position correctly, exacerbated by the movement not being constant - to explain, even in a steady descent with the in game pointer rotating at a steady speed, the physical pointer will more to fast for part of the rotation, and then slow down too much for another period, then speed up etc. It seems random, so the sketch I am using isn't really keeping control of the pointer. Things are worse still on trying to go to RS485; I managed to get it 'working' but it stutters constantly and is just not good. This is the code I'm using //#define DCSBIOS_IRQ_SERIAL #define DCSBIOS_RS485_SLAVE 48 #define TXENABLE_PIN 2 #include <AccelStepper.h> #include "DcsBios.h" #include <Wire.h> struct StepperConfig { unsigned int maxSteps; unsigned int acceleration; unsigned int maxSpeed; }; class Vid29Stepper : public DcsBios::Int16Buffer { private: AccelStepper& stepper; StepperConfig& stepperConfig; inline bool zeroDetected() { return digitalRead(irDetectorPin) == 1; } unsigned int (*map_function)(unsigned int); unsigned char initState; long currentStepperPosition; long lastAccelStepperPosition; unsigned char irDetectorPin; long zeroOffset; bool movingForward; bool lastZeroDetectState; long normalizeStepperPosition(long pos) { if (pos < 0) return pos + stepperConfig.maxSteps; if (pos >= stepperConfig.maxSteps) return pos - stepperConfig.maxSteps; return pos; } void updateCurrentStepperPosition() { // adjust currentStepperPosition to include the distance our stepper motor // was moved since we last updated it long movementSinceLastUpdate = stepper.currentPosition() - lastAccelStepperPosition; currentStepperPosition = normalizeStepperPosition(currentStepperPosition + movementSinceLastUpdate); lastAccelStepperPosition = stepper.currentPosition(); } public: Vid29Stepper(unsigned int address, AccelStepper& stepper, StepperConfig& stepperConfig, unsigned char irDetectorPin, long zeroOffset, unsigned int (*map_function)(unsigned int)): Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), irDetectorPin(irDetectorPin), zeroOffset(zeroOffset), map_function(map_function), initState(0), currentStepperPosition(0), lastAccelStepperPosition(0) { } virtual void loop() { if (initState == 0) { // not initialized yet pinMode(irDetectorPin, INPUT); stepper.setMaxSpeed(stepperConfig.maxSpeed); stepper.setSpeed(1000); initState = 1; } if (initState == 1) { // move off zero if already there so we always get movement on reset // (to verify that the stepper is working) if (zeroDetected()) { stepper.runSpeed(); } else { initState = 2; } } if (initState == 2) { // zeroing if (!zeroDetected()) { stepper.runSpeed(); } else { stepper.setAcceleration(stepperConfig.acceleration); stepper.runToNewPosition(stepper.currentPosition() + zeroOffset); // tell the AccelStepper library that we are at position zero stepper.setCurrentPosition(0); lastAccelStepperPosition = 0; // set stepper acceleration in steps per second per second // (default is zero) stepper.setAcceleration(stepperConfig.acceleration); lastZeroDetectState = true; initState = 3; } } if (initState == 3) { // running normally // recalibrate when passing through zero position bool currentZeroDetectState = zeroDetected(); if (!lastZeroDetectState && currentZeroDetectState && movingForward) { // we have moved from left to right into the 'zero detect window' // and are now at position 0 lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(zeroOffset); } else if (lastZeroDetectState && !currentZeroDetectState && !movingForward) { // we have moved from right to left out of the 'zero detect window' // and are now at position (maxSteps-1) lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(stepperConfig.maxSteps + zeroOffset); } lastZeroDetectState = currentZeroDetectState; if (hasUpdatedData()) { // convert data from DCS to a target position expressed as a number of steps long targetPosition = (long)map_function(getData()); updateCurrentStepperPosition(); long delta = targetPosition - currentStepperPosition; // if we would move more than 180 degree counterclockwise, move clockwise instead if (delta < -((long)(stepperConfig.maxSteps / 2))) delta += stepperConfig.maxSteps; // if we would move more than 180 degree clockwise, move counterclockwise instead if (delta > (stepperConfig.maxSteps / 2)) delta -= (long)stepperConfig.maxSteps; movingForward = (delta >= 0); // tell AccelStepper to move relative to the current position stepper.move(delta); } stepper.run(); } } }; /* modify below this line */ /* define stepper parameters multiple Vid60Stepper instances can share the same StepperConfig object */ struct StepperConfig stepperConfig = { 730, // maxSteps 2200, // maxSpeed 1000 // acceleration }; // define AccelStepper instance AccelStepper stepper(AccelStepper::DRIVER, 4, 5); // define Vid29Stepper class that uses the AccelStepper instance defined in the line above // v-- arbitrary name Vid29Stepper alt100ftPointer(0x107e, // address of stepper data stepper, // name of AccelStepper instance stepperConfig, // StepperConfig struct instance 6, // IR Detector Pin (must be HIGH in zero position) 0, // zero offset [](unsigned int newValue) -> unsigned int { /* this function needs to map newValue to the correct number of steps */ return map(newValue, 65535, 0, 0, stepperConfig.maxSteps - 1); }); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } This was based on some code produced (I think by Craig) some time back. I now want to try a clean sheet version. The IR sensor part works fine, but I would like to see if there is a revised version that works better. So, do any of you have any alternative sketches that I could try? Cheers Les

no, the terminating resistors for my design at least actually made things worse. None of the iterations made any improvement. The setup that I have now is two master Megas running in parallel, each running three MAX487 chips. No resistors at all anywhere. It shouldn't work, but it does, I can't explain it but I won't complain The problems I seem to have seem to stem from too many devices being on one slave line, so more slave lines, the less devices on each. I'm sure there's a logical reason I think I should do as No1SonUK suggested and provide a schematic for what I did Les

It's simple - I pulled another Mega out of the drawer, made another RS485 shield with 3 MAX487 chips on it, and have two parallel masters, giving me a total of six slave lines I can use. Essentially it means that there is only a limited number of devices connected to each slave line ***EDIT*** For the record I didn't think it would work, as I though it would only recognise one instance of the master, by they seem to just function as one system Cheers Les

I posted in this thread that I had solved the glitching issues by the simple use of an additional master Mega. I have to report that it has also (apparently, subject to more extensive testing) seemed to get rid of the display corruption and artefacts, random warning light illumination, gauge flickering, and also more surprisingly the switch crosstalk issues. I no longer get another switch being activated when one near it is moved. The SAS panel was particularly bad, but now behaves perfectly As a fix it was really good value for money, as it really has in one go removed a load of the issues. the only down side is it has increased the need for the SOCAT as I have to initialise 6 com ports on startup So, now on to the Altimeter, as this is the biggest fail yet to be fixed. Les

Well, I fixed the glitching problem ******PURISTS STOP READING NOW****** I followed the circuit design that puts the various resistors in, so 120 Ohm at each end between the A and B lines and 470 ohm resistors from the A and B lines to 5V and GND respectively (although lack of caution on my first attempt meant I put the 470 ohm resistors from B to 5v and A to GND). If anything at best it seemed to make everything worse, with really slow responses, and at worst just corrupted the whole lot, including those items on other slave lines. Last night I was at a group of people who were meeting for a beer or five at a neighbour's house, and people were asking how I was getting on with building the rig. During that conversation I though of something at the speed of beer - you know, one of those 'brilliant' ideas that only occur to you after you've had one too many. Why not, I thought, put another mega master in alongside the original one...? After unsuccessfully trying the other things above, the idea from last night came back to me, so I thought why not give it a go. So I did. And blow me down if it doesn't work perfectly. I have the three original slave lines from the original master Mega, and I am currently using one of three more on another master Mega, and have two spare lines in case I need it. It is rock solid, stable, all the artefacts have disappeared, anything that wasn't displaying properly now does, and there is none of the gauge twitching that I used to get. The down side is I now have one more com port to open, but that seems to be no issue. I'm sure that there will be electronics experts out there screaming at the PC about what an aberration this is and that I should go away and do it properly, and they would be right that I am only compensating for some designed in or manufactured in problem of my own creation. But it works, and so while I would like to track down what it is so that I can improve any future components or projects, the only way will stop using the second Mega is if I do fix it. Until then, it stays. So, taking my own advice, it doesn't matter how you do it as long as it works and you are happy with it Les

I will give that a go tomorrow, I'll make some removable modules with the different resistors on them. Once I can see what works I will make a more permanent solution Cheers Les

ok, 1st attempt, putting a 120 ohm resistor between the A and B channels of the HARS panel ( last one on the RH console)seems to make the RS485 line worse, with a delay when actuating a switch or potentiometer. I soldered it between the traces that take the RS485 signal from the RS485 connector to the MAX487 chip I've checked the resistance with a multimeter, and it correctly reports circa 120 ohm Any ideas? Les

Great thanks for the responses guys. Nice example there too Vinc! With the exemplar network diagram it also shows two 470 ohm resistors at the mega end, each going to the 5v and GND, I can try those too, I assume they are there for a similar reason and I am not using the RS485 modules Cheers Les

Is there a guide on how to use the SOCAT? I've found the the SOCAT folder in the scripts / programs next to the com connect that I currently use, and there is an examples text file but it seems to be written in Martian..... Cheers Les

Solved it, for some reason the external views were disabled in the MISC controls section, I can only assume during reinstallation as it would not be something I would toch Cheers Les

Found it - more by luck than anything else to be honest. I thought I had gone through the options checking before, but I assume that I must have missed it. In the 'controls', 'misc' page, there is a box 'player external views' that was unchecked. I know I didn't uncheck it, so something must have done so, maybe it is one that was autoselcted off when I reinstalled DCS. As I had no other idea what to do I was literally going through every single option in the menus An embarrassingly stupidly simple fix for something that had me stuck for weeks Les

I've posted this on a thread in the bugs section, but after weeks I still have no answer. The HUD View, the one that you get using l-alt+f1 that just shows the external view with the HUD overlay, will not display any more. I have checked the assignment in the controls to verify it is still set as l-alt+f1, and have also assigned it to an auxiliary button on a Bodnar controller. Despite this the HUD view is not selectable. I can get all the other (useless) ones and can pan around the cockpit using l-alt+C, but the one I need for my cockpit setup is simply now working. Is it part of a script or something that may have been corrupted? Cheers Les

I still have no HUD view, can anyone help with this? Cheers Les

is there any reason that the resistors can't be SMD types? Les

Thanks If I interpret this statement correctly "if you use termination, you should locate the termination networks at the two extreme ends of the cable, not at every node" I should definitely put a resistor at the furthest point on the slave line, but also at the Mega end of the line too, or am I misinterpreting? I see the use of capacitors too in multiple node termination situations but references as to what type of capacitors to use are lacking I (presumably) can make a simple mod to solder on the resistor / resistor and capacitor combo onto a patch board to add that to my existing PCB's and would do that at the end furthest the RS485 in connection Cheers Les

Hi All So now my Rig is essentially working, I'm going to try to knock off the little bits and pieces that are not quite right. In that list is some weird glitching I get with RS485 connected components, which I ascribe to me not being an electronics wizz, and probably not knowing how to correctly implement the requirements of RS485. Don't get me wrong, most work really well, but the more you add to a particular slave line the more likely it is that the glitching happens. One of the things I was doing, rightly or wrongly, was including multiple nanos onto one PCB, with traces connecting all the RS485 buses (GND, A, B, 5V) so essentially making it a solid state affair and reducing the number of wires and connectors. however this may not be the best way. For example, my Altimeter and Climb gauge PCB actually has four Nanos, each with it's own MAX487 chip. That's one each for the Altimeter and Climb gauges, and one each for the Altimeter and Baro Alt OLED's. If anyone is wondering why so many Nanos, if you drive the OLED and a stepper from the same Nano, the stepper refresh frequency is driven by the OLED display and so it becomes very jerky, and the OLED's are i2C and so as the nano has only one set of i2C pins (A4 and A5) it was simpler to use two Nanos than going to the complexity of a multiplexer. Being homemade PCB's I have to design them so that they can be manufactured with my limited facilities, so using double sided PCB board I run the traces as best I can then link any that have to cross but putting matching traces on the rear of the board, and linking the two side with bits of wire soldered through holes. Crude, but it works. Very often the GND is a common large trace that utilises the rest of the board not designated as a trace, similar to the way that a car uses the bodyshell of the structure as a common earth. The 5v bus is then woven between everything else, and again is a common 5v bus, often with a 5v supply on a dedicated connector so that there is sufficient power. The A and B busses are then normally done using traces on the rear of the board so that they can reach the MAX487 chips and the keyed RS485 cable connector. I usually solder the X27 steppers directly to the board, again using traces on the rear side so hardwiring the steppers to the nano headers. Any switches, LED's, OLED connections etc are also connected this way. It results in a vastly reduced amount of wires, and firmly attached components that don't have potential connector issues. The PCB forms a module that can be attached easily using screws to the back of the panel, which you can see in my numerous posts. It clearly isn't perfect though as the glitching phenomenon exists. I believe that the concept of the RS485 is that it is a daisy chained setup, but my use of the PCB's described above is not true to that - it's more of a spiders web, or tree in concept, with one cable connecting multiple parts of the network. I do have a main bus system that runs down the side of the console, with multiple connectors, so maybe the best way to describe it would be a house ring main circuit, with a multiple power outlet adapter plugged into each socket So is there something I should be doing to ensure that the RS485 is being given the best chance to function? Any suggestions gratefully received Cheers Les

Thanks for the responses guys, let me check into that SOCAT thing Cheers Les

Sorry for the delay in responding - yes, all missions Cheers Les

Sure, here you go Les