Serial out for LRS boxes

Thanks for the testing. It wouldn't surprise me if there's a small resistance between PA9 and the TX pin for short/ESD protection. If it's more than a couple hundred ohms then it might be the wrong pin. Can you measure with an ohmmeter? Compare to the resistance between PA8 and the trainer jack.

The oscilloscope should show a short burst of 400 kbps data every 4 ms. At 400k one bit time is 2.5 microseconds, so the 25 byte packet will only last 625 microseconds.

Number of channels doesn't matter. If less than 16 the unused channel data is set to the midpoint value in the data packets.

With other protocols selected there should not be anything on the tx pin . Changing back to CRSF and hitting re-init should start the serial signal to the tx pin so there may be a problem there.

The TESTSER protocol is for testing the serial data out. Its background is grey because it has protocol options. Clicking the field and setting the format to "Send H" should send consecutive "H" characters (0x48) to the tx pin. The other protocol options set various serial parameters.

If the data is getting to the Crossfire and not being recognized there could possibly be a problem with the packet CRC, though that was checked with CRSF test data. In the video posted earlier the user said he configured the TBS module to CRSF protocol with his PC (though in the video it obviously auto-detected PPM). Is there any configuration of the TBS module that might be applicable?

Confirmed that changing the protocol away from CRSF or TESTSER and then changing back does not restore the serial output. Please work around that bug for now. Will look into it this weekend.

hexfet wrote: Confirmed that changing the protocol away from CRSF or TESTSER and then changing back does not restore the serial output. Please work around that bug for now. Will look into it this weekend.

Probably UART_SetDataRate(0) messes up the serial device on deinit? It think it results in a division by 0 in libopencm3:

Thanks, that was the problem. Test build is updated with a fix (a262373).

Why still the detour with SetDataRate(0) and then?
Seems like an unnessecary waste of rom (thinking devo7e here)

hexfet wrote: Thanks, that was the problem. Test build is updated with a fix (a262373).

Restoring this behavior was the fix that affected the least number of files. I think a better fix would be to call UART_Initialize() to restore the default state, but this branch already mixes several unrelated changes. Plus until my speaker arrives I can't test how it affects voice.

This is a muddle of my own making as the behavior of using zero to set the rate to the default was added for FrskyX. Then I broke it in PR 396 by removing the behavior without changing where it was used (so the bug is in master at the moment). The intent was to give an easy way to put the serial port back to default settings, but now that some protocols are changing things besides the data rate it's no longer the right solution.

The use of the serial port has changed from only debug output to being used for debug, extended audio, and soon protocols. The use of the UART_ functions could benefit from some attention. I think UART_Initialize is only called in main to set it up for printf output, but printf only evaluates to a real function in dev builds. And in dev build today printf doesn't work without disabling extended audio. It would be cleaner for each feature to set up the uart as needed. It would only be enabled in main for dev builds. Only initialized for voice if the transmitter has a player installed. Each serial protocol will initialize as required. Then just need a special case to handle de-init for a serial protocol when voice is active. Maybe this subject deserves a separate discussion. Did not want to mix this in with the CRSF protocol branch.

I fully agree to your observations. I thought the same thing when I worked on the voice stuff and noticed the hassle with different stuff wanting to use the uart. But you're right, this doesn't belong to this discussion. I'm wondering how the next CRSF test results are...

Will there be an option to update the receiver firmware OTA using the Crossfire Micro module?

It should be possible but don't have the necessary information right now. The protocol doc includes the command to start the bootloader but not the bootload procedure itself. I'll ask TBS support.

Have you had a chance to try the Crossfire module in your Plus? Test build is here .

hexfet wrote: It should be possible but don't have the necessary information right now. The protocol doc includes the command to start the bootloader but not the bootload procedure itself. I'll ask TBS support.

Have you had a chance to try the Crossfire module in your Plus? Test build is here .

I just flashed the firmware and the protocol is now available. Now I just need to solder a wire between the pins. So it's the top and bottom pin? I was looking at the traces and it seems the bottom pin isn't connected to anything.

I think it's also important to add Mode, Sbus rate and output mapping. You might find this video helpful to know what's involved in configuring Crossfire via Lua scripts:

Are you making the CRSF protocol code available? I'd like to have a look at what you've done so far.

Branch protocol_crsf is here . Basics are in src/protocol/crsf_uart.c. This branch also contains uart changes and changes for t8sg v2 and plus.

Yes, the bottom JR pin is not connected to anything on the Plus. Connect it to the top pin to support the CRSF protocol.

I'll take a look at the Lua scripts, thanks.

still no luck here...

Can you check the signal with a scope or analyzer? It should show a short burst of 400 kbps data every 4 ms. At 400k one bit time is 2.5 microseconds, so the 25 byte packet will only last 625 microseconds. Can be difficult to capture without a storage scope.

I reviewed the opentx code and the serial port setup seems the same. Will spend some more time on that. You mentioned that sometimes the display changes from no signal so it seems something is getting to the pin.

Hi just to check are there still ongoing works on Sbus or PXX protocol ?

CRSF test build is updated ( d670472 ). The first header byte in the packet is changed based on a another reading of the spec.

I can't test crossfire as do not have such system, but I like to use test Sbus out or PXX out deviation, so I can test it with Qczek LRS. (I bought some UHF lora RF modules, it is very simple to build)

Test build is updated ( 7cb0da7 ).

• Added new protocol SBUS. The output is not inverted so a hardware inverter may be needed. Couldn't find any info about what Qczek expects. Due to memory limitations this protocol is not included in modular builds (7e, f4, f7)
• Added CRSF to modular builds, but without telemetry. Fits with 4 bytes to spare. Better to exclude CRSF from modular builds?
• Merged recent changes to master.

I'll try to test it during weekend. I think Qczek LRS also needs uninverted.Also will put into aflight controller first,as hten can easylly check all the channel decoding in Betaflight configurator.

oscilloscope tests:

I just tested the signal with my osci. I will post detailed results later. Just for now: I can see a square signal with a period of 60-70 microseconds. This would be a factor 10 compared to your post with 625 microseconds. Perhaps you can check that.
(I am not very familar with oscilloscopes, so maybe I just messed up the scale...)