Jump to content

doveman

Members
  • Posts

    1418
  • Joined

  • Last visited

Everything posted by doveman

  1. Here's a photo showing the plastic ball at the base of the stick, with some markings at the rear which may be scratches, although the surface feels smooth What I don't like is the feeling of 'steps' when the FFB is engaged, so it makes it stick and then jump as I move through these 'steps' and I don't have the fine control I want and need when flying helos. As it isn't sprung and stays where it's left even without the FFB, I might prefer it without the FFB active but that rather defeats the purpose of buying this stick and I could have probably spent the money on something else to do that. With the FFB active, it seems to center itself too far forward, even after repeated calibrations, as shown here:
  2. OK but the Steam DCS openbeta 1.2.8 doesn't recognise them as activated, so what do I do?
  3. Ah thanks, that's fixed that weirdness :) Unfortunately, it still jerks a bit when trimming, so that it doesn't trim to where I have the Shark flying, even if I hold her steady for a bit before clicking it, but jerks left or right a bit, making me turn when I'm trying to fly straight. Pretty much the same problem I had with my non-FFB stick and which I hoped this FFB one would cure. Maybe the motors are just knackered and not doing what they should be when I click trim. Should there be any rumble/vibration effects from the stick, as I'm not getting any as far as I can tell?
  4. I was just wondering about that, whether the Steam version stores the keys in a different location. Yeah, I've got all the modules installed and unlocked in 1.2.7 standalone but those keys aren't being picked up from the registry by Steam DCS. In fact, if they were, surely we wouldn't need to enter the keys again via 'Activate a game on Steam', which makes me think this stores the keys somewhere else as well. The registry key is a bit confusing, as it has Current User\Software\Eagle Dynamics and under that Black Shark 2\Keys DCS World\KA-50 and P-51D (no keys here) UH1H\Keys Warthog\Keys
  5. So I did the 'Activate a product on Steam' thing for my KA-50, UH1H and A-10C modules, all bought ages ago and when I launch DCS now it popups a window with my keys and says I need to copy them and enter them when DCS launches but there's nowhere that DCS prompts me for them. Anyway, the KA-50 is unlocked now but the other two modules remain locked, so how do I unlock those as well?
  6. I just got a FFB2 I bought on e-bay. The worst problem is that when I trim in the KA-50, it jerks into a completely different position. So if I move the stick left and trim, it jerks forward, if I move it right and trim, it jerks backwards, forward it jerks right and backwards it jerks left. The more I move in any direction before trimming, the more severe the jerk, so if I move it all the way left and trim, it will jerk too full forward. It does it whether I quickly click trim or press and hold, move the stick, then release trim. I've calibrated it in Windows and tried with 1.2.7 with mods and 1.2.8 without any. Apart from that, it's quite scrapy/dry moving it around without the FFB activated, which is even more noticeable when the FFB is activated, the motors emit a high-pitched whine in several positions (back left, back right, forward, backward) and button 8 doesn't work properly (takes about three hard presses for it to trigger). Should I just return it or is it savagable? I can't really open it up to check anything as then the seller will say I broke it and not accept it back.
  7. Another nice thing I've found is that X-Plane always keeps any existing datarefs/commands valid, even when they add new ones for whatever reason, so existing setups don't get broken. If ED took the same approach, as well as maintaining an updated list of all the valid datarefs/commands like X-Plane does, I think it would make everyone's life a lot easier. So how about it ED?
  8. Is this compatible with the Rift?
  9. I'm just going by the dozens of posts by people who seem to know what they're talking about that repeated click-trimming is the proper Russian way to fly the KA-50. Thanks for taking the time to make those scripts. Unfortunately I don't have a TM Warthog but it just goes to show that ED could implement something similar for all non-FFB sticks if they could be bothered.
  10. Ah, I see. I'll probably use all wood, maybe acrylic for the front once I've done a few dummy builds to iron out the issues that will undoubtedly only become apparent when I go to put it together, lol. I'll probably put a base and back on it, even if only to keep the dust out.
  11. Looks great Gothic. I'm planning to build something very similar, albeit with a larger face at a steeper angle just for switches and other controls to go next to the monitor. What did you use to attach the front panel to the frame? I was thinking of using wooden blocks screwed to the side panels which the front panel could then be screwed into but they'll be a bit chunky.
  12. Well that sucks, as the TM Warthog isn't really ideal for flying helos and the X-55 would have been much better with the spring removed I think but there's no point buying it if it's poor quality. Guess I'll have to keep trying to find a s/h FFB2 and make do with the limited amount of buttons and no HOTAS :(
  13. Well assuming that's all correct, I'd still consider it a bug if it's not possible to fly the KA-50 properly (by which I mean the Russian click-release method, I don't like using the click-hold method) with a non-FFB stick, which an awful lot of people have. I've suggested some methods that might fix this problem before, to enable non-FFB users to rapidly click-release without having to recenter the stick, such as having a button to hold which makes the sim ignore the stick, so after we've finished trimming and are in steady flight and want to be able to let go of the stick, we hold this button, release the stick to center and then release the button and the physical stick would be centered whilst the virtual one is trimmed where we left it. Or after clicking trim, treat the current physical stick position as input 0, so that it doesn't add anything more if we don't centre it, then only recognise further movement away from the centre but ignore movement back towards it, as generally when trimming you're meant to bank/pitch a little and trim, then a bit more, trim, etc until you get to where you want it, so you'd do that then release the stick to centre. Maybe they're not the best solutions and ED can come up with something better but I feel they could do something like this if they were interested in non-FFB users being able to fly the Shark. I almost got a FFB2 but the e-bay seller turned out to be a joker who didn't send the stick or any messages and after I opened a case, said he'd been busy with a new job, miscalculated the postage (now he reckoned it was going to cost twice as much as every other FFB2 seller is charging to post it) and asked for some more money. I told him to get lost and give me a refund, which he did at least but it means I'm stuck with my non-FFB stick for now.
  14. OK. So I guess you're saying I could drive it by using three digital pins as outputs to the DIN, CS and CLK pins? I don't think that's going to be good for me though, as I need to drive multiple displays and don't want to use up loads of digital pins, hence why I want to use the SDA/SCL I2C bus with an AND gate. Maybe I could use an AND gate with just three digital pins to do the same thing though? I don't really see how I could drive it from the two I2C pins when it requires three input lines. I had a look at the datasheet but couldn't see anything that suggested that it would be possible. If I can't use an AND gate with the three digital pins though, I guess I can just buy the LED segments separately and build the circuitry to drive them via I2C myself. I just saw these and thought it would be a nice way to save myself a bit of work and have something all ready to screw into the panel. :) Pete, if I'm wrong and can drive these via the I2C bus, please jump in.
  15. I've started or posted in several threads about this problem in the past. Most people just said I must be doing something wrong but I've never found a way to make the click-release trim method work without the KA-50 oversteering (i.e. lurching forward or to the left or right) and have had to just resort to using the click-hold method, which I don't really like using as it disengages the AP and makes the bird a bit unstable but it's better than the alternative. I'm sure it must be a bug as the correct (i.e. Russian) method is click-release and they wouldn't be able to use it, if it actually oversteers like that in real life. I don't have a FFB stick and have tried both the old and new center trim methods. I've bought a FFB2 on e-bay so I'll test with that once I get it to see if it's any different. Although I'm not sure I'm going to get it, as the seller's gone dark on me :mad:
  16. Sorry, I'm too dumb to understand that ;) Does that mean it can be driven via the I2C Bus (using just SDA and SCL, via an AND gate to drive multiple displays)?
  17. Awesome Boltz, can't wait to have a play with it :)
  18. I've seen this http://www.ebay.co.uk/itm/321321910472?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT and was wondering if it's something that can be driven via the I2C bus (through the AND gate circuit) or not, as it seems to use three data pins and none are labelled SDA or SCL?
  19. Exciting news Boltz, even if I probably won't be in a position to use it when you release it :) Great idea to release what you have ready I think, so that people can benefit from your work and they have V2 to look forward to ;)
  20. Yeah, it seems that ED don't take care not to change things in terms of export/input and cause problems for people who've got things setup already and another problem is that they use non-user friendly IDs, rather than easily understood datarefs/commands like X-Plane, so it would be great if they could understand the benefits of copying that approach. Of course, once we have A2DCS things will be a lot easier for those of us using Arduinos but even if ED did see the light and improve things, A2DCS would still be very much needed as an easy way to interface between DCS and Arduino and translate the signals between the two. Thanks for the attachments Boltz, they are helpful to see how DCS works at the moment.
  21. Thanks dok_rp, that's really helpful. I was concerned that the Warthog might not be ideal for flying helos and it sounds like I was right to be. I'll keep looking for a FFB2 for helos and maybe get a X-55 or Warthog in the future for the A10-C and other planes.
  22. That's great Peter, much appreciated :thumbup: I looked up the 4081 and I can see I misunderstood the diagram to show individual components at the Ux,x parts, when in fact they're just pins on the 4081 (or whatever other AND gate chip) and what I thought were diodes are in fact LEDs. So I think I know what I need to get to build this now, thanks.
  23. Hey Boltz, Regarding the toggle switches, all I was thinking is that say you're flying and crash, when you restart then all the toggle switches might be in a different state to the sim and it would be a pain to have to set them to match. I guess from a cold start it wouldn't be a big deal, as you'd just need to set everything to off and start from there but if doing a warm/in-air start then maybe it could get tricky making the toggle switches match the sim switches without causing problems. Using momentary buttons and LEDs (whether built-in to the buttons or external), when restarting the LEDs would reflect the status of the virtual switches without the user having to do anything. I'll probably just use toggles or rockers though, for my first panel at least, as it's going to be much more complicated using momentaries and LEDs. I hadn't actually thought about having to solder up 18 7-segment LEDs for my radio/autopilot displays. I guess I thought I'd be able to get them in blocks and drive them with two wires using the I2C bus, like these OLED displays http://www.ebay.co.uk/itm/0-96-I2C-IIC-SPI-Serial-128X64-OLED-LCD-LED-Display-Module-for-Arduino-white-DE-/251499783216?ssPageName=ADME:L:OC:GB:3160 but I realise now that 7-segment LEDs don't work like that. I did find this mind but I don't think that uses I2C, so I'm not sure how that would work http://www.ebay.co.uk/itm/5V-MAX7219-8-Digit-Red-LED-Display-Module-7-Segment-Digital-Tube-For-Arduino-MCU-/321321910472?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item4ad04740c8 It'll be great if you can incorporate X-plane into A2DCS. I have a dream of running generic code on the Arduino and using a program like A2DCS to map the generic I/O to the various sims and quickly switch 'profiles' depending on which one we want to fly. :D Anyway, don't let my suggestion about X-Plane make you delay releasing until you've added support for it. It will be great to have it just for DCS for now.
  24. @Peter, I wonder if you could tell me what components I should use for this AND gate, for the Ux,x and D parts. I'd like to get this built so that it's ready for when I come to hook up the OLEDs. If you don't mind sharing your Arduino code that drives the OLEDs via the gate, that would be really great too.
  25. X-Plane uses what it calls datarefs for sharing instrument (and other) data and commands, all with permanent names, for actions the sim can take. A simple explanation and examples are here: http://developer.x-plane.com/2009/04/datarefs-vs-commands-i-whats-the-difference/ and the full list here: http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html With all the difficulties in DCS with editing lua files to enable exporting data and commands changing, so that people have to edit the files again to get things working that have been broken, I've been wondering if DCS wouldn't be improved and made easier to manage if it just used a similar method to X-Plane? I don't see why special export files should need to be created to make the data available for display in other programs or pit instruments/displays. In X-Plane, you can just tick the data you want enabled (or displayed on screen for testing purposes) which is so much easier. For the commands, we could have something like: dcs/ka50/autopilot/altitude_arm I figured we might need to specify the aircraft at the second level but maybe that's not necessary and just using dcs/autopilot/altitude_arm would work fine and be translated internally to the relevant switch (or ignored if the aircraft doesn't have that function). There will be some commands/datarefs that only work/apply to some aircraft but that shouldn't be a problem. I think this would not only make it easier for pit builders but also for stick owners, as it would allow for a separate app, whether official or third-party, to map stick axis/buttons to these commands, which could be a lot easier than doing it in DCS's current GUI and even if commands are added in future, the existing ones would stay the same. So once the stick config file is setup with: Button 1 = dcs/autopilot/altitude_arm Button 2 = dcs/autopilot/trim and so on, that won't be affected by any update and no-one should ever have to map all the buttons again, unless they want to change them of course. Anyway, what do people think?
×
×
  • Create New...