Elevation trim offset (xBC0): Min / Max values

[rustam]

As far as I can trace in the event log, by default the controls 65607 and 65615 has max step of 31. Therefore, I'm trying to implement the following code to bypass default values with step 256/16384:

-- Elevator Trim -------------------------------------------------------------------------

if ipcPARAM == 890 then				--	Up

	local val = ipc.readSW(0x0BC0)
	local newval = val + 256
	
	if newval > 16383 then
		ipc.writeSW(0x0BC0,16383)
		ipc.writeLvar(soundSet,0)
	else 
		ipc.writeSW(0x0BC0,newval)
		ipc.writeLvar(soundSet,10)
	end
	
end

if ipcPARAM == 891 then				--	Down

	local val = ipc.readSW(0x0BC0)
	local newval = val - 256
	
	if newval < -16383 then
		ipc.writeSW(0x0BC0,-16383)
		ipc.writeLvar(soundSet,0)
	else 
		ipc.writeSW(0x0BC0,newval)
		ipc.writeLvar(soundSet,10)
	end
	
end

But it seems strange that when I reach 0 (zero) trimming down the elevator, instead of switching to negative values, the offset values start counting down from 65536, as shown in the image below, whereas in the List of Offsets it's clearly stated that elevator trim control input at offset xBC0 ranges from –16383 to +16383 being of type signed word (SW). Or, am I getting smth wrong?! :)

 

 

Thanks!

 

Rustam

 

[Pete Dowson]

But it seems strange that when I reach 0 (zero) trimming down the elevator, instead of switching to negative values, the offset values start counting down from 65536, as shown in the image below, whereas in the List of Offsets it's clearly stated that elevator trim control input at offset xBC0 ranges from –16383 to +16383 being of type signed word (SW). Or, am I getting smth wrong?!

 

As the image shows, you are logging the value as a UW, Unsigned word! The values over 32767 will actually be negative. It's all in the interpretation -- you are just displaying them wrongly!

 

Pete