Making this thread to specifically address questions regarding implementation of SRXL2 in DIY electronics.

See the following for documentation and code library:
https://github.com/SpektrumRC/SRXL2

For telemetry sensor specifics, this thread should still be the go to:
https://www.rcgroups.com/forums/show...IY-sensors-%21

You can also find official telemetry documentation here:
https://github.com/SpektrumRC/Spektr...ster/Telemetry

Thanks Miguel. I had not seen the latest update of the spektrumTelemetrySensors.h file. Should the GPS_BINARY identifier be 0x26? It is shown as 0x16 in the sensor specific section under GPS Binary Type.

Binary GPS is not yet supported in the transmitter. Use the standard GPS.

Andy

Thanks Andy. Would it be possible for Spektrum to identify which sensors are currently supported in the DX and iX transmitters? That would be helpful for those of us wishing to experiment with different sensors.

Hi,
Working on sending telemetry data via srxl2.

If I use device id 30 (or 40 both behave the same) and request a handshake, I can successfully complete the handshake and I include a device priority of 10.

I then start receiving control data with the servo data at 11ms intervals (servo data is empty until about 5 seconds as rx goes through as3x initiation)

Approximately every 1200 ms I receive control data with the Reply ID matching mine.

I then reply with a telemetry pack using a sensor ID of 0x7E.

All of this does result in the telemetry data I am sending displayed on the transmitter.

However, there are the following issues:

1. The telemetry link on the TX becomes intermittent with longer periods of the no telemetry connection symbol than connection with a frequency similar to the 1200ms above. That doesn’t seem right and….

2. As a result of item 1, getting auto-configure to initiate is hit or miss as you need to hit auto-configure right when the brief period of telemetry connection exists.

3. Changing the value of device priority to higher than 10 seems to have no effect on 1 or 2.

If I set the device priority to 0 the Telemetry connection is always solid bars on the TX. But of course I can't send telemetry then since 0 means I'll never be asked for it.

This is on DX9 and AR637T both with current firmware.

Any suggestions?

Attached is a capture of the communication between my device (Teensy 3.2) and the AR637T.

Following is GitHub repository of my code. Started with Spektrum GitHub and modified for Teensy. https://github.com/delateurj/SRXL2SensorAndBridge

Thanks,
Joe.

Here is log file as csv, probably easier to view ...needed to zip it since csv is not allowed file type.

The transmitter needs to see QOS (7F) messages. If you are swamping the telemetry system with other data, there will be inadequate QOS to keep the bars alive.

Andy

Thanks for the reply Andy.

Agreed. Swamping could cause this. Not sure if that is what is happening and if it is, what is causing the swamping by the AR637T.

My device doesn't send telemetry via RF as it has no rf. and is sending a single telemetry packet via srxl2 to the AR637T about once a second when requested by a control packet.

I assume Miguel would cover the AR637T behaviour.

I think with his help I need to better understand the spec. and base RX behaviour when receiving data via srxl2 from a non-rf device. For example, the handshake packet has an info byte. The spec. says:

Info: A byte used as a bitfield to report additional device options that could be useful for an FC or
Smart ESC. Currently, bit 0 = 1 if the device can send long range telemetry, or 0 if short range only.

That means only options are long range or short range telemetry, but what if the device has no telemetry rf?

Also, the spektrum library has the following defines:

/ Bit masks for Device Info byte sent via Handshake
#define SRXL_DEVINFO_NO_RF (0x00) // This is the base for non-RF devices
#define SRXL_DEVINFO_TELEM_TX_ENABLED (0x01) // This bit is set if the device is actively configured to transmit telemetry over RF
#define SRXL_DEVINFO_TELEM_FULL_RANGE (0x02) // This bit is set if the device can send full-range telemetry over RF
#define SRXL_DEVINFO_FWD_PROG_SUPPORT (0x04) // This bit is set if the device supports Forward Programming via RF or SRXL

This doesn't seem to agree with the spec as the comment says 0x00 is for non-RF devices (this is what I have been using).

Thanks,
Joe.

First, I'd point out that any values you don't intend to provide yourself should be FF's or 7F's (depending on signed/unsigned), not 0's. Anything other than that, and the RX will override its own data with what you provide. In this case, you'd be losing RSSI data from the receiver based on what I can tell in your packets.

For the option bits, I would go by the defines, in which case 0x00 is correct. It's possible the documentation needs to get updated, but I'll leave that one to Matt.

I'm personally not super sure about the priority and why you're getting delayed requests. It's possibly related to what Andy mentioned, but I'll see if I can get Matt to chime in.

Hi Miguel,

Thanks for the reply and your suggestion.
I think the value I am leaving 0 in my telemetry packet are the A and B dbm. (If you see something else, please let me know)
While the Telemetry spec says 0 means no value, I'll give 0xFF a shot since it says that is supported as well:

INT8 dBm_A, // Avg RSSI in dBm (<-1 = dBm, 0 = no data, >0 = % range) -- (legacy)antenna A in dBm
dBm_B; // Avg RSSI in % (<-1 = dBm, 0 = no data, >0 = % range) -- (legacy)antenna B in dBm
// Note: Legacy use as antenna A/B dBm values is still supported. If only 1 antenna, set B = A.
// The "no data" value is 0, but -1 (0xFF) is treated the same for backwards compatibility

Update: 0xFF for dBm_A and B does not change behaviour.

Originally Posted by delateurj

Hi Miguel,

Thanks for the reply and your suggestion.
I think the value I am leaving 0 in my telemetry packet are the A and B dbm. (If you see something else, please let me know)
While the Telemetry spec says 0 means no value, I'll give 0xFF a shot since it says that is supported as well:

INT8 dBm_A, // Avg RSSI in dBm (<-1 = dBm, 0 = no data, >0 = % range) -- (legacy)antenna A in dBm
dBm_B; // Avg RSSI in % (<-1 = dBm, 0 = no data, >0 = % range) -- (legacy)antenna B in dBm
// Note: Legacy use as antenna A/B dBm values is still supported. If only 1 antenna, set B = A.
// The "no data" value is 0, but -1 (0xFF) is treated the same for backwards compatibility

Actually it's possible you are correct with this getting reported as 0 by default if you don't have a value. I'll defer to Matt as well on this. My assumption was on how all the other values are typically handled.

Originally Posted by delateurj

...
However, there are the following issues:

1. The telemetry link on the TX becomes intermittent with longer periods of the no telemetry connection symbol than connection with a frequency similar to the 1200ms above. That doesn’t seem right and….

2. As a result of item 1, getting auto-configure to initiate is hit or miss as you need to hit auto-configure right when the brief period of telemetry connection exists.

3. Changing the value of device priority to higher than 10 seems to have no effect on 1 or 2.

If I set the device priority to 0 the Telemetry connection is always solid bars on the TX. But of course I can't send telemetry then since 0 means I'll never be asked for it.

This is on DX9 and AR637T both with current firmware.

Any suggestions?

I agree first of all that 1.2 seconds between requests for your telemetry does not seem right. Are you connecting your device to the Bind/Prog/SRXL port or the throttle port via a Y-cable? I'd like to know if you get different results for the two different ports. I actually don't expect it to work properly on the Bind/Prog/SRXL port currently, so I'm hoping that's the problem. Unfortunately, the receiver firmware does not yet properly handle anything on that Bind/Prog/SRXL port other than a remote receiver.

The internal priority value for the RPM packet is 10, so I'd expect that's what you would want to use, unless you're wanting to send other data as well.

Matt

Hi Matt,

I am using the dedicated srxl2 port with the 4 pin cable.

Sounds like its not anything obvious or already known. I have tried various approaches and had a few more questions/"facts" but didn't want to put in too much detail on the first inquiry. Let me do a little more experimentation and post some more info/questions when I have it organized and confirmed.

For example, I thought maybe the problem was using an ID that initiates a handshake instead of an iD that wait for the rx to initiate. However, if I don't initiate the handshake, I never see handshake attempts from the RX....now this might be that I am not booting up in time (I have reason to doubt that is the problem) but to be sure, I am setting up separate power switches on V+ so my device is up and read to receive prior to the rx being powered up. Will still be on same battery with common ground needed for serial comms.

So unless something else immediately comes to mind, let me try some things like that and organize my findings/questions.

Let me know if this is the best way to share info/questions. If something is easier for you, like creating issues on the spektrum github, I can do it that way or do both.

I also got a SPM4651T I can try as well as a DX18 and ix20 but I doubt its the tx.

Thanks,
Joe DeLateur.

Originally Posted by delateurj

I am using the dedicated srxl2 port with the 4 pin cable.

Sorry, I wasn't very clear: I don't think that dedicated port will work currently. Please try it on the throttle port instead and let me know if that works. If it does, then it will require a firmware update to make it work on the other port, and I can't give a timeline of when that will happen. The other option would be a Y-cable and a Smart ESC.

Matt

Will try the throttle port....thanks for the follow up clarification.