Jump to content
The simFlight Network Forums

Is it possible to write the 120.000 and 130.000


Recommended Posts

Hi There,

 

while trying to write into the COM1 standby frequency (Offset 0x311A) i'm running into a problem.

If i switch to frequency 120.000 inside the simulator, the reading is ok. But if i write back that same value and read again, i'm getting a different result.

 

>>> pyuipc.open(pyuipc.SIM_FSX)
>>> dat = pyuipc.prepare_data([(0x311A, 2)])
>>> pyuipc.read(dat)
['\x00 ']
>>> pyuipc.write(dat, ['\x00 '])
>>> pyuipc.read(dat)
['\x00\x00']

 

Is this behaviour know? Also, is it possible, that the '\x00' terminates the string?

 

I'm using the python sdk: UIPC_SDK_Python

 

thanks for your time,

Matthias

Link to comment
Share on other sites

while trying to write into the COM1 standby frequency (Offset 0x311A) i'm running into a problem.

If i switch to frequency 120.000 inside the simulator, the reading is ok. But if i write back that same value and read again, i'm getting a different result.

 

What are you writing for 120.0? It should be just the 16-bit value 0x2000

 

Is this behaviour know? Also, is it possible, that the '\x00' terminates the string?

 

 

There's no "string", so nothing to terminate. It is just a simple 16-bit value, a number, not a string!

 

Pete

Link to comment
Share on other sites

What are you writing for 120.0? It should be just the 16-bit value 0x2000

 

I'm writing two bytes, so exactly the 16-bit value, bcd-encoded. I can repeat this behaviour by writing exactly, what i get from the read.

 

>>> pyuipc.read(dat)

['\x00 ']

>>> pyuipc.write(dat, pyuipc.read(dat))

>>> pyuipc.read(dat)

['\x00\x00']

Link to comment
Share on other sites

I'm writing two bytes, so exactly the 16-bit value, bcd-encoded. I can repeat this behaviour by writing exactly, what i get from the read.

 

>>> pyuipc.read(dat)

['\x00 ']

>>> pyuipc.write(dat, pyuipc.read(dat))

>>> pyuipc.read(dat)

['\x00\x00']

 

Sorry, I don't understand your code. Please instead use the FSUIPC logging facilities. In the Logging tab enter the offset as type U16 and check the "hex" box, on the right-hand side. Then check "normal log" below. Repeat your test -- set the frequency first the normal way, via the cockpit screen (so its value will be logged), and then show me the log file.

 

You can also play with reading and writing offsets using FSInterrogate2 (from the SDK), which will show you that it works fine.

 

Regards

Pete

Link to comment
Share on other sites

My code should only illustrate, that i'm writing exactly what i'm reading.

 

I did not know about the logging feature, but this is brilliant :)

This should be the relevant part from the log:

Running inside FSX on Windows 8
Module base=0AA90000
  1576625 Monitor IPC:311A (U16) = 0x2002
  1576625 SimRead: 311A="COM STANDBY FREQUENCY:1"
            INT32: 9986 (0x00002002)
  1582937 Monitor IPC:311A (U16) = 0x2000
  1582937 SimRead: 311A="COM STANDBY FREQUENCY:1"
            INT32: 9984 (0x00002000)
  1601844 Monitor IPC:311A (U16) = 0x0

To me this shows, that FSUIPC recieves the 0x0, which isn't the value i'm sending from the python code.

Also this point's out, that the problem isn't on the FSUIPC side. So sorry for bothering.

 

Just for information:

I debugged into the wrapper code, that provides the python interface to FSUIPC. Inside that code, c-strings

are used, to store the bytes that will later be handed over to the write function. My assumption is, that

somewere along the lines, the null-termination of the c-strings strikes, and only the 0x0 is handed over.

I've contacted the developer and will report back, if there is something new.

 

so long, thanks for your help,

Matthias

Link to comment
Share on other sites

I debugged into the wrapper code, that provides the python interface to FSUIPC. Inside that code, c-strings

are used, to store the bytes that will later be handed over to the write function. My assumption is, that

somewere along the lines, the null-termination of the c-strings strikes, and only the 0x0 is handed over.

I've contacted the developer and will report back, if there is something new.

 

Okay, but i must admit that talk of using strings when the value being talked about is a 16-bit binary number, not a string of any sort and especially not a C string, is very confusing. There are offsets which have strings, but most are just numbers, be it 8-bit, 16-bit, 32-bit, or 64-bit. Some are in floating point format, some, like this one, are just plain integers.

 

Pete

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.