The Robot Thread

I knew I had read this but could not find it again. Right in the documentation
You can use any RC transmitter/receiver system, provided it has a minimum of four channels.
Click to expand...
That is my problem. My Surface Transmitter DX2.0 only has 2 channels.
Using wrong hardware.

ELRS is cheap.
The Transmitter, built into the RC controller is the same price.
Radiomaster 8T would probably do just fine for ELRS rover. Gamepad sytle for $50 new just add receiver for $25. RB3

So advantages of ELRS over DSMx Serial Adapter = Range, Channels and probably battery life.

In the same vein you have to consider "Crossfire" systems. More and more features.. Some I really don't need.

I have a HobbyTown store in the area and I almost went and bought a SPM461T from. In stock.
But when I looked at controllers the SLT3 Spektrum Car Style controller has its own protocol. SLT. There is an upgrade to DSMR.
I might go browse actual product.
 
I don't think the two-channel transmitter itself is what caused the "Bad channel 1 input" error. For Rover, the default mapping is basically:
Code: 
CH1 = Steering
CH3 = Throttle
CH8 = Mode switch
MODE_CH can be changed, so you do not actually need a physical channel 8 just to get RC input working. I think the bigger problem was the type of receiver/output. The SR3000 has normal individual servo outputs for Steering, Throttle and AUX. That is different from feeding a serial RC protocol into an ArduPilot UART. The BAT/TEL connector also should not automatically be assumed to be a DSM serial RC output just because it says TEL or DATA.
The SPM4650 you found looks much more appropriate because it is explicitly an SRXL2 serial receiver. ArduPilot's SRXL2 documentation says to connect it to a UART like this:
Code: 
GND -> GND
VCC -> 5V
Signal -> UART TX
Then configure that UART, for example:
Code: 
SERIAL1_PROTOCOL = 23
SERIAL1_OPTIONS = 4
Option 4 enables half-duplex operation on the TX pin. SRXL2 is a single-wire half-duplex protocol, which is why the signal goes to TX rather than the usual RX pin. I would leave RC_PROTOCOLS on auto-detection initially instead of forcing only DSM while testing SRXL2.
Once the SPM4650 is connected, I would first check Mission Planner Status and watch ch1in, ch2in, ch3in etc. If those values move when you move the transmitter controls, then the receiver-to-ArduPilot link is working. Only after that would I worry about RCMAP.
mceclip0.png


So I think you were right in your latest post: the missing piece was probably a serial receiver/interface rather than simply needing more RC channels.
Also, RC_OPTIONS=48 should still be useful because it enables logging of the raw serial RC input bytes along with your existing option. That could be useful if SRXL2 still does not decode. Spektrum explicitly warns that Surface and Air are incompatible, even within their ecosystem
 
You must log in or register to reply here.
Back
Top