does anyone have any update/info on droneshare?
Is it abandoned?
Its not abandoned. Its just proving tricky to get fixed. Hopefully soon.
Thanks, Grant.
[quote=“gmorph”]Its not abandoned. Its just proving tricky to get fixed. Hopefully soon.
Thanks, Grant.[/quote]
I see.
Note that I wrote abandoned because this has now been bouncing for over a month:
"A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
support@droneshare.com
all relevant MX records point to non-existent hosts"
Hi Guy’s,
Same issue here.
On APM:plane 3.4 / APM Mini 3.1 the logs were truncated (it was creating 20-30 logs for what should have been one session) I upgraded to APM:plane 3.4 / Pixfalcon, that fixed issue with truncated logs and I can download/open the PixFalcon bin log in APM planner2 and graph data. Converting to .log causes Planner2 to crash when opening the the .log that is created. I did get a kms from the .log using the method described. Mission Planner won’t download or open the logs at all, throws an error about MavLink 0.9 messages in the Log and to upgrade my FC.
An old MavLink library in the mix?
Hope this helps.
This is my first APM/Pix setup and getting log into mission planner is kinda critical for me to get my head around what is going on. Should I go back a version on plane and suggestions, I’m running digital airspeed sensor and remote compass, everything else is standard 4 channel areobatic plane.
Hi,
I just wanted to add to my last post.
2 conditions.
APM mini 3.1 / Plane 3.4 with LOG_BITMASK,16254
Produced lot’s of truncated logs for one flight session. (I don’t think this is correct based on what I see with the pix)
It would download in MP, it took a long time, I don’t think there is any GPS data with this mask. Planner2 wouldn’t download, I wasn’t using the latest beta.
Pixfalcon / Plane 3.4 with LOG_BITMASK, 65535 I get the MavLink 0.9 message in mission planner when trying to download logs using MP.
Planner2 does download *.bin, won’t convert.
Putting the *.bin into MP causes the behaviour described.
Can I ask those that checked out logging as OK what there bitmask is set at? Is there a possibility that it is a particular type of log that is causing the corruption/readability issue with the various tools?
Thanks
This post was originally related to AC3.4 logs not being supported. They are… Please raise new topics if you are still having issues. Thx