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.

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

to much severity messages.. or to slow? #23

Open
wolkstein opened this issue Sep 17, 2015 · 5 comments
Open

to much severity messages.. or to slow? #23

wolkstein opened this issue Sep 17, 2015 · 5 comments
Labels
Milestone

Comments

@wolkstein
Copy link
Collaborator

severity messages currently flute taranis. after my changes on teensycode, commit: 057c3a6 , all severity messages will send to taranis. at least this is very good, but the cons, this are a lot of messages. after arming you hear around five messages.
calibration- beside init- and ready- messages. after this flightmode and at least the armed message. this need arround 10-15 seconds. at least the vehicle is armed while taranis is still reading pre arm messages. in my case the motors spin since 7 seconds befor taranis is ready with all pre arm messages and say arming. this is not really a problem but a little bit a feeling like an audio offset in films. you see something but you hear it later.

currently teensy repeat each message 1400ms. this produce at least a small time gap on taranis between messages. this mean reducing this to 1100ms save some time without the risk to loose messages because RPM T2 only transmit each 1000ms. but this recover only 2 seconds.

any other ideas?

/g
wolke

@Clooney82 Clooney82 added this to the Version 1.6 milestone Sep 19, 2015
@Clooney82
Copy link
Owner

Haven´t tested it until now, but maybe we can play only important messages, like warnings or critical.

@wolkstein
Copy link
Collaborator Author

yes, but user configurable from an mixer script. because for example i need infos about waypoints. i fly a lot of jobs where i have to use navigation points. and it is really important for me to get informed if an command member is reached.
so maybe we can create an mixer script which do the severity job with some filter options which can enabled/disabled.

so imo, we can move this issue to milestone 1.7. currently i think we can reduce the dequeue time from 1400ms to 1000ms or 1010ms. it is only important that we send inside the 1000ms interval for T2. that will be enough for milestone 1.6.
/g
wolke

@Clooney82 Clooney82 modified the milestones: Version 1.7, Version 1.6 Sep 20, 2015
@wolkstein
Copy link
Collaborator Author

testing with 1050 up to 1300 ms lost randomly some messages. at 1400ms all messages are captured.

at 1400ms we also have randomly messages twice. this need a bit more debugging. i am not sure if this happens because FC send different messages but our parser failed. i use rev apm3.2, so imo i am on the old message system.

because all messages are queued, we can simple remove double messages from queue. but before we do such filtering on teensy we need more infos if the parser works as expected.

/g
wolke

@Clooney82
Copy link
Owner

@wolkstein maybe you can test my latest commit 41e6a5a in my lua_rework branch.
I added possibility to send severity messages to RC

You must add new Telemetry Sensor called "MSG".
You also need to run Ntelem1 & Ntelem2 on you RC.

Didn´t test it so far, because currently I have no working copter here.
Maybe I can verify my commit in the next days.

@wolkstein
Copy link
Collaborator Author

because i use 6s all my telemetry slots are in use on taranis. first i have the need to figure out how i can get cells 1-x without self defined custom sensors on taranis telemetry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants