X Plane Data Refs

Status
Not open for further replies.

vegasflyer

New member
Is there a limit to the size of a dataref that can be sent by teensy, I am trying to adjust the artificial horizon and observe no communication, if I shorten the string it says that it can not be found so it seems to only occur when the size of the Data Ref becomes large.

XPlaneRef("sim/cockpit2/gauges/actuators/artificial_horizon_adjust_deg_pilot");

Any help would be greatly appreciated.
Thanks
 
I had the issue with the long DataRefs some time ago, when I built my Flightsim based on two Teensy 2++s. I didn't have any problem with the number of DataRefs, but tha fact that I wasn't able to to handle DataRefs like "sim/cockpit2/engine/actuators/prop_rotation_speed_rad_sec[0]" - that drove me nuts.

Basically, it has to do with the USB RawHid protocol that doesn't support packets above 64 bytes, which effectively limits the DataRef name to 58 bytes. There was no easy fix. Paul helped me out with his XPlane plugin source code and I had to extend the protocol on both sides (Teensy and XPlane plugin) in order to split the registration of longer DataRefs around various USB packets. Finally, I got it working, but my changes didn't make it back to the official TeensyDuino release. They also add some overhead and complexity and might not be complete.

I still have the source code lying around somewhere, but this change was for Teensy 2, with an older version of the XPlane plugin. It seems that Paul's XPlane plugin source code is not publicly available, so we would have to involve him.
 
Is your change backwards compatible, so older versions still work? If so, just send a pull request on github.

Yes, it is.

However, it worked only on Teensy 2 AND required changes in both the plugin and the USB source code. As it was a while ago (2012, before Teensy 3), I'd have to check if it still works. I could use some help. Any volunteer out there?
 
I just found the source code and saw that I also implemented some additional commands to handle menu items. I think this is where I got stuck somehow, don't remember.

Basically, the revised protocol allows to fragment data packets. If the first packet indicates a length >64, you would send additional sequentially numbered fragments that have a command byte of 0xff until the whole message has been transmitted. No change for packets up to 64 bytes.

As I said, there is no code for Teensy 3 and the plugin code hasn't been tested against newer versions of XPlane (i.e. 10.30). So, I definitely would need some help from out there...

Here's the new version of protocol.txt which explains the changes I've made:
Code:
Version Info:
        byte1:   length (always 4)
        byte2:   0x00
        byte3:   protocol version major
        byte4:   protocol version minor

Packet fragment:
        byte1:   length of fragment
        byte2:   0xff
        byte3:   fragment id (starting at 1)
        byte4-n: data

Register Command or Data
        byte1:   total data length, may be fragmented
        byte2:   0x01
        byte3-4: identifier (assigned by Teensy)
        byte5:   type, 0=command, 1=integer, 2=float
        byte6:   reserved, use 0
        byte7-n: name

Write Data:
        byte1:   length (always 10)
        byte2:   0x02
        byte3-4: identifier (assigned by Teensy)
        byte5:   type, 1=integer, 2=float
        byte6:   reserved, use 0
        byte7-10: data, lsb first

Enable/Disable:
        byte1:   length (always 4)
        byte2:   0x03
        byte3:   1=enable&send IDs, 2=enable, 3=disabled
        byte4:   reserved

Command Begin:
        byte1:   length (always 4)
        byte2:   0x04
        byte3-4: identifier (assigned by Teensy)

Command End:
        byte1:   length (always 4)
        byte2:   0x05
        byte3-4: identifier (assigned by Teensy)

Command Once:
        byte1:   length (always 4)
        byte2:   0x06
        byte3-4: identifier (assigned by Teensy)

Register Menu or menuItem:
        byte1:   total data length, may be fragmented
        byte2:   0x07
        byte3-4: identifier (assigned by Teensy)
        byte5:   type, 3=menu, 4=menuitem
        byte6:   reserved, use 0
        byte7-8: parent identifier
        byte8-n: name

MenuItem enable:
        byte1:   length (always 4)
        byte2:   0x08
        byte3:   identifier (assigned by Teensy)

MenuItem disable:
        byte1:   length (always 4)
        byte2:   0x09
        byte3:   identifier (assigned by Teensy)

MenuItem remove checkmark:
        byte1:   length (always 4)
        byte2:   0x0a
        byte3:   identifier (assigned by Teensy)

MenuItem checkmark off:
        byte1:   length (always 4)
        byte2:   0x0b
        byte3:   identifier (assigned by Teensy)

MenuItem checkmark on:
        byte1:   length (always 4)
        byte2:   0x0c
        byte3:   identifier (assigned by Teensy)

MenuItem clicked:
        byte1:   length (always 5)
        byte2:   0x0d
        byte3:   identifier (assigned by Teensy)
        byte4:   1 = checked, 0 = unchecked
 
Thank you, this definitely helps, it was driving me nuts not knowing what the problem was, at least I know where it is, to be honest this is a little beyond me at this stage but I will do some work on this and look at the plug in side.

Its good to know that I am not the only one that have faced this problem so maybe a fix will be published as I have several teensy's that I am interfacing and they work great except for those long data refs.
 
I downloaded the source and will take this on and contribute if I can. I will test the current plug in against the latest xplane later.
 
It's been over a year, any updates? I have this one XPlaneRef("sim/cockpit2/radios/nav1_flag_glideslope"); Teensy says it doesn't exist Well it does and surely it this simple on or off dataref isn't over the 58byte limit????
 
The full source code for the X-Plane plugin is available on github.

https://github.com/PaulStoffregen/X-Plane_Plugin

Likewise, the full source code running on Teensy is in your copy of Arduino, under teensy/hardware/cores. Two copies exist, for Teensy 2.0 and Teensy 3.x & LC. They're very similar, so make sure you're looking at the one which corresponds to the Teensy you're using.

When you assign a dataref on the Teensy side, it sends the name to the plugin. That's where the length restriction comes into play, since it can only use the remainder of a 64 byte packet.

On the plugin side, after parsing the incoming data, the name Teensy sent is given to Teensycontrols_new_item(). If the item is a number, it's calls the X-Plane API function XPLMFindDataRef(). That code is at line 198 in memory.c:

https://github.com/PaulStoffregen/X-Plane_Plugin/blob/master/memory.c#L198

If XPLMFindDataRef() returns NULL, the string can't be used. If you've got the "Show Communication" window open, you should see the message "Teensy request data sim/cockpit2/radios/nav1_flag_glideslope does not exist" appear. As you can see in the source code, only 1 thing makes that message appear: when XPLMFindDataRef() returns NULL. Because the message in the "Show Communication" window includes the same string that was given to XPLMFindDataRef(), you can see exactly what the plugin tried to ask XPLMFindDataRef() to find.

I know this doesn't directly solve your problem. There's no way I can do that. But hopefully this can give you something more useful to ask on the X-Plane forum. You can ask why XPLMFindDataRef("sim/cockpit2/radios/nav1_flag_glideslope") is returning NULL, instead of asking why some unfamiliar plugin isn't working.

Small details matter. I recommend taking a screenshot of the Show Communication window. Even the slightest typo, even uppercase vs lowercase, in the string can cause this to fail. If there is some subtle error in the string, an actual screenshot may help someone to notice such a small, elusive detail.

Any number of other things could go wrong too on X-Plane. I don't know enough about X-Plane's internals to say. But I do know if you're seeing that message in the Show Communication window, one thing is absolutely certain. XPLMFindDataRef() must be returning NULL for that particular string. If the string is correct, that's an issue on the X-Plane side.

If you do get a helpful answer on the X-Plane forum, please take a moment to post a link or quick followup here. Maybe it'll save someone else who hits this same issue from suffering the same frustration?
 
Last edited:
As I mentioned before, the code that I wrote back in 2012 to handle long datarefs was only for Teensy 2 (actually, the T3 didn't even exist back then).

As of Rob's (raflyer's) request, I have implemented the protocol changes for Teensy 3 (, 3.1, LC) as well. I also took a look at the plugin and resolved an issue under OSX.

I have published the changes to usb_flightsim on this cloned github repositories:


I'm inviting everybody who's interested in the issue to test the new core and plugin. The protocol has been designed to be backwards compatible (old versions of the plugin simply will ignore dataref requests with long names).

The plugin was tested with Teensy2++, Teensy 3.0, Teensy 3.1 and Teensy LC and X-Plane 10.36 running on Windows, Linux and OSX, all in 32 and 64 bits. This is quite a number of variables and I'm pretty sure that I didn't test all possible cases, so, please treat this as an alpha version. I hope to be able to turn it beta with your help and eventually, maybe, Paul can include it in the official distribution.

Please let me know if it works - and what DOESN'T.

Jorg
 
Last edited:
jblesener, thanks a lot for that!
I will try for sure, I haved great time with Teensy 3.1 and Xplane and I'm really happy that someone continue the amazing work of Paul!
 
Jorg, aka jblesener

Just wanted to report that with the latest version of the plugin, I can confirm that it functions perfectly with long datarefs and with ZERO fps loss using 11 Teensy's now in my SIM.
Thank you so much!!!!

Rob
 
Good to know, Rob. If anybody's interested, the code is available in two Github repositories:



Both are required to handle long datarefs. There are also some other improvements like fixing the exit-crash on OSX and parameters to the callback-function.

I have sent a pull request to Paul and maybe he'll incorporate the changes into his official distributions.
 
Tested yesterday and works as supposed. Fixed also the usual OSX crash.
++ for me to add in Teensyduino!
 
Hello,

I'm trying to follow this thread and update the teensy plugin so I can have more than 12 commands going with my teensy LC. Are there instruction on how to do this or a video? I have limited knowllege but I can figure it out with a little help.



I'm using a MAC BOOK Pro. This is the program that I'm running on the teensy. I can get everything to up to pin 10 to work but thats it.

#include <Encoder.h>
#include <Bounce.h>



enum INPUT_PINS {
SOFF = 0,
RMAG = 1,
LMAG = 2,
BOTH = 3,
SSTART = 4,
ALT = 5,
BAT = 6,
PUMP = 7,

BEACON = 8,
LNDLGT = 9,
TLGT = 10,
NLGT = 11,
SLGT = 12,
HEAT = 13,
AVI = 14,
ALTAIR = 15,

LGTTEST = 16,
FUP = 17,
F10 = 18,
F20 = 19,
FFULL = 20,
FUEL = 21,
BRAKE = 22,};

void setupInput () {
pinMode (SOFF, INPUT_PULLUP);
pinMode (RMAG, INPUT_PULLUP);
pinMode (LMAG, INPUT_PULLUP);
pinMode (BOTH, INPUT_PULLUP);
pinMode (SSTART, INPUT_PULLUP);
pinMode (ALT, INPUT_PULLUP);

pinMode (BAT, INPUT_PULLUP);
pinMode (PUMP, INPUT_PULLUP);
pinMode (BEACON, INPUT_PULLUP);
pinMode (LNDLGT, INPUT_PULLUP);
pinMode (TLGT, INPUT_PULLUP);
pinMode (NLGT, INPUT_PULLUP);

pinMode (SLGT, INPUT_PULLUP);
pinMode (HEAT, INPUT_PULLUP);
pinMode (AVI, INPUT_PULLUP);
pinMode (ALTAIR, INPUT_PULLUP);
pinMode (LGTTEST, INPUT_PULLUP);
pinMode (FUP, INPUT_PULLUP);

pinMode (F10, INPUT_PULLUP);
pinMode (F20, INPUT_PULLUP);
pinMode (FFULL, INPUT_PULLUP);
pinMode (FUEL, INPUT_PULLUP);
pinMode (BRAKE, INPUT_PULLUP);
}

Bounce soff = Bounce (SOFF, 5);
Bounce rmag = Bounce (RMAG, 5);
Bounce lmag = Bounce (LMAG, 5);
Bounce both = Bounce (BOTH, 5);
Bounce sstart = Bounce (SSTART, 5);
Bounce alt = Bounce (ALT, 5);

Bounce bat = Bounce (BAT, 5);
Bounce pump = Bounce (PUMP, 5);
Bounce beacon = Bounce (BEACON, 5);
Bounce lndlgt = Bounce (LNDLGT, 5);
Bounce tlgt = Bounce (TLGT, 5);
Bounce nlgt = Bounce (NLGT, 5);

Bounce slgt = Bounce (SLGT, 5);
Bounce heat = Bounce (HEAT, 5);
Bounce avi = Bounce (AVI, 5);
Bounce altair = Bounce (ALTAIR, 5);
Bounce lgttest = Bounce (LGTTEST, 5);

Bounce fup = Bounce (FUP, 5);
Bounce f10 = Bounce (F10, 5);
Bounce f20 = Bounce (F20, 5);
Bounce ffull = Bounce (FFULL, 5);
Bounce fuel = Bounce (FUEL, 5);
Bounce brake = Bounce (BRAKE, 5);

FlightSimCommand genOn;
FlightSimCommand genOff;
FlightSimCommand batOn;
FlightSimCommand batOff;
FlightSimCommand pumpOn;
FlightSimCommand pumpOff;
FlightSimCommand beaconOn;
FlightSimCommand beaconOff;
FlightSimCommand lndlgtOn;
FlightSimCommand lndlgtOff;
FlightSimCommand tlgtOn;
FlightSimCommand tlgtOff;
FlightSimCommand nlgtOn;
FlightSimCommand nlgtOff;
FlightSimCommand slgtOn;
FlightSimCommand slgtOff;
FlightSimCommand heatOn;
FlightSimCommand heatOff;
FlightSimCommand aviOn;
FlightSimCommand aviOff;
FlightSimCommand lgttestOn;
FlightSimCommand brakeOn;







void setup() {
setupInput();
genOn = XPlaneRef("sim/electrical/generator_1_on");
genOff = XPlaneRef("sim/electrical/generator_1_off");
batOn = XPlaneRef("sim/electrical/battery_1_on");
batOff = XPlaneRef("sim/electrical/battery_1_off");
pumpOn = XPlaneRef("sim/fuel/fuel_pump_1_on");
pumpOff = XPlaneRef("sim/fuel/fuel_pump_1_off");
beaconOn = XPlaneRef("sim/lights/beacon_lights_on");
beaconOff = XPlaneRef("sim/lights/beacon_lights_off");
lndlgtOn = XPlaneRef("sim/lights/landing_lights_on");
lndlgtOff = XPlaneRef("sim/lights/landing_lights_off");
tlgtOn = XPlaneRef("sim/lights/taxi_lights_on");
tlgtOff = XPlaneRef("sim/lights/taxi_lights_off");
nlgtOn = XPlaneRef("sim/lights/nav_lights_on");
nlgtOff = XPlaneRef("sim/lights/nav_lights_off");
slgtOn = XPlaneRef("sim/lights/strobe_lights_on");
slgtOff = XPlaneRef("sim/lights/strobe_lights_off");
heatOn = XPlaneRef("sim/ice/pitot_heat0_on");
heatOff= XPlaneRef("sim/ice/pitot_heat0_off");
aviOn= XPlaneRef("sim/systems/avionics_on");
aviOff = XPlaneRef("sim/systems/avionics_off");
lgttestOn= XPlaneRef("sim/annunciator/test_all_annunciators");
brakeOn = XPlaneRef("sim/flight_controls/brakes_toggle_regular");}





void loop() {
FlightSim.update();
soff.update();
lmag.update();
both.update();
sstart.update();
alt.update();

bat.update();
pump.update();
beacon.update();
lndlgt.update();
tlgt.update();
nlgt.update();

slgt.update();
heat.update();
avi.update();
altair.update();
lgttest.update();

fup.update();
f10.update();
f20.update();
ffull.update();
fuel.update();
brake.update();



if (alt.fallingEdge() ) {
genOn.once(); }

if (alt.risingEdge() ) {
genOff.once();}

if (bat.fallingEdge() ) {
batOn.once();}

if (bat.risingEdge() ) {
batOff.once();}


if (pump.fallingEdge() ) {
pumpOn.once(); }

if (pump.risingEdge() ) {
pumpOff.once();}

if (beacon.fallingEdge() ) {
beaconOn.once();}

if (beacon.risingEdge() ) {
beaconOff.once();}


if (lndlgt.fallingEdge() ) {
lndlgtOn.once();}

if (lndlgt.risingEdge() ) {
lndlgtOff.once();}


if (tlgt.fallingEdge() ) {
tlgtOn.once();}

if (tlgt.risingEdge() ) {
tlgtOff.once();}

if (nlgt.fallingEdge() ) {
nlgtOn.once();}

if (nlgt.risingEdge() ) {
nlgtOff.once();}


if (slgt.fallingEdge() ) {
slgtOn.once();}

if (slgt.risingEdge() ) {
slgtOff.once();}

if (heat.fallingEdge() ) {
heatOn.once();}

if (heat.risingEdge() ) {
heatOff.once();}

if (avi.fallingEdge() ) {
aviOn.once();}

if (avi.risingEdge() ) {
aviOff.once();}


if (lgttest.fallingEdge() ) {
lgttestOn.once();}

if (lgttest.risingEdge() ) {
lgttestOn.once();}

if (brake.fallingEdge() ) {
brakeOn.once();}

if (brake.risingEdge() ) {
brakeOn.once();}








}
 
Status
Not open for further replies.
Back
Top