What's new
Aloft Forums

Welcome to Aloft Forums. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Archer M+ not working with Archer SR8 Pro

Scottand1000

New User
My last post about this didn't generate any responses, so I thought I would try and post again. I now have a SR10 Pro (firmware 2.1.12), and the same thing; it will not see the S.Bus input from the M+. This makes a total of 3 stabilized Rx's I have that don't see the S.Bus input from the M+. But my R8 Pro (non-stabilized Rx) does see the S.Bus input from the M+. Can someone point me in the right direction? Is there some config issue I am missing when it comes to the Archer SRx receivers not working with a M+?



Old post below
-----------------

I have a SR8 Pro, and I am trying to set up a M+ as a redundant Rx. I can't get the SR8 Pro to *see* S.Bus input from the M+. What doesn't work is M+ connected to SR8 S.Bus IN.

For completeness, SR8 Pro and M+ using firmware 2.1.12. X9D+ 2019 Tx using OTX 2.3.15



I have a spare R8 Pro (not sure of its firmware rev). I tried the following combinations.


M+ connected to R8 Pro S.Bus IN -- works (w each Rx bound to a different model i.e one Rx green light, the other Rx red light). Each Rx alone will work a servo. This verifies M+ and its soldered cable is working.
SR8 Pro S.Bus OUT connected to R8 Pro S.Bus IN -- works (w each Rx bound to a different model i.e one Rx green light, the other Rx red light). Each Rx alone will work a servo. Interestingly, the SR8 Pro S.Bus output seems to work OK.

--but--

R8 Pro S.Bus OUT connected to SR8 Pro S.Bus IN does not work.

So, both the M+ and the SR8 Pro can talk to the S.bus IN port on the R8 Pro, but neither the M+ or the R8 Pro can talk to the S.Bus IN port on the SR8 Pro.

I have a second SR8 Pro (firmware rev 2-1-10). I repeated all the above with the second SR8 Pro. Same results as above.

Any idea why the SR8 Pro doesn't seem to take S.Bus input?

Thanks, Scott
 
Well, I guess it is working now. After playing with it for the umpteenth time, I stumbled on this:

If the SRx is the primary, and the M+ is the secondary, the only way I can get the SRx to see the M+ input is to switch models *while* both Rx's remain powered on. Previously when I would try to test this, I would first select the model that the SRx is bound to and then turn on the power to the Rx's. The SRx would go green and the M+ would go red, and the servo moves. Good, as expected. I would then power off the Rx's, switch models on the radio, then power the Rx's back on. The M+ would go green, the SRx would go red, but no servo movement. Hence I say it doesn't work.

Tonight, I repeated this experiment. In haste, this time I didn't bother turning off the Rx's in between the switching of models on the radio. The radio barks at this a little, but an "enter" gets past this. And wouldn't you know, now a green light on the M+ works the servo. At this point I was still a little skeptical, so I watched the RSSI while moving foil near the M+ antenna, intentionally trying to block the reception. And yeah, the RSSI drops. It picks back up when I move the foil out of the way, so I guess the M+ truly is taking over.

The thing that gets me is when I set up an plain R8 Pro as the primary and the M+ as the secondary, I can turn off power to the Rx's in between switching models on the radio. When I power the Rx's back up, the M+ goes green, the R8 goes red, and the servo moves just fine. Weird that the SRx behaves differently than the R8 in this respect...

-Scott
 
I'm not really following what you are trying to test with your model switching, but I remember struggling with an R8Pro (I believe) that I couldn't get to recognize an R9SX on SBus. It's more than a year ago, but as far as I remember the solution was to bind the R9SX with channels 1-16 instead of 1-8. With 1-8 I could still set channel 8 to SBus out in the menu, but it had no effect.
Take this with a grain of salt as it's too long ago to remember the details, but it maybe something for you to explore.
 
Getsuyoubi,

Re: model switching. If you set up a redundant Rx system (i.e. master/slave Rx's both on 2.4GHz), how do you know the slave is working properly? If they are both bound to one model, the master will always be commanding the servos. So how do you test? How do you only talk to one Rx at a time? The way I know how to test this is to temporarily copy the model so you have the original model (call it A), and a copy of the original model (call it B). Bind the master Rx (and only the master Rx) to A, bind the slave (and only the slave) to B. Now, depending on which model you have active, only one Rx will be communicating with the radio at one time. Both Rx's will have power at the same time (whenever the battery in the plane is "on"). If model A is active, then the Master Rx will have a green light and the slave will have a red light. Moving the sticks will get servos to move bc the master RX is commanding the servos. Now switch to model B. The slave Rx will now have a green light bc it is bound to model B, and the master Rx will have a red light bc it is not bound to model B. Move the sticks and the sevros should still move, but this time commanded by the slave Rx and passed through the master Rx. A successful test like this will let you know both Rx's are capable of driving the servos and the redundant setup is working properly. Now, delete model B and bind the slave Rx to model A (which already has the master bound to it). You now have a tested redundant RX setup, with both Rx's bound to one model. Should one Rx get a bad signal, the second Rx should be there to take over and keep the plane flying -it's been bench tested and shown that each Rx independently can move the servos .

The issue (for lack of a better word) I found with the SRx's is this: When testing as described above, and the SRx is setup to be the master Rx, if I shut off the power to the Rx's (by turning off the plane while I switch between model A & B), then power back on the plane, the slave will not make the servos move. The slave has a green light, the master has a red light, but the servos don't move. However, if I leave the Rx's powered on as I switch between models A & B, then all works as advertised. And this is fine bc if, say, the master Rx couldn't get a good signal when up flying, then the slave will take over providing input to the master. Of course the power would remain on to both Rx's the whole time in this real-life type of scenario. The reason I was turning off the power to the Rx's during my bench test is that the radio complains if I leave them powered on when I switch models. The radio warns me the "receiver is still connected". I have to purposely hit an "enter" to get around this. So I would power down the master/slave when switching between models. And this is why I thought the slave wasn't able to talk to the master; I was turning off power to the Rx's in-between switching models and when I did, it really didn't work LOL. And curiously, in the process of trying to debug this, I found this isn't the case if I make a non-stabilized Rx like the R8 Pro as the master Rx. If I hook up the servos to the R8 Pro, and hook up a M+ as a slave, I can turn the power off to both Rx's in-between switching models, re-power the Rx's and it all works fine. The slave will drive the servos. This had me convinced the SRx receivers had a problem with the M+ as a slave. It took many iterations and lots of hours to figure this out. I would have thought the SRx receivers and the R8 Pro would behave the same in this regard...

Anyhow, in the future, I hope this helps someone else that tries to bench test the setup like I did. The SRx's can't be powered down in-between switching models or the results will make it seem like the M+ slave is not communicating with the SXr master.

Scott
 
Back
Top