Hamish Willee

@WeifengY Thank you for the more detailed explanation. Some thoughts: 1. I'm not sure a message can conform to MAVLink 2 if it doesn't strip the zero's (ie it is...

Hi @yaoyz-yuneec I believe I do understand what you are saying. The incoming message comes in "untrimmed" and with a CRC calculated for the untrimmed string. You can't use the...

@haiyangyuneec @WeifengY See ... We wondered again which implementation sends untrimmed mavlink 2? Is it one of the open-source ones?

Hi @WeifengY Thank you. > The implementation who sends untrimmed mavlink messages is not from an open source project. Even though we are probably going to add support for handling...

@haiyangyuneec What https://github.com/mavlink/mavlink-devguide/pull/135 says is that it is invalid to send an untrimmed message, but not invalid to receive one. The spec has always said that messages should be trimmed,...

Hi @WeifengY @haiyangyuneec Note that neither the refinement to the spec or the PR have been accepted. We don't have a test case for this so even though allows this...

@magicrub No. This is waiting on "someone" to write a test case for mavlink 2 untrimmed messages. FWIW IMO we'd have been better saying they are not allowed.

I though we might be able to do something like adding the following to setup.py, but it still doesn't find mavgen (though it builds cleanly). ``` entry_points={ "console_scripts": ["mavgen=pymavlink.tools.mavgen:main",] },...

Thanks @rotu - frustrating. Still, encouraged me to try the console scripts again: #838 - it "works" but might not be optimal.

Thanks. I've been running it on Windows (only) so far. Good catch on Python restriction. I still want to see if I can turn off strict checking. Apparently the right...