Serial out for LRS boxes

Tested CRSF with devo12 on trainer port with the crossfire module. Sadly the protocol is not recognized by the module. I´ve attached the images. First the screen on the devo (for CRSF and PPM) and then the display of the crossfire module. PPM works, CRSF not (yet). According to Crossfire manual it should display "RC Input: CRSF V2" when a correct signal comes in.
(Receiver was not connected, but doesnt matter either)

In your build I couldn´t select SBUS. I assume it is in elmtrees repo? I`ll compile and try this later on.

Maybe the crossfire module doesn´t support CRSF on the PPM pin. I found an article for futaba. There is an instruction for a custom cable. They use a pin of the "extension port" for CRSF input. So probably the signal is already correct. I will try to stick this together tonight.

team-blacksheep.freshdesk.com/support/so...-futaba-crsf-support

That makes sense. The information from TBS on the Micro module was that it cannot accept CRSF on the PPM JR pin due to a hardware limitation. If the hardware is the same in the regular module then that's likely the issue.

The 12S hardware is slightly different too so there's a chance the serial code for it is not right.

CRSF test build is updated (7c8e073) with support for basic telemetry. Thanks to OpenTX project for the parsing code.

Here's the 128x64 layout for the telemetry monitor screen. Color layout is similar.
GPS telemetry should also be working.

I received my Crossfire module today and I'm ready to start testing the new protocol code. What hardware modifications do I need to make to the pin layout?

Connect the top JR module pin to the bottom JR module pin.

hexfet wrote: Connect the top JR module pin to the bottom JR module pin.

So just run a wire between the two pins internally?

Yes, that should be all that's needed.

Still no luck here. I hooked up the "Futaba" Cable. Crossfire module doesn´t get the CRSF in. I tested in all combinations. The only thing that works is PPM on the specified pin (3). CRSF isn´t recognized at any pin, PPM also doesn´t work on "CRSF" pin (5).

I tried both builds (5026091 and 7c8e073).

Telemetry page is accessible but with no data coming in.

Anything usefull I can contribute?

I disassembled the crossfire JR adaptor (for accessing the right pin without cutting the wire). I can post some pictures of it. I thought it would only wire the pins to the other side. Indeed has complex electronics inside (including a ESP-12S Wifi chip ???).

I think the signal is not getting out of the Devo12 hardware. The trainer port is not connected to the serial port according to the GPIOA table here . Apologies for not realizing this earlier.

It should be fine to connect PA8 (pin 100) and PA9 (pin 101) together at the processor. I'll check the code tonight to be sure the PPM output is disabled when not in use. Or you could run the PA9 signal out separately.

UART1 is wired to a pin header labeled TX/RX on the devo12 main PCB.

Moeder wrote: UART1 is wired to a pin header labeled TX/RX on the devo12 main PCB.

So I have to connect this pin header to the tip of the trainer port?

hexfet wrote: It should be fine to connect PA8 (pin 100) and PA9 (pin 101) together at the processor. I'll check the code tonight to be sure the PPM output is disabled when not in use. Or you could run the PA9 signal out separately.

So PA8 is PPM and PA9 is UART1? And it is OK if these two are connected, BUT it all is messed up, if there is signal on both?

I'm not sure if this will work, I rather doubt it. Connect TX signal from the pin header directly to the modules input for testing purposes.

xfapv wrote:

Moeder wrote: UART1 is wired to a pin header labeled TX/RX on the devo12 main PCB.

So I have to connect this pin header to the tip of the trainer port?

Yes, on the Devo12 PA8 is PPM and PA9 is serial out. On all other transmitters PA9 is used for both functions, so the code is already in place to switch between the two functions. You will be able to tie PA8 and PA9 together (or connect the TX pin header to the trainer jack tip) as soon as I ensure the software can't have both PA8 and PA9 set as outputs at the same time. Unfortunately having to work late today so will likely be tomorrow.

Looking at the code a couple one-line changes are needed to be able to tie PA8 and PA9 together, but there is a trade-off. Currently a devo12 with the voice feature installed can play audio while using the PPM protocol or the PPM In (trainer) feature. With the pins tied together voice will be disabled in these cases. Won't change that as the default, but could add a hardware.ini setting for devo12 users to specify they have tied these pins together. The benefit is having serial data protocols available on the trainer jack. Opinions?

was just working on the SBUS code. I had accidentally done all the bit shifts inverted because SBUS does high byte last I guess.

Anyways now I'm not getting any response (even bad data) on the sbus channel. Will look at the raw serial after finals.

hexfet wrote: Won't change that as the default, but could add a hardware.ini setting for devo12 users to specify they have tied these pins together. The benefit is having serial data protocols available on the trainer jack. Opinions?

As I don`t have the audio option installed, I don´t care. A software remapping / swapping of the two pins is not possible due to hardware limitations?

Anyway I will try to test with the pin header tonight.

I tested with the Devo12S pin header TX to crossfire module pin5 (and obviously GND) connected. The protocol is still not recognized. Randomly the crossfire module displayed "PPM X Ch" with X ranging from 1 to 9 or even sometimes "Fut 12 Ch" but each just for a second. So I assume that something is perhaps coming in, but not in the correct way...

Question / discovery: The TX pin header is not physically connected to processor pin PA9 (?) At least I tested with a continuity checker.

Just messing around with the oscilloscope. On the TX pin header there are some strange things going on. When I boot the transmitter with CRSF previously enabled I can see a weird oscillation. When I switch to another protocol and hit "Re-Init" I get zero signal. When I go back to CRSF (with Re-Init) the signal stays at zero!? I only get this oscillation when Transmitter is turned on with CRSF.

There is also a protocol TESTSER. What should I see here?
The TESTSER background in the protocol selection field is gray. CRSF background is white. What does that mean.

Is the number of channels important. Should I set it to a specific value?

By the way: I can see a clear PPM signal just for counterchecking.