Maybe my English is just so Bad, you cant understand me at all.
I know that the TX will be a GCS ;D Just like to know what functions you will implementing. ;D
Do you get it now?
With Relay, i mean such things as:

1---Receive Telemetry from HF Module, show everything on Transmitter GCS, Send Pakets out over Aux Serial to Tracker.
=The Way you answered this, i Understanding "Yes, why you asking, this should be Clear, no questions Ask *lol*
To be Honest, thank you for this detailed Answer and this Explanaition. This has everything cleared for me.

2--Receive via RPI, Feed Telemetry into Transmitter trough Aux Serial,(as to tracker but other Direction) and show Data additional on Transmitter Screen, beside the Rpi working as the Main GCS. I know about the Mav-Router implementation
(But was not shure, if is possible, using the Transmitter for that in an other way as USB Joystickmode)
So again, thank you for that technical detailed explanation, that cleared it all. This sounds really great

The Thing with the BT on the T16 is not complete, compareable with the other Models.
If you download otx with the BT Option. Then the BT Module will be Utilized by OTX. OTX then configure it. (The Traces to BT, are also configured in a different way, as you can read in the hal.h)

And this is the problem here.
After that, you cant choose Aux Serial Mirror anymore.
AND on radios where the Module is equipped from Factory, its not possible to deselect that Option in firmware and get Aux Serial Mode back. Sorry, i dont want to bother you.
The Horus BT Module thats suited for this, is just so Bad designed, that a reliable Connection is impossible.
And also, there is no other way configuring the Module, there is no Stream at the Pads, if its unbounded. other then with aux serial Option.

On some Radios this is also the only place where a UART (UART6)can be suited as aux2_serial, like on the tx16s for all that.

Since the (UART3) is disabled for aux_serial Mode to avoid system Crashes on some Radios.
(Only active in debug Builds but still causes the compilation issues at post 130)

If this will not be changed in future releases, the last choice Myself and other Users have, is to buy a new Radio.
Otherwise i cant Use My Tracker in the first explained way, by the lack of a connectable serial. Even youre implementation would support it.

I hope everything is finally cleared now,?
Thank you so far for all your Work on this stunning Mav-Link Implementation.

Deactivate aux_serial on Horus Targets

Maybe you can resolve the Compilation Issues from Post 130 with -debug build option ;D
Its of course still possible, that im wrong with something here. Then please do not throw a Brick at me.

it are probably rather my limited English capabilities, but you are right that I appear to have difficulties to follow what you're saying
thx for the nice words btw
cheers

Do you noticed that you using the uart3 in the hal.h?
The uart3 is not available on All Horus based Radios.
Maybe you should try the uart 6. Just to test if you not running into compiling issues with that.
Btw. There is a compile Code says:
if not Bluetooth and NOT internal gps then use aux2_serial.
You can enhance this Code to
If not Bluetooth and not INTERNAL_GPS and not Telemetry_Mavlink use AUX2_serial

elseif (PCBREV STREQUAL TX16S)
set(FLAVOUR tx16s)
set(LUA_EXPORT lua_export_t16)
add_definitions(-DRADIO_TX16S)
add_definitions(-DRADIO_FAMILY_T16)
option(INTERNAL_MODULE_MULTI "Support for MULTI internal module" ON)
option(BLUETOOTH "Support for bluetooth module" OFF)
option(INTERNAL_GPS "Support for internal ublox GPS" OFF)
set(HARDWARE_TOUCH YES)
set(USB_CHARGER YES)
set(DEFAULT_THEME "DARKBLUE")
set(SBUS_TRAINER ON)
set(AUX_SERIAL ON)
if (NOT BLUETOOTH AND NOT INTERNAL_GPS)
set(AUX2_SERIAL ON)
endif()

Horus/cmakelists.txt

Hal.h should be changed to:

#if defined(AUX2_SERIAL) || !defined(MAVLINK_TELEMETRY) || !defined(INTERNAL_GPS || !defined(BLUETOOTH))
#define AUX2_SERIAL_RCC_AHB1Periph (RCC_AHB1Periph_GPIOB | RCC_AHB1Periph_GPIOG | RCC_AHB1Periph_DMA2)
#define AUX2_SERIAL_RCC_APB1Periph 0
#define AUX2_SERIAL_RCC_APB2Periph RCC_APB2Periph_USART6
#define AUX2_SERIAL_USART USART6
#define AUX2_SERIAL_GPIO_AF GPIO_AF_USART6
#define AUX2_SERIAL_USART_IRQn USART6_IRQn
#define AUX2_SERIAL_GPIO GPIOG
#define AUX2_SERIAL_GPIO_PIN_TX GPIO_Pin_14 // PG.14
#define AUX2_SERIAL_GPIO_PIN_RX GPIO_Pin_9 // PG.09
#define AUX2_SERIAL_GPIO_PinSource_TX GPIO_PinSource14
#define AUX2_SERIAL_GPIO_PinSource_RX GPIO_PinSource9
#define AUX2_SERIAL_USART_IRQHandler USART6_IRQHandler
#define AUX2_SERIAL_DMA_Stream_RX DMA2_Stream6
#define AUX2_SERIAL_DMA_Channel_RX DMA_Channel_5
#define AUX2_SERIAL_PWR_GPIO GPIOB
#define AUX2_SERIAL_PWR_GPIO_PIN

And to be more specific what i mean with uartmode:

radio/src/targets/common/arm/stm32/aux_serial_driver.cpp
companion/src/firmwares/generalsettings.h
This is out off constants.h

#if defined(CLI) || defined(DEBUG)
UART_MODE_DEBUG,
#else
UART_MODE_NONE,
#endif
UART_MODE_TELEMETRY_MIRROR,
UART_MODE_TELEMETRY,
UART_MODE_SBUS_TRAINER,
UART_MODE_LUA,
UART_MODE_COUNT,
UART_MODE_MAX = UART_MODE_COUNT-1

THIS IS WHAT AUX_SERIAL OR AUX2_SERIAL ENABLES!

So, Why not a UART_MODE_TELEMETRY_MAVLINK
?
The way you added the mavlink Code in the hal.h makes it a bit hardcoded to me. Because if you define it without other codefinitions. It's always bound to that Pins if you download the fw with that fw Option.
That are All only Suggestions and ideas. If you dont like my Feedback, then im ok with that too.

I believe I understand what you are trying to say, but I also believe that you were not understanding what I was trying to say. I really have absolutely no issue with your feedback, and I'm far from not liking them. I however may not have the response you like to hear.

yes, I fully notice that I'm using uart3. I in fact did that on purpose, since I found it by far the easiest to do code wise. It's much more difficult to use the other uarts, and I think you quite underestimate it, it's not just setting some defines or some hal settings.

Yet, as said already, it for sure would be a great addition if uart6 could be used. I didn't accomplish this yet however.

As regards the UART_MODEs, I agree too that it would be convenient from a user perspective, but again I think it's much more difficult than you say.

The code is public. You are most welcome to attempt doing the changes yourself, and accomplish what I couldn't yet.

Maybe it Looks that im think this is totally easy. But In fact i know that it's not.
After All i just want to talk with you over this.. All express Radios use this uart or other ones cant at all. Because of that a lot Horus based Radios are not compatible with that Integration. And I think compatibility should be a major goal. Thats it. The Changes i wrote with the definitions should be most an example and to describe a bit better what i try to explain. And ithink that u got me finally. It would be a lot better in terms of usability. ;D

Originally Posted by Brainbubbler

It would be a lot better in terms of usability.

I don't disagree. Not at all.

It's however somewhat beyond my reach. It's simply so that I own only a Jumper T16, and neither a Horus nor a TX16S. If you look at Almi_'s attempts, we thought it should be just simple to make it work also for the TX16S, but apparently it wasn't. We seem to miss the key point here, and I can't really contribute since I don't have that radio. Etc.

What I should be able to do is to make it possible to use uart6 on the T16 (only), I just didn't yet have found the time to do this. Well, I did look at it before, but it wasn't immediately clear to me what I have to do, implying that it will take more time, and it's this time I didn't yet had. It's not my only project .

It's good to have feedback and fresh ideas and suggestions. But there are some real world restrictions one shouldn't foget.



I'm somewhat surprised to hear that with the Horus radios one can't use uart3. But what do I know, right

aux_serial Disabled on Horus Targets

but this should be a GOOD thing, since it should make it easy (easier) to use the horus with this project here ...

what I rather meant is that I would be surprised if the horus radios do not expose the uart3 hardware-wise, i.e., if there wouldn't be any solder pads or other connectors one could use to physically connect to this uart

Yes there are solder pads. But These are used for external communication with access HF Modules on newer Radios.
Or with the express Upgrade external access mod.
Additional on older accst Radios is a conflict with the Heartbeat Signal. This Clock like Signal is generated from the internal HF Module. Non Frsky Radios dont have such Frsky HF Boards and use internal Multimodules. Thats why there is no Heartbeat Signal that can cause issues.
The UART6 on the other Hand is present in almost every otx Radio out there.
There are of curse Pros and cons for each UART.

here are the uart3 solder pads for the express Upgrade on a few Radios.

But you can also See the unused bt solder place traced to uart6 on t16, t18, t16s.

Originally Posted by OlliW

ah ... that's probably interesting ... with that uncommented the whole mavlink loop isn't running, which means that it is something with the very basics ...
it might indicate it's still something to do with UART3 ...

there is e.g. this strange inconsistency in horus/board.h line 637, where it says #if defined(AUX_SERIAL_GPIO), but AUX_SERIAL_GPIO is defined for TX16s, see horus/hal.h line 405.
So maybe the aux_serial stuff is not totally disabled creating the conflict
maybe in horus/hal.h:405 one needs to write

#if defined(AUX_SERIAL) && (defined(PCBX12S) || defined(RADIO_TX16S))

or maybe even better

#if !defined(TELEMETRY_MAVLINK) && (defined(PCBX12S) || defined(RADIO_TX16S))

just speculating

I also wonder if maybe the enabling/disabling in mavlink_telemen.cpp void MavlinkTelem::wakeup() is working. I note that there might be a bug in that if _interface_enabled = true but _interface_config is not a valid value.
Maybe you could outcomment the part // handle configuration change, i.e., lines 448-471, and see if that helps.

After line 467 one probably should add a _interface_enabled = false;

could you describe in more detail the error pattern? What does it mean "doesn't work"? Is it such that you power up and just nothing happens right away? Or is there something happening and when blocking? Do you have a serial signal connected to uart3? ???

you have the SD card in pristine state, right, with nothing of the project copied over, no widget installed?

It took me a while, but I just tried all of your suggestions with the same outcome as before.
When I experimented with different SD-Cards I accidentally put one in with exfat, which OpenTX can not read but doesn't give a "No SD Card" error. With that it started with very little functionality (e.g. none) but it started. Maybe that helps finding the problem. If you are interested and want to try it yourself I can send you the radio for while...

yet another demonstration of what is possible with OpenTx with native MAVLink support

Drone Quickshots with ArduPilot Lua Scripting & OpenTx for MAVLink: Cable Cam (21 min 55 sec)

@Almi_

sorry for not responding earlier

and THANK you SO much for this really generous offer. Indeed, this would really what I would need to bring it forward. However, I'm afraid, I won't have time for that in the next time ... there is already too much on my plate. Maybe you would find it acceptable if I would come back to this offer when I see me having time for it ?