Jump to content
The simFlight Network Forums

LUA - Serial Communication with Arduino not working


Recommended Posts

 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

 

Link to comment
Share on other sites

17 minutes ago, FrankP said:

the arduino really sends "C25" and "C26" with linefeeds.

By "linefeeds" do you mean just 0x0A or the more usual CRLF (0x0D then 0x0A)? Because:

21 minutes ago, FrankP said:

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

if the ARDUINO is sending a terminating zero (0x00) after a single LF (0x0A) then the length of each transmission would be a multiple of 5, of course, and 6 in the case of your Y010. Conversely, those lengths would apply also if it isn't sending a 0x00 but is sending CRLF instead of LF.

The odd things in your code are these, I think:

1. The event.com action provides whatever was read up to the time of the event. That is given in the datastring parameter, which you then destroy by reading again into datastring. If you read the description of the event.com function it does say that the data is supplied for you. It also says you CAN use com.read  but that is for additional data which may arrive if you take some time to process the event data.

2. The event.com call is asking for a minimum of 1 byte, which would be useless to you. You want a minimum of 5 surely (see above)?

3. The event.com call allows up to 50 bytes -- that is up to 10 calls from the Arduino, so you'd need to go around a loop to see if there are more than one. With your function you should have a min and max of 5.

4. Discard the delays. Those will make things worse not better.

Pete

 

 

Link to comment
Share on other sites

 Hello Pete,

thank you so much!!!

0: linefeeds - I don't quite know to be honest, but:

1: This not only made my day, it made my week-end! :-) I deleted the com.read-statement and it works like a charm.

2: Changed to 5, thanks!

3: Some of my rotary encoder, that I will add to the code, send multiple commands per dent when they are turned fast enough. For those, I include the suggested loop:

Quote

        for i in string.gfind(datastring, "A58") do
            ipc.control(65884,0)
        end

4: done

 

Thanks a lot,

 Frank

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.