Aperhinsive about the RTH

[kydan]

The first is a misunderstanding of what "binding" is. Binding is NOT just the connection. It's how that connection is bound together between the components of the system.

When you turn on your RC, and then turn on your Phantom, there's a handshake that occurs. The Phantom passes info about itself to the controller, which the controller stores as the "target", and the Phantom in turn stores info about the controller so it knows who's talking to it. That is "binding". And that binding is kept (stored) for as long as the controller and Phantom are powered on.

When you power off the controller, it not only breaks the connection, but also forgets the binding. So that when you power it back on, the RC and the Phantom have to go through the entire handshaking process again to re-initiate the binding. Sometimes this is successful, sometimes it is not.

I agree with everything in your post except that the binding information isn't forgotten. The misunderstanding you are talking about is true. Think of it as "bind" and "link". You only should have to bind the TX to the RC unit once. We don't even bind our RTF Phantom when we get it the first time--they've already done it for us. That's why other Phantom TX's won't control ours--they'd have to bind it first. For some heli's you have to insert a bind clip so that the TX and RC unit can bind together. Once they're binded, you normally don't have to bind the unit ever again.

When you "link" the units, you simply power on the TX first, then power on your desired RC unit. The TX picks up the RC unit and the link is made. Once you turn off the TX, the link is lost until you can power off the RC unit and redo the TX on>RC unit on.

The link is what we are arguing on this thread about whether it can come back or not in the same session of powering off the TX to enable RTH (Which it usually can't).

 

[Mike]

Your power switch can be your 4th S1 switch for failsafe and would be no different than using S1 to bottom most position for failsafe.. Just my opinion!

Of course you're entitled to your opinion, but your assumption is wrong. Flipping the S1 to trigger RTH does not sever the control signal. Signal is always maintained unless you fly out of range or turn the transmitter off. The switch simply invokes the RTH function until you either turn it off by flipping the switch back or the craft lands. Though the end result is the same for either flipping the switch or turning off the transmitter power, all control is lost when powering down the transmitter.

 

[srandall25]

When I required my first RTH, I didn't have the S1 failsafe enabled. I turned off the tx to let the phantom come home. When the Phantom got into sight I flipped the power to the TX back on, but was unable to gain control. It had to land itself..

This actually makes sense, because simply turning the controller back on is not enough. You must still flip S1 to ATTI and then back to GPS (top position). Per the manual "when the S1 switch is switched to position 1 (top most position), toggle the S1 switch to any other position once to regain control." You must perform the toggle.

For this reason, it is actually more efficient to use S1 to initiate because it's less steps in the total process. You flip down to failsafe to initiate, then flip again to regain control... as opposed to turning the controller back on and then making the additional switch flips required.

Regarding the other member's input stating that I'm wrong about S1 severing the control signal. Well I can certainly respect that if I'm truly wrong. It's merely speculation at this point on my part because I haven't seen any evidence to the contrary. I see the statements, but nothing to back it up. I'm not at all saying you're wrong. I just see no evidence that proves the control signal isnt' actually lost. Yes I fully realize that just because a message states it is, that this may not actually be happening.. got that.. I've sent an email on this to DJI tech support hoping they can confirm one way or another. I believe they're the only ones who can really say for sure or not.

 

[srandall25]

One very simple test you can run is...

Test RTH by turning off the RC, wait for a bit, and then turn the RC back on. Time how long it takes for the orange RTH LEDs to turn to green. There is a delay. That delay is however long it takes for the full handshake to occur.

Now test RTH by switching S1. Wait for a bit, and then flip S1 back to normal flight. The LEDs switch to green nearly instantaneously. That's because there is no handshake that needs to occur. Because the binding still exists (and, in truth, I'm betting even the TX communication still exists).

I find this interesting. Could the delay you mention be due to the fact that the control signal isn't technically re-established until you perform a toggle switch after the controller is turned on? The manual states that when S1 is in position 1 (top most position) that you must "toggle the S1 switch to any other position once to regain control".

If you have the opportunity (and I will as well) perform this same test and observe how long it takes the LEDs to turn green after you've not only turned on the controller, but also flipped S1 to ATTI and back to GPS.

 

[Toddzilla]

FYI re S1 when it is switched from position 1 to position 3 (failsafe)

According to my HP 8569B Spectrum Analyzer, the transmitter continues to transmit a "spread spectrum" signal when S1 is in position 3. There is apparently no digital information "on" the 2.4 GHz "spread spectrum" pulses that the P2 receiver can use so it goes into the "go home" mode.

Your thoughts/comments welcome

 

[srandall25]

FYI re S1 when it is switched from position 1 to position 3 (failsafe)

According to my HP 8569B Spectrum Analyzer, the transmitter continues to transmit a "spread spectrum" signal when S1 is in position 3. There is apparently no digital information "on" the 2.4 GHz "spread spectrum" pulses that the P2 receiver can use so it goes into the "go home" mode.

Your thoughts/comments welcome

So when S1 is in position 1, it is pulsing digital information, and when it is flipped to position 3, it is no longer pulsing digital information?

 

[Toddzilla]

Re my earlier post this afternoon on this topic.

The spectrum analyzer previously mentioned simply showed that the P2 controller transmitter continues to transmit a spread spectrum radio signal in the 2.4 GHz band when switch S1 is in position 3 (failsafe). The analyzer cannot decode the digital signal(s) riding on the 2.4GHz signal. It is quite likely that switch 3 position simply transmits a digital signal to the P2 receiver which puts the NAZA-M into a RTH mode and that this digital signal turns off when S1 is switched out of position 3.

In any case, the controller transmitter continues to transmit a radio frequency signal in the 2.4GHz band until the transmitter is switched "off" by the power switch. I guess that the NAZA-M also goes into RTH mode when the air-unit receiver loses its radio frequency connection with the ground-unit controller transmitter, ie. the signal strength of the transmitted signal and data falls below that which the receiver can decode. (too great distance between air-unit and ground-unit OR loss of line-of- sight connection.

thoughts/comments

 

[Toddzilla]

OR the transmitter is simply turned "OFF" !!

 

[JWarren]

I'd highly recommend testing it by flying it out to its limits given the fact people have PV2+s that have stock ranges to 600ft all the way to 3500ft. You need to know what your aircraft's operating ranges are. You'll get real nervous the first time you have Loss of Signal on your screen but as long as you have GPS and home lock you'll be just fine. I personally would not trust it landing itself. When it gets back to you where you are sure you are within range move S1 to middle then back to top to regain control.

 

[srandall25]

Re my earlier post this afternoon on this topic.

The spectrum analyzer previously mentioned simply showed that the P2 controller transmitter continues to transmit a spread spectrum radio signal in the 2.4 GHz band when switch S1 is in position 3 (failsafe). The analyzer cannot decode the digital signal(s) riding on the 2.4GHz signal. It is quite likely that switch 3 position simply transmits a digital signal to the P2 receiver which puts the NAZA-M into a RTH mode and that this digital signal turns off when S1 is switched out of position 3.

In any case, the controller transmitter continues to transmit a radio frequency signal in the 2.4GHz band until the transmitter is switched "off" by the power switch. I guess that the NAZA-M also goes into RTH mode when the air-unit receiver loses its radio frequency connection with the ground-unit controller transmitter, ie. the signal strength of the transmitted signal and data falls below that which the receiver can decode. (too great distance between air-unit and ground-unit OR loss of line-of- sight connection.

thoughts/comments

Excuse my ignorance here... but knowing the controller transmits at 5.8GHz, why is it also transmitting at 2.4GHz?

 

[BigTulsa]

There really is no "loading" of the NAZA software. In fact, your bird is already flying with NAZA. It's how the Phantom does what it does. All you're missing is the ability to CONTROL the NAZA functions and settings (Vision mode simply hides all that from you... dumbing down the interface, rather than the underlying functionality).

All that's needed to get your bird into "NAZA mode" (and have control over the settings) is to go into the Assistant utility and select NAZA. Then you have the ability to configure the switches.

And, in fact, with both switches up, you are, in affect, in Vision mode. No difference at all between that and where you are now... other than the ability to switch on other functions... like RTH manually, etc.

Except that the rear deck light sequences in flight mode are completely different than when in Vision mode.

https://flic.kr/p/nmChQU

 

[Toddzilla]

my previous discussion re Phantom 2 control at the frequency of 2.4 GHz applies to the "non-vision" Phantom 2 units which:
1. use 2.4 Ghz for communication from the ground RC transmitter to the air-unit Phantom 2 receiver
2. use 5.8 GHz for video communication from the air-unit Phantom 2 to a ground unit receiver/monitor/goggle.

The "Vision" Phantom 2 models use 2.4 GHz for the video communication from the air-unit to the ground-unit receiver/monitor/goggle (This is a wi-fi frequency spectrum common to a many other modern electronic devices...digital phones...wireless laptops...Go-Pro cameras (this is why you do not activate the Go-Pro wi-fi capability if you have a Go-Pro hung underneath your non-vision Phantom. The camera wi-fi signal at 2.4 Gig and the Phantom internal control receiver looking for 2.4 gig control commands from the ground RC transmitter now have a significant problem. The camera's transmitter and the Phantom's receiver are only inches from each other >>> your Phantom is not controllable by the RC unit and you will have a fly-away (hopefully near the take off position>>hard to miss this one !!)
Vision units use 5.8 GHz for ground to air control of the Vision Phantom models.

 

[Mike]

So when S1 is in position 1, it is pulsing digital information, and when it is flipped to position 3, it is no longer pulsing digital information?

It is always transmitting unless the power is turned off. If you have a P2 with a gimbal, go out and prove it to yourself. Activate RTH via the S1 switch and watch as your gimbal tilt still works.

 

[srandall25]

So when S1 is in position 1, it is pulsing digital information, and when it is flipped to position 3, it is no longer pulsing digital information?

It is always transmitting unless the power is turned off. If you have a P2 with a gimbal, go out and prove it to yourself. Activate RTH via the S1 switch and watch as your gimbal tilt still works.

Are you referring to gimbal tilt control via the 7th channel on the controller or via the app?

 

[ProfessorStein]

The messages in the app mean absolutely nothing. Don't base your assumption on those alone. To save development time, software engineers are notorious for using the same error message for multiple situations that have little to do with the actual underlying behavior. "Lost connection" could very well be a human-friendly version... and doesn't necessarily mean the connection is actually lost.

I don't believe that any one here is going to be able to convince anyone else either way. So I say go ahead and practice whatever you're comfortable with.