Open ynielson opened 1 year ago
From the above comment, "it didn't set the RcLost status by calling "RCIN_Custom_RC_Lost(TRUE)" as it did in other failure cases."
I can see that it may not need to do so, because the RcLost and RcFailSafe was already set by the Translate function, "RCIN_Custom_PWM_Translate()". It considered that it is streaming correctly, because the app received that data and was received correctly, no matter what data corruption happened in the middle of the way. (I think it's the matter of whose responsibility)
But the frequencies mentioned in number 1, 2, 3 will affect the performance greatly or somehow depending on the tuning status.
When the RCIN Custom Parser translated the sbusData(with correct header and footer) with the result of "Measure.RcFailsafe = TRUE" && "Measure.RcLost = TRUE", it didn't set the RcLost status by calling "RCIN_Custom_RC_Lost(TRUE)" as it did in other failure cases.
The app "ReadDevice" checked this status "Measure.RcFailsafe = TRUE" && "Measure.RcLost = TRUE", but it caused different error_count depending on the ReadDevice calling frequecy, as the parser's errorCount depends on the "RCIN_Stream_Task()" frequency.
The error count can be increased or decreased depending on the app tuning status as follows:
test case: Test_RCIN_ReadDevice_Multiple_25Bytes()
![rcin_Multiple_25Bytes_2_2023-03-20 16-14-59](https://user-images.githubusercontent.com/102169856/226468431-699ab53e-6125-4143-a4f4-88eca0c564bd.png)
test case: Test_RCIN_ReadDevice_Multiple_12Bytes()
![rcin_Multiple_12Bytes_2_2023-03-20 16-19-03](https://user-images.githubusercontent.com/102169856/226469061-a73c4fb7-1fb1-41d2-819e-a2afecc8e6e5.png)