Setting of PIDs and Rates on KISS FC does not work with KISS 24RE ESC telemetry connected about kiss_osd HOT 11 CLOSED

i started on config rewrite today. ;)))

from kiss_osd.

Awesome Alex! Let me know how I can be of any help.

from kiss_osd.

Check your rcg messages :)

from kiss_osd.

Again: THANKS A TON!

I tested this about 20-30 times on my desk with the props off. No motor even moved. Even though I had some bugs in SendFCSettings() and it partially send crap data - all fixed now :)

I have two requests:

1. Can you please make the ESCs beep if there is no buzzer configured (after saving)? Some people do not use a buzzer or it is not connected to the FC.

2. In the long run, it would be great to use a separate code to just save the PIDs and Rates. Using the settings could create havoc in the future: What if you make a major change in the byte stream for the settings, but the OSD is not updated? I do have everything updated until 104, and I will keep monitoring what you and Felix are doing inside protocol.js. But you cannot expect the end user to keep the OSD up to date. Let me know what your thoughts are on that, or if you maybe have a better idea.

3. I need to do more testing, but I have a suspicion that retrieving the settings through 0x30 does not work any more after telemetry has been requested through 0x20. Did you run into a similar issue with your GUI?

Will do more testing in the field on both of my quads. If there is no major accident in the next two weeks of testing - I think we should talk about releasing it to the community :)

Thanks,
The other Alex :)

from kiss_osd.

I switched frames on my Acro quad recently and gave KISSFC-1.1RC4-unsafe a try. Tweaking the PIDs has never been that much fun before - just land, change them in the menu - beep - take off again. No more fiddling around with the cable etc.
While it was a lot of fun while it lasted, at some point the OSD stopped working. Or better say: The OSD was still running, however the KISS FC just decided to stop sending the settings at some point. My OSD FW won't display anything if it does not receive any settings from the KISS FC. My other quad (with same OSD and KISS FC FW) did the same from the get go. So I flashed back to T107xx and voila - OSD works again (no change in OSD FW).
Very strange.

from kiss_osd.

Any ways to reproduce it? Does it happen when you DONT save settings from OSD?

from kiss_osd.

I will try to reproduce it tomorrow.
But what I can already say: On one of my quads I just updated the KISS FC FW to KISSFC-1.1RC4-unsafe, loaded my backup through your GUI and the OSD would not work (because it would not receive any settings).

from kiss_osd.

well.. format changed probably?

On 18 Nov 2016, at 03:32, awolf78 [email protected] wrote:

I will try to reproduce it tomorrow.
But what I can already say: On one of my quads I just updated the KISS FC FW to KISSFC-1.1RC4-unsafe, loaded my backup through your GUI and the OSD would not work (because it would not receive any settings).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #3 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACARCqDbeCjjJqEf3rk-gEZtVNyVWe2Nks5q_Q5BgaJpZM4KZCEq.

from kiss_osd.

From current protocol.js:

if (obj.ver > 104) {
                data.setUint8(128, obj.NotchFilterEnable);
                data.setUint16(129, obj.NotchFilterCenter,0);
                data.setUint16(131, obj.NotchFilterCut,0);
                data.setUint8(133, obj.YawCfilter);

                blen=142;
            }

Why is blen=142 while you only set 133 bytes in the buffer?

If the format changed, and my ReadFCSettings() procedure is wrong, I should have never been able to read the settings. But as I said earlier, it did work for a while, then stopped working.

UPDATE: I double checked with some debug output, the OSD definitely gets stuck in ReadFCSettings() (protocol.ino), since the checksum failed.
I compared the checksums, it was off by 1 (36 vs. 37 calculated). Your protocol code uses a float to calculate the CRC which is very expensive on ATMEL. Does the KISS FC also use a float for the CRC? Do you mind pasting the code from the KISS FC for the CRC calculation?

from kiss_osd.

Ok, I think I found the issue - shame on me, had a bug in my protocol code :(
I have been saving away many times on both of my quads and have not found any issue so far. Thanks for providing the FW to test and debug my code!

Before I close this:
How are we going to convince Flyduino that saving with a Lipo attached does not cause any issues?

from kiss_osd.

Its noted ;)

from kiss_osd.