Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Blackbox - Add logging of critical rx loss state flags. #1266

Closed
hydra opened this issue Aug 28, 2015 · 6 comments
Closed

Blackbox - Add logging of critical rx loss state flags. #1266

hydra opened this issue Aug 28, 2015 · 6 comments
Assignees
@thenickdude
Labels
Critical Enhancement
Milestone
1.10.0

Comments

@hydra
Copy link
Contributor

hydra commented Aug 28, 2015 

[01:01] <Hydra_> thenickdude, lo
[01:03] <Hydra_> any chance you could update the blackbox code so it records these two flags:
[01:03] <Hydra_> https://github.com/cleanflight/cleanflight/blob/master/src/main/rx/rx.c#L442
[01:03] <Hydra_> rxFlightChannelsValid
[01:03] <Hydra_> and
[01:04] <Hydra_> https://github.com/cleanflight/cleanflight/blob/master/src/main/rx/rx.c#L447
[01:05] <Hydra_> rxSignalReceived
[01:05] <Hydra_> it will be very useful in 1.10.0 when people start using the new code.
@hydra hydra added this to the 1.10.0 milestone Aug 28, 2015
@thenickdude
Copy link
Contributor

Implemented now!

screen shot 2015-08-28 at 5 34 05 pm

Is rxSignalReceived supposed to be this gnarly? I set rx_max_usec to 1950 so I could trigger failsafe by going full throttle (2000). You can see that after my throttle reaches 2000, rxFlightChannelsValid correctly goes to zero and failsafe behaviour begins. But should rxSignalReceived be ping-ponging like this? I'm using a D4R-II in PPM mode.

EDIT: Looptime is 3500, Naze32.

@hydra
Copy link
Contributor Author

hydra commented Aug 28, 2015

awesome. it depends where you log it. I'll look at your implementation.

@hydra
Copy link
Contributor Author

hydra commented Aug 28, 2015

i think you need another method that updates those 'slow' fields. it's likely that you're logging the data between the time the flag is reset after and before the flag is updated after the rx data is verified.

I will take a look and adjust if that is the case.

@thenickdude
Copy link
Contributor

The slow data is only loaded by Blackbox at the end of a main loop iteration, so it seems like the Rx loss detection fields should be in a valid state at that point?

@hydra
Copy link
Contributor Author

hydra commented Aug 29, 2015

yes correct. the plot thickens.

@ProDrone
Copy link

rxSignalReceived is used internally to indicate that a new PPM frame is received (set to true), when timed out (no good frame received with a repetition rate of 10Hz) it is set to false. Also when a good frame is received, but it has pulses for stick channels that are out of range, it is set to false.

Can it be that your transmitter is very close to your receiver and that it indeed does not receive good frames? I remember that this was reported by @Maca55 on 27 juli #995 (comment)

@hydra hydra mentioned this issue Sep 28, 2015
Closed
This was referenced Sep 30, 2015
Closed
Merged
borisbstyle pushed a commit to betaflight/betaflight that referenced this issue Oct 15, 2015
@borisbstyle
Improved RX failsafe detection & handling
802b2e0 
modified debug output (currently disabled)

To solve problem as indicated here:
cleanflight/cleanflight#1266 (comment)

and here:
cleanflight/cleanflight#1340

and here:
cleanflight/cleanflight#1342

Tested on FrSKY X4RSB with latest CPPM firmware (non-EU version).
Firmware filename: X4R-X4RSB_cppm_non-EU_150630

In both SBUS and CPPM mode.
@hydra hydra modified the milestones: 1.10.1, 1.10.0 Oct 15, 2015
flacjacket pushed a commit to flacjacket/cleanflight that referenced this issue Oct 22, 2015
@flacjacket
Improved RX failsafe detection & handling
25fd2ff 
modified debug output (currently disabled)

To solve problem as indicated here:
cleanflight#1266 (comment)

and here:
cleanflight#1340

and here:
cleanflight#1342

Tested on FrSKY X4RSB with latest CPPM firmware (non-EU version).
Firmware filename: X4R-X4RSB_cppm_non-EU_150630

In both SBUS and CPPM mode.

---
Added delay to rxfail detection

All channels are monitored for bad (out of valid range) pulses.
On bad pulses channel data will HOLD the last value for a period of
MAX_INVALID_PULS_TIME (300ms) before starting rxfail substitution.
This should prevent a too aggressive reaction to small dropouts.

---
Init ARM switch rc channel to OFF for safety

Initialize ARM switch to OFF position when arming via switch is defined.
To prevent arming during init when RX is disconnected and/or when RX is
connected but TX is still off.

---
Modified rx_rx_unittest.cc

Adapted because rxInit() parameters changed.
Added tests for ARM switch initialization.
No further tests added.

---
Move smoothing of rcData to rcCommand

Commit from @borisbstyle pr cleanflight#1418
rc_smoothing function has changed to leave rcData unchanged in cleanflight#1418
martinbudden pushed a commit to martinbudden/cleanflight that referenced this issue Oct 4, 2016
@blckmn
Merge pull request cleanflight#1266 from martinbudden/bf_serial_const…
fdb4a36 
…_correctness

Made serial const correct
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@thenickdude thenickdude

Labels
Critical Enhancement
Projects
None yet
Milestone
1.10.0
Development

No branches or pull requests
3 participants
@hydra @thenickdude @ProDrone