Jump to content
The simFlight Network Forums

Search the Community

Showing results for tags 'serial'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Product Support Forums
    • FSUIPC Support Pete Dowson Modules
    • MyTraffic Support Forum
    • FeelThere Support Forums
    • FS Commander Support Forum
    • Flying W Simulation
    • AConstable Traffic Sounds Support Forum
    • Fabio Merlo Products Support Forum
    • Elite-Air Studio Support Forum
    • Nikola Jovanovic Support Forum
    • Intrasystems Support Forum
    • FScene Support Forum
    • Taburet & DanVFR Support Forum
    • Environ Scenery
  • simFlight DE
  • FS MAGAZIN (DE)
  • simRussia
  • FSUIPC Client DLL for .NET

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. Hello, let me start by thanking Pete for his great work! :-) I am trying to replace the use of link2fs with lua-scripts. link2fs is great and it works but it seems to be no longer supported and while it finally seems to work with P3D V4 again, sooner or later it might cause problems. With the help of fess' and other examples online, I've written the following short script to adjust the QNH. I have verified using the link2fs traffic monitor that the arduino really sends "C25" and "C26" with linefeeds. The "Arduino_Data"-function also gets called, whenever I turn the rotary encoder. But that is as good as it gets. :-/ When I turn the rotary encoder slowly, nothing further happens. No datastring gets shown, nothing happens to the QNH. With the addition of the 50ms ipc.sleep before the datastring is read, the ipc.controls get executed when I turn the rotary encoder fast enough. (I assume that this happens when the com port buffer holds two Cxx-commands, because the datastring-readout that is shown in these case reads "C25C2", so one character is missing. When I am giving out the string length 'n', it is either 0, 5, 10 or 15. Something seems to quantize the datastring to multiples of 5. When I turn other encoders however, whose command is longer (e.g. "Y010"), n is 0, 6, 12, ... I've run out of ideas where the error might be and I'd be thankful for every suggetion where to look. Kind regards from Munich, Frank -------------------------------------------------------- --- VARIABLE INIT -------------------------------------- feet_per_meter = 3.28083989501312 port_number = "3" -- Change Port Number for your Arduino speed = 115200 handshake = 0 serial_wait = 20 -------------------------------------------------------- --- SERIAL COMMUNICATION INIT -------------------------- SwitchPanel_Com_Port = com.open("COM"..port_number, speed, handshake) if SwitchPanel_Com_Port == 0 then ipc.display("Could not open Switch Panel at Com Port"..port_number,5) --ipc.exit() else ipc.display("Switch Panel connected at Com Port "..port_number,5) end ipc.display("SwitchPanel script loaded", 10) -- TEMP -------------------------------------------------------- --- INPUTS --------------------------------------------- -------------------------------------------------------- function Arduino_Data(SwitchPanel_Com_Port, datastring, length) -- the code always gets here ipc.sleep(50) datastring = com.read(SwitchPanel_Com_Port,50,1) ipc.lineDisplay(datastring,-32) -- TEMP if (string.find(datastring, "C25")) then -- Increase QNH ipc.control(65883,0) end if (string.find(datastring, "C26")) then -- Decrease QNH ipc.control(65884,0) end --ipc.sleep(serial_wait) -- needed??? end -------------------------------------------------------- --- OUTPUTS -------------------------------------------- -------------------------------------------------------- function call_xpndr (offset, value) value = string.format("%04x", value) --ipc.display(value) com.write (Arduino_Com_Port, "=J"..value) end -------------------------------------------------------- --- EVENTS --------------------------------------------- -------------------------------------------------------- event.com(SwitchPanel_Com_Port, 50,1, "Arduino_Data") event.offset (0x0354, "UW", "call_xpndr") -- transponder
  2. Pete- Per your request................ Thanks for your patience and assistance (as usual). After ALL of this- my solution for the SERIAL PFC HARDWARE & THE PMDG NGX (using PFCFSX.dll v4.40 & FSUIPC v 4.859s) is the following- I put this here in the hopes of saving some other poor soul from the frustration encountered- DO NOT CALIBRATE THROTTLES OR REVERSER AXIS IN FSUIPC USE PFCFSX.dll for throttles and reversers- calibrate those axis in PFCFSX.dll ONLY FLY AND ENJOY THE NGX :) Best- C
  3. My PFC Cirrus II Yoke is not responding in FSX. With FSUIPC 4.853 installed, the device is recognized over COM1 within FSX. Throttles and switches respond correctly, but the yoke reports a solid '64' in the configuration screen. Throw the hidden switch under throttle panel and the numbers jump to '17' and flicker to '23'. Some details of the configuration: Precision Flight Controls Cirrus II Serial Flight Console (w/hidden switch under throttle panel) Windows 7 64-bit (fresh install) FSX with Acceleration Pack Lava PCIe Serial Card - 64 bit driver / tested with known working serial cable FSUIPC 4.853 pfcfsx.dll Opening up com1 via putty, I'm able to ascii scroll by as I throw switches and push buttons. The yoke also seems to send data (was trying to ensure it wasn't a hardware failure). Additional efforts: I've also tried the ELITEFS serial driver without success (same issue with yoke not working). My original goal was to get this device working with ASA IP Trainer. ASA provided me with CirrusBATD.dll and it was also unsuccessful. I'm very encouraged that Pete has gone to the trouble to author and maintain FSUIPC. I'm looking forward to being a registered user and practicing for my IFR rating. Thank you for your assistance.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.