no, no problem, since it's uint it wraps correctly around
standard microcontroller stuff

hey Folks,

here now the video for what is available since few months, the full bi-directional MAVLink through the SPort pin in the transmitter module. I finally found time to do a 3D printed module to make it an all nice drop-in installation, so it was time to also do the video on that feature LOL.

OpenTx with MAVLink: Via Transmitter Bay (14 min 48 sec)

as always, have fun

Hi Olli,
by looking at the schematic of your half-duplex to full-duplex S.Port serial converter/bridge here, I am not yet understanding, when one should populate for "normal" and when for MPM (Multi-Protocol-Module)? I guess, "normal" means here the JR-bay adapter like in your video?

technically you can use either of them
the C code I did however is for what I call "normal"
if you want the "MPM" one, the C code needs to be adapted respectively

Thx for the answer, unfortunately I am still in the dark.
What for would the MPM (Multi-Protocol-Module) mode in this case be ?

How would you need to attach a MPM to your bridge and what would the benefit of that be in comparison to hooking a MPM directly to the JR-Bay?

And just to be sure, with MPM you mean smth. like the following, right?:



https://www.multi-module.org/

it is not a MPM mode and you don't attach a MPM to the bridge, you always just connect the bridge to teh sport pin and get a uart in return
it is just that this then exactly the same hardware design for connecting the mcu to the sport pin as it is used in the MPM ...

the FM30 uses it too, hence I made the board to also allow to use it (in case one wanted to develop firmware for the FM30 )

I'm frankly not totally sure what the source of confusion is here

Originally Posted by OlliW

I'm frankly not totally sure what the source of confusion is here

Thx. for the answers - I think I got it now what for the two options are for. I will go and populate the "normal".
Best,
Risto

great
you've seen the hex in the repo, right, so you just need to flash

Hey folks,

just for your info, I've pushed a new version v28 to the git repo, https://github.com/olliw42/opentx. It also includes binaries for the "usual" suspects, T16, TX16S, T18.

The main upgrade is that it is now based of the latest OpenTx2.3.12, but it also has seen some significant internal changes, which however do not affect behavior from a user perspective.

Along with this release there is also a new version of the telemetry script, https://github.com/olliw42/otxtelemetry, which really has just one minor bug fix for the tx16s.

As always, have fun
Olli

Hi Olli,

thank you for shipping me one of your SPort bridge PCBs

Very much appreciated and eager to test this functionality. I am thinking that with HC-06 or ESP32 attached, this might be very interesting option for DragonLink users, who mount DragonLink e.g. on top of the high pole and use it's internal ESP32 to relay MAVLink to the radio.

But I guess I need your help/expertise to get it running, as I have no luck so far. I populated the components for "normal" option. Top side:



Bottom side:



As getting STM32F103C chips from usual electronic component distributors at the moment due to shortage was impossible, got myself a Blue Pill with STM32F103C8 from eBay and desoldered the chip from there. I'm pretty sure it is some cheap knockoff board, although I am hoping that at least the µC is original. It's laser engraving says STM32F103C8 and in a font that I know of from original ST chips of this type (naturally this is no guarantee of originality )

I created a custom SWD cable matching the pinout you used and flashed the µC with your *.hex from https://raw.githubusercontent.com/ol...art-bridge.hex:



Programming and verify seems to have worked OK as well:



Thus I assume, that at least power is good and the chip was programmed OK.

For testing I used my OpenTX fork of your work, augmented with my roller PR (branch EnhancedRoller):



Configured external module as Mavlink:



and attached the other Holybro radio modem to Durandal with ArduPilot. Checked the comms first with Mission Planner, by connecting the radio module that is connected to SPort Bridge via USB to PC. Works. The radio modem was parametrized to work with 57600 baud, and the Durandal side with hardware flow, the radio side without hw-flow.
Then I attached it to SPort Bridge with GND and +5V and with crossed TX and RX lines.

Used your latest LUA widget from https://github.com/olliw42/otxteleme...entx2.3/SDCARD , but unfortunately do not get comms going:



I see that the SPort Bridge red LED is lit the whole time, but the green LED never even blinks. I am thinking of writing a small blink LED for green LED to verify that the code is running at all (resonator error, knockoff STM32 etc.?), but maybe you have a quick tip how to otherwise debug, where the issue of no connection might stem from?

Thanks,
Risto

it could be just the solder bridge, see pic below

the red led is just power and should flash permanently
the green led should indeed blink at regular rate, since it doesn't, something is wrong (maybe it's juts populated incorrectly, note that the two leads are oppositely oriented)

if possible you could check your 5V and 3.3V with an oszi if it is stable

a good way to test the communication is to connect e.g. your flight controller via its uart to the uart on the sport bridge, and when to connect missionplanner via the tx16s' usb, and to see if one can connect MissionPlanner to the flight controller, it is kind of the straightest thing to do

Hi Olli,
thank you for the tip.
You have eagle eyes - mine are already so bad that I was not able to see it. Envy...

I put it now under the microscope, and sure enough there was a solder blob:



Removed it:



And immediately your LUA script as well as my Yaapu mod get data and are happy. Sorry for the extra trouble.

About the LEDs though - the red LED lights constantly, but the green does not light at all. I double checked the polarity of green - matches the schematic - cathode towards 2K2. Tested also with multimeter in diode mode - also here lights up when applying positive tip to the 2K2 connection pad of the LED and GND to GND. I re-soldered STM32 pin 16, re-soldered the 2K2 resistor, double checked under the microscope and verified with multimeter that the STM pin 16 is not shorted to neighbors and has connectivity to 2K2. Dunno, why it does not blink.

In the C code the LED and LED2 seem to be swapped from what schematic says (green LED1 = PA6, red LED2 = PA7); the code defines LED as PA7 and LED2 as PA6. I sure do see LED2_TOGGLE in the code that should be triggered every 500 iterations. Dunno why it isn't blinking on mine.

I used your hex file for flashing, did not build from the C file. Likely some fault of mine, but allow me to ask if it might be possible that the hex is built from another revision of the C file?

Originally Posted by Risto

And immediately your LUA script as well as my Yaapu mod get data and are happy.

fantastic

Originally Posted by Risto

Sorry for the extra trouble.

no worries, things happen, I'm glad we got it sorted
it is also only because you gave expert info

Originally Posted by Risto

About the LEDs though

yeah, it might be that I mixed led1 and led2 ... I tend to get easily confused with them LOL

I have flashed exactly the hex in the git on my 2nd sport bridge module, and it works for me, so, while I would never rule out I mixed up something, I think the hex works

btw: I many years back got me magnifier with LED ... it was one of my very best purchases ever ... i have shown it several years ago in a yt:

SMD Soldering: Building a STorM32 v2.4 Board (12 min 7 sec)

Hi Olli,
I made a super simple test Blinky with STM32CubeIDE:

#define LED_green_Pin GPIO_PIN_6
#define LED_green_GPIO_Port GPIOA
#define LED_red_Pin GPIO_PIN_7
#define LED_red_GPIO_Port GPIOA

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  while (1)
  {
	  HAL_GPIO_TogglePin(GPIOA, LED_green_Pin);
	  HAL_Delay(100);
	  HAL_GPIO_TogglePin(GPIOA, LED_green_Pin);
	  HAL_GPIO_TogglePin(GPIOA, LED_red_Pin);
	  HAL_Delay(500);
  }
}

I get blinking red and green LEDs with this, so HW should be just fine.
Beats me, why the green LED does not blink with the hex from your GH fork. If you would be willing to try - could you maybe please post the binary here, so I will retry with this. Thanks!

this is super weird ... I've just double and triple and quadruple checked again, flashing all sorts of hex I found and could generate ... it's working for me just fine ...
I've pushed the .bin to the otxtelemetry/SPortBridge repo
and also add them both here as zip
let's see