X-Star Premium & X-Star WiFi FIrmware Issues Version Now @ 2.0.12 Final

[Busdriver]

Guys... Electronically defined 'no fly zones' are determined by a signal (beacon) sent out from an air control facility. They are not based on a set of coordinates which are programmed into any aircraft, including fixed wing aircraft. If your drone is receiving a NFZ signal further from an airport than it should, it is NOT because of a fault with the aircraft, but, because the signal from the airport is reaching out further than it should. This can happen for a number of reasons (topography being the most common). If the aircraft receives the beacon signal from the airport, then it's going to think it's in a NFZ. That's the way it's designed; including in full-sized aircraft. If you are receiving the signal further out than 8 miles from an airport, then you should contact the airport, or the FAA. Don't contact the aircraft manufacturer as the aircraft is only doing what it is supposed to do (stay out of NFZ's).

Can you please share the source of the above statements?

 

[Tufargon]

How exactly are the beacons sent to the the XSP or Starlink app?

 

[Tommy Molnar]

I have never received a "no-fly" warning when flying my XSP. And I've flown in areas near airports (but not in any way dangerously). Where does this warning show up? From the same voice that tells me there's "video interference"?

 

[Quadrotor]

Can't you just note gps time (several good phone apps out there) when you begin a new photo set and reference to your file creation times when you pull the data?

That isn't practical while taking hundreds of photos in rapid succession. Furthermore, categorization based on file timestamps during post-processing is a mess.

 

[Quadrotor]

I believe this information may be incorrect. In the USA (and I assume everywhere currently), NFZ's are in fact part of the firmware and have zero to do with any airport beacons. As far as I am aware, there is no such thing as a beacon for UAV's at airports. The manufacturer puts the NFZ's in at their discretion and uses GPS to determine if the drone has reached one of those NFZ's. If you have other information that says otherwise, please post your source.

This is correct with the minor exception that both aircraft firmware and app software are involved in the overall process. Code in aircraft firmware determines whether aircraft GPS coordinates are currently within a defined NFZ (which incidentally can be a zone that is not associated with an airport, such as an area over a government facility of some kind). If so, that information is communicated to the remote-controller and then to the app software which displays the actual notification to the pilot.

 

[Quadrotor]

I have never received a "no-fly" warning when flying my XSP. And I've flown in areas near airports (but not in any way dangerously). Where does this warning show up? From the same voice that tells me there's "video interference"?

The current XSP firmware version 2.0.12 doesn't enforce no-fly-zones. An early beta-version of that firmware sent NFZ warnings back to the remote-controller, which then sent them to the app, where they were displayed and announced to the pilot. That functionality was disabled in subsequent firmware versions.

 

[Jagerbomb52]

Autel does have some NFZ's but they are very few. On their facebook page they have admitted to having some for the more sensitive sites.

 

[Busdriver]

Autel does have some NFZ's but they are very few. On their facebook page they have admitted to having some for the more sensitive sites.

I think I read somewhere that Autel doesn't believe in the idea of enforcing NFZ's or even restricting altitudes and that those decisions should be left up to the PIC (unlike DJI). You could argue that one all day long.

PS - my info on DJI maybe incorrect but I was researching their site on the subject and noted a bunch of screaming on the topic. No, I have no plans to convert to the dark side (yet).

 

[Busdriver]

I think I read somewhere that Autel doesn't believe in the idea of enforcing NFZ's or even restricting altitudes and that those decisions should be left up to the PIC (unlike DJI). You could argue that one all day long.

PS - my info on DJI maybe incorrect but I was researching their site on the subject and noted a bunch of screaming on the topic. No, I have no plans to convert to the dark side (yet).

BTW - I would initially agree with Autel's position on the subject. I wonder what their position would have been if Autel's CEO was flying right seat with me when I was on approach into Las Vegas in an A320 at the middle maker (1/2 mile from the runway) at 2300 hours and noticed that the lights were alive and getting closer?? If the refreshments had not been already collected, everyone would have been wearing them.

 

[Jagerbomb52]

Well as much as Autel likes to say they have not put any NFZ's into the firmware there has been a few that get the message that you are in a restricted zone and to fly carefully. Over the last 14 months I have seen Autel CS trying to figeure out a customers problem only to admit later that some airports are restricted

 

[Busdriver]

Well as much as Autel likes to say they have not put any NFZ's into the firmware there has been a few that get the message that you are in a restricted zone and to fly carefully. Over the last 14 months I have seen Autel CS trying to figeure out a customers problem only to admit later that some airports are restricted

Always best to fess up early on. Otherwise your credibility goes in the toilet.

thanks for that. I'm waiting for CS to admit a known issue after making me jump through all kinds of hoops on the Go Home feature. For me and a bunch of other XSP flyers, it's useless since we can't select a safe Go Home altitude for the flight profile, which makes it dangerous. What comes to mind is what if the XSP looses contact with the RC and the Go Home function is inop. What then?

This is exactly the nature of the lawsuit filed against DJI.

I'm just saying.

I've got some holes to punch in the clouds. The fog is making for ideal conditions to run some IFR approaches. Chat on the backside.

 

[Jagerbomb52]

My go home altitude is set to 200 feet. I have used it a half dozen times and worked as it was suppose to. It will go to 200 feet if I was below the set 200 foot altitude or it will just fly back at any altitude above the 200 foot altitude that I might have been flying at. If you are in the 40 foot radius the RTH will not kick in as the pilot should be able to control it at that distance. A added feature to pulse or cancel to the return to home I think was added in one of the betas to give control back to the pilot.

 

[Wildseyed]

I think I spotted a battery firmware problem. Last weekend my daughter was flying XSP-001 and I was busy teaching her cousin on XSP-002. Both birds had been in the air for some 10 minutes+, so I asked he to check how much flight time she had left. She reported 39 minutes! I told her "That's the wrong number! Look at the one with min next to it" She came over and showed me the screen, and sure enough it was showing 39min. Playing back the flight log, I could see that at takeoff, Starlink was already reporting 48 minutes, and the battery on the ground only flashed one LED. My guess is that if we had not landed then, there would have been a long drop, and a sudden stop soon after.

Autel is reviewing the flight log later today. I will post the results as they become available.

 

[Squirrel!]

I think I spotted a battery firmware problem. Last weekend my daughter was flying XSP-001 and I was busy teaching her cousin on XSP-002. Both birds had been in the air for some 10 minutes+, so I asked he to check how much flight time she had left. She reported 39 minutes! I told her "That's the wrong number! Look at the one with min next to it" She came over and showed me the screen, and sure enough it was showing 39min. Playing back the flight log, I could see that at takeoff, Starlink was already reporting 48 minutes, and the battery on the ground only flashed one LED. My guess is that if we had not landed then, there would have been a long drop, and a sudden stop soon after.

Autel is reviewing the flight log later today. I will post the results as they become available.

Been a month now, any word?

 

[Squirrel!]

What comes to mind is what if the XSP looses contact with the RC and the Go Home function is inop. What then?

If the bird loses contact with the remote, RTH kicks in automatically. As long as you took off and are flying in GPS mode.

 

[Wildseyed]

The final conclusion was that the sensor chip that measures current and voltage was bad. This is probably how I came to buy this bird as a crashed fixer. They sent a replacement free of charge.

 

[Wildseyed]

There is nothing else wrong with the battery. It still gets 20+ minutes of flight time, so I'm thinking of replacing the brains with those I pulled from the puffed battery that also came with this bird. Nothing to lose I suppose.

 

[Jagerbomb52]

There is nothing else wrong with the battery. It still gets 20+ minutes of flight time, so I'm thinking of replacing the brains with those I pulled from the puffed battery that also came with this bird. Nothing to lose I suppose.

Just be careful not to short any wires out when desoldering the board. The only thing plug & play is the balance lead, the two mains need to be unsoldered.

 

[Wildseyed]

Yeah. I never desolder first. I've already taken one apart, and the only safe way to get at the electronics is to cut everthing nice and flush at the joint on both ends. This makes it much easier to melt the solder too.

 

[Jagerbomb52]

Let me know or post your progress if the board resets itself so the doner battery gets a fresh start or does the board retain the information from the old battery.
Thanks