Yes of course, that problem isn’t solved yet
Patrick I think you are confusing the older PX4IO?
The Pixhawk1 is the FMUV2, the PIxhawk 2 is the original 3DR cube in the Solo, FMUV3, Then the newer FMUV4 was the Pixracer etc…
I should have written the original PixHawk was running on fmuV1 was short live and most clones are running on fmuV2
i flashed fmuv2 firmware, but i observe, that FlowHold mode is gone now !?! (message in mission planner: “no such mode”) i think this has something to do with 1MB limit ?
Ther was a check some time ago, to verify whether the chip has 1MB or 2MB. I did this check and my Pixhawk lite appeared to have 2MB
shall i flash fmuv3 firmware or better Pixhawk1 firmware (that had allowed FlowHold mode) ?
“I should have written the original PixHawk was running on fmuV1 was short live and most clones are running on fmuV2”
Patrick, Yes there you go.
FS007 I don’t think that has anything to do with the fmu version but rather some of the features do change from version to version of the Ardupilot firmware releases. Some features are removed and new ones added and some they change the name of the parameters. So it is probably the version of Ardupilot not the fmu version. All of the fmu versions should have the same Ardupilot features and as far as I know they have not exceeded the 1mb limit yet, purposefully.
Then there is this:
" rmackay9
I think what’s happened is the flight controller being used suffers from the 1MB limit so Mission Planner is loading the fmuv2 firmware instead of fmuv3. If you manually download the fmuv3 firmware and then use the “Upload Custom Firmware” to load it to the flight controller it will probably work.
I’ll have a chat with the other devs on the weekly dev call about this."
This implies that there are some features now that require a 2mb fc. I’ll have to update myself on this subject.
i used the so called “latest” from download section, which is 3.7.0
PixHawk1: FlowHold mode present
fmuv2: “no such mode”
fmuv3: FlowHold mode present
Question is: can i use fmuv3 for my Pixhawk lite ?
Interesting, @fs007 can you open the cover and tell us exactly what is written on the STM …if it is a STM… :-
Sorry, that would mean quite a lot of disconstruction work.
meanwhile i flashed fmuv3 and that seems to work … i’ll do a short test flight … fingers crossed
1 Like
Cool , sound like good news
just back from my test flight with firmware fmuv3:
everything worked as it should, except one thing: i can’t fly higher than approx. 1 meter.
crazy
Have you tried with flying althold wih ekf2
as far as i remember: yes that worked
honestly: i’m using arducopter since 3 years now and you can believe me, if i could never fly higher than 1m i surely wouldn’t have used it.
i see 2 possibilities:
- there is something wrong with my parameters
- or with EKF3 ?
Here what I suggest, make a test flight with ekf2 and is proven OK on both on althold & flowhold then you/we can open an issue on github
You know when I get weird stuff like this, and it does happen, I try to erase ALL of the parameter memory by installing an entirely different firmware line, like plane or antenna tracker, then reinstall. I swear there are times when a bad parameter memory location brings over a bad value from another install when that location is not written over during a firmware install.
After hours of testing finally i found the culprit: It’s this parameter: EK3_GPS_TYPE
I had set it to 3 for indoor flying without GPS. That was obviously a mistake:
After setting it to 0 again, everything works fine and i can fly as high as i want !
BUT: I consider this as a bug in that firmware, because this parameter should simply disable GPS and not restrict flight height.
There’ s no GPS in the basement of my house anyway, so i can live with that.
It prevents you from hitting the ceiling indoors. 
Glad you figured it out, these are the hardest problems. You only see them out of the corner of your eye.
Hummm … Thats weird,
I fly indoor GPS denied using this config EK3_GPS_TYPE set to 3.
Just to make sure , what happens if you set it back to 3 ?
It should restrict the height if your flying in a mode that needs location from optical flow, I guess that makes sense. You should be able to do whatever you like in the other modes, if this is not the case its a bug. Can you open a github issue.
Thanks
Imho that doesn’t make sense at all:
- I flew in AltHold
- Restricting height to 1.2m isn’t needed for optical flow. OF sensor allows much higher altitude.
I’ll check if i can reproduce that after all the flashing and if so i’ll post a second log.