Ok, so, for a stable version will be like a week or 2 more depending on the beta results?
Great work on releasing such a big update.
I’m keen to try it but have a quick question.
Can you tell me if there are any changes to the Batt2 configuration. I can’t calibrate current under the previous version as the drop downs are different to Batt1 and don’t allow it?
The other thing I wanted to check was in post #30 you said regarding parameter conversion,
“So load 3.9.11, load your old parameters, then load 4.0.0beta2 and during boot it will automatically convert your parameters.”
I am currently running a previous version (3.9.10). If I just load 4.0.0 does this definitely just convert the parameters automatically? (this is how I’m reading it). I assume that the “bad idea” would be to load 4.0.0 first and THEN load the old parameters from 3.9.10?
Any news on when we can use 2 x Here2 gps units on CAN 1 and CAN 2 ?
I understand that in post #69, it says that the current 4.0 already includes the betas and therefore can be updated without load parameteres from backup
I just tried it and it works fine
that should work already. What happens when you try it?
I’ve just released plane 4.0.1beta1. Changes are:
- Added Q_ASSIST_ALT parameter which offers a way for VTOL assistance at low altitudes
- fixed channels 5 and 6 on the MatekF765-Wing
- fixed a bug with sending data on a full UART in mavlink parameter download
- added TECS_LAND_PMIN for constraining pitch minimum during landing
- fixed use of UAVCAN primary GPS with UART secondary GPS
- fixed failover between rangefinders of same orientation
- added RC option for TAKEOFF mode
- fixed logging of current on secondary battery monitors
- fixed register checking on DPS280 for mRoControlZeroF7
- added clock panel to OSD
- fixed B/E led brightness on Pixhawk4
- support RTCM injection to UAVCAN GPS for RTK support
Thanks a lot!!
if i plug one one more into CAN 1 as the label are wrong on my carrier board i lose all leds and get the msg no gps found
What is the difference between TECS_LAND_PMIN and LAND_PITCH_CD?
well, this is embarrassing. While I was working on landing for an aircraft I had thought that LAND_PITCH_CD also applied to pre-flare, but it doesn’t. So the two parameters are actually the same. I’ll remove TECS_LAND_PMIN for the 4.0.1 final. Thanks very much for your question!
Is there an estimation on when or even if you will enable the camera switching on the F765-Wing FC?
I am aware that there are more important features and issues to implement and solve but I’m just asking because this feature would be really interesting to have as the board is equipped with it.
It would be really nice to have FPORT support for Frsky users…
@tridge Do you need additional testing for the SDP33 sensor BUG? Please tell me how to help then.
I have a PH1 and Cube Black here for testing.
Channels 5 and 6 on the MatekF765-Wing, working!!!
Thats awesome news but I’ll wait for the “Stable” version as the plane is not cheap…
Tested the 4.0.1 B1 and still bootloops …
It is fixed in master. The fix will be in the 4.0.1 final release
I have a fport receiver now, and plan on working on supporting the protocol. It won’t make it into 4.0.1 though as it is a fairly complex protocol to add.
I don’t have cameras setup on my F765 board, but looking at the schematic I think it may be that we support this already as the pin is already setup as a user controllable GPIO which can be used as a relay pin. Can you please try the following:
- set RELAY_PIN = 82
- set RC7_OPTION = 28 (can be any free RC channel)
that should give you control over pin PE15 which is the camera switching pin.
Similarly you can do this:
- set RELAY_PIN2 = 81
- set RC8_OPTION = 34
and RC8 should then give you control over pin PE4, which is the Vsw power switching pin.
Please let me know if this works. If it does we should add it to the docs.
Please which bug is this exactly? Thank you