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.
@Charlie_R I haven’t tested with rc3 or rc4, but your param file works fine on my Pixhawk 1 (armed or not) with rc5… Let me know if rc5 works on your end…
I recently started to use FlightDeck and noticed the same thing. The FlightDeck telemetry sensors (VFAS, Alt, USpd and GPS) are not updating causing the dashboard to freeze. It only occurs when the motors are armed and when I disarm them I get the audio message “sensor loss”. If I enable logging when disarmed by setting LOG_DISARMED to 1 they don’t update when disarmed either which proves the logging is causing the issue. The LOG_BITMASK is set to the default of 830. My Taranis is a X9D. My Pixhawk is version 1 (3DR clone) and its running Arducopter 3.5.5. The version of FlightDesk is 3.3.3. I can make it work by setting the LOG_BITMASK to 0 effectively disabling all logging but that’s not very good if I need to troubleshoot another problem. The SD card in the Pixhawk is the original so I will try installing a faster one to see if that makes any difference.
After replacing the SD Card with a newly formatted kingston 16GB class 4 SD card mission planner started to report a pre-arm error of “logging failed” and “No IO thread heart beat”. Also the Flight Deck sensors were not updating at all. To eliminate these errors I had to set the LOG_BITMASK to 655358 and restart the Pixhawk. I then set the LOG_BITMASK to 830 (default) and now the sensors are updating all the time. I did noticed they stop for a short period when the Pixhawk beeps indicating that there is a GPS lock and when they resume updating the Taranis reports a “sensor loss” but I can live with that.
