by Volador » Sun Dec 20, 2020 3:26 pm
Hi wkitty and the collective,
I changed big value variables like Alt target indicated alt and VS to float (doubles) in the output .xml and set them as double in the arduino code but this didn't make any difference that I could detect. I thought that perhaps I was approaching saturation of the input buffer/speed etc on the arduino as I progress and test I'm adding more variables to the output xml so I increased the baud rate to 192000 and reduced the frequency of transmissions to 8Hz - the reduction in frequency alone did impact the FPS and when VS was engaged the hit was not as bad but it still points to a conflict I can't see.
Further investigation studying the property instrumentation/afds/settings/flch-mode I noticed that without the interface, pressing VS made this true or false but with the interface connected FG was not updating this boolean internally for some reason unlike the interface button for FLCH which, once pressed does cause FG to update instrumentation/afds/settings/flch-mode internally. I'm coding the interface to force this update to the boolean for the VS operation condition.
As for all the floats or doubles I set all these back to integer and in the process I did spot an error in my input.xml for display altitude (where I'd included a character as a start marker where it wasn't needed) which probably wasn't helping.
Conclusion at this point, VS is still a source of frame hit when triggered from the interface so I'm going to observe the property changes under no interface conditions then duplicate these in the code.
Just a reminder to other windows interface builders, having two arduinos overcomes the com port limitation, one can be set to input the other to output and using Wire or SoftEasyTransfer you can actually update variables across the two (for things that FG updates internally that need checking against any current variable values)