Jump to content
The simFlight Network Forums

Paja

Members
  • Posts

    30
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://www.dc-9.eu
  • ICQ
    224401042
  • Skype
    brodha88

Profile Information

  • Gender
    Male
  • Location
    Czech Republic
  • Interests
    Gliding, sim building, VATSIM :-)

Recent Profile Visitors

815 profile views

Paja's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Thank you Roman, saved me few moments 😉 Pavel
  2. Thank you! That is probably the problem, that the L:var does not exist. Thank you! Pavel
  3. Hello, What I am trying to do is to create Lvar that will contain a value from a FSUIPC offset. I need this in order to use this L:Var using Air Manager later on. I am tesing on simple dewpoint value: while 1 do dp = ipc.readSW("0E8E") ipc.display("dew point from offset"..dp/256) ipc.writeLvar("L:DEWPOINT", dp) dpL = ipc.readLvar("L:DEWPOINT") ipc.display("\n".."dew point from Lvar"..dpL) ipc.sleep(50) end Which returns error into FSUIPC log "2651078 *** LUA Error: ...s (x86)\Steam\steamapps\common\FSX\Modules\Meteo.lua:9: attempt to concatenate global 'dpL' (a nil value)" I am trying to .display both the values to check if the read and write is working. I will remove the display later on Do I need to introduce the L:DEWPOINT var before? --------------------------------------------------------------------------------------------------------------------------------------------- while 1 do dp = ipc.readSW("0E8E") ipc.writeLvar("L:DEWPOINT", dp) ipc.sleep(50) end With this minimalistic code there are no errors in the log, but the Air Manager seems to read "0.0" from L:DEWPOINT variable. Thank you! Pavel
  4. I know about using the other computer to slave, standard thing. I was just thinking about using the lowcost Linux boards - but if it is not possible, ok - thanks for info. I will try Lua to send the data, thanks :) Pavel
  5. Hello Pete, have you considered developing the WideClient for Linux? It would be very useful together with all those ultra cheap minimalistic Linux computers (Raspbery Pi, Arduino Yun, etc). They are small devices that can run simplistic version of Linux, so if we had WideClient on them, we could hopefuly access FSUIPC variables remotely via LAN - it would be easier than having ton of USB or RS232 devices connected to the flightsim computer with lot of their custom applications running... Pavel
  6. I have never been completely sure about which of those "DBl, FLT, DD, SB, SD, etc) types should I read so I have done this small LUA file which will help you to decide. You just need to change the offset ID on the second line and then simply run this LUA in your FSX - you will see your offset being read as all the available types and you can decide which of them fits your individual needs. while 1 do offset = "132C" --write the Offset ID from FSUIUPC4 Offsets Status.pdf (eg. "132C") test1 = ipc.readDBL(offset) test2 = ipc.readFLT(offset) test3 = ipc.readDD(offset) test4 = ipc.readSB(offset) test5 = ipc.readSD(offset) --test6 = ipc.readSTR(offset, 4) -- Not used test8 = ipc.readUB(offset) test9 = ipc.readUD(offset) test10 = ipc.readUW(offset) ipc.display("testDBL="..test1.."\ testFLT="..test2.."\ testDD="..test3.."\ testSB="..test4.."\ testSD="..test5.."\ testSW="..test7.."\ testUB="..test8.."\ testUD="..test9.."\ testUW="..test10) ipc.sleep(50) end Attached you can see the result for testing NAV/GPS switch offset reading. I need 1 or 0 regaring the switch position so I will use probably the UB type which is the "simplest" format of the offset which yet matches my need to be 0 or 1 - however all those except DBL, FLT and DD give the same result so technically this is completely up to me which of the remainings I will use. Pavel Brodsky
  7. Ok, got it working... Attached I am sending the easiest ever example of serial communication with arduino. Just paste the INO into your arduino and the LUA into your FSX/Modules and you will get parking brake LED working on the Arduino's onboard LED. dev = com.open("COM3", 9600, 0) function pkgbrake(offset, value) if value == 0 then com.write(dev, "g") else com.write(dev, "a") end end event.offset(0x0BC8, "UB", "pkgbrake") int strValue = 0; int light1 = 0; const int out1 = 13; void setup() { Serial.begin(9600); pinMode(out1, OUTPUT); } void loop() { if(Serial.available() > 0) { strValue = Serial.read(); } if (strValue == 'a') { digitalWrite(out1,HIGH); strValue = 'z'; } if (strValue == 'g') { digitalWrite(out1,LOW); strValue = 'z'; } } Hope that helps. Pavel
  8. Hello, thank you very much for you effort, I will try it as soon as I get to my Arduino which is currently at home... Very appreciated! By the way, I found this project: https://code.google.com/p/arduino-fs/which seems to be doing it similar way, I will try investigating it a little bit... Regards, Pavel
  9. Interesting - I have tried real time printing of the n variable to a ipc.display and it returns just 1, regardless if the line is "a" or "g" or if I specify the length parameter or not. I have googled it but the ONLY thing I could find is some VRInsignt MCP driver where autor uses the same name for handle name and for variable which openes the com.open and he does NOT save it to any variable like dev=com.write but he uses just com.write... I have tried it exactly as he did and the result was quite...weird :grin: Do you have any tips where to get more info about com.write in LUA? I cant find it on their website... I have tried lot of COM sniffing programs but all of them are unable to open the COM port while FSX (or Arduino terminal or whichever app) is communicating on that port with Arduino... My only and last hope is to find another computer with COM port, try to wire them together and log on the second computer what is my LUA actually sending to it (LUA wont know it is not arduino but computer, I hope) Pavel
  10. That sounds like a good point however code handle = com.open("COM3",9600,0) --COM 3 opened, 9600bps, no handshake while 1 do com.write(handle,"a",1) ipc.sleep(500) com.write(handle,"g",1) ipc.display("overhead driver ok") end gives the same result - just RX led blinking (even if I tried it with spaces inside like (handle, "g" 1). I found out that Arduino in default settings has 8-N-1 mode (http://en.wikipedia.org/wiki/8-N-1) - is it the same for LUA? I can change this setting to any other mode in Arduino if required... Or maybe am I missing something when LUA Library pdf says that I should use n = com.write( ? What should I in my simple example place instead of n? Pavel
  11. Well if I start the portmon.exe it says Not Connected even if I start it after or before the FSX with transmitting LUA plugin (or any other COM software like the COM terminal from Arduino) - have you experienced it? Or possibly could LUA debug to some file everything it has sent via COM? The arduino is receiving data correctly, it blinks every 500ms with RX LED but the orders dont work so LUA must be sending something else than just a and g there :sad: When I send a and g by COM terminal it works with my board... What does the "handle" word mean? Does my code send "handle a" or "a"? Pavel
  12. Didn't know, thank you for info ;) Pavel
  13. Ok, I did some testing with updated code: handle = com.open("COM3",9600,0) --COM 3 opened, 9600bps, no handshake while 1 do com.write(handle, "a") ipc.sleep(500) com.write(handle, "g") ipc.display("overhead driver ok") end which does something... the message appears, the script runs, the Receiving LED on Arduino blinks quickly, but the arduino is not receiving what it is expecting to (the "a" should turn on a LED, the "g" should switch the LED off - which works from any Serial terminal app, so the arduino code is correct). Is here any way how to log the outcoming traffic from LUA? Pavel
  14. Hi Mickey, thank you for the link. However as I understand from it he was working with HIDs, not with "pure" COM port which I am trying to... Pavel
×
×
  • 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.