Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hello, I have been trying to extract some flight sim variables for physical representation such as gauges, using the oacsp library for Arduino and command gateway. I am trying to extract the bank angle data mapped with offset 0x057C. When I bank left I get some useful reading and I am able to convert it into degrees. But when rolled right, I get a constant value of 0 irrespective of my bank angle. Could you please help me out. I have attached my Arduino code below. Please disregard the file name

pitch_read.ino

Posted

If I monitor 057C (as S32) in the FSUIPC logging tab, I can see this value change from + to - and it looks to be correct. This is in FSUIPC5.

Can you try this to see if you see the same? If so,  then the error is in your code (or the interface library you are using - what is this?)

 

Posted

Thank You for your help sir It worked as soon as I used SINT instead of UNIT. I am now trying to read altitude from the simulator. It says the offset has two parts, 0574 and 0570. now if I want to read the height do I make two independent events and read them?

Posted

As the documentation says, you can read both 0574 (for altitude in metres) and 0570 (for fractional part) and combine them, or just read 6020 which is the altitude as a a 64bit double floating point.

  • 3 weeks later...
Posted

Hello, so I have been working with the OACSP library for a bit now and works just fine. But now, I want to eliminate that and send values to Arduino with fsuipc and lua script. The script seems to send data to Arduino and the Arduino does seem to receive data as the RX is blinking. But when I use an LCD screen to print the data it shows nothing. Could you please help me out here. The LCD screen I use is I2c interfaced, hence does not need the serial port to be available. Also randomly the data would start appearing on the screen. I am also logging the data using ipc.log and that data seems consistent.  i have attached the Arduino code and lua script.

Thanking you 

Dinesh 

 

 

ipcready.lua     Beech99wFlapandOAT.ino

Posted
1 hour ago, Dinesh said:

have been working with the OACSP library for a bit now and works just fine.

Sorry, what is "OACSP"?

1 hour ago, Dinesh said:

 The script seems to send data to Arduino and the Arduino does seem to receive data as the RX is blinking. But when I use an LCD screen to print the data it shows nothing.

Don't you have any means to track what the Arduino is actually receiving? I thought there was a program which could show you everything your program did?

I really don't know Arduino. Is "lcd" a standard Arduino library?

1 hour ago, Dinesh said:

The LCD screen I use is I2c interfaced, hence does not need the serial port to be available.

Sorry, I don't understand the terms used here either.

1 hour ago, Dinesh said:

I am also logging the data using ipc.log and that data seems consistent. 

Consistent with what you intend, you mean?  So you know the Lua part is okay, then, right?

In the Arduino code I assume "Setup" is automatically run on loading.  Does the "All Good" message get displayed?

How does the "loop()" function get called?

How many lines does the LCD have? If only one, wouldn't the '\n' character at the end of each string cause it to scroll off?

One other thing I do notice: you are sleeping for 200 mSecs in the Lua, presumably to prevent a pile up of messages in the Arduino. In the Arduino code you seem to have defined the \n as "endmarker" but i don't see that being used anywhere. And in your loop reading the serial data you also delay 200 mSecs. Couldn't having the same delay both ends possibly cause a clash, where you get the last half of one message and the first of the next? I suspect you want to have the Arduino code reading a lot more often. Is there a good reason to have a delay at all?

I assume the "readString" will wait till there's something to read?

==========================================

Please note that FSUIPC is really just a utility program, not a hardware driver. Specific hardware support does really need to be addressed by the corresponding hardware maker or it's included software. Possibly there's an Arduino support forum which can help, if you are seeing the data logged by Lua matching what you expect.

Pete

 

Posted

Hello Sir,

Thank you for your quick reply 

OACSP is a library for Arduino. It stands for open airbus cockpit. This library helps in extracting data from Fs and sending it to Arduino to be worked on. The library is capable of both, extracting and writing data to the flight sim. problem being I cannot extract double floating point values. hence I am individually trying to get the data out of the simulator. 

I am not aware of any program that can track your Arduino process if there is please do tell me. For the LCD to work there is a simple library and to print anything on the lcd all we have to do is lcd.print(); My LCD has 2 lines.

When I run the Arduino I get the all good message but it just stays there.

By consistent, I meant that the data that is shown on my aircraft is the same as the one logged into log file.

And sure sir I will look into the delay clashing, I presumed the delay must be same so that data comes out syncronised. 

I would also ask on the arduino forum but the problem is there are a very few people who are working with Arduino Fs and Lua scripts. 

 

Once again Thank You for your response 

 

Posted
2 hours ago, Dinesh said:

am not aware of any program that can track your Arduino process if there is please do tell me

I used Ardino once, but I don't remember a lot about it, but the folder with the Arduino software contains

Arduino_debug.exe

as well as Arduino.exe

I seem to remember debugging my little program before using them in practice. Maybe I'm mis-remembering. it was a while back and I am getting old!

3 hours ago, Dinesh said:

By consistent, I meant that the data that is shown on my aircraft is the same as the one logged into log file.

Okay, so the Lua program is working, though I still think you need to consider what the \n terminator is actually doing. Maybe making the messages fixed length and only sending and reading that number of characters would be better.

3 hours ago, Dinesh said:

I presumed the delay must be same so that data comes out syncronised. 

Well, if the clocks in both Arduino and the PC were also somehow synchronised, and ran at exactly the same speed, and P3D and other threads in the PC didn't interfere with the Lua timing, and the value you are reading changed often enough to guarantee a new value at least on time, and you somehow started the Arduino loop running a millisecond or so after the Lua sending started, then, yes, they might stay synchronised.

But no, that isn't possible for most of those reasons. So, if the Arduino read just waits for more to arrive before diving a result then the Arduino loop should be running faster that the Lua.

However, none of that explains why the Arduino end isn't seeing the data. Is there no way you can log what it gets -- as you say it is obviously getting something.

3 hours ago, Dinesh said:

I would also ask on the arduino forum but the problem is there are a very few people who are working with Arduino Fs and Lua scripts.

But I think it will be the Arduino side you need help with. If you want to see what is going out of the COM port you can either use logging in FSUIPC (see below) or a port monitor program.

To log COM data add these lines to the [General] section of the FSUIPC5.INI file:

Debug=Please
LogExtras=x40

The data will be in hexadecimal of the ASCII byte values.

This will be all from me till 19th, earliest.

Pete

 

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.