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 R4 with very short range

Good call on inspecting the raw data.

I looked at InternalAntennaRadioCheck.csv and found RX2 listed as active in row 49. I didn't check the other files. I'd be curious to know if you learn anything more.

View attachment 23774
Here is the response form FrSky engineering.

"Abot the failed safe mode, it was stored in the receiver side, not trgier by the radio when sigan lost or telemetry lost.
and it is a normal. because the radio do not know how many receiver are connected in actual communication.
so it will have a try to switch to other receiver if radio can not get the telemetry.'"
 
The first question that pops into my mind is, how can the radio not 'know' the number and types of the connected receivers? That information is a key part of the model programming. There must be something important that I'm missing or misunderstanding.

Another thing I wonder is whether we know anything more now about why the non-existent RX2 became the active receiver. I suppose it might have been triggered by a simultaneous lack of telemetry from both RX0 (2.4GHz) and RX1 (900MHz). Another possibility is that the switching algorithm prioritized RX2 over RX1 in some cases for a reason we don't know. Or maybe there's some randomness involved.

But we can say with confidence that any outages on the 900MHz link were brief (if they occurred at all). We know that from the the telemetry reporting period (~0.5s) and the fact that RX2 was only active for one period at a time (i.e. less than about 1s). If the 900MHz link did cut out, it might have been caused by a moment of very poor antenna orientation. But we're way out into hypotheticals now.

By the way, it may be helpful to reduce your telemetry reporting period to the minimum (0.1s). The finer grained data can come in handy, plus there's no downside other than larger log files. I always use the minimum myself.

Edit
All the above is only a matter of curiosity as long the system is working as intended. I guess we could delve into it more deeply, but the problem in this thread does seem to revolve around a possibly wonky R4 -- and perhaps an imperfectly connected antenna inside the transmitter. Maybe.
 
Last edited:
I got my power board today so will dive into replacing that and verifying all the internal antenna connections.
I like your idea of running the logging at minimum interval as I still have signal loss in one spot at .23 miles out, I have had a failsafe there 3 times on 2 different 2.4 GHz Rx now.
Strange thing is the INAV log did not show a signal drop or FS the last time but they were clearly shown on the OSD and the model initiated a RTH.
 
I still have signal loss in one spot at .23 miles out, I have had a failsafe there 3 times on 2 different 2.4 GHz Rx now.

A distance of .23 miles (370m) is obviously small potatoes, even for 2.4GHz. That said, I can easily credit a link failure at such a distance based on my own experience. In my case, data strongly suggested that RF noise was the culprit. There can be other causes for such occurrences, of course.

If your failsafes happened with two or three different models, that clearly reduces the likelihood of a problem specific to one model. But that won't be news to you or anyone else reading here, I'm sure. :)


Strange thing is the INAV log did not show a signal drop or FS the last time but they were clearly shown on the OSD and the model initiated a RTH.

Failsafe is a funny old thing. Different protocols, firmware, and hardware handle it in different ways. And, yes, there are cases where failsafe itself has been known to fail. Back in 2020, a inventive fellow posted instructions for making a high frequency SBUS data logger. Among other things, the device provided insights into the moment to moment health of an RF link and whether failsafe had been (or should have been) triggered. There were some interesting discoveries.

Staying tuned to see what more you discover.
 
Last edited:
Interesting article I may just have to build one of those loggers. Could shed some light on what is going on and well it sounds like a cool gizmo to have in the tool box.
 
And the saga continues, after removing and reinstalling the antenna the Rx will not bind. I created a new model for testing, registered and all looked normal, clicked bind and power cycled the Rx and all I get is a red flashing light. I thought thats strange but perhaps the Rx finally died so I grabbed the other new R4 and got the same result. Switched to another Tx and get the same, flashed previous R4 FW and still same result.
I am starting to wonder if there is a FW conflict but I do not want to downgrade ETHOS for troubleshooting and create new issues with other models that are working properly.
 
Before messing with firmware, do you have another receiver to try?

From the RCG thread, I saw that you're having this problem with two different R4 receivers. Did you happen to replace antennas on both? If so, that could be a clue.
 
Last edited:
Gizmo - You want to send the gear to us for checking it out? Sending just the receivers should be easy.
 
Before messing with firmware, do you have another receiver to try?

From the RCG thread, I saw that you're having this problem with two different R4 receivers. Did you happen to replace antennas on both? If so, that could be a clue.
Only replaced the antenna on the one that had short range, the second one has never been installed but was used to test some servos. The Rx6R that replaced the crippled R4 registered and bound just fine, I think it is something specific to the Archer R4.
 
Back
Top