Originally Posted by geofrancis

prority ... system ... drop non critical messages so critical commands always get sent and received .

well, the SiK is doing sort of such a thing (if configured for mavlink)

my statement is that one first should try to do all one can to stay loss less ... and my statement is also that by far not everything has been done here, see 4th way and other comments I made

this priority and scaling system can get really complex ... I'm not a native fan of it ... especially not for as long as alternatives haven't been squeezed out
dropping common status messages is the most of "priority and scaling" I would consider

Originally Posted by OlliW

well, the SiK is doing sort of such a thing (if configured for mavlink)

my statement is that one first should try to do all one can to stay loss less ... and my statement is also that by far not everything has been done here, see 4th way and other comments I made

this priority and scaling system can get really complex ... I'm not a native fan of it ... especially not for as long as alternatives haven't been squeezed out
dropping common status messages is the most of "priority and scaling" I would consider

the only other thing i could think of is just have a really fast link so it cant get saturated, to hell with range, just crank that radio up and emulate a wire.

haha ... yeah ... that's what we are kind of doing in this early stage anyway, to go as fast as possible with Lora and hope for the best

We are bound by the law of physics and the capabilities of the SX128x

As long as we keep things user configurable, this project will be very successful.

If full MAVlink only does 10km on stock power levels, then so be it. We already have a 1W system designed for people looking to go much further but many will be happy with 10km, the standard 100mw SiK modems do far less.

One of the reasons I wanted to add MAVLink to ExprLRS was because I have some planes with flight controllers deep in the heart of the aircraft, getting USB in there is a hassle. With ULRS and my own crappy LRS on 433Mhz, I could configure and upload missions from the house while leaving the plane in the garage. I could even upgrade the firmware over wireless.

I have a powered FPV glider with a head tracker, it needs 6 full width channels, max I fly this distance wise is 3km, mlrs is the only way I can move that to 2.4Ghz without getting locked in to the commercial stuff.

I'm super excited for MLRS, the only snag I have now is the chip shortage, the STM32s I want to use and which I think are perfect for us are not available, I knew this before I started but not going to route these designs until we can get them.

Going to look at your designs Olli and get some hardware ordered.

What I would like to know is how are we going to configure our hardware? Obviously Lua but will we need a desktop / mobile app? Will there be EEPROM emulation on the STMs for config storage or just compile time options? I guess it is too early to ask that now though.

Originally Posted by Sore_Paws

If full MAVlink only does 10km on stock power levels

well "stock" power is only 12 dBm on the Sx128x ...

10 km would be most amazing, I'd say, I don't believe that

since the current LORA setting is basically identical to ELRS' 500 Hz setting, the ELRS results may give some indication, but I'm not sure if that really translates ... I frankly was a bit schocked that just going from my basement to the outside made 70 dBm difference and basically killed the link (see video) ... so I'm not sure at all what we should expect ...

we simply will have to see, I guess ...

Originally Posted by Sore_Paws

What I would like to know is how are we going to configure our hardware? Obviously Lua but will we need a desktop / mobile app? Will there be EEPROM emulation on the STMs for config storage or just compile time options?

currently it's compile options only but there will be of course EEPROM emulation (I do have code for that since years for my STorM32 project)(the only problem to solve here is to handle the long write times)(is a problem since one needs to switch off all isrs)

it should be also configurable via USB, and from within MissionPlanner (we are talking amvlink, right ). And eventually also via OLED. The USB configurator I will however not do myself, just don't have the bandwidth, so someone would have to jump in for this to happen.

I'm not sure yet on the OpenTX side. I tend a bit to make it have options under the external module field, even though it might give a longer list. The alternative would be a lua configurator. What seems clear is that the OpenTx side will be deeply linked to the MAVLink for OpenTX firmware - unless someone else jumps in and does the code for the more normal ways (which I'm totally open to).

as said, currently it's compile options only. My near term plan is to get it to a version v0.1, which I actually tested in flight. There are 'only' three items left I want to do for that.

The plan for v0.2 would be adding bind, parameters and a means to configer the parameters.

Originally Posted by Sore_Paws

the only snag I have now is the chip shortage, the STM32s I want to use and which I think are perfect for us are not available

yeah, that's a major issue

I was hoping someone would jump in and port to ESP32

that's the reason I went with F103CB for the rx. I happened to have a half dozen of them, and they are still somewhat available (e.g aliexpress, or from things like blue pill or cc3d and so on, one just needs to be "creative"). For the Tx I went with the G471RE, since the respective discovery board are available every once in a while on mouser. The last time I got me 3 of them ... one just needs to check mouser regularly LOL

Originally Posted by OlliW

The USB configurator I will however not do myself, just don't have the bandwidth, so someone would have to jump in for this to happen.

I'll take that for sure when we get there. Perfect chance to play with Vue3.

By stock power I did mean with a PA but I guess time and testing will tell where we end up going to be fun to find out. I'm really interested in it.

With the ESP32, I think the only thing going for it would be that they can be bought now, maintaining multiple architectures is a pain without something like PlatformIO.

It makes sense now why you picked the good old F103CB, there are also clones of those around in China as well. I have a few them around.

Just want to check, USB is only on the TX side?

Originally Posted by Sore_Paws

Just want to check, USB is only on the TX side?

yes
I think it should work such that you do all parameter settings in the tx module, and that it copies them over to the rx module
no idea yet how to implement that, but this should be the goal I think

chip shortages are what killed off QLRS so i wouldnt get too attached to any specific chip thats hard to get, even esp32 chips are going up in price but there is still plenty out there and is probably one of the few that stock can be relied on.

Originally Posted by geofrancis

chip shortages are what killed off QLRS

my understanding of the situation is quite different: AFIAK the problem here is that is based on a single very specific module which the single vendor stopped producing ... (and that the author appears to not want to port it to another module). I don't think that's comparable to the global chip shortage

Originally Posted by geofrancis

i wouldnt get too attached to any specific chip thats hard to get

so what is your proposal?

Originally Posted by OlliW

yes
I think it should work such that you do all parameter settings in the tx module, and that it copies them over to the rx module
no idea yet how to implement that, but this should be the goal I think

Perfect, same thought. Good thing as I am using the USB pins for other functions on the RX.

QLRS was the module was not in production anymore, the company just moved on to other things.

Everyone has this issue right now, the ESP32 has been spared a bit simply because of their fab situation and it is not much in use compared to the STM32. The STM32 is used in everything, it's not like it is a niche product.

We've been here before with AVRs, years ago they had supply issues whilst the STM32 was real easy to get.

We can still use the older STM32s, using the same code, good enough for testing.

Originally Posted by OlliW

so what is your proposal?

I just mean don't get tied to a specific variant of a chip, Qlrs modiles were stopping being made because the stm8l152m8 chip for them wasnt available anymore so the manufacturer came out with a new version of the module with a new chip asr6505 that was totally incompatible. even things like the vesc motor controllers I use are getting starved of chips and have seen multiple new version appearing using different driver chips because its all thats available.

yeah
with the STMCubeIDE it is at least relatively simply to migrate from one STM32 to annother STM32 - I would wish it would support this even better/nicier, but it is not very difficult (for a project like mLRS, for other projects this may not be true at all)
so, at least, if it ever happens that anyone would want to produce a larger batch for a particular STM32 it wouldn't be much of a problem
(except H7, which is a pain, but I guess H7 is out of question anyway LOL)

@Sore_Paws: you were suggesting having 6 full channels instead of 4, and I'm thinking about adding this for v0.1

two questions please (to you and everyone):

* is it indeed a realatively common case (for plane fliers) that 4 full channels are not sufficient but 6 are needed?

so far there is only one voice, and I really would feel much more comfortable if there would be more voices

* what's the situation then concerning channel ordering? would different orderings like AETR or TAER or whatever also affect the 5th&6th channel, or would it still only affect the first four channels?