finally after a few months of trepidation i mustered the gall to test RTH on BF4.4.0 using assigned rescue switch.
1. highlight of this test is a very noticeably odd handling behavior of the quad while flying to home. it is like a bucking rodeo bull on the way back! is there any way to make this thing more docile??
2. i am still running FW BF4.4.0 using BF configurator 10.9.0 for when this “upgraded rth” was supposed conceived. i see two newer FW versions BF4.4.2 and i think 4.4.3 which i flashed using present configurator. oddly after i installed all my saved presets, diff, etc. the goggles OSD did not display the satellite count and DOP information but it was all enabled in the OSD tab!
3. there were some hair pulling moments when i updated to BF configurator 10.10.0 RC1 if only to see if it fixes the issue with the much newer FW 4.4.2 and 4.4.3 but i still did not get the satellite info via OSD.
4. i finally gave up on the newer BF FW and configurator! so i reverted to square one with FW BF4.4.0 and configurator BF10.9.0 and reinstalled the saved files. voila i get back my satellite counts on OSD again!
5. there is a merit to why i fiddled with the newer firmwares. on my first RTH attempt the quad did fly back to me as planned. but on the second attempt with same location it did not and just stayed there hovering in place! so i flew around and attempted another RTH and again it flew back. another try and again it hovered in place! ergo i did not get a consistent RTH behavior which i found very odd and unacceptable!
then the circus of mix and match firmware/configurator of steps 1-3 above began! finally i gave up thinking that this wonky RTH is still wonky after all so i reverted everything to square one just to get back satellite info via OSD. strangely when i attempted RTH again on the reverted firmware RTH worked consistently with every attempt!
pardon the lengthy share but i hope someone here who has had the same experience can shed light. i knew many folks complained about RTH in BF4.4.X in general and it seems an abandoned feature moving forward as the newer firmwares did not even display the gps! what a big PITA getting this thing to finally work. just for everyone’s benefit i am using an HGLRC mini M10 gnss module. BF4.4.X was picky with the gnss chips in general but this one performed very well!
i have added a YT link showing a short RTH test which was shot after the initial successful attempts. as of this writing all is working as expected, all flights uneventful!?
https://youtu.be/4Qqc6h1o4Xo?si=7x8QTXgJNpuaaijO
latest flight test report:
i flew a couple of my heavier lipos to see the quad’s performance and it seems not to mind the additional weight at all. the prevailing wind has also picked up quite a lot granting the opportunity to test for these conditions. i did a direct crosswind departure from home point and when i hit RTH the quad as always halted forward flight and briskly turned 180deg to face home. this 180 turn can be a bit of a mess as it typically overshoots the mark. then it slowly adjusts heading in order to track home. i must say it’s quite impressive how it flew in crabbed fashion to compensate for the hard crosswind.
i also flew away from home point with a direct tailwind. after a few hundred meters i hit RTH. after the usual wonky 180 turn and after quad establishes its bearing to head home, this is where i noticed something amiss. the strong headwind is now eating up its forward speed to a low 15kph (selected 40kph in BF settings) to eventually almost standstill. this is where things get exciting! somehow the quad really did stop and may have pondered its already home! then it went into a very slow descent which may have ended into a landing until i intervened.
i deem it necessary to be mindful of the proper forward speed setting in BF to allow for the most reliable value under most conditions. otherwise it would be prudent to avoid critical missions that my need RTH in heavy winds going back to home point!
i have also observed another quirk when i hit RTH from a few hundred meters and i was inadvertently reducing the throttle stick as if i were flying to descend the quad. this also prompted the quad to think that it was already at home from an intermediate position enroute and thought it has landed while still airborne. this event lost the proper home point and had the arrow pointing to some random location and the quad was going to follow this new home wherever it was! again i intervened to save the day.
so far my thoughts on BF RTH is modestly useful but pilot has to be very mindful of its quirky behaviours as stated in my flight reports. it is still a very far cry from the dji implementation but it may be quite reliable especially under calmer wind conditions.
1. highlight of this test is a very noticeably odd handling behavior of the quad while flying to home. it is like a bucking rodeo bull on the way back! is there any way to make this thing more docile??
2. i am still running FW BF4.4.0 using BF configurator 10.9.0 for when this “upgraded rth” was supposed conceived. i see two newer FW versions BF4.4.2 and i think 4.4.3 which i flashed using present configurator. oddly after i installed all my saved presets, diff, etc. the goggles OSD did not display the satellite count and DOP information but it was all enabled in the OSD tab!
3. there were some hair pulling moments when i updated to BF configurator 10.10.0 RC1 if only to see if it fixes the issue with the much newer FW 4.4.2 and 4.4.3 but i still did not get the satellite info via OSD.
4. i finally gave up on the newer BF FW and configurator! so i reverted to square one with FW BF4.4.0 and configurator BF10.9.0 and reinstalled the saved files. voila i get back my satellite counts on OSD again!
5. there is a merit to why i fiddled with the newer firmwares. on my first RTH attempt the quad did fly back to me as planned. but on the second attempt with same location it did not and just stayed there hovering in place! so i flew around and attempted another RTH and again it flew back. another try and again it hovered in place! ergo i did not get a consistent RTH behavior which i found very odd and unacceptable!
then the circus of mix and match firmware/configurator of steps 1-3 above began! finally i gave up thinking that this wonky RTH is still wonky after all so i reverted everything to square one just to get back satellite info via OSD. strangely when i attempted RTH again on the reverted firmware RTH worked consistently with every attempt!
pardon the lengthy share but i hope someone here who has had the same experience can shed light. i knew many folks complained about RTH in BF4.4.X in general and it seems an abandoned feature moving forward as the newer firmwares did not even display the gps! what a big PITA getting this thing to finally work. just for everyone’s benefit i am using an HGLRC mini M10 gnss module. BF4.4.X was picky with the gnss chips in general but this one performed very well!
i have added a YT link showing a short RTH test which was shot after the initial successful attempts. as of this writing all is working as expected, all flights uneventful!?
https://youtu.be/4Qqc6h1o4Xo?si=7x8QTXgJNpuaaijO
latest flight test report:
i flew a couple of my heavier lipos to see the quad’s performance and it seems not to mind the additional weight at all. the prevailing wind has also picked up quite a lot granting the opportunity to test for these conditions. i did a direct crosswind departure from home point and when i hit RTH the quad as always halted forward flight and briskly turned 180deg to face home. this 180 turn can be a bit of a mess as it typically overshoots the mark. then it slowly adjusts heading in order to track home. i must say it’s quite impressive how it flew in crabbed fashion to compensate for the hard crosswind.
i also flew away from home point with a direct tailwind. after a few hundred meters i hit RTH. after the usual wonky 180 turn and after quad establishes its bearing to head home, this is where i noticed something amiss. the strong headwind is now eating up its forward speed to a low 15kph (selected 40kph in BF settings) to eventually almost standstill. this is where things get exciting! somehow the quad really did stop and may have pondered its already home! then it went into a very slow descent which may have ended into a landing until i intervened.
i deem it necessary to be mindful of the proper forward speed setting in BF to allow for the most reliable value under most conditions. otherwise it would be prudent to avoid critical missions that my need RTH in heavy winds going back to home point!
i have also observed another quirk when i hit RTH from a few hundred meters and i was inadvertently reducing the throttle stick as if i were flying to descend the quad. this also prompted the quad to think that it was already at home from an intermediate position enroute and thought it has landed while still airborne. this event lost the proper home point and had the arrow pointing to some random location and the quad was going to follow this new home wherever it was! again i intervened to save the day.
so far my thoughts on BF RTH is modestly useful but pilot has to be very mindful of its quirky behaviours as stated in my flight reports. it is still a very far cry from the dji implementation but it may be quite reliable especially under calmer wind conditions.
![[-]](https://intofpv.com/images/collapse.png)
Well at least it is heading in the right direction. It does look like it is actually flying very smoothly though, is the 8" mavic conversion? You got the turning setup?
