I’m going to post this in the 3.5 rc3 thread as well.
When I turn on my Taranis - then power my copter, I get several of the PH2 boot messages, then it appears to lock
the script / telemetry. I can still change flight modes, fly the copter fine, but the Flightdeck hud no longer repsonds.
I’m using the GPS2 port for the telemetry module - 57.6 and 10 on Serial 4.
I’m using this build on 2 other copters both with the same telemetry setup on the same radio with no issues.
I am having the same problem. Reverted to 3.4.6 and Flight deck is working again.
Normally the first message received at the Taranis is ‘landing complete’
With 3.5rc3 this message is missing. Flight deck telemetry appears to be working until the copter is armed, Flight Deck then stops receiving updates until the copter is disarmed. I was getting the occasional message in flight, but no sensor data.
Happens both with and without a Sik radio on telem1, and with a 3dr Pixhawk and Proficnc Cube.
edit so this is a copter 3.5 issue not a Pixhawk 2.1 issue
Glad it isn’t just me. Having a real time with this PH2.
I did see a difference by changing my log and log buffer setting on the PH2.
However, I’m not seeing this specific issue with either of my Pixhawks (clones - 2.4.6 & 2.4.8) on 3.5RC3.
I have seen a good amount of telemetry lag on them all with 3.5 - especially bad right after arming but this goes away after about 20 seconds - at which point I’ll receive my flight mode announcement.
If you have EKF3 on, turn it off.
My backend_logging is "file only"
I had bumped my log_buffer up to 40 and it was causing problems(EKF 3 errors out with insufficient memory at 40) - changed to 20.
log_bitmask to 45054
log_replay changed to 1
This has cleared up my issues, I’ve been connected via USB only for an hour now - and have had Telem the whole time with fast updates.
I was also able to reinstall my Edison, and actually power and connect the PH2.1 via usb.
I think a combination large EKF3 overhead, and large logging had simply overloaded the FC / Edison, and the combination was keeping the unit from booting on USB. Of course, I’m sure there’s way more to it - nonetheless, it’s working.
I’m going to post my setup experience here in a minute - now that I think I’ve worked much of it out. If for nothing else, to help somebody whom might be having issues.
Edit - while Craft & Theory may need to change some code or buffering or something for new EKF3 messages, I really don’t feel like it’s entirely their issue.
There’s an old thread somewhere - may have been the old forums - that had several different designs but there was 1 from a guy who posted schematic and photo for the design. The simplicity was genius IMO.
It’s a very simple unit using a TTL level shifter to invert data on the s,port bus. If I can find it I’ll send it to you.
I purchased my first one from C&T but I’ve made all the others.
FWIW - I’ve used many of the open source options with Teensy and etc. and they work well but are simply too much work and too cumbersome for my taste. And the FlightDeck HUD is WELL worth the cost alone.
I don’t know what the problem is, but I can confirm, when I upload 3.4.6 firmware (both PH2.1 and 3dr PH1), flight deck works. With 3.5rc4 flight deck appears broken. Some information is reported correctly, but updates stop when armed. Additionally, on the taranis fewer sensors show up when using the ‘discover sensors’. Very odd.
I was having this very issue on one of my Pixhawk clones. Half of the items working slownl updates on the rest.
In the end turning off EKF3 solved it on that one. There’s most definitely an issue between EKF3 and Flightdeck.
It’s odd though I have another Pixhawk clone that it isn’t affecting. This way. It’s a different mfg and new chip rev though.
You might also look at the SRx Params and make sure they aren’t 0 on the serial port you’re using…not sure but that could possible do it.
@Lance_B Was EKF3 enabled by default? Which parameter names and values did you use to turn EKF3 off? I would appreciate a concise summary of the modified parameters so that I can streamline the testing on my end. This info would also be helpful to anyone who want to know how ot enable/disable EKF3.
Changes to the SRx parameters does not enable/disable or otherwise affect the performance of the Native passthrough FrSky telemetry protocol that FlightDeck relies on. Only the MAVLink protocol is affected by changes to the SRx parameters, and native FrSky telemetry does not use MAVLink protocol for communications.
As discussed here (EKF2 and EKF3 memory issues), if EKF3 uses too much CPU, it delays the responses by ArduPilot to polling requests from the FrSky receiver and that’s what is causing the partial to complete FrSky telemetry loss (ArduPilot has 4ms to respond to polling requests from the receiver)…
EKF3 is disabled by default. It was disabled on both my machines. The SRx parameters are all default on both frames iirc. Mostly 0 - is this correct? No difference in these parameters between 3.4.6 and 3.5rc4 in any case…
@Charlie_R My understanding is that the SRx parameters (that configure the frequency of certain MAVLink data streams) are relevant only if the corresponding serial port is set for MAVLink (which is not what FlightDeck uses). Therefore, I assume that the SRx parameters don’t do anything if the corresponding port is set to something other than MAVLink.
If EKF3 is disabled and FrSky telemetry is not reliable, then it’s likely something else uses CPU resources intensely. I know that logging large amounts of data onto a slow SD card can cause this. By default, logging is active only when armed so I think that’s exactly what’s happening for you. Try either logging less or no data (LOG_BITMASK parameter) or swapping for a faster SD card.
I do have full IMU logging enabled on the PH2.1, but not on the PH1, and in any case, the only change I am making to the setup is changing between 3.4.6 and 3.5rc4. So Flight Deck works with full imu logging on 3.4.6 but not on 3.5rc4. Very odd…
I tested 3.5-rc4 on my first batch Pixhawk 2.1 and telemetry works.
It could still be related to logging if your SD card is too slow (maybe 3.5 logs more data than 3.4 even if LOG_BITMASK has the same value). I’m wondering otherwise if there’s anything else in your parameters causing this.
Could you send me your Pixhawk 2.1 .param file so that I can try it out? Please send to info@craftandtheoryllc.com
I received a param file from someone having similar issues. Which the FrSky link still works, some packets are being lost (because the Pixhawk does not respond in a timely manner to the RX’s polling requests). I haven’t identified yet what is causing this. Looks like too much activity on the other serial ports may be a contributing factor to the lost packets.