Was curious since 4.1 beta came out, do you think it will solve the issue with being able to turn hd recording on and off on the run cam hybrid v2. I know you told me to wait for 4.1 to come out or should I wait for a stable version.
The fix is in the latest beta - so you should try it
Yes, the FC is the only thing that changed. Start/stop worked on the CTR but not now on the WING. AP vs. AC might just be a coincidence, just wanted to mention it.
This is only for a DART 250G, so there won’t be long flight preparation and therefore not much useless 4k video before launch, so it’s not extremely important to have that start/stop switch working. But just when I thought I can make this work on any craft now… The other 2 cams are Hybrids though, so it’s not exactly the same. Should I maybe run Mavproxy again with a special version?
OT question that just cost me an hour: I can’t seem to find NTF_DISPLAY anymore in latest plane dev versions? So far I had them on all AP crafts to indicate armed state, just in case it goes down and people help searching, so they’re warned in case disarm didn’t work.
Thanks for the correct link, for some strange reason the extra / was included in a link I found via startpage.com (results by Google).
1 Like
NTF_DISPLAY is only on 2Mb boards now
I had checked https://ardupilot.org/plane/docs/common-limited-firmware.html#common-limited-firmware and hoped this wouldn’t be the case. Display is not included there. Does that mean it will stop working on all my existing crafts (all running 1 MB FCs) once I update them, and is it possible to tell on which date this change occured? Looks like a big update freeze is coming up for me now, as I can’t afford to buy 5 new F7 FCs and don’t have the time to rebuild all those models either. To me the OLED display is an important safety feature I’m used to and that I really don’t want to give up.
I think 2 weeks ago when I last updated another F405-WING, the display was still working afterwards (and by the way, external I2C baro, which has been on the list for a while, is still working for me on 1MB). On a side note, I wonder why NTF_LED parameters are still available, as I was under the impression they required LUA, which never was working on 1MB?
NTF_LED works it does not require LUA. The problem is that the display code takes up quite a bit of flash and we didn’t think it was used that much. This will all be solved with the custom build server.
1 Like
Ok, I want make sure that I do this correctly, first I save my parameters to a file on desk top, then install new beta firmware and then reload the saved parameters. Also not a big deal , but I will do another auto tune after every firmware update? How often should I do a auto tune, because after doing a auto tune , I would like to put a different flight mode in place of auto tune and if I have to do another auto tune just add it on the flight mode tab perform auto tune and replace it with different flight mode?
It’s worth saving your parameters but the upgrade from 4.0 to 4.1 should preserve your parameters and not require you to retune.
Ok, lost one, gained one. I had always been under the impression that there are no LEDs without LUA on AP. So I always used ones that flash on their own. Using NTF_LED will be a good replacement for the display, at least to warn about armed state.
I had read about the custom build server a while ago and found the idea fantastic of course. However, it sounded like it could still be some months off.
In any case I will still put a display on the DART as planned and either keep using the dev version from the beginning of June which still had NTF_DISPLAY, or wait for the custom build in case I decide to upgrade. Thanks!
Sounds like you used iNav before, which sometimes forbids you to import old parameters, even on minor version changes. Luckily it’s different here. 
Is this on plane or copter that you want it? It’s possible that as we get close to the release that if there is still enough flash we could put it back - the challenge is that seems like a pretty little used feature compared to other things that are already disabled on 1Mb boards.
Well, maybe I am the only NTF_DISP fan - it’s true that when watching peoples’ build videos usually a display is not part of the process. But I find it very practical, even on the bench and while building. For example in rare cases, the OSD doesn’t show up and the display is a quick way to see if booting has completed anyway, even without connecting a GCS. Or if someone is about to throw a plane for me while I’m already seated with goggles on, he can check for prearm failures himself (for example, holding plane more level). I simply like redundancy I guess. 
As for warning about armed state after a crash, a display is very useful IMO, although NTF_LED might be even better. I will try it today I hope.
It’s hard to say if I’d like it to remain in on copter or plane - actually on both, as I hope by the end of the season I’ll have 4x AP and 3x AC. But if I have to pick one I’d say plane because it’s always easier to find a good place to mount a display there.
As for disabled things, I think the list at https://ardupilot.org/plane/docs/common-limited-firmware.html#common-limited-firmware must be a little outdated, as I2C baro is still working for me on F405-WING and Kakute F7 AIO and really hope it can stay (I like to put a temp sensor out on an arm/wing). Even CRSF telemetry is in that list if I interpret it correctly, and in-flight FFT which I used last autumn on F405-CTR.
Upgraded to 4.1 beta and camera is working. Thank you so much for your effort and time.
1 Like
To get back on topic: Downgrading to a version from June 5th (to get back NTF_DISP) also made RunCam Control work with the Split4k. So the version that I flashed originally (from last week I think) simply was one that happened to include broken RunCam Control.
That’s not good. Any chance you can narrow this down a bit more?
I think it was this one, actually downloaded during the weekend:
arduplane-410dev-270621.apj (847.9 KB)
Right but where did it break?
Start/stop was simply ignored, as initially described here. I didn’t try anything else. The cam was recognized though I think, “0x77” and “2-button”, as usual.
Maybe it’s already working again in today’s version - I once had a version that apparently broke CRSF telemetry/Yaapu (nothing was received), it worked again with a newer version.
Not the only fan of NTF_DISPLAY, I will miss it too, its extremely handy to use also for sat count, arming pass and armed state. I do hope we don’t have to give this up…
Ok let me know if it now works. If it does not if you are able to identify which build in which it broke that would be really helpful.
Ok, I will temporarily (because of NTF_DISPLAY) flash today’s latest version tonight and report back.
It could have been broken in any version between June 5 (works) and June 26 (didn’t work), I’m afraid that’s too many to flash and test.