Mavlink to FrSky S.Port Passthru Converter for LRS or PX4 Pro

Yes, you can use the usb, but you cannot arm the motors.

Is it necessary to arm the motors to get tlog from the mission planner? Sorry I am not too familiar with it. I get that “no GPS error” on Yappu lua screen even when the plane is just sitting stationary disarmed on my work bench.

You dont need to arm to get telemetry, but if so ‘flight’ event causes the issue then the circumstances producing the error won’t occur.

Okay. I will get Tlog from the second serial port. Thanks.

Maybe try the usb and see the problem arises. Much easier.

Sure. I will try USB first.

Not related to my current “No GPS” issue but I would like to give feedback about the inverters while running as Relay mode. I was using this recommended Inverter but it only worked until Version 2.62.8. After that version, S Port telemetry stopped working. Everything else was working except S Port telemetry on a Relay mode. Then I just removed that inverter and used just a Schottky diode on pin13 of heltec and connected it straight to the "un inverted pad on Frsky R-XSR receiver and then S-port telemetry started working.

Maybe something had changed on the newer versions in respect of timings, that made above mentioned inverter stopped working. I tried flashing back and forth and results were consistent. S port telemetry was not working after 2.62.8 while using the above mentioned inverter.

So your idea of using Schottky diode did the trick. So could it be due to the logic levels or timing issues? Thanks.

Hi Eric,

Looks I have narrowed the issue down. After bootup, everything was normally working and I had GPS stats on yappu script screen and mission planner was showing the status of my both GPSs as 3D Fix ( On Mavlink inspector: Fix type as 3 system.byte) but after few minutes, fix type changed from 3D Fix to 3D dgps (On Mavlink inspector, Fix type changed from 3 to 4) and Exactly at that moment, yappu script announced “No GPS” and it started blinking with 0 Sat. But the OLED screen of Heltec had valid GPS coordinates and so as GPS sensor on OpenTx ( when you go to discover sensor screen on OpenTx).
Hopefully it will help you to find the issue. Thanks.

Note: I have 2 GPS modules on my plane.

hi eric,

what does this line mean?

FrPort scheduler buffer full. Check FrPort Downlink to Taranis/Horus

and how do i get around this?

There is a setting in cinfig.h that invsts to Sport, or not . Check config.h very carefully between the vesions. I do change my setting from time to time while testing, and they sometimes creep into the master on github.

Conf8g changes could also explain your problem where telemetry dries up. There is a #define setting to periodically prompt the FC to keep sending telemetry.

Ah, ok. This is a good clue.

Hi Erwin, in realay orr air mode we must read the sport on the air receiver to find a slot to send our sport frame. If we cant read the sport, for whatever reason , our buffer fills up with sport mesages until it’s full. If / when you connct properly, the buffer empties to the sport and receiver and normal workiing commences.

Right, it seems that my rs232-ttl module got fried, i replaced it and now it works again. Although im still having issues connecting to the mav2pt access point, my wifi settings on the phone prompts me that I cant get IP from the access point. any fix on this?

Could you perhaps try one or two versions back? I’m not aware of this as a problem, but i did make a change to support a different ip subnet from the usual 192/168 4/24.

Maybe check to change log. I’m not at my pc right now.

i downgraded to 2.67.5, and was able to connect to the access point, but still was not able to connect to qgroundcontrol. then I tried your suggestion to swap the read ports, and now it works! How did changing the readport fixed this? I havent tried changing this before. but at least now it works

I also needed to change the listening port on qgroundcontrol to 14555, otherwise, it keeps on disconnecting and reconnecting

In TCP and UDP port number are used to filter out unwanted traffic, or sekect the traffic you want. They got switched around on my github master for a project for someone else and regretfully were not reset for QGC.

Hi Eric

Sorry I am not sure if that reply was to my post of GPS display issue?

@epquilloy Wifi connection is working fine here with the 2.67.12

[ninja_zx11]:

Yes, just the part about checking the config.h. There is a line

#define Data_Streams_Enabled // Requests data streams from FC.

If this line is not enabled, please enable it.

Thanks Eric. I will try to check tonight.