Support for walkera telemetry.

After much experimenting the following code works the best:
The important new check is this:
&& !(CYRF_ReadRegister(CYRF_05_RX_CTRL) & 0x80)

This added check was found to improve range and shorten rebind time.

Why is it needed?
Even when receive buffer is full, it will be overwritten whenever next telemetry packet arrives. So first we check that data isn't currently arriving (so we don't interrupt it) before we lock receive buffer for reading by disabling overwrite:

void CYRF_ReadDataPacket(u8 dpbuffer[])
{
. . // need to set RXOW before data read.
. . CYRF_WriteRegister(CYRF_07_RX_IRQ_STATUS, 0x80);
. . ReadRegisterMulti(CYRF_21_RX_BUFFER, dpbuffer, 0x10);
}

If receive buffer is full and not currently receiving, but last receive is incomplete; we read it anyway to reset pointer to start of buffer. That is why:

(rx_state & 0x02) // Receive complete

is not checked until after reading the buffer.

If all good we parse the telemetry packet for processing.

Finally we remove our overwrite lock with:
CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x87); //Prepare to receive


You can download test build 72057cf here:
bitbucket.org/Indigo1/deviation/downloads


Source code is here

Hi, just got loss of connection executing this Test
Version deviation-devo10-v4.0.1-72057cf.zip from Indigo

Ok, Devo loss of connection with Telemetry ON problem still exists.

If there is a known past version where this problem didn't exist, that would help.

My chances of fixing this without a Devo model to test with myself are slim. If someone could lend me a Devo model even a damaged one that still binds would do the job, it wouldn't need to have telemetry support.

Or, another developer that can test Devo is going to have to take on this task. Anyone?

PB, walkera has the RX705, this RX has telemetry port that can be use it into the x350 pro. I'm not sure, but I think that the rx has some similar protocol like mavlink.

Indigo wrote: Ok, Devo loss of connection with Telemetry ON problem still exists.

...

It is not the problem of dropping in level, it is the RF locked up..

My speculation would be under Telemetry, the RF module would be switching between Tx and Rx mode so as to collect remote data. However, once in a very very rare while, the switching has been locked up into receiving mode indefinitely causing NO power output for usual radio control..

Not sure if it is really the case but for the moment, turn Telemetry OFF for a safe flight ...

cmPang

cmpang wrote: My speculation would be under Telemetry, the RF module would be switching between Tx and Rx mode so as to collect remote data. However, once in a very very rare while, the switching has been locked up into receiving mode indefinitely causing NO power output for usual radio control..

cmpang's speculation may be true.
A Spectrum-analyser (e.g. Wi-Spy, RF Explorer) would tell.

During testing I had at least one incident with GeniusCP-V1 (not telemetry capable), so it is likely sufficient to just turn telemetry on.

Problem: it may take many hours to show the issue.
Question: Why does DSMX not seem to be affected?

@PB did you try this test ?

Edit:
Would it be possible, to write some debugging code?
This code could try to capture the state of the CYRF6936 at the time the issue is present.
Maybe write all sorts of registers to a file when TX is powered off.

vlad_vy wrote:

Indigo wrote: Finally we remove our overwrite lock with:
CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x87); //Prepare to receive

Why we need this last step if then we immediately switch to TX Mode?

I believe it prepares the receive buffer ready for next switch to RX mode.

I've tried removing each test and changing the order. What you see is the minimum required to make it work.

Ok, thanks.

I was doing my testing on DSMx where it was originally after READ_B, but where Devo has it looks better so I'll try changing it.

EDIT: I see, DSMx has it before READ_B as well as when switching to RX mode.

PhracturedBlue wrote: @linux-user, do you run with your Tx hooked up to a bench power supply?

Well, I am using a (cheap) 12V power supply which came with a USB-harddisk. This is plugged into the charge-port of my Devo10. TX itself is equipped with 8 AA eneloops.
The very same TX configuration does not show any connection losses with telemetry switched OFF or with DSMX.

Version deviation-devo10-v4.0.1-c810bb4.zip from Indigo has been runnnig flawlessly for 5h. Checked again after 8h and connection was lost executing this Test with MiniCP.
TX power was set to 3mW

Huh, got disconnect much sooner than expected.
I'll give it another try.

PhracturedBlue wrote: can you grab a reference copy when the model is bound

My second attempt ran flawlessly over night.
So here it is!

Q: In the case RX won't reconnect, would it make any difference if RX is powered on or powered off the time grabbing the error.txt?

I am asking, because I don't remember which was the case in the first attempt.