Is it possible to write the 120.000 and 130.000

[frosch03]

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

[Pete Dowson]

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

[frosch03]

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']

[Pete Dowson]

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

[frosch03]

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

[Pete Dowson]

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