Not sure if it is the correct topic but i am using Plane 3.8.2 and i am trying to make the MFD TeleflyPro OSD to share the GPS with the Pixhawk the issue is that pixhawk on init try to set the GPS to UBLX 115200 and the MFD TeleflyPro OSD have issue reading UBLX 115200 and can work well with NEMA at 38400 but when i set the pixhawk:
GPS_AUTO_CONFIG = 0
GPS_TYPE = 5
GPS_GNSS_MODE = 0
GPS_SBAS_MODE = 2
SERIAL3_PROTOCOL = 5
SERIAL3_BAUD = 38
At the mission planner i see red “NO GPS” while the MFD OSD shows 3D fix with 12 sats, meaning pixhawk can’t find \ parse the stream, how can i know which NEMA messages the code looks for?
MyFlyDream is a mavlink autopilot. Have you tried just connecting the osd to Pixhawk as a serial device, with all the sensors only connected to the autopilot?
NMEA is a much worse way to use the GPS for flight reasons. Particularly the GPS cannot provide any speed accuracy estimates to the EKF, which means that using it in this manner is strongly not recommended. Plane 3.9 onwards will not attempt to configure a NMEA u-blox.
If you don’t mind, if the TFPro will speak UBX why are you trying to make it work on NMEA? The u-blox driver will give you far better performance and assurances that everything is working correctly.
If I had to guess your problem on NEMA is that the NMEA driver sends a configuration blob (the one that is removed in master/3.9) enables GGA and VTG but disables RMC. RMC is however required in the NMEA driver these days. No one noticed with the u-blox because no one is using the u-blox with NMEA mode, or if they are they pulled the Tx pin to it, so it couldn’t be mis configured. (GPS_AUTO_CONFIG is not respected in the NMEA driver unfortunately).
Thanks a lot for this input it is valuable and will be taken in to consideration, the main issue is the following, the TFPro OSD is said to support both NEMA and UBLX at baudrates from 9600 to 115200 in the manual, having said that, it has a procedure where on startup it tries to recognize the input stream protocol (NEMA / UBLX) and baud rate, i have tried UBLX all the way from 9600 to 115200 but never got the TFPro OSD to lock on it, and with NEMA it is working all the way from 9600 to 115200, so i am guessing the issue is with the TFPro firmware, i have contacted MFD support regarding this issue few times over the last year but never got a response, tried again two days ago hoping to get some answers / support for this issue.
so far your input makes me consider 2 separate GPS units, one for Pixhawk working on UBLX with all its pros for navigation and one for TFPro working on NEMA just for antenna tracking.
Thanks.
Will update if i’ll get any response, i am guessing i am not the only trying this setup.
@Guy_Tzoler it’s possible that the TFPro doesn’t like the u-blox changing baud rate after it’s been booted. Try using it in ublox mode with GPS_AUTO_CONFIG 1, then set GPS_SAVE_CFG 2. After it is fully configured (IE you can pass the GPS pre arm checks, this can take upto 30 seconds). You will see a message that says “GPS: u-blox 1 saving config” when we tell the GPS to save the config. If you powercycle the system now the GPS should start out at 115200 baud instead of changing later.
@WickedShell already tried to do so and let the TFPro try to read the UBLX stream only after full configuration and 3D fix in mission planner but it won’t lock on the stream i suspect that it does not really support UBLX with all its available messages since its last firmware is pretty old, June 2016, and from what i can recall from old posts it was a fix for a problem caused when the GPS reported more than 14 sats it had some kind of overflow making the system think it has no sats, i suspect that it has issue with data coming from GNSS other than GPS causing it to lose sync or something like this.
the problem is that it is not open source and the support form the manufacture is limited to none.
guessing my only option for now is to use 2 GPS receivers until MFD will release a working firmware for the TFPro.
Unfortunately I’m out of useful ideas on this one. If you are using a u-blox 7 or newer we are requesting PVT messages and turning off almost every other position message. It’s quite possible that the MFD is only looking for the POSLLH messages for example which we no longer use.
The TFPro was i n market before Mavlink was popular and the autopilot came out later and i am guessing it uses Mavlink to be able to run with GCS without MFD needing to develop their own GCS.
I’ll try contact MFD support to ask if it will take MAVLINK.
I’ll try check this lead by manually configuring the GPS with u-center.