Searching for specific FSUIPC5 offsets

[Sea2Sky]

I've been looking for advice on some FSUIPC5 offset codes that I've been having issues with.

 

Has anyone had any luck programming the following offsets in P3Dv4?

 

- Avionics Bus 1

- Avionics Bus 2
- Vac Left Warning
- Vac Right Warning
 

The individual light offsets listed below for the Cessna 172 does not seem to work, is this a limitation with the aircraft, or the simulator?

- Beacon

- Landing

- Taxi

- Nav

- Strobe

 

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I also had a couple secondary  related questions as well:

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I noticed that FSUIPC5.154 was just released this month. Is there a changelog available between 5.152 and 5.154 for P3Dv4?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Is there a raw fsuipc5 offset list available? I have printed out the fsuipc5 offset status guide, and currently browse through it, but my current raw offset list for my hardware's software uses an older fsuipc4 raw offset list. I would like to update the list to v5. This is a csv based file in text format that looks like this:

&h0000, 0,"Not USED","","","","" 
&H0020, 4, "Pos/Attitude", "Ground elevation",  "#*3.28084/256" , "Read Only" , "in metres * 256, See also 0B4C" 
&H0024, 4, "Misc", "Startup situation/flight",  "#" , "Read Only" , "Path from FS folder is included. The string continues through more than the four bytes shown here." 
&H012C, 1, "Simulator", "Log Book name [FS2002+]",  "#" , "Unknown" , "Zero terminated ASCII string, but just 'logbook' by default." 
&H0238, 1, "Environment", "Clock Hour",  "#" , "Read/Write" , "0-23" 
&H0239, 1, "Environment", "Clock Min",  "#" , "Unknown" , "0-59" 
&H023A, 1, "Environment", "Clock Sec",  "#" , "Unknown" , "0-59" 
&H023B, 1, "Environment", "Zulu Hour",  "#" , "Read/Write" , "0-23" 
&H023C, 1, "Environment", "Zulu Min",  "#" , "Read/Write" , "0-59" 
&H023E, 2, "Environment", "Day of Year",  "#" , "Read/Write" , "Counts from 1, not 0" 
&H0240, 2, "Pos/Attitude", "Year",  "#" , "Read/Write" , "" 
&H0246, 2, "Environment", "Time Zone offset to Zulu (minutes)",  "#/60" , "Read/Write" , "Determines local time from Zulu and aircraft position (+ve=behind Zulu, -ve=ahead)" 
&H0248, 2, "Unknown", "Season",  "#" , "Read/Write" , "0=winter, 1=spring, 2=summer, 3=fall" 
&H0262, 2, "Misc", "Pause control",  "#" , "Write Only" , "Write 1 to pause, 0 to unpause" 
&H0264, 2, "Simulator", "Pause flag",  "#" , "Read Only" , "0=Running, 1=Paused" 
&H0274, 2, "Misc", "Frame Rate",  "32768/#" , "Read Only" , "" 
&H0278, 2, "Controls", "Auto-rudder",  "#" , "Read/Write" , "1=on, 0=off. Also known as auto-coordination. Changing this works but doesn't affect Menu setting." 
&H0280, 1, "Cockpit", "Nav Lights",  "#" , "Unknown" , "Operates NAV, Taxi, Panel and Wing light (but only reflects NAV settings). See $0D0C for more control" 
&H0281, 1, "Cockpit", "Strobe/Beacon Lights",  "#" , "Read/Write" , "Operates Strobe and Beacon Lights. See $0D0C for more control" 
&H028C, 2, "Cockpit", "Landing Lights",  "#" , "Read/Write" , "Operates Landing Lights. See $0D0C" 
&H029C, 2, "Cockpit", "Pitot heat",  "#" , "Read/Write" , "0=Off, 1=On" 
&H02A0, 2, "Pos/Attitude", "MagVar",  "#*360/65536" , "Read Only" , "-ve is West, +ve East. Convert Mag to True by subtracting this, True to Mag by adding it." 
&H02B2, 2, "Simulator", "Zoom factor (FS2002+)",  "#/64" , "Read Only" , "64=x1, 128=x2 et cetera. Read only, FS2002 only" 
&H02B4, 4, "Pos/Attitude", "Ground Speed",  "#*3600/65536/1852" , "Read Only" , "Metres/sec * 65536. Not valid in Slew mode!" 
&H02B8, 4, "Pos/Attitude", "True Air Speed",  "#/128" , "Unknown" , "Knots * 128" 
&H02BC, 4, "Pos/Attitude", "Indicated Air Speed",  "#/128" , "Unknown" , "Knots * 128" 
&H02C4, 4, "Pos/Attitude", "Barber pole airspeed",  "#/128" , "Read Only" , "Knots * 128" 
&H02C8, 4, "Pos/Attitude", "Vertical speed",  "#*60*3.28084/256" , "Unknown" , "VSI / 256 = VS per sec (in meters)" 
&H02CC, 8, "Pos/Attitude", "Whiskey Compass",  "#" , "Read Only" , "Degrees" 
&H02D4, 2, "Radios/Navigation", "ADF2 freq (FS2004)",  "#" , "Read/Write" , "Main 3 digits in BCD" 
&H02D6, 2, "Radios/Navigation", "ADF2 Extended Freq (FS2004)",  "#" , "Read/Write" , "BCD, high byte=1000's digit, low byte=fraction digit" 
&H02D8, 2, "Radios/Navigation", "ADF2 Rel Bearing (FS2004)",  "#*360/65536" , "Read Only" , "" 
&H02DC, 4, "Radios/Navigation", "NDB2 identity (FS2004)",  "#" , "Read Only" , "six byte character string including zero terminator" 
&H02E2, 4, "Radios/Navigation", "NDB2 name (FS2004)",  "#" , "Read Only" , "25 byte character string including zero terminator" 
&H02FB, 1, "Radios/Navigation", "ADF2 ident sound switch (FS2004)",  "#" , "Read/Write" , "1=enabled, 0=disabled"

Ideally, I would like to not type out the entire fsuipc5 list in a text/csv file if there is one already out there.

Thank you for your support and product.

Edited March 20, 2020 by Sea2Sky

[Thomas Richter]

Hi,

in case those functions are not available in default aircrafts that come with FS/P3D, so they don't exist as Offsets.

Quote

- Avionics Bus 2
- Vac Left Warning
- Vac Right Warning

Offsets for different Lights are working mostly for default aircrafts that come with FS/P3D but might not work or only partly with add-on aircrafts that use their own internal logic/systems. Those might be reachable via their SDK (if available) or via L:vars, check the FSUIPC manuals for handling of those.

FSUIPC changes are always listed in FSUIPC5 History.pdf file, located in \Modules\FSUIPC Documents\ folder.

The Offsets are listed and described in FSUIPC5 Offsets Status.pdf file, located in \Modules\FSUIPC Documents\ folder. You would have to convert it yourself to a different format to you needs.

Thomas

[Pete Dowson]

14 hours ago, Sea2Sky said:

The individual light offsets listed below for the Cessna 172 does not seem to work, is this a limitation with the aircraft, or the simulator?

- Beacon

- Landing

- Taxi

- Nav

- Strobe

There's only one lights offset which works for all the lights supported by an aircraft using the default lighting system, and that is 0x0D0C. That is a set of 16 bits and has one bit for each of 10 lights.

Pete

 

[Sea2Sky]

 I did print out the FSUIPC5 Offsets Status a while back and refer to that guide frequently. I can't believe I missed the FSUIPC5 History guide. Thanks for pointing that out.

I was unable to find the specific offsets for Avionics Bus 2, and the Vacuum L/R warning indicators. Do they exist?

Regarding the individual light switches, these are the offsets I currently have configured. The offsets are increased by 1 bit, but are not functioning (other than Nav at 0D0C).

Hex Val: Name (Int) - bit

0D0C: Nav (3340) - 0
0D0D: Beacon (3341) - 1
0D0E: Landing (3342) - 2
0D0F: Taxi Lights (3343) - 3
0D10: Strobe (3344) - 4
0D11: Instruments (3345) - 5

I apologize if there's something I'm missing here, but I assume the additional offset bit is added to 0D0C as shown above? I've tried searching the internet, but unfortunately to no avail.

***UPDATE*** Interesting enough, 0D11 did work for my instrument lights, but 0D0D - 0D10 do not engage the switches on the panel, or the exterior lights themselves.

[Pete Dowson]

5 hours ago, Sea2Sky said:

I was unable to find the specific offsets for Avionics Bus 2, and the Vacuum L/R warning indicators. Do they exist?

Which default aircraft has these?

5 hours ago, Sea2Sky said:

Regarding the individual light switches, these are the offsets I currently have configured. The offsets are increased by 1 bit, but are not functioning (other than Nav at 0D0C).

Hex Val: Name (Int) - bit

0D0C: Nav (3340) - 0
0D0D: Beacon (3341) - 1
0D0E: Landing (3342) - 2
0D0F: Taxi Lights (3343) - 3
0D10: Strobe (3344) - 4
0D11: Instruments (3345) - 5

I apologize if there's something I'm missing here, but I assume the additional offset bit is added to 0D0C as shown above? I've tried searching the internet, but unfortunately to no avail.

You are completely misunderstand the use of bits as flags I'm afraid.

First, there is only the 16 bit offset, 0D0C. This does encompass 0D0D as well, because 16 bits occupies 2 x 8 bit bytes.

Second, each individual bit in 0D0C operates oen light. Please try to get to grips with what a "bit" is. It is a value which can only be 0 or 1. There are 10 of them being used in 0D0C.

Please review this FAQ subforum thread :

 

[Sea2Sky]

It was more related to the annunciator panel hardware that I'm trying to configure. It has warning indicator lights for L/R VAC, and I was trying to find the offset values for this in particular.

 

 

Regarding the Avionics Bus1 and Bus2 switch, once again, this is hardware specific to my simulator.

 

 

 

If there are no offsets for these, please let me know and I will move on and will ignore some of hardware limitations.

 

 

Regarding the instrument light bits, I'm very well aware of what a bit is, but might not understand how they are used as flags if the following bits aren't working for individual Beacon, Landing, Taxi, and Strobe lights. Let's convert my hex example to binary to discuss what I mean:

 

0D0C: Nav = 1101 0000 1100 ***WORKING*** (reducing to 12 bit for simplicity, otherwise 0000 1101 0000 1100)

0D0D: Beacon = 1101 0000 1101

0D0E: Landing = 1101 0000 1110

0D0F: Taxi Lights = 1101 0000 1111

0D10: Strobe =1101 0001 0000

0D11: Instrument = 1101 0001 0001 ***WORKING***

 

I've flipped each bit, and Nav and Instrument light switch works according to the bits set above. According to the Offsets Guide, the bits go from 0 (Nav) to 9 (Cabin), in which in this case, I'm trying to make use of bits 0-5.

 

If I've misunderstood flipping each bit in the offset between Nav and Instrument bits, please help me understand. Since Instrument lights do work with 0D0C + 5 bits = 0D11, and 0D0C = 0 bit switch, then why wouldn't 0D0C + 1 = 0D0D? If Beacon is not 0D0D, could you please give me a freebie on what the Beacon light offset is, so I can get a better grasp on what you're talking about.

[Pete Dowson]

28 minutes ago, Sea2Sky said:

If there are no offsets for these,

Which aircraft is that?

29 minutes ago, Sea2Sky said:

Regarding the instrument light bits, I'm very well aware of what a bit is, but might not understand how they are used as flags if the following bits aren't working for individual Beacon, Landing, Taxi, and Strobe lights. Let's convert my hex example to binary to discuss what I mean:

 

0D0C: Nav = 1101 0000 1100 ***WORKING*** (reducing to 12 bit for simplicity, otherwise 0000 1101 0000 1100)

0D0D: Beacon = 1101 0000 1101

0D0E: Landing = 1101 0000 1110

0D0F: Taxi Lights = 1101 0000 1111

0D10: Strobe =1101 0001 0000

0D11: Instrument = 1101 0001 0001 ***WORKING***

What is all that about? Why the reference on the left to "0D0D, 0D0E, etc"? As I keep saying, it is only the 16 bits at 0D0C which are involved. OD0D contains only 2 light switches, at bits 8 (Logo) and 9 (Cabin). Offsets 0D0E to 0D4F inclusive are not used (or may be used internally). Please refer to the Offsets list.

Only set and reset one bit at a time in 0D0C only so you can see what happens. You seem to have almost random assortments of bits out of 12 starting in 0D0C and creeping up to 0D11. Why?

Pete

 

[John Dowson]

You are still misunderstanding! Please read what Pete said, as well as the documentation. There are 16bits for the light toggles (only 10 used), starting at offset 0D0C:

5 hours ago, Pete Dowson said:

First, there is only the 16 bit offset, 0D0C. This does encompass 0D0D as well, because 16 bits occupies 2 x 8 bit bytes.

You said:

39 minutes ago, Sea2Sky said:

0D0C + 5 bits = 0D11

No! Its the 5th BIT at offset 0D0C that you want. Not 0D0C + 5 BYTES = 0D11

39 minutes ago, Sea2Sky said:

If Beacon is not 0D0D, could you please give me a freebie on what the Beacon light offset is

Its the second BIT (bit 1, from lo to hi) of the 2 bytes at offset 0D0C.

 

39 minutes ago, Sea2Sky said:

It has warning indicator lights for L/R VAC,

As Thomas has said, there are no offsets for these lights (they are non-standard).

John

[Pete Dowson]

Thanks John, maybe you can explain better than I. I'm running out of ways of saying it! 😞

Dad

 

[John Dowson]

You could try assigning a button or keypress to the FS control 'Offset Word Togglebits', giving the offset as 0x0D0C, and one of the following parameters
    0x0001 - for Navigation lights (bit 0)
    0x0002 - Beacon lights (bit 1)
    0x0004 - Landing lights (bit 2)
    0x0008 - Taxi lights
    0x0010 - Strobes
    0x0020 - Instruments
    0x0040 - Recognition
    0x0080 - Wing
    0x0100 - Logo
    0x0200 - Cabin
   

[Sea2Sky]

53 minutes ago, John Dowson said:

You could try assigning a button or keypress to the FS control 'Offset Word Togglebits', giving the offset as 0x0D0C, and one of the following parameters
    0x0001 - for Navigation lights (bit 0)
    0x0002 - Beacon lights (bit 1)
    0x0004 - Landing lights (bit 2)
    0x0008 - Taxi lights
    0x0010 - Strobes
    0x0020 - Instruments
    0x0040 - Recognition
    0x0080 - Wing
    0x0100 - Logo
    0x0200 - Cabin

 

I found this to be completely helpful when assigning the FS control function parameter to a button on my yoke. Testing it allowed me to toggle each switch accordingly, and gives me much hope in finding a solution! I need to figure out if converting it to a new hex offset value is the right or wrong path.

I'm using an IO board from Flight Illusion which has its own function configuration that maps to my switches, and I've been trying to figure out the offset conversions for each individual light. I've been trying to convert binary to hex by changing the bit values to calculate the offset value. My original assumption was that 0D0C was the main offset, and I had to replace the bits at the end, which was incorrect.

To give you an example of what I'm working with, here is the NAV light function which is set to 0D0C. I've also noticed an offset of 280 which also appears to be used as NAV (NAV, Taxi, and Wing lights), but am currently using 0D0C, which converts to binary 1101 0000 1100:

 

There is also an offset of 28C (binary: 0010 1000 1100) which also activates the Landing lights switch:

 

 

So using the Nav and Landing lights function, I am seeing the following binary:

Nav (280):             0010 1000 0000
Landing (28C):     0010 1000 1100

But don't understand how those are related to the binary offset of 0D0C (they might be completely unrelated):

Nav (0D0C):       1101 0000 1100

I want to understand very badly what you two are saying, but maybe I'm approaching this completely wrong. I appear to be missing something in regards to converting the binary from the 0D0C offset value. Are there any other fields within the offsets function field that need to be updated shown above other than the offset field, or am I on the right track on assuming that the offset value is recalculated by changing bit values within the converted 0D0C hex to binary string?

Unfortunately, the only working offset examples I have for the lights are 280, 28C, and 0D0C as listed in the offset guide. I'm starting to think that it's not the offset value that I need to change within the IO board software, but something else?

Once again, apologies if there's any frustration on your part from something that I might be missing here. I'm trying really hard to understand what it is that I'm doing wrong as far as the offset hex conversion (if that's even the case). I might be trying to apply the offsets for beacon, taxi, strobe that might not even exist based on incorrect binary conversion?  Or maybe the offset field is to remain as 0D0C, and there is another bit/flag elsewhere that needs to be added?

I promise you, there is a dram of really fine scotch waiting for you in Canada if you can help me solve this. 🙂

[Thomas Richter]

Hi,

first forget about Offset 0280 and 028C. Those switches multiple things ON/OFF altogether like the 'L' key on your keyboard does.

One byte has 8 bit, each bit is a ON/OFF switch. Bits are representing the power of 2 in math. So 2^0=1,  2^1=2,  2^2=4,  2^3=8,  2^4=16,  2^5=32,  2^6=64,  2^7=128.

The 8 bits are counted from 0 to seven and we count the bits always from right to left.

So  what you get is bit0 = 2^0 = 1, if this bit (switch) is ON. In binary you would write 00000001 (bit0=ON), 00000000 (bit0=OFF).

11111111 (all bits=ON)Dec value=255 (1+2+4+8+16+32+64+128), 00000000 (all bits=OFF)
00000001 (bit0=ON)(dec value=1, 2^0=1), 00000000 (bit0=OFF)
00000010 (bit1=ON)(dec value=2, 2^1=2), 00000000 (bit0=OFF)
00000100 (bit2=ON)(dec value=4, 2^2=4), 00000000 (bit0=OFF)
00001000 (bit3=ON)(dec value=8, 2^3=8), 00000000 (bit0=OFF)
and so on
00000101 (bit0+bit2=ON)(dec value=5, 2^0 + 2^2)
00001101 (bit0+bit2+bit3=ON)(dec value=13, 2^0(1) + 2^2(4) + 2^3(8))

Offset 0D0C = 2 bytes = 16 bits (bit0 to bit15)
bit 0 Navigation
bit 1 Beacon
bit 2 Landing
bit 3 Taxi
bit 4 Strobes
bit 5 Instruments
bit 6 Recognition
bit 7 Wing
bit 8 Logo
bit 9 Cabin

So switching NAV + LndLight + Logo to ON (bit0+bit2+bit8)
00000001 00000101 = dec value=261, 2^0(1) + 2^2(4) + 2^8(256)

Switching LndLight from above now to OFF, leaving NAV + Logo ON (bit0+bit8)
00000001 00000001 = dec value=257, 2^0(1) + 2^8(256)

Thomas

[Sea2Sky]

Thanks Thomas,

So to my understanding, offset 0D0C are 2 bytes, (2x 8 bits) which is:

0000 1101 0000 1100 = 0D0C

I've been tying to figure out which bit to flip within which byte in the 0D0C offset.

 

I'll limit my example to just the beacon light. Here's the attempt flipping bit 1, by flipping the bit in the second bit, which changes the offset value to 502. As expected this doesn't work as the offset value has changed in only the second byte.

0000 1101 0000 0010 = 502

Attempting to change the beacon bit to the first byte also doesn't work, as expected, since the offset value changes:

0000 0010 0000 1100 = 20C

 

So let's clear all the bits, and try the following which also does not work as expected because the 0D0C offset no longer exists:

0000 0000 0000 0010 = 2

No need in even attempting this, since the offset would be 2, which does not make sense, and would not apply to other offset function values that have bit flags.

 

So then I thought, what if we make it 4 bytes, keep the 0D0C 2 byte offset, and then added 2 bytes previous to the offset which would look like this:

0000 0000 0000 0010 0000 1101 0000 1100 = 20D0C

This seemed promising at first since the offset 0D0C remained, with an additional bit added. And attempted flipping another bit to test landing lights:

0000 0000 0000 0100 0000 1101 0000 1100 = 40D0C

This unfortunately did not work as well.

 

So I guess my question is, which bit am I flipping, while still keeping the 0D0C offset value? I'm guessing there is a bit outside of the offset that needs to be flipped that I'm not aware of to retain the 0D0C offset? Otherwise, I would assume my question would have been answered with a unique offset value per individual light.

 

Is there a missing bit flag field within my G-Step configuration software that I pasted in an earlier post? Am I on the right path of flipping bits, but just not in the right byte?

[Pete Dowson]

9 minutes ago, Sea2Sky said:

So I guess my question is, which bit am I flipping, while still keeping the 0D0C offset value?

It is ALWAYS  0D0C for the light switches. Different bits are within that word (bits 0 - 9) for each light -- remembering bit 0 = value 1, bit 1 = value 2, bit 2 = value 4 ... up to bit 9 = value 512.

The value is 2 to the power of the bit number, shown as 2^9 = 512, for example. i'm sure you can find a calculator or a calculator App which will compute this for you, but it is just double (multiplying by 2) for each bigger bit number!

You are continuing to make it so complicated for yourself. Please try to review more carefully what everyone has been trying to help you with! Also, I don't really think you visited that FAQ subforum thread I referred you too days ago, did you? If you did but didn't underrstand it you should have said so!

Pete

 

[John Dowson]

26 minutes ago, Sea2Sky said:

which changes the offset value to 502

the offset value is not relevant. Only 10 bits of the available 16 bits are used.

26 minutes ago, Sea2Sky said:

As expected this doesn't work as the offset value has changed in only the second byte.

No, not as expected. If you set the 2nd bit (bit 1), then this will activate the beacon lights. If it isn't, you are doing something wrong (or you are using an add-on aircraft that doesn't support standard FS controls - you should initially at least try with a default aircraft).

26 minutes ago, Sea2Sky said:

So let's clear all the bits, and try the following which also does not work as expected because the 0D0C offset no longer exists:

0000 0000 0000 0010 = 2

As expected? No longer "exists"? What are you talking about! The offsets are always there. The value (decimal or hex) is not important in this offset, you should only be interested in what bits are set or not. If you set that value, then the Beacon lights will be activated (and all other lights turned off). This is basically what the Offset Word Togglebits does with that offset and parameter 0x2 (except that uses a mask so ONLY toggles the 2nd bit)

26 minutes ago, Sea2Sky said:

No need in even attempting this, since the offset would be 2, which does not make sense, and would not apply to other offset function values that have bit flags.

What does not make sense is this sentence!

...I see Pete has also replied.

Sorry, but its is really not worth going through the rest of your post. As Pete says, please read the documentation and re-read our previous answers. You seem to have a basic misunderstanding of how this offset works, and we can only explain so many times....

John

[Sea2Sky]

I am so frustrated and disappointed in myself that I can't comprehend what is being said. I understand in theory what you mean, but not in practice.

42 minutes ago, Pete Dowson said:

It is ALWAYS  0D0C for the light switches.

Unfortunately, when I set a particular bit in a byte, the offset value changes for me, and all I can do is enter an offset value to set the function within my software.

42 minutes ago, Pete Dowson said:

Also, I don't really think you visited that FAQ subforum thread I referred you too days ago, did you? If you did but didn't underrstand it you should have said so!

If you only knew how many times I've read, and re-read that article. 😞

32 minutes ago, John Dowson said:

the offset value is not relevant. Only 10 bits of the available 16 bits are used.

Once again, when I change any bit, the offset value changes for me, and that is the only thing I can enter in my software is an offset value. There are other data types I can change as well other than Bytes, which include Integer, Unsigned Integer, Long, Double, and BCD Code.

32 minutes ago, John Dowson said:

If you set the 2nd bit (bit 1), then this will activate the beacon lights. If it isn't, you are doing something wrong (or you are using an add-on aircraft that doesn't support standard FS controls - you should initially at least try with a default aircraft).

As mentioned, 0000 1101 0000 0010 = 502  was the second bit, and did not work within the default Cessna 172 aircraft supplied by FSX.

On 3/23/2020 at 9:55 AM, John Dowson said:

You could try assigning a button or keypress to the FS control 'Offset Word Togglebits', giving the offset as 0x0D0C, and one of the following parameters

This did work when assigning a yoke button directly in FSUIPC as 'Offset Work Togglebits' FS control, so the switch does appear to work for that aircraft using that method only.

I appreciate all your advice, and thank you for your support, but it doesn't appear that I can get it working after spending full days attempting this. Thank you so much for trying, but I am at a loss of what to do anymore. I can sense that some of you are as frustrated with me, as I am with setting the bits. So I think it is best for me to walk away as this has caused aggravating stress for both me and you.

My current assumption is that the issue lies in the software I'm using for my hardware which only uses offset values to define the functions. I will reach out to them and see if that is the case.

I will continue to support and praise your project, and was looking to donate for all your time, but I no longer see the donation contribution page.

 

[John Dowson]

1 hour ago, Sea2Sky said:

Is there a missing bit flag field within my G-Step configuration software that I pasted in an earlier post?

I have no idea what that is - maybe that is your problem - have you tried their support?

...ah, just see you have replied....

34 minutes ago, Sea2Sky said:

My current assumption is that the issue lies in the software I'm using for my hardware which only uses offset values to define the functions. I will reach out to them and see if that is the case.

yes, what I was going to suggest...

What you could also do is monitor offset 0D0C using the FSUIPC logging facilities. You can then verify what you think the software is setting with what FSUIPC is actually receiving. Monitor as U16 and hex, and send to log file (and also FS title bar so that you can see the value). You can then check what FSUIPC is receiving, and we can explain what those values mean. You can  also activate the different lights and see the values in that offset change, which may help you.

Cheers,

John

 

[Pete Dowson]

3 hours ago, Sea2Sky said:

Unfortunately, when I set a particular bit in a byte, the offset value changes for me, and all I can do is enter an offset value to set the function within my software.

Am I right then in assuming that the software you are using cannot change an individual bit -- i.e change just one 0 to a 1 or vice versa?

In the Lua library supported by FSUIPC there are "togglebits", "setbits" and "clearbits" functions which operate on bits. If your software doesn't support this sort of thing, see if it can do logcal "AND" and "OR". These are operations to exclude bits or set them without changing other bits in the same byte.

The offset number, like 0D0C, is actually an ADDRESS. It is the address of a byte of memory,  real memory in your computer!***  Changing the value within a memory address doesn't change the address, as you seem to be saying. That would be like your postman only being able to post one letter in your house because the next would go to the next house, and so on.

I think maybe you need to learn more about how to use your software, because that's really where your solution lies. Perhaps there's a Help forum for it, or at least for the hardware you are using it for?

If your software allows you to send keystrokes, then an alternative, though messier than the logical solutions already suggested for you, woud be for you to assign keystrikes to the Offset Togglebits control (it's in the FSUIPC assignments dropdown), with x0D0C as the offset (the field shown as such) and parameters 1, 2, 4, 8, 16 ... 512 as already listed for you.  Togglebits would toggle the light on and off

Alternatively if you are using latching switches you can use Setbits and Clearbits to switch them on an off. But that would of course use twice as many assignments and corresponding keystrokes.

There are ways of sending keystrokes via offsets if your software can't send them -- please check the offsets list for details.

Pete

*** to be exact, the Offset is literally the offset from an address, i.e. the value to be added to a known address to get the actual address. This is how the term 'offset' came to be used. it it literally the offset from someplace else, fixed inside FSUIPC's memory.

 

[Sea2Sky]

6 hours ago, John Dowson said:

What you could also do is monitor offset 0D0C using the FSUIPC logging facilities. You can then verify what you think the software is setting with what FSUIPC is actually receiving. Monitor as U16 and hex, and send to log file (and also FS title bar so that you can see the value). You can then check what FSUIPC is receiving, and we can explain what those values mean. You can  also activate the different lights and see the values in that offset change, which may help you.

Thank you, I will start troubleshooting more with the FSUIPC logging facilities in the future.

3 hours ago, Pete Dowson said:

Am I right then in assuming that this software you are using cannot change an individual bit -- i.e change just one 0 to a 1 or vice versa?

Yes, that was the case. I would hope that there is a way somewhere to configure this bit, and I will continue to troubleshoot the software in question.

3 hours ago, Pete Dowson said:

The ofset number, like 0D0C, is actually an ADDRESS. It is the address of a byte of memory,  real memory in your computer. Changing the value within a memory asddress doesn't change the address, as you seem to be saying.

Thank you, this makes total sense. My original assumption was that FSUIPC hex offsets were based on an adjustable programmatic FSUIPC value changing the bytes in the initial offset, not an additional byte/parameter set. Understanding that it's an actual byte in memory definitely clears things up for me. Due to the options presented to me in my hardware's software, I was making an incorrect guess and changing the initial offset value. I required a deeper understanding of FSUIPC.

3 hours ago, Pete Dowson said:

In the Lua library supported by FSUIPC there are "togglebits", "setbits" and "clearbits" functions which operate on bits. If your software doesn't support this sort of thing, see if it can do logcal "AND" and "OR". These are operations to exclude bits or set then without changing other bits in the same byte.

I will sit down and start reviewing the Lua code better understand how it's designed to work. Clearly my understanding was misunderstood. I will also make some time to sit down and read through all the FSUIPC manuals I have in front of me, rather than skimming to what I'm after.

Thank you all for your time. I feel more at ease being educated on the subject, and knowing where to look next.

 

[Sea2Sky]

I've resolved my issue, and wanted to post the solution here in case anyone in the future is searching for a similar answer.

The bit mask was on the bottom right corner 'Mask if Bit cmd'. In the past, I was using the bit flag values of 0-9, rather than the bit values of 1, 2, 4, 8, 16, 32, 64, 128, 256, and 512.

If anyone has this issue, I hope that this can help.

 

 

Much thanks to the FSUIPC team for dealing with me, and for clearing up any misunderstandings I had with the offset hex values.

[John Dowson]

Glad you've solved your issue, and thanks for posting the solution!