HI
I have been having alltitude reporting issues for some time on my Spark and recently it has nearly caused a crash.
I am investigating the log files using CSVview and the online system via airdata.
Examining some early logs before my problems started suggests that when the aircraft is above the VPS max altitude the vps signal goes to a N/A condition.
My recent logs are showing that the VPS is working fine within its working range and landing the aircraft successfully BUT the signal always appears to be there even when above its max working range.
The symptoms of my problems appear in two places.
-
I am not getting a readable Height displayed on my phone when the aircraft is above the VPS max altitude (around 4m). The height flickers but appears to show a low altitude not related to the real altitude of the aircraft.
-
Looking at the logs of Baro altitude there are occassions when the Baro altitude read by the spark descends when I know the aircraft is flying level. This eventually results in a negative altitude. The Spark then shows symptoms of instability when climbing or descending resulting in me having to issue an opposite stick command to stop an ascent or descent.
My questions are these
Has the software algorithmn for calculating relative height from Home Point in the spark been changed such that VPS signal is not being ignored after exceeding the max VPS height which is resulting in the accumulation of large altitude errors and if so why?
If the vps signal is still showing up on logs after the aircraft is above the max VPS range does that mean there is a fault with the VPS unit.?
Is there a failure of the Baro altimeter unit which can cause these affects?
I have ordered a new GPS module which I believe also houses the Baro altimeter unit to see if this cures the problems. When tried I shall report back.
Thanks for any sensible ideas and if anybody really knows exactly how the spark is computing its relative altitude I would be grateful for an explanation
Cheers
This shows an example of the Baro altitude going negative (red line) and also to continuous presence of the VPS signal
I always thought that relativeHeight is computed from the barometer data. It can’t use VPS height because the ground elevation can vary away from the HomePoint.
I assume that the relativeHeight in your plot is inconsistent with your recollection of the flight? Looks to me like the barometer has a problem.
Why don’t you provide the .DAT so we can look at it together.
Thanks for responding Bud
file WLX 18_10_17.DAT link =
https://drive.google.com/open?id=18neuafK9ch9xtYwKM-GDGNVhWwwYg72b
file Binders Yard.Dat =
https://drive.google.com/open?id=10cje3-tZbQmP3BBikvyXCZcZ-SFTyeK2
I am unable to upload a file as the system says I am a beginner. However I am hoping I can insert links to the two files in question.
The File called WLX 18_10_17.Dat was taken in October 2017 when i encounted low cloud and this led to an auto landing initiation at high altitude, If you examine the Baro altimeter and compare it to VPSheight you can see that above 8m the VPSheight becomes invalid and disappears from the plot except when it encountered the fog when it suddenly became active and caused the erroneous auto land attempt. The Spark was working fine at this time with correct height readouts the problem was caused by weather.
The latest plot called Binders yard.dat ( see previous jpeg) when opened up and Baro altimeter is shown alongside VPSheight shows that after about 4 mins into the flight the Baro altitude descends into negative territory when I know the aircraft was maintaining altitude. All this time however the VPSheight is active and shows around 4m , which to me does not seem consistent with the older plot.
I am trying to determine if I have a VPS fault or a Baro altimeter fault.
Hope the links work
Cheers
A quick note about baro altimeter
When I refer to Baro Altimeter I should really be saying relative heaight as you are perfectly correct that heaight relative from takeoff point is computed by zeroing the baro reading at takeoff time with regard to the plot
Looking at BindersYard.DAT there is a problem with both the barometer and the VPS. I can’t see how they would be related though.
Here is the GPS:heightMSL and the IMU_ATTI:barometerSmooth data.
I’m assuming the GPS:heightMSL data is correct since the barometer data shows the Spark descending below the HP height. A few of the discrepancies are high lighted.
There are many messages in the eventLog like this
459.245 : 28791 [L-FDI][CTRL]: fault on , height_ctrl_fail
459.283 : 28793 [L-RC]craft ctrl failed!!!
As for the VPS problem it appears that the vps height data is correct up until about 6 meters but then reports around 4 meters for heights above 6 meters.
Vps height will become invalid when the AC exceeds a height where the ultrasonic sensor can operate. Here, there are several small intervals where this happens.
Don’t know what to say about this. A covered or dirty ultrasonic sensor will cause the vps height to read very low - less than 0.1 meters. This looks more like a HW failure but I can’t see how it would be related to the barometer failure.
Thanks Budwalker for the analysis
I am thinking that there maybe two faults here or that somehow it is a VPS fault that eventually affects the relative heaght calculations.
It was very useful to see the expanded vps signals that revealed the periods of undetermined signals as this may explain the flickering height readout on the phone. It does appear on the phone to show a signal that jumps to and fro between the 4m reading and some higher value that may well be from the correct baro reading.
I have another GPS/Baro module coming in the next few days and will install that to see if it corrects any of these faults but I am now thinking that a replacement of the VPS unit may be required which is not such an easy job I believe.
will report back the results
I don’t think the ultrasonic sensor data is used in determining the relativeHeight.
I’m not sure which altitude display is jumping back and forth. The Go App separately displays both the vps height and the relativeHeight.
I believe the barometer is part of the IMU module, not the GPS module.
Hi Bud
Thanks again for the reply.
The reason i mention the GPS module as containing the Baro altimeter is that having spoken with a repair consultant he mentioned that the Baro altimeter sensor is mounted on the GPS board which is mounted above and to the back of the main Spark control board. Indeed i opened up the spark and removed this board and as far as I can see there is a sensor which is surrounded by a foam pad that allows air to pass through but will prevent gusting that could lead to errors.
With regard to the downward low altitude height sensing the unit looks to me like it is using some form of infra red LED system as if you look at the sensor if it were ultrasonic I would have thought there would be devices that look more like microphonic components than LED.
forward snensor is the vertical camera I think .
What do you think?
Blockquote
I’m not sure which altitude display is jumping back and forth. The Go App separately displays both the vps height and the relativeHeight.
Blockquote
On my display I only can see one height readout on the bottom left which is always a relative to HP height. Where is the other one?
HI again
I have just recieved the replacement GPS module , which I believe contains the baro altimeter unit.
Anyhow I have fitted the replacement and flown a test flight.
THe results are interesting as it does not seem to solve the problem which suggests to me that the problem IS with the VPS system which is outputting data when it should not be.
There is of course one other explanation that there has been a rogue software update so I may try and go back to an early software update and see how it behaves
https://drive.google.com/file/d/18neuafK9ch9xtYwKM-GDGNVhWwwYg72b/view?usp=sharing
this is the dat file which shows the VPS signal still giving data when the aircraft is above the VPS range.
The flight was initially leveled at 2.6m after 9 secs then a climb to 6.8m at 23 secs arriving after30 secs followed by a climb to 9.4m at38 secs arriving after38 secs at which point the VPS height is starting to misbehave showing signals around the 4.4m point the phone height is also showing incorrect data at this point .I eventually climbed to 12.5m at which point I noticed the Spark climbing without any control input and I had to put full down command in to get it down.
The relative altitude has also gone negative again which shows at the end just before landing as -2.6m.
I do like a good puzzle…it passes the time in lockdown
Have downgraded the Spark software to version V1.00.600
to see if that makes any changes.
Still same problem…
Will return the GPS unit and am going to seek out a replacement VPS unit if I can get one in the UK.
My comment that the barometer is part of the GPS module comes from my experience with the Mavic 1 and Phantom 3. The Spark may be different but I’m supposing it’s the same. I.E., the barometer is part of the IMU. The fact that you still have the problem supports that supposition.
Seems to me that relativeHeight can’t be dependent on VPS height. VPS is height above the ground which, in general, has a different elevation than the home point.
VPS height appears in the lower left of the Go App. But, only when it’s valid, i.e. the AC is close enough to the ground.
The .DAT you attached in post #9 is the same one as post #2.
HIya
I have dismantled the Spark completely to examine the Infrared VPSheight unit. I could not see any obvious faults with it.
However I decided to reassemble the Spark to try inhibiting the VPS signals to determine what affect that would have. I noticed during reassembly that DJI had used a silicon sealant to help secure the miniature signal plugs. I noticed also that some of this sealant had found its way underneath the data cable from the VPS unit where it connects to the main board. During reassembly I had to remove some of this to get the plug to reengage.
Having reassembled the drone it seemed to all be working so I tried a test flight. The first flight immediately suggested that something had improved as initially the height readout was stable above the 8m point. There were however some glitches but I was getting a more realistic relative height readouts.
I landed and decided to do some flights leveling off at known heights. I took it in stages first to 10m then 17m and finally 20m. To my glee the height readouts remained stable and correct.
I downloaded the flight data and it appears that the VPSheight is much more behaved than it was. There are some erroneous signals at height but not the continuous signal that disturbs the baro altimeter computation which is correct throughout the flight.
So what has changed?
I am wondering if the problem has been the cabling between the main board and the VPS unit.
I have ordered a new VPS unit but that will not be here for sometime as its coming from the USA.
In the meantime I shall fly some more test flights.
The Spark has a different architecture to the Phantom and Mavic. The IMU in the spark is mounted underneath the main board at the front and is directly linked to the Camera stability system. The IMU only measures short term acceleration and rotation signals that keep the drone stable. The long term sigmals that give altitude/GPS position and (probably heading data?) are produced from the GPS/Baro board which is mounted on the top rear of the main board.
Relative height , as you say is not produced by the VPS sensor EXCEPT when at low altitude <8m.
I would suggest that at takeoff the primary source of relative altitude is the VPS sensor, at the same time a note is made of the absolute pressure altitude at the Home point for later calculation of the relative height. When the Spark is above the the VPS range, relative altitude is computed based on the Baro altimeter reading less the baro reading noted at takeoff.
I think there is again a difference here between the Phantom/Mavic displays. The spark only has one altitude readout that is active throughout the flight and it displays VPS below around 8m and above it displays the computed Baro relative altitude. The change over between signal sources is transparent to the user… unless you have a fault in the VPS like I do
Thanks again for your help Bud, I do enjoy learning about technology .I will do a more closely monitored test flight and post the results… not sure why the same dat file went out in post 9 as post2 but please ignore .
Cheers
hello everyone
i have the same problem but my spark show at the VPS Altitude N/A and i don’t have no more idea how to fix that
here is the link log view
https://www.phantomhelp.com/LogViewer/24RWZXZHXFLLYMK8JC80/
i remplaced the downward sensor and nothing change
please any one can help me with just an idea
Hi again
Some time has passed since my last posting and due to lockdowns i havent been very active with my drone. However , I recently decided to pickup where i left off with my altitude problems.
Unfortunately the changing of both the Ultra sonic down facing sensors and also the barometric/GPS board did not solve the intermittent low altitude reporting. I then moved on and decided to try an ipad mini istead of android. This did not change things though.
Looking at the displayed altitude on the ipad shows a <(( symbol at low altitude and an H at high altitude. This symbol does flicker between the <(( and H when at altitudes above 5m or so indicating that the barometric altitude is being computed correctly but something is triggering the low altitude sensor.
The only part not changed was the motherboard. I found a very good company here in the UK called droneOptix that could supply me a used motherboard with the previso that it could be returned if it did not solve my problem. They were very good and I received and fitted a replacement motherboard. The drone flew okay but the incorrect altitude reporting remains a problem so I have refitted my original motherboard.
So where am I now with this problem. All the hardware has been changed apart from camera systems and some of the sensor cabling. If this issue is software related then I am surprised that DJI have not had more problems flagged up with this. There are some people out there with altitude issues and I did see on another forum someone who appeared to solve their issue by replacing a motherboard which is why I went on to replace it
I do like my Spark and I hate to see good hardware wasted that could be fixed but this may be the end of the road.
best wishes to all for 2021
Hi, after I replaced the cracked case on my Spark, I started having problems with the height exactly as you describe. Did you manage to solve this?
