Originally Posted by geofrancis

what about automatically scanning if the signal is lost, if no mavlink data is received for a number of seconds start panning and tilting to reacquire signal.

Not a great idea - you need to consider why the signal would be lost. Flying out of a high gain antenna beam is usually difficult or impossible within a few seconds. Scanning the antenna would always shift the middle of antenna beam away from the aircraft. Losing the beam is more likely to be caused by flying behind something and moving the antenna wouldnt help there either. Not many FPV pilots can report getting their aircraft back after flying behind something and losing signal for more than a few seconds. The best strategy is to freeze the antenna position if signal is lost, that's the best chance of getting the signal back. There is a lot of historic discussion on antenna tracking strategy if you do some searching.

zs6buj: I found a thread earlier that was on how to get Frsky telemetry out of the serial port in the back of the Taranis and into a bluetooth module. Is this similar to what you plan when you get your Taranis?

Here's an interesting project, converts the sport telemetry out into mavlink packages and sends it to his tablet via bluetooth.
The link in the post takes you to another product so either they canned it or are keeping it under wraps for now. I have sent them an email enquiring about it...
This sort of interface would probably work really well with your tracker?

Originally Posted by geofrancis

what about automatically scanning if the signal is lost, if no mavlink data is received for a number of seconds start panning and tilting to reacquire signal.

I tend to agree with Opt on this. Also consider, for example, what happens when you lose the WFB link. I have observed that it is resilient up to a point, then eventually disconnects, and fails to reconnect. So sweeping for reconnect won't work. Sweeping for best rssi on the ground station might have some merit as part a a wider resilience strategy if the link keeps trying to reconnect. Remember, if you have telemetry, you will always be pointing at the correct point in the sky.

Originally Posted by Kenniffs

I found a thread earlier that was on how to get Frsky telemetry out of the serial port in the back of the Taranis and into a bluetooth module. Is this similar to what you plan when you get your Taranis?

Actually I'm very much into this aspect of Frsky right now. The Taranis arrived a few days ago, together with an XRS receiver. I'm converting mavlink out of the Pixhawk to Frsky telemetry using an stm32, inverting/converting to S.Port and sending it to the Taranis and out the S.Port there. The Frsky telemetry is nothing like mavlink or LTM. It seems to have evolved from a simple sensor bus, and new ideas just cobbled on. Sensor data tends to come from outboard sensors and not a FC. Anyway, I've got the gps and heading data I need, and telemetry is popping out the Taranis S.Port, but I still have work to do. If the men in white coats don't come fetch me first. The way Frsky encodes latitude and longitude results in a slight loss of accuracy but it should not be material.

I haven't yet contemplated reconstructing mavlink packets on the ground for Mission Planner, QGroundControl or one of the other ground stations. I understand there is a mavlink "pass through" mode that might help with this. But the immediate goal is get gps telemetry into the tracker.

Wow, that was fast!
I think I'd better tidy my workshop and clean off a bench so I'm ready to go

Have you seen the u360gts project?
This one started in a German forum and has been in development by a Spanish group.
I've been having some trouble getting my head around it due to the translations required and the lack of a concise 'all-in-one-place' wiki, but just last night this thread popped up in RCGroups giving a full run-down in english...

Kenniffs: That looks like a nice project. How did I miss it before? Maybe I can find more information on protocol versions.

It's been a busy week for me, but the Frsky S.Port version of the tracker is ready. I'll post it a little later.

There was a huge amount for me to catch up with since getting my Taranis, and a couple of hurdles. The first was this:

How To Fix FrSky XSR Receiver No Telemetry Bug (8 min 45 sec)

I'm sure everyone in the universe knew about this be fore me. But if you plan to use the XSR receiver, make sure that your example does not have the buggy software.

The second hurdle was that OpenTX recently upgraded from version 2.1 to 2.2. It's by all accounts a wonderful upgrade, and highly recommended, but many things have changed. Some LUA scrips need modification, and there is an annoying little voice reminder that pops up telling you that a SENSOR is LOST if no update is seen for 10 seconds. Of course this is not a bad thing, but it seems to have uncovered an underlying problem for many people using variants of Rolf Blomgren's excellent Mavlink to Frsky converter. If all you are doing is updating the Taranis telemetry screen periodically, and viewing it periodically, it is not really critical how often GPS co-ordinates and altitude come through. If you are tracking an aircraft in real-time it can be critical.

When I first started getting telemetry out of the back of the Taranis, the periods between updates were far too long, but eventually improved enough by doing these things:

1. Updating the XSR firmware to the latest version (it still seems buggy)
2. Slowing down the Frsky telemetry batches to 100 Hz out of the STM32 in which my flavour of MavToFrsky software runs
3. Dropping off unwanted telemetry types

Anyway, good GPS co-ordinates and altitude are arriving out of the Taranis S.Port, being fed into the new Frsky version of the tracker, which responds appropriately to track the craft.

Later on today I'll post some of the details for anyone interested. I had to make up inverters/converters for each end. Easy enough, sure, but I'll share some of the details if anyone wants to make them up for a dollar or two rather than buy them for $20 plus. I'll also post more information on how the Frsky S.Port X telemetry protocol fits into this application. The application does NOT support the older D (hub) protocol.

I'm interested!
Are you still using a cable connection from the Taranis to the tracker?
I finally got some feedback from that guy who had developed a Bluetooth unit for the Taranis and he is going to look into making me one, that's the good news.
Bad news is that he is snowed under in work at the moment and i am (voluntarily) at the bottom of the list. He hasn't yet given me a time frame so I'll back off for a couple of weeks and ask again.

Kenniffs:

Yes S.Port telemetry is taken from the S.Port in the back of the Taranis. It comprises a simple two wire connection.: Ground and S.Port. I'll publish some pictures. Adding Bluetooth to this is trivial really, but I recall you need the telemetry back in the Mavlink protocol. Maybe I'll tackle that next. The Frsky tracker is working and can be put to bed.

FRSKY S.PORT IS HERE.

For anyone wanting to try this tracker with the Frisky protocol, source and binaries are published with the first post. Please be aware that I have desk and garden checked it only as I don't yet have a craft with a Pixhawk FC and Frsky receiver in it. However, the non-Frsky parts of the software are well used by now and should be good. Please be prepared to thoroughly check out the software yourself before you fly, and please report back any possible bugs. My STM32 variation of Rolf Blomgren's excellent MavLink_FrSkySPort converter was used for the testing. http://diydrones.com/forum/topics/am...port-converter

Below you will find attached the source of my stm32 version of the Mav to frsky converter. Invert the serial out (tx=B10, rx=B11) and convert to single wire to connect to your Frsky receiver, like the XSR or X4R or X8R. Commercial converters are available or see diagram of the simple one I built.

Here is a diagram of the air side, showing the Mavlink flight controller, STM32 running Mav to Frsky protocol converter firmware, electrical UART to S.Port inverter/converter, and XSR receiver wiring. The FC is a Pixhawk, but of course it could be an APM or other FC. Note we pick up 3.3V from the Pixhawk arm/disarm switch port pin 1. You might need or prefer a 3.3V BEC.

Below we have a diagram of the ground side, showing how S.Port X telemetry leaves the back of the Taranis X9D Plus, through the electrical inverter/converter and into the STM32 running the Frsky X version of the tracking firmware. The rest of the wiring is identical to that of the other versions of the tracker.

I said that I would publish a little more information on how the Mavlink and Frsky protocols fit into this scenario. Let's deal with the electrical characteristics first. Later we will look at how the XSR, using the X protocol, polls for "sensors", requesting data. Our Mavlink_FrsySPort converter pretends to be a sensor, and when polled for GPS co-ordinates, voltages, current, altitude, heading, attitude, battery information etc, it replies immediately to the poll with an 8 byte packet containing the requested "sensor" data. In our case, the data came from the FC and was stored in the stm32 protocol converter waiting to be polled.

Lets look at the electrical signals first. Imagine your Mavlink compatible flight computer, like APM or Pixhawk, feeding telemetry out into Rolf Blomgren's Mavlink_FrskySPort converter. The serial telemetry will come out of the Telemetry 1 or Telemetry 2 port. Normally Mavlink wants to be requested to supply a telemetry type, but Arducopter or PX4 have setting to constantly stream telemetry for OSDs or other things. In this mode, only the Ground and TX out from Pixhawk or APM are essential, otherwise connect both RX and TX. This is essentially a two-wire system. Incoming telemetry on one wire, outgoing on the other wire. Remember RX and TX must cross over when connected to the converter. The Mavlink serial telemetry from the FC tx port looks like this on an oscilloscope:

Notice that the wave-forms drop down from the 3.3v level to zero. The UART on the converter detects the leading edges to read the telemetry at 57600 bits per second (b/s), sometimes referred to by the old unit baud.

The Frsky telemetry out of the converter looks similar, dropping down from 3.3V, but it needs to go into the S.Port of the Frsky receiver, say an XSR, and from there down to the Taranis. So it must be inverted, and converted to a single wire. The Frsky S.Port telemetry looks like this:

Notice that the wave-forms rise up from the zero volts level to about 3.3V. The S.Port in the XSR receiver detects the leading edges and converts them to two-way telemetry.

EDIT: Circuit diagram updated Feb 2019

You can make a simple bi-directional two-wire telemetry inverter to single-wire S.Port converter from a handful of parts. This one works well for me.

Or you can buy a converter/inverter here http://www.craftandtheoryllc.com/fli...t-port-serial/

Or Google is your friend.

You will typically need two of these. Remember they are bi-directional.

1. One to convert telemetry out of Mavlink_FrskySPort protocol converter (STM32) to S.Port of the XSR receiver.
2. One to convert the S.Port signal out of the back Taranis back to regular UART for the Tracker (another STM32). Uni-directional only.

The S.Port and a ground wire plug onto the pins in the back of the Taranis like this. You will probably want to use a shielded single core 1 or 2 metres long, shield to ground. In the picture, white wire is S.Port, black is ground.

FRSKY S.PORT X PROTOCOL

The X series receiver (XSR, X4R, X8R...) polls a fixed range of sensor ID in a round-robin fashion, the data on the receiver S.Port line looking like this, repeating two byte pairs:

7E 1B 7E 00 7E A1 7E 22 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48 7E E9 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71 7E F2 7E 53 7E 34

The repeating 0x7E is the X protocol start/stop character, the second byte in each pair is the sensor id.

The RX pin of the Mavlink_FrskySPort protocol converter (STM32) monitors the stream of polls from the receiver (and switches on it's LED to show there is good traffic from the RX). When it sees sensor id x067, it responds by sending the 8 bytes below (in my case).

10 00 01 5E 3D 02 00 51 (altitude=1467)
10 00 08 D0 BE 00 81 D6 (longitude=28.0434399)
10 00 08 98 8B ED 40 95 (latitude=-25.9462795)
10 40 08 60 3B 00 00 0C (heading =152)

Of course, not the comments in brackets

For example: 10 - 00 01 - 5E 3D 02 00 - 51

To break the 8 bytes down into meaningful chunks

• The first byte is the data frame character 0x10, always the same
• The next two bytes are the data id, little-endian (swop them around), so 00 01 = 0x0100, which identifies an altitude frame
• The next four bytes contain the value, also little-endian. In this case altitude = decimal 1467
  The last byte is the crc character, or cyclic redundancy check. It is recalculated at the received end, and if it is wrong the packet is rejected.

The other data ids for longitude/latitude, heading and so on are structured in the same way. For latitude and longitude, separate frames with the same data id 0x800 is used, but the two most significant bits of the value 4 byte word code for neg or pos, lat or long. The lat and long values are coded in degrees and decimals of minutes. !

What comes out the S.Port in the back bay of the Taranis is a composite of the receiver polling, and the response. The example below selects on start/stop byte 0x7E to print a new line. Of course the stream would be continuous.

7E 48
7E E9
7E 6A
7E CB
7E AC
7E 0D
7E 8E
7E 98 10 05 F1 01 32 0D 00 B8
7E 98 10 01 F1 53 00 00 00 A9
7E 98 10 04 F1 53 00 00 00 A6
7E 2F
7E D0
7E 71
7E F2
7E 53
7E 34
7E 95
7E 16
7E B7
7E 39
7E 1B
7E 00
7E A1
7E 22
7E 83
7E E4
7E 45
7E C6
7E 67 10 00 01 5E 3D 02 00 51 (altitude=1467)
7E 67 10 00 08 D0 BE 00 81 D6 (longitude=28.0434399)
7E 67 10 00 08 98 8B ED 40 95 (latitude=-25.9462795)
7E 67 10 40 08 60 3B 00 00 0C (heading =152)


These packets

7E 98 10 05 F1 01 32 0D 00 B8
7E 98 10 01 F1 53 00 00 00 A9
7E 98 10 04 F1 53 00 00 00 A6

contain rx specific information like rssi and rx voltage, and other sensors will also show up if present when polled by the receiver.

Pixhawk + APM v3.7.3 with Frsky Telemetry Output

Since writing the above, I switched one of my Pixhawks from PX4 firmware to APM v3.5.3, and enabled "native" Frsky telemetry output from serial port 4. To activate this feature set the SERIAL4_PROTOCOL parameter = 4 in Mission Planner, and take the serial output from the Pixhawk socket labeled "SERIAL 4/5" directly to your X model Frsky receiver through the electrical inverter/converter. On the ground side, take the telemetry out of the Taranis, through a similar inverter/converter and then to the Tracker. It works beautifully, and as a bonus you can display selected telemetry on the screen, as Taranis owners have long known.

Unfortunately PX4 does not seem to support Frsky telemetry at the time of writing. I found some old references to a project, similar to the APM/Ardupilot one, that seemed to work but was abandoned.

Of course you would no longer need the weight and complexity of the Mavlink/Frsky conveter aboard the craft.

Does it work with Pixhawk's FrSky Passthrough telemetry? I'm trying to get it worknig but I don;t know if my problem is S.Port converter connected to Taranis or just that type of telemetry is not supported. Beside that, I waited for a long time for FrSky tracker to appear... You made my dream real I appreciate your work so much
EDIT: I'm trying to use that type of converter - should it work? https://discuss.ardupilot.org/upload...3819013e50.JPG

Originally Posted by MacPiston

Does it work with Pixhawk's FrSky Passthrough telemetry? I'm trying to get it worknig but I don;t know if my problem is S.Port converter connected to Taranis or just that type of telemetry is not supported.

Hi MacPiston

The best information I could find on Frsky-Mavlink passthrough is here: http://ardupilot.org/plane/docs/comm...ssthrough.html

When you say "Pixhawk", I'm assuming you are running APM firmware on it. I'm not aware (yet) of frsky X/mavlink passthrough on PX4 firmware.

If anyone can point me at newer information I would be grateful. On that page there is a link to a spreadsheet which sets out the passthrough protocol data IDs and data types. See below:

The spec seems to leave out heading, or am I missing something? In order to track a craft from a home position I need

1. GPS co-ordinates
2. Relative altitude
3. Initial heading

The tracker is aligned with the craft's heading before take off, so the initial heading from the craft is essential. This seems an obvious omission, so expect it must be added at some point. The GPS data ID and structure is the same as the Frsky X protocol, so we will pick that up no problem. I could easily add in the other data types. ( I'm planning to reconstitute Mavlink out of the Taranis - but that's another project).

Originally Posted by MacPiston

I'm trying to use that type of converter - should it work? https://discuss.ardupilot.org/upload...3819013e50.JPG

I don't have any experience with that converter. I assume you have seen this diagram:

The "FUL-1" adapter seems to do the conversion/inversion, and the the "SPC" cable is just a diode to switch RX and TX onto a single wire for S.Port X. So I'm guessing that the diode on your TTL2RS232 board does the same, and it should work. But hey, I'm guessing. You need to persevere and see if you can make it work.

Yes, my converter is DIY version of those two Frsky cables. But the problem is that when I connect it to the back of Taranis, it says telemetry lost and... That's all. Oh, and the pass-through telemetry must be sending heading data, because I'm having it on Taranis screen when using lua telemetry script.