frosch03 Posted June 7, 2014 Report Share Posted June 7, 2014 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 More sharing options...
Pete Dowson Posted June 7, 2014 Report Share Posted June 7, 2014 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 More sharing options...
frosch03 Posted June 7, 2014 Author Report Share Posted June 7, 2014 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 More sharing options...
Pete Dowson Posted June 7, 2014 Report Share Posted June 7, 2014 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 More sharing options...
frosch03 Posted June 8, 2014 Author Report Share Posted June 8, 2014 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 More sharing options...
Pete Dowson Posted June 8, 2014 Report Share Posted June 8, 2014 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now