- Posts: 3333
Support for walkera telemetry.
- vlad_vy
- Offline
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;
}
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.
- PhracturedBlue
- Offline
- Posts: 4402
the alarm code should not be able to preempt the protocol code, so this is a very odd behavior.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
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.
- vlad_vy
- Offline
- Posts: 3333
For test I used code in my message #31245. For linux-user we need write working code, not this test build.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
I have created a devo10 build here:
www.deviationtx.com/downloads-new/catego...blue-devo-reset-test
Note that I do NOT recommend actually flying with this. Just use it to see if you can reliably maintain a connection over multiple days with telemetry enabled
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
if (txState == 1) {
int i = 0;
while ( !(CYRF_ReadRegister(0x04) & 0x02)) {
if(++i > NUM_WAIT_LOOPS)
break;
}
if ((i > NUM_WAIT_LOOPS) || (CYRF_ReadRegister(0x02) & 0x80)) {
CYRF_Reset();
cyrf_init();
cyrf_set_bound_sop_code();
txState = 0;
return 1500;
}
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;
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
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.
- vlad_vy
- Offline
- Posts: 3333
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;
Probably will be better to change code for CYRF reset to:
if (txState == 1) {
int i = 0;
while ( !(CYRF_ReadRegister(0x04) & 0x02)) {
if(++i > NUM_WAIT_LOOPS)
break;
}
if ((i > NUM_WAIT_LOOPS) || (CYRF_ReadRegister(0x02) & 0x80)) {
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_StartReceive(); //Prepare to receive
}
}
} else {
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
There IS a bug as you mentioned though. We need to sett he RF channel every time we reset, since pkt_num may not be 0:
if(...) {
CYRF_Reset();
cyrf_init();
cyrf_set_bound_sop_code();
CYRF_ConfigRFChannel(*radio_ch_ptr);
delay = 1500;
txState = 15;
} else {
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
The only odd thing I've observed is, that telemetry values are randomly getting inverted.
I don't think, that running this even longer would get us any new information.
With every version since 4.01 I have been able to recover manually by switching telemetry off/on.
IMHO, the real challenge is to reliably detect the "loss of connection" situation in a timely manner.
I may run this [PhracturedBlue]CYRF Reg Dump and capture more "connection losses" to get a more consistent picture.
Or, as I now have a cp2102 USB-to-UART, we could use this as well.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
www.deviationtx.com/downloads-new/catego...vo-telemetry-los-fix
This SHOULD properly detect loss-of-signal and force a reset. It is a debug-build, and it will report each time a reset condition is detected on serial and on the new on-screen logger.
For the serial:
I needed to connect the 'Tx' pin (pin 3) to the tip and GND (pin 1) to the base of the 1/8" jack. I then use putty at 115200 baud to connect to the serial port. Turn on the tx and you should get some text. If it doesn't work, try the 'Rx' pin instead.
Since we have the on-screen log now, this isn't that important unless you get so many logs that they scroll off the screen.
A message of 'Rst CYRF' will indicate that a fault and reset occurred.
I tested this on my Devo10, and it looks ok, but I on't have a DEVO model handy at the moment to ensure the protocol still works.
Note this is based on the trunk, and does not include any of Indigo's fixes. those may or may not help with telemetry reliability. I am only concerned with loss-of-signal in this version. i checked in the changes on the 'devotelem' branch
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- linux-user
- Offline
- Posts: 271
Oh yes, I see the problem.PhracturedBlue wrote: it is possible he'd get a loss-of-signal until the unrelated Reset condition happens and restores the Tx. That would give a false sense of security since the test he's running would pass, but in real life you'd have lost control.
If you reset the CYRF from time to time, I would never see the LOS although it may happen.
What about making another debug build that only triggers a message + an alarm sound, but does not reset CYRF?
Then I could check if really "loss of connection" happened.
Edit:
It may even dump all CYRF registers to serial.
Edit 2:
IMHO the key is, not to try to solve the issue, but try to reproduce and record the situation.
I have no idea how I could rig up an alarm on the Rx side.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
The problem is that logging the error won't be sufficient I think. Let's say your Tx loses signal every 100 times that the bad-transmit condition happens. Let's also suppose I report this on serial but do not correct for it. You see the 1st 'bad tx' message, and check the Rx but it still binds. You come back 5 hours later, see a lot of 'bad tx' messages, and the Rx no longer binds. Ok, so how can we tell whether this is the proper test condition? We really have no way to do so. because we don't know if one of the 100 failures caused the issue or if it was something unrelated.
We could continue to write tests, and try to find one that fires only when you lose signal, but it may not be possible to do. It is quite possible that there is no difference to the Tx whether the 'bad tx' condition above caused a loss-of-signal or not. i.e. there may not be an indicator that means 'we need to reset the CYRF chip now'.
Also, recall that noone but you can actually duplicate the problem so far. I've run hundreds of hours on multiple transmitters and have never been able to reproduce the issue you have.
The test I have in place now is, I believe, very similar to the test Walkera does in the production firmware, so I hope it will be good enough.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
PhracturedBlue wrote: TXCTRL has the TX_GO bit set AND XACT_CFG_ADDR has the FRC_END bit set. This is not a legal combination
TX_IRQ_STATUS shows the buffer is empty with TX_GO active, which probably shouldn't occur
The RX_Status is showing both EOP and BAD_CRCIRQs set
if (((reg & 0x22) == 0x20) || (CYRF_ReadRegister(0x02) & 0x80)) {
CYRF_Reset();
cyrf_init();
cyrf_set_bound_sop_code();
printf("Rst CYRF\n");
delay = 1500;
txState = 15;
} else {
I think "(reg & 0x22) == 0x20)" is excessive.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- Support for walkera telemetry.