Servers by jDrones

Which mavlink messages in each data stream?

Hi, just wondering if there is a reference anywhere written to outline, which mavlink messages are contained in each data stream (I.e. those streams whose telemetry rates are controlled by the SRn_<stream_name> parameters)?

Thanks in advance, Paul

Most of the messages in each data stream are described in the Mavlink message spec:

The SRx_EXTRAx parameters specific to ArduCopter are summarized in the parameter list in the documentation.

Just realized you’re using plane firmware. For the most part, the EXTRAx groups are similar to the copter link above, but I’ve previously gone into the GitHub source to find the message definitions for Plane.

Many thanks James. I’ll document this for my future reference. I’m using both copter and Plane.

Actually I have one further question, as its not clear which stream the STATUSTEXT (msg #253) message belongs to. This is not mentioned in the MAV_DATA_STREAM section of the common messages page (first link sent by @jmack above), and in the Ardupilot complete parameter list (second link sent by @jmack above), it is not mentioned explicitly either . I can see that the AP parameter list shows EXTRA3 containing a HWSTATUS message but its not clear if this is the same thing as STATUSTEXT, and HWSTATUS does not appear in the mavlink common messages doc. So is this the same thing?

Thanks, Paul

STATUSTEXT is actually a unique case because it’s not part of any stream. STATUSTEXT messages are event based and come along when certain things happen, like autopilot initialization or waypoint crossing. I’ve used them in programs before but never felt quite right about it and usually found another way, because they’re human readable English I’m not sure they’re standardized, and if you miss one there’s no way to know you did.

What info were you looking to get from STATUSTEXT messages? There might be another source.

Not looking for anything specifically - I recently inherited a dev role for the MavLink_FrSkySPort teensy telemetry convertor project. I am just going through the code trying to make it more efficient and trying to spot any issues. I am not a dev by trade, so its taking me time to get a good understanding of the code. I have already applied a bunch of improvements and fixes, and from a -next branch (developed by another guy on the project) I have taken and integrated some code which listens for the STATUSTEXT messages and displays these on a dedicated LUA screen on the Taranis. It works to a point, but occasionally there is corruption in the message text. I’ve also done a tonne of changes to allow this project to integrate with the Ultimate LRS Tx/Rx and have the Teensy ground based now, feeding directly into the Taranis using sensor polling (and DIY Tx/Rx and antennas), so there are a lot of improvements to the teensy code - and also a re-design of the LUA telemetry screens also. Liknk is here if you are interested:

The reason I was asking about streams and messages belonging to them, is that the code sets up the stream rates, but only for three of them, and I have since added some additional telemetry to the code, so wanted to make sure I had all the required stream rates catered for in the rate configuration code. As ULRS means sharing a telem port between the Teensy and Mission Planner, I have only the MP connection with full bi-directional Mavlink, so the teensy only listens, so there is no way using ULRS to have the Teensy configure those stream rates anyway, so I have added a compile time option in the code to disable the stream rate config if that’s preferred. Mission planner configures these anyway with its bi-directional connection (over bluetooth).

Anyway, I’ve gone on enough! Thanks for the interest and response, and have a great weekend, Paul

Pretty cool stuff, Paul! I’ll be on the lookout for my next build when I want to get the telemetry data down to my Taranis. The Taranis is new-ish to me (been flying Spektrum and Futaba) so I haven’t assimilated its new capabilities yet.

I think for value for money, its unbeatable! The technical features are astonishing to be honest. I have been spoiled only ever having a Taranis since I took up this awesome hobby about 2 years ago. Its perfect for my gadget geekery too :slight_smile: Takes a bit of getting used to though - especially if you’ve been brought up on Spektrum and Futaba, and the build quality is a bit cheaper than those brands (well, I shoukd say that some of the components feel a lot cheaper than those but the actual build quality internally is actually not bad). There’s a ton of hacks for the radio also - beware though, I tried the antenna hack and it didn’t go well - 3 Tx boards later, I gave up and now use an external XJT module (and my home made ULRS module of course). I think the QC on the boards sold as parts might not be as good as on those which get fitted in the radios in the factory - either that or i"ve just been unlucky. The Rx’s are soo cheap though compared with Futaba, and the telemetry system is very good. Would recommend the FLVSS Lipo sensor - I have them in all my models and integrates nicely with the teensy which supplies all the other telemetry info. The 6 pos switch mod is definitely worth doing though - works well with a Pixhawk. Enjoy!

Another Mavlink library question if anyone still listening on this thread:

I want to pull out the AP version using the GCS_Mavlink library. I see I can call mavlink_msg_autopilot_version_get_flight_sw_version(&msg); (from mavlink_msg_autopilot_version.h), but wondered if this message (#148) is included in one of my existing streams, or do I need to request another stream to get this. Any idea which stream its in?

Or is there a way to easily check stream code to determine which messages are contained within? I appreciate the links sent previously in this thread do document some of the messages/streams but don’t think they necessarily give the full picture.

My hunch is that you need to request it. Logically it should be a one shot. ( I mean, if it isnt a one shot, that is crazy. I don’t need to keep knowing the software version!)
Here is the request message being decoded in ArduPlane

I think that is arduplane sending its version to Mavlink rather than it being decoded. I am looking at the way to obtain the version info from Mavlink. I believe the call I detailed is correct, but just need to know if that message #148 is contained inside a stream or if there is some other way I need to request that this message be sent.

So in more detail - I have a teensy listening to mavlink on a telem port of Pixhawk. I need to be able to determine the AP version in order that I can parse the correct status message set in my code. Just looking for a way I can determine the AP version - 3.3, 3.4 3.x etc?

Sorry, maybe I wasnt clear enough.

  1. from teensy send a message with id ‘MAVLINK_MSG_ID_AUTOPILOT_VERSION_REQUEST’

  2. in teensy, wait for a message with id ‘MAVLINK_MSG_ID_AUTOPILOT_VERSION’, then call mavlink_msg_autopilot_version_get_flight_sw_version(message) on the message.

There is no stream associated I would hope!, since the version doesnt change state at runtime

Thanks for the info. If my teensy is not talking to mavlink however, but only receiving data, then is there any way to get Ardupilot to include that in the message stream? If not, then is there perhaps any other way to determine if we are running AP3.3 or newer (maybe some new telemetry introduced in 3.3 I could check to see if exists)? I basically need to be able to see if AP is >=3.3 so I can line up status messages specific to the version. At the moment this is defined manually in the code - was hoping to automate it to allow ground based telemetry conversion - where there could be an array of different AP versions airside connecting via this one ground station. Thanks, Paul

I have never used Teensy, but apparently it has 3 serial ports, so
Connect your s.bus or whatever to your RcRx with first port
Connect TX and RX of the Teensy 2nd serial port to Pixhawk Telemetry.
Use 3rd serial port on the Teensy as your Pixhawk telemetry Port.
Sell this to users as a "smart mavlink cable"
You can inject your own custom messages either direction.

That’s not possible, as it is ground based in many instances - so is connected to the single serial port of the ULRS Tx board - so only a single Mavlink feed available, and this port is also shared by a BT module for connecting Mission planner - so the BT requires both Tx and Rx (for mission planner), leaving the teensy as only a receiver of Mavlink data in this configuration. Several users now using this setup so I was hoping for a configuration which would work for all applications (both ground and air based teensy). I think I might rig a physical switch where the user can choose between Mavlink versions - shame! Thanks anyway.

The Mavlink version or the Autopilot firmware version?
FWIW if you only want The Mavlink version, it is available in the heartbeat message I believe, which is always sent regardless

Anyway, its sounds like a very interesting project

Sorry, I am still referring to the AP version rather than Mavlink. The project is actually an old/well established one but I seem to be the one charged with progressing it :slight_smile:

My v2 dev repo here:

It looks very similar to one of my old projects where I used FrSky telemetry to send gps data to an antenna tracker:

At that time FrSky telemetry was ground breaking!
I used an Arduino Pro Mini to access the Mavlink data. I connected the Arduino TX and RX to the Ardupilot Mavlink port. Of course on the Arduino Pro mini you only have one serial port but it is quite easy to make a software uart for transmit only on the Arduino Pro Mini.
That TX only software uart was used to send the data to the FrsKy Telemetry receiver.
I used a Frsky DHT module in an old Futaba Tx (This was pre Taranis and pre Pixhawk). The telemetry data transmitted out of the Rc Transmitter to the tracker
The scheme worked very well and was very reliable. The only downside being the serial cable from Tx to tracker. I could probably have made a wireless link but decided to look at other ways to send telemetry.

Could do that serial Tx->tracker with a couple of BT modules now.

Forgot to say that in OpenTx 2.2 you can now send commands over telemetry link to the flight controller (or teensy/pro-mini). So definitely some good possibilities on the horizon. Being used for programming PIDs in some cases and also setting up VTx channels from a LUA script.

Servers by jDrones