BLHeli32 ESC telemetry setup - how?

Hmmn, that’s weird - log download was all working for me yesterday on my branch. Not tried the latest master. I know @tridge made some kind of SPI change, maybe that is responsible? You could try my branch instead - it’s based off 4.0rc2?

Yes you need to set SERVO_BLH_POLES correctly. 14 is the default for most motors so I am lead to believe but on my F20’s it’s 12 - it’s the 12P in the 9N12P configuration

It’s not necessary to set INS_NOTCH_* at all, just the parameters above.

BLHeli setup is here but if you are seeing reasonable RPM values then you are probably ok. Note that I do see rpm values in MP.

it is code for sure. i have 2 models now with this kakute - just flashed other one with this last compile, and it stopped making logs in the same way. pity.

that link above is not very helpful - it has a lot of info in there, but, does not say antyhing of what actually to do, imho. i looked at it before, and it is set - like i said before, i still do not understand why some people do see data in the MP for all thise ESC vlaues in the ‘status’ window and i never see anything other than 0 in there. but, i do get RP in the log - so, it should work. but, now without logs it is in the stalemate again.

Be worth trying the latest Copter-4.0 branch as that does not have all of master

does it have this new harmonic notch filter in it?

Yes. It has all the changes you need apart from the DMA fix for Kakaute Mini. My branch is the same but has the DMA fix and my FFT PR. Be good to know what is causing the issue regardless.

i suspect this new master code somehow ruined both my kakute f7 minis. i did regression from master back to the code i had - so, none worked. then flashed original code i compiled on 10/17th - one that worked, and, alas, still no logs. not sure yet what to look at.

Ouch, that’s nasty! Has your configuration changed at all?

Hey @Paul_Atkin1 I’ve just tried with my KakuteF7Mini and my small copter branch (basically 4.0rc2) and all is fine - I can create and download logs just fine. Please double check that you have:

LOG_DISARMED = 0 
LOG_BACKEND_TYPE = 4

These are my current blheli settings:

i have same settings for log - post whole file here i will compare with mine.
only alteration i have in my hwdef file - i did set all UARTS to NODMA. how is yours set?
so, what i saw yesterday - it makes files fine if there is a file already there. if you go and clear all logs - it stops making new files. i tried it with both log_disarmed and without. with a build from 10/17th (or earlier) it seems to more reliable but i managed to make it miss couple of times also on that earlier build. if i repeat logs clear command several times on the earlier code it eventually starts making logs again. with current master it seems to be getting stuck always, no matter how many clear log commands i give.

Even after reboot? I always find that clearing logs is “sticky” unless I reboot.

Exactly so. No logs after no matter how many reboots, persistent condition. If at least one file exists - it all works. That is what i have now.

Hmmn, interesting - I have no idea why it happens, but I have seen general flakiness with logging to flash for a while now. Sometimes it works sometimes I get a zero length file, never really been able to pin it down.

In this scenario it makes file reliably every time if old files are there. What is the logic of the logger when device gets full? Will it replace older ligs or simply stop logging?
I will try to look at it later but i am quite puzzeled right now. I did not have this issue with earlier builds on this f7 mini.

I don’t know the logic, but I haven’t seen it fill up - maybe files get recycled after a while

in 3.7 when my logs filled (omnibus nano), I experienced corruption… Files were listed as (NaN), or all 5 or whatever files would be gone and instead I’d have one large file, or other strange things.
I haven’t logged in a few months, though… Going to enable it again for my next flights.

i have managed to make it fly and make me a log, finally. need to figure out what is the deal with vibrations on this 4" model - if it is given a decent kick it just goes over the roof. it was flyable, still. here is a log - can you see from that log if that new filter actually worked?

It’s not working - CTUN->N is 100 the whole time. I would expect to see it varying as the throttle varies.

Can you post your parameters?

here is the param file. gecko4kakute110219.param (22.1 KB)

odd, just noticed - the _REF param went to 0. i did not alter it, but, will go try again now.

so,. went out to fly, i would not say i felt much of a difference, but, when got home to look at the log it did show there just an empty 256 bytes file. pity. that logging thing needs to be fixed. it will have to wait now, i will not have much time to deal with it next week.

Yeah REF at 0 would do it.

I also think your roll and pitch FTLD & FLTT are too low. I think you could set these at 80 and raise your gyro filt to 100. Also I fly all of my small quads with a loop rate of 800.

i did that, i think it all helped quite a lot - it did not dart into sky no more. ctun-n param showed diff values, cpu load was at 50% somewhat with 800 loops - not too bad. overall it looks as a success.

the INS_HNTCH_FREQ param - in your file it seems to be set to 268 - in mine i did set it to 100 - does it even matter what is it set to?