- Posts: 271
Support for walkera telemetry.
- linux-user
- Offline
Indigo wrote: Ok, I made function CYRF_RxPacketIsGood() similar to the code used in db5dcb3.
New version 3123e28 is available in Test Builds.
Spontaneous reboot of 3123e28 without even touching it on my Devo10
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
From your log, the stack trace was:
spi_xfer()
CYRF_ReadRegister(0x0f)
CYRF_SetTxRxMode()
devo_cb()
It is a software fault which means that too much time has elapsed since the watchdog timer was updated. This usually means the code is stuck in a loop.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
// Wait for the FRC_END_STATE bit in the XACT_CFG register to clear
while(CYRF_ReadRegister(CYRF_0F_XACT_CFG) & 0x20) {};
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
void CYRF_SetTxRxMode(enum TXRX_State mode)
{
//Set the post tx/rx state
if (mode == RX_EN)
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x10); // receive mode
else {
if (mode == TXRX_OFF)
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x24); // force idle mode
else
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x28); // force Synth(TX) mode
// Wait for the FRC_END_STATE bit in the XACT_CFG register to clear
while(CYRF_ReadRegister(CYRF_0F_XACT_CFG) & 0x20) { ; }
}
For "RX Mode" you do not set FRC END bit, RX mode will be active after next transaction only (receiving or transmitting a packet). Will be better change to:
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x30); // force Receive mode
For my opinion we have not any need to change TX and RX mode, for "Fast Turn Mode" and TX_OFFSET = 1MHz TX and RX mode synthesizer frequency is equal. We can always use Force End State "Synth Mode (TX)":
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x28);
"Fast Turn Mode" and TX_OFFSET = 1MHz have place for all CYRF6936 protocols: Devo, DSM, J6Pro.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
RX abort tested by inserting CYRF_StartReceive() after CYRF_ReadDataPacket(packet) in devo_telemetry_cb().
void CYRF_SetTxRxMode(enum TXRX_State mode)
{
//Set the post tx/rx state
CYRF_WriteRegister(CYRF_0F_XACT_CFG, 0x28);
int CYRF_RxPacketIsGood(u8 len)
{
unsigned rx_state = CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS);
if (rx_state & 0x02) { // receive complete
if (!(rx_state & 0x01)) { // RXC=1, RXE=0 then 2nd check is required (debouncing)
rx_state |= CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS);
}
CYRF_WriteRegister(CYRF_07_RX_IRQ_STATUS, 0x80); // need to set RXOW before data read.
u8 length = CYRF_ReadRegister(CYRF_09_RX_COUNT);
if (((rx_state & 0x25) == 0x20) && length == len) {
// good data (complete with no errors)
return 1;
}
// else bad data, empty buffer
while (length) {
CYRF_ReadRegister(CYRF_21_RX_BUFFER);
length--;
}
}
return 0;
}
txState++;
if(txState == 16) { //2.3msec have passed
if (CYRF_ReadRegister(CYRF_05_RX_CTRL) & 0x80) { // We're still in receive mode
// Disrupt any pending receive by enabling abort
// Force End State should not be used to abort a receive if a SOP has already happened.
CYRF_WriteRegister(CYRF_29_RX_ABORT, 0x20);
CYRF_RxPacketIsGood(0x00);
// Abort by writing the FRC_END_STATE bit in the XACT_CFG register.
CYRF_SetTxRxMode(TX_EN); //Write mode
// Disable abort
CYRF_WriteRegister(CYRF_29_RX_ABORT, 0x00);
}
else CYRF_SetTxRxMode(TX_EN); //Write mode
if(pkt_num == 0) {
//Keep tx power updated
CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power);
radio_ch_ptr = radio_ch_ptr == &radio_ch[2] ? radio_ch : radio_ch_ptr + 1;
CYRF_ConfigRFChannel(*radio_ch_ptr);
}
txState = 0;
}
return delay;
}
Changed files:
Please Log in or Create an account to join the conversation.
- Indigo
- Offline
- Posts: 230
New version 84cc0db (incorporating your changes) has been uploaded to Test Builds.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
int delay = 100;
if (txState == 1) {
int i = 0;
while (! (CYRF_ReadRegister(0x04) & 0x02)) {
if(++i > NUM_WAIT_LOOPS) {
delay = 1500 - i*5;
txState = 15;
break;
}
}
delay = 100 - i*5;
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
delay is calculated based on the time the callback is entered, so you don't ever want to adjust it for the time you spent in the callback. Unless I'm missing the point of the compensation.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
900 + 1500 = 2400
900 + while(up to 100) + 1500 = 2500???
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
the timer is referenced from when the devo_cb is entered NOT from when it exits. so if you want a callback every 1000usec, you always return 1000 regardless of whether you use 10us or 990usec inside of the devo_cb function. If devo_cb takes more time than what you return, you are screwed though (so if the maximum runtime of devo_cb is 1100us, you cannot return 1000). So I don't recommend changing the delay values in the code unless you think they are wrong for some reason.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Please Log in or Create an account to join the conversation.
- linux-user
- Offline
- Posts: 271
But you are very good at thatvlad_vy wrote: I'm not a programmer and only exercising my brain.
My Devo10 MiniCP test has been running for 17h successfully with Indigo's test build 84cc0db.
Checked again at 18h and got loss of connection.
This was definitely the longest time I've observed it running successfully.
Are we now closer to a solution or still lost?
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Hardware: Devo 12s without any mods, RX1202, WK-CTL01-D telemetry module, Walkera GPS sensor, elevator servo. All powered permanently.
Software: nightly build with some changes: www.deviationtx.com/forum/protocol-devel...etry?start=240#30974 or PB test build www.deviationtx.com/downloads-new/catego...o-fixes-for-devo-dsm
Test results:
Day 1, 24 hours = still connected
Day 2, 48 hours = still connected
Day 3, 72 hours = still connected
Day 4, 96 hours = still connected
Day 5, 120 hours = still connected
Tx as usual powered, Rx powered off
Day 6, 144 hours = Rx still connect without problems
Day 6, 149 hours = Rx can't connect...
Test ended with connection lost.
Please Log in or Create an account to join the conversation.
- linux-user
- Offline
- Posts: 271
Well, there is one significant difference to my test:vlad_vy wrote: Hardware: Devo 12s without any mods, RX1202, WK-CTL01-D telemetry module, Walkera GPS sensor, elevator servo. All powered permanently.
My RX is powered off most of the time. Just reconnect it from time to time.
Only my TX is running all the time.
So my TX is receiving invalid telemetry data i.e. no valid telemetry data most of the time.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Second, I've tried such metod with Devo 8s, Ladybird and Fixed ID, 24 hours = still connect without problems.
Please Log in or Create an account to join the conversation.
- linux-user
- Offline
- Posts: 271
Well, my original motivation to test this was real v120d02s-v2-lost-binding-mid-flightvlad_vy wrote: First, it's not real life test. We want to fly without disconnection..
Because of this I have changed the CYRF module, which seems to have solved my issue.
This post from cmpang made me rethink about it.
Since then the code has changed a lot, so you may be right, it is different now.
IMHO if we can't fix it, we should at least disable telemetry as a default.
Statistically 17h is not too far away from 24h.vlad_vy wrote: Second, I've tried such metod with Devo 8s, Ladybird and Fixed ID, 24 hours = still connect without problems.
The incident is definitely very rare
Edit: Hmm
#30562
PhracturedBlue wrote: ...
I have evidence that the official firmware actually has CYRF lockup detection that will send a Reset() and Init() if the chip gets into an illegal state. We could actually code that into the protocol if certain errors are found. It would be better to pay the few msec to reinitialize the chip than to lose contact for a longtime. Just need to find a reliable flag for when to do it.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Probaly, if we get stuck in while() loop:
if (txState == 1) {
int i = 0;
while (! (CYRF_ReadRegister(0x04) & 0x02)) {
if(++i > NUM_WAIT_LOOPS) {
if(CYRF_ReadRegister(0x02) & 0x80) //TX_GO still active
RESET_CYRF(); ???
delay = 1500;
txState = 15;
break;
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
if (txState == 1) {
int i = 0;
u8 reg;
while (++i <= NUM_WAIT_LOOPS)
reg = CYRF_ReadRegister(0x04);
if (reg & 0x02) {
break;
}
}
if (i == NUM_WAIT_LOOPS || (reg & 0x22) || (CYRF_ReadRegister(0x02) & 0x80)) {
CYRF_Reset();
CYRF_Init();
txState = 15;
return 1500;
}
}
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
static u16 test_reset = 25000;
...
...
if (txState == 1) {
int i = 0;
while (! (CYRF_ReadRegister(0x04) & 0x02)) {
if(++i >= NUM_WAIT_LOOPS) {
delay = 1500;
txState = 15;
break;
}
}
test_reset--;
if(!test_reset) {
test_reset = 25000;
CYRF_Reset();
cyrf_init();
delay = 1500;
txState = 15;
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
static u16 test_reset = 25000;
...
...
if (txState == 1) {
int i = 0;
while (! (CYRF_ReadRegister(0x04) & 0x02)) {
if(++i >= NUM_WAIT_LOOPS) {
delay = 1500;
txState = 15;
break;
}
}
test_reset--;
if(!test_reset) {
test_reset = 25000;
CYRF_Reset();
cyrf_init();
cyrf_set_bound_sop_code();
delay = 1500;
txState = 15;
} else {
if (state == DEVO_BOUND) {
/* exit binding state */
state = DEVO_BOUND_3;
cyrf_set_bound_sop_code();
}
if(pkt_num == 0 || bind_counter > 0) {
delay = 1500;
txState = 15;
} else {
CYRF_SetTxRxMode(RX_EN); //Receive mode
CYRF_WriteRegister(CYRF_07_RX_IRQ_STATUS, 0x80); //Prepare to receive
CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x80); //Prepare to receive (do not enable any IRQ)
}
}
FYI: Regardless of whether it is a 'real' test or not, I think linux-user's test is fine. It indicates instability in the protocol in telemetry mode. I also cannot duplicate it on my equipment, but that doesn't mean there isn't an issue. I don't trust the '17 hr' number though. My guess is the issue is inherently random, and that 17hr is no different than 1hr in reproducibility
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- Support for walkera telemetry.