Just wanted to add a beta report on my configuration.
Sonar hold was not working on 2.24a beta and moving the sonar to a low- unobstructed spot away from the battery on the frame seemed to solve the problem. Sonar alt hold at was working well in 2.24b, and 2.25.
After a few days I upgraded to 2.29, and sonar hold was flaky again - looked at the logs and the sonar sensor was getting my old behavior - show some good samples of data 150 cm or above intermittant with fixed 60 cm data. I repeated the test in 2.30 and same behavior - sonar hold flaky - rising and falling to the ground with lots of bad sonar data. I've repositioned the sonar again, check the cabling, changed and rerouted the cabling, added a remote power supply to the sonar (5 volt) from a bec and external battery. In all cases - I can see the outline of my altitude envelope with lots of dropped sonar samples.
I finally fedex'd a new sonar sensor 2 days ago - the MB1260 XL-MaxSonar-EZL0 High Performance Ultrasonic Range Finder (only 1 in stock at the store - MB1200 XL not in stock) and mounted it on the frame today. I flew 3 flights and the first flight show progress - altitude hold seemed to be working. Went to check the log and no log recorded. Reloaded 2.30, erased EEPROM, went through setup. Erased log memory, flew again with fairly good sonar alt hold and again no log. Reloaded 2.30,.. repeated the install procedure. Now the sonar is flaky again and no log. Reloaded 2.30 again, and same result - flaky sonar and no log.
At this point, since I can't upload a log here I'm stuck and will have to try a couple of other ideas. (By the way - the CLI shows both sonars - the 1200 and 1260 work great when I point the quad in the room).
I don't know much about issues with the sonar sensor and mounting. I assumed that a single standoff would be ok as long as it cleared everything, but now I'm not so sure. Maybe I need two mounting points, maybe some anti-vibration Zeal tape - I'm not sure. I'm starting to wonder now also about my Hotel IMU shield and the 7th A/D input. I'll experiment.
I will go back to 2.25 and debug there since logs were being created ok for that build. It would be a good test to see if logs don't operate in 2.25 and would point to some weirdness in my EEPROM. I will load 2.25 from the Arduino environment and check the sonar hold there and see if I can log.
I'm travelling to a farm in Illinois tomorrow for the weekend to do some testing in the wide open spaces and I plan to disable the sonar and just test loiter with GPS and baro alone since connectivity will be mixed out there.
Heino
Replies
Heino,
Thanks for the report!
You can dump the logs by typing dump 0, or dump 99, or just dump. These invalid numbers will force a dump of the entire flash chips contents.
Jason
I haven't seen any logs created normally since updating from 2.0.25 to 2.0.30. I can "dump 0" and copypaste from CLI terminal to get something out of it though.
Here's my flight log from this evening. Baro alt hold works decently, with about a meter's accuracy.
29-06-11_bad_log_2.txt
Same here with v 29.
Here's my log.
29-06-11 10-55 1.log