search

olliw42 / mLRS

2.4 GHz & 915/868 MHz & 433 MHz/70 cm LoRa based telemetry and radio link for remote controlled vehicles
GNU General Public License v3.0
347 stars 79 forks source link

Possibility for MSP (and maybe LTM) awareness and optimal packet size #178

Closed b14ckyy closed 6 months ago

b14ckyy commented 6 months ago

I am absolutely no expert in the field, but from what I know, its beneficial if the OTA packet handling is optimized for a certain protocol to reduce overhead and data errors. The INAV devs are currently working on a cleanup of the MSP stuff, slowly putting MSPv1 at rest and focus on a clean and defined MSPv2 that is also supposed to become more robust.

I know MAVLINK is more wide spread nowadays but more and more people use INAV for bigger crafts and Long-range. Pawel is also working on a GCS mode for configurator for monitoring and I know companies that start to work with INAV for UAV tasks. I am currently building a GCS case template based on MWPTools for one of those companies. mLRS would be the perfect solution for that and it would be great it if can work as good as it can.

olliw42 commented 6 months ago

many thx for bringing this topic up.

I have never used anything working with MSP, so can't speak with competence. However, if MSP systems fall into the class needing full-bidirectional communication (and not just telemetry) then this certainly could/should be something for mLRS. In principle nothing speaks against adding specific MSP support to mLRS, like there is specific support for MAVLink.

However, it would need the involvement of competent MSP persons, who especially would use mLRS in a MSP system. Practical testing and use would be the key yardstick here. We do have a development channel in the mLRS discord, they would be highly welcome there.

:)

olliw42 commented 6 months ago

I briefly looked at MSPv2, found that document: https://github.com/iNavFlight/inav/wiki/MSP-V2

from my perspective this is not a very robustly designed message format. We could do however a similar "trick" as we do with MAVLinkX, namely to repackage, could call it MSPvX. However, MSPv2 also does 65536 palyoad sizes. That's really a bad decission for an OTA format, and will defenitely cause issues. So, my first quick impression: As said, if respective folks get involved there is nothing which would speak against adding specific MSP support. However, it doesn't seem that a high level of robustness can be achieved. No stm32/esp can really afford having to buffer up to 64k bytes of data ...

b14ckyy commented 6 months ago

Thanks for your quick reply. MSP-V2 documentation is not fully up2date. The INAV devs are thinking about an Update that also involves a message ID system to detect out of order or missed responses. The Payload size is theoretical 65k indeed but INAV with the most advanced MSP implementation so far, does not have any MSP message that goes above 64 byte. Afaik the biggest ones I know of are the waypoint send/recieve messages at 31 byte? Might be 32byte with the Message ID addition if it will be implemented. https://github.com/iNavFlight/inav/wiki/MSP-Navigation-Messages

I will tell them and I am sure someone will hop on and assist if necessary.

olliw42 commented 6 months ago

thx for the info it's good to hear that the practical range is not exceeding 255. I wonder why they felt a need to extend it to 65k. Anyway, I think the spec should be changed accordingly.

and assist if necessary.

just to be on the same page, the writing the code part looks pretty straight forward and I don't see a big issue here and we would really need assist here. I mean, any help with that will be appreciated, but my main point is that there needs to be some folks who do the testing and are continously using it in real world practice. It's not only pointless to add a feature which isn't really used, it's in particular a matter of keeping these code parts maintained and working. :) In plain words, there needs to be some INAV users who use a mLRS system.

I should maybe add that mLRS is not MAVLink specific, it does also support transparent bidirectional serial data flow. That is, it should be possible to use it for MSP right out of the box. It won't have robustify features, but it should just work.

olliw42 commented 6 months ago

discussion moved to https://discord.com/channels/1005096100572700794/1237748187662647327

closing this hence

THX for bringing this up !