Add no-RX option for broken Tramp implementations on some VTX

[c3n]

The serial data from my VTX (eachine nano - known problem, see: https://www.banggood.com/Eachine-NANO-VTX-5_8GHz-48CH-25100200400mW-Switchable-FPV-Transmitter-Support-OSDPitmodeIRC-Tramp-for-RC-Drone-Tiny-whoop-p-1525228.html?cur_warehouse=UK) is either too weak or the timing not accurate enough to register with my FC (F4 NOX). The data from FC to VTX works fine though. With this new cli option "vtx_tramp_norx" you can disable checking for responses and control frequency and power of the vtx instead of just pit mode (which was unidirectional already). This also means the vtx will always show as ready, even if it isn't connected.

[etracer65]

We’re not going to implement workarounds for broken implementations in specific hardware. Contact the manufacturer and report the problem so they can fix it.

[c3n]

There‘s already code in vtx_tramp.c to repeat setting frequency and power because some matek boards don‘t always register the messages the first time and this issue has been present before and even been reported here and usually resolved by using a different pin on the FC that works. However if you don‘t have a free pin left you could now use my unidrectional patch instrad of buying a new VTX or FC.

[etracer65]

Retransmitting a command that requires a response when the response is not received is a technique that is commonly used to increase robustness in many protocols. Breaking the protocol to not expect the response because of one manufacturer's incorrect implementation is not something we want to do. If Eachine wants to clone hardware then they can at least properly clone the interface. If the device doesn't function properly, then return it to the manufacturer.

[c3n]

I don't need to return it, I have it working with the workaround in this PR. I just wanted to have it merged so that others can get these kinds of devices working

[mikeller]

@c3n:

this issue has been present before and even been reported here and usually resolved by using a different pin on the FC that works.

This sounds a lot like the hack that you are proposing is the wrong approach to solving this - can you provide examples of what pins do not and do work for this VTX for any given board? This can potentially be addressed by changing the setup for these pins.

[c3n]

I tried uart2 tx in hardware and softserial mode, PPM and LED in softserial mode with and without extra pullups but none of these work and an F4 NOX doesn‘t exactly have a lot of pins to play with (others got it working either by changing the pin or by adding a pullup). On each of theses configurations I can enter and leave pit mode since the communication from FC to VTX works flawlessly but changing channels is impossible because that function only gets enabled after betaflight gets the supported frequency range from the VTX (which now has to be set via VTX tables anyway).

I connected a RasPi UART RX to the Tramp wire and I can see both the query being sent to the VTX as well as the reply (all 16 bytes including frequency range and correct checksum) but the FC only sees one byte out of the 16 (the third one: 0xec, the one with the most ones in it). At that point I gave up debugging and implemented the workaround and CLI variable to enable it which doesn‘t really remove any useful functionality for people wit vtx table not using the button on the VTX.

If you look at #3692 towards the bottom you‘ll see a few people with different FC and VTX experiencing the same problems. Also on https://www.rcgroups.com/forums/showthread.php?3022381-IRC-tramp-via-softserial-works-partially and on an oscarliang page in the comments I can‘t find anymore.

[mikeller]

@c3n: Almost sounds like the VTX is not pulling down hard enough. Can you try adding a 1k or so pull down between the UART pin and ground?

[c3n]

Already did. pulldowns and pullups with 330, 570, 1k... nothing works. With 330 the one byte it registers disappears, with the others its still just the one byte. I even tried an i2c bidir level shifter with 3.3v on both sides, but nothing. The RasPi never has a problem picking up the response so maybe its a timing issue

[mikeller]

@c3n: Do you have a scope or a logic analyser that you could use to get an idea of what is going on on the line?

[c3n]

Unfortunately not, just a multimeter and that doesn‘t help

[c3n]

I used the debug cli to output the raw data from softserial decoding. The problem is indeed a timing problem: apparently the start bit is registered at the wrong time (a litte more than half a bit too late or too early - I don't know which way the counter is counting :-) ) and so more than half the sampling points record the wrong bit. reducing the timer ARR value in line 521 of serial_softserial.c makes the tramp protocol work bidirectionally. If you are willing to merge a new PR introducing a CLI variable to move the sampling point of the softserial out of the middle (say 0-255 with a default of 128) I'd be willing to create one.

[mikeller]

@c3n: This looks a lot like the Eachine hardware is not pulling down hard enough or fast enough when starting to send data - the hardware you are using is clearly defective, and you should return it to your supplier for a refund.

Unfortunately Eachine is well known for selling defective hardware, and selling hardware that uses firmware with unpublished sources, throwing their customers under the bus in both cases. Adding hacks to firmware will do nothing to fix this - the only way this will be fixed is if enough customers return defective gear and stop buying Eachine products to stop making the sale of defective / unsupportable products a viable business model for them.

[nangel0]

I don't need to return it, I have it working with the workaround in this PR. I just wanted to have it merged so that others can get these kinds of devices working

Can you enlighten me with that workarround? Can't use same vtx on a generic 20x20 f4 fc...

[etracer65]

@nangel0 You should return it and try a different brand. That vtx has a broken tramp telemetry implementation.

[nangel0]

I'm going to educate myself to understand how to solve this. Do I need to compile a version of BF off my own for use this implementation? A quarta, 25/12/2019, 10:57, c3n <notifications@github.com> escreveu:

…

You have 2 possibilities to do it in software: 1. If you're using softserial for the vtx and only for the vtx (no second softserial!) then you can edit serial_softserial.c in line 517 where it says: TIM_SetCounter(self->timerHardware->tim, self->timerHardware->tim->ARR / 2); and change that to TIM_SetCounter(self->timerHardware->tim, 0); - or - 1. Use the commits I posted here and apply them to the source tree to get a cli config option "vtx_tramp_norx" that you can then set to "ON" and that will make the FC not expect any communication from the VTX at all — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9263?email_source=notifications&email_token=ALFEXRW6LCM6T3UWYD32RMLQ2M4B3A5CNFSM4JXMBUWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHUIBVQ#issuecomment-568885462>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALFEXRU3BKX6DZBK6KUXXKLQ2M4B3ANCNFSM4JXMBUWA> .

[c3n]

Yes

[mikeller]

@nangel0: You should do as @etracer65 told you to do, and return the defective part for a refund.
If users keep using hacks to work around broken hardware that is sold by unscrupulous manufacturers like Eachine then this will just lead to these manufacturers selling even more broken hardware, and giving more users a bad experience.