APM P2 Messes up Taranis / Teesny Lua script in 3.3

I’ve been having an issue with my Taranis lua script. It would misbehave by giving continuous incorrect verbal notifications …but I stumbled on the fact it only does so when connected to APM P2. Connecting to another GCS or just the 915 mhz radio doesn’t duplicate the issue but once connected to APM P2 it does.

Note it didn’t do this with copter 3.2 but now does with 3.3 so I don’t know what the heck that means. But hopefully copter devs and APM P2 devs can work it out for us Mac guys. Seems like it’s changing the SR params that don’t play well with the lua script I’m using. Which is a rather popular one from Peter King at Droneshop.biz
These are the SR settings that do work well. settings SR1 Extra 1,2 and 3 get changed when APM P2 connects… might be others but I know of those for sure…
SR0_EXT_STAT,2
SR0_EXTRA1,5
SR0_EXTRA2,5
SR0_EXTRA3,3
SR0_PARAMS,10
SR0_POSITION,3
SR0_RAW_CTRL,0
SR0_RAW_SENS,5
SR0_RC_CHAN,0
SR1_EXT_STAT,2
SR1_EXTRA1,6
SR1_EXTRA2,6
SR1_EXTRA3,1
SR1_PARAMS,10
SR1_POSITION,2
SR1_RAW_CTRL,0
SR1_RAW_SENS,1
SR1_RC_CHAN,2
SR2_EXT_STAT,2
SR2_EXTRA1,5
SR2_EXTRA2,5
SR2_EXTRA3,3
SR2_PARAMS,10
SR2_POSITION,3
SR2_RAW_CTRL,0
SR2_RAW_SENS,5
SR2_RC_CHAN,0
SR3_EXT_STAT,0
SR3_EXTRA1,0
SR3_EXTRA2,0
SR3_EXTRA3,0
SR3_PARAMS,0
SR3_POSITION,0
SR3_RAW_CTRL,0
SR3_RAW_SENS,0
SR3_RC_CHAN,0

Great find. Which telemetry ports are the AP2 and Teensy/Taranis connected to on the board?

Teensy is in telem 2. Is it worth while to switch the radio and teensy to see if the problem goes away? Not hard to do I will do that in the next day or so I guess. Thanks Randy.

you can set ‘custom’ telemetry rates in AP2

It should cause the telemetry to fail for the teensy, unless it can’t handle the changes correctly.

[attachment=0]TelemetryRates.png[/attachment]

[quote=“billbonney”]you can set ‘custom’ telemetry rates in AP2

It should cause the telemetry to fail for the teensy, unless it can’t handle the changes correctly.

[attachment=0]TelemetryRates.png[/attachment][/quote]

Sorry Bill guess I’m not %100 sure what you mean…

In the params there are the SR settings… is SR0 the telemetry 1 on the pixhawk and SR1 the telemetry 2 on the pixhawk? If so…I see the extra 2 and extra 3 there in the AP2 screen dump you posted… so if my teesny is in telemetry 2 would I set those to 6 and 1 respectively as referenced in the SR settings below?
SR0_EXT_STAT,2
SR0_EXTRA1,5
SR0_EXTRA2,5
SR0_EXTRA3,3
SR0_PARAMS,10
SR0_POSITION,3
SR0_RAW_CTRL,0
SR0_RAW_SENS,5
SR0_RC_CHAN,0
SR1_EXT_STAT,2
SR1_EXTRA1,6
SR1_EXTRA2,6
SR1_EXTRA3,1
SR1_PARAMS,10
SR1_POSITION,2
SR1_RAW_CTRL,0
SR1_RAW_SENS,1
SR1_RC_CHAN,2
SR2_EXT_STAT,2
SR2_EXTRA1,5
SR2_EXTRA2,5
SR2_EXTRA3,3
SR2_PARAMS,10
SR2_POSITION,3
SR2_RAW_CTRL,0
SR2_RAW_SENS,5
SR2_RC_CHAN,0
SR3_EXT_STAT,0
SR3_EXTRA1,0
SR3_EXTRA2,0
SR3_EXTRA3,0
SR3_PARAMS,0
SR3_POSITION,0
SR3_RAW_CTRL,0
SR3_RAW_SENS,0
SR3_RC_CHAN,0

I think you LUA script can’t handle the higher data rates for EXTRA1 i.e. Attitude and EXTRA2 in the Advanced Config section of AP2. Change it from 10 to 5 and see if that helps.

BTW this is not an issue per se with AP2, but the teensy board. It should be able to gracefully handle this, or send it’s own RequestDataStream message requests for what is required. AP2 has to do this periodically otherwise other device interfere with AP2 and data stop coming in (it’s only an issue when GCS and Teensy share the same com (serial) port)

[quote=“billbonney”]I think you LUA script can’t handle the higher data rates for EXTRA1 i.e. Attitude and EXTRA2 in the Advanced Config section of AP2. Change it from 10 to 5 and see if that helps.

BTW this is not an issue per se with AP2, but the teensy board. It should be able to gracefully handle this, or send it’s own RequestDataStream message requests for what is required. AP2 has to do this periodically otherwise other device interfere with AP2 and data stop coming in (it’s only an issue when GCS and Teensy share the same com (serial) port)[/quote]
Thanks Bill

[quote=“billbonney”]I think you LUA script can’t handle the higher data rates for EXTRA1 i.e. Attitude and EXTRA2 in the Advanced Config section of AP2. Change it from 10 to 5 and see if that helps.

BTW this is not an issue per se with AP2, but the teensy board. It should be able to gracefully handle this, or send it’s own RequestDataStream message requests for what is required. AP2 has to do this periodically otherwise other device interfere with AP2 and data stop coming in (it’s only an issue when GCS and Teensy share the same com (serial) port)[/quote]

Still no go. I reduced extra 1 and 2 to 5 and it still does it. It does it with iDrone Control too but not with Tower. So I agree it’s not APM P I just don’t know what it is :frowning:

It has nothing to do with APM 2.

Go back to where you bought the Teensy and ask them to provide a solution.

Sorry if I seem harsh, but my name is on the script that runs on the radio, and also on the software that runs on the Teensy, although I wasn’t asked/informed of that.

That project was developed with a specific target which was OpenTX 2.0.x and Copter 3.2.1.

I’m sorry for being the bearer of bad news.

[quote=“govsux”][quote=“billbonney”]I think you LUA script can’t handle the higher data rates for EXTRA1 i.e. Attitude and EXTRA2 in the Advanced Config section of AP2. Change it from 10 to 5 and see if that helps.

BTW this is not an issue per se with AP2, but the teensy board. It should be able to gracefully handle this, or send it’s own RequestDataStream message requests for what is required. AP2 has to do this periodically otherwise other device interfere with AP2 and data stop coming in (it’s only an issue when GCS and Teensy share the same com (serial) port)[/quote]

Still no go. I reduced extra 1 and 2 to 5 and it still does it. It does it with iDrone Control too but not with Tower. So I agree it’s not APM P I just don’t know what it is :frowning:[/quote]

What happens when you set all of them to 1. It won’t matter is just means all messages are sent 1 a second.

That can still be 30 messages in that second.

It does the same thing. So… I’m thinking maybe some file/s on my Taranis is corrupted or something. In any event it isn’t because of APM P I guess so I’ll mark this as solved… sort off. Now that 3.3 is the official release and we don’t seem to see a widespread telemetry issue like I’m having I guess it’s safe to say it’s something odd with my Teesny or lua script or something.

[quote=“luisvale”]It has nothing to do with APM 2.

Go back to where you bought the Teensy and ask them to provide a solution.

Sorry if I seem harsh, but my name is on the script that runs on the radio, and also on the software that runs on the Teensy, although I wasn’t asked/informed of that.

That project was developed with a specific target which was OpenTX 2.0.x and Copter 3.2.1.

I’m sorry for being the bearer of bad news.

[quote=“govsux”][quote=“billbonney”]I think you LUA script can’t handle the higher data rates for EXTRA1 i.e. Attitude and EXTRA2 in the Advanced Config section of AP2. Change it from 10 to 5 and see if that helps.

BTW this is not an issue per se with AP2, but the teensy board. It should be able to gracefully handle this, or send it’s own RequestDataStream message requests for what is required. AP2 has to do this periodically otherwise other device interfere with AP2 and data stop coming in (it’s only an issue when GCS and Teensy share the same com (serial) port)[/quote]

Still no go. I reduced extra 1 and 2 to 5 and it still does it. It does it with iDrone Control too but not with Tower. So I agree it’s not APM P I just don’t know what it is :frowning:[/quote][/quote]

Just to satisfy my own curiosity can you tell me in basic terms why does the script work in 3.2.1 but not in 3.3 if connected to a GCS? Thanks

I’m only referring to OpenTX 2.0.x.
The script is NOT the only part that is responsible for the telemetry on the Taranis. In fact is the dumbest of the 2 parts of the solution.

The part that is running on the Teensy does all the heavy lifting.

A common issue with Copter 3.2.1 was that the telemetry wouldn’t be sent to a specific port, because the Teensy doesn’t “request” for that to be sent. When the Teensy is in the same port as a telemetry radio, the GCS requests data to be sent (with the frequencies set by the SRx parameter) and so the Teensy also picks up that data stream. If the Teensy is alone in a telemetry port the SRx parameters come into play and must be enabled (or on Mission Planner go to the OSD configuration and manually enable OSD).

On 3.3 several things have changed on the messages that are sent on the telemetry stream, and the program running on the Teensy does not know about this, so either sends gibberish to the radio, which in turn the script won’t understand, or send anything at all. When using OpenTX 2.1.x there’s an additional problem with the new telemetry system that started with 2.1, but I won’t go into that now.
Also the serial ports on 3.3 are more versatile and can perform several functions other than GCS telemetry, and must be correctly enabled and configured.

On one of my PixHawks I have both the Teensy and telemetry radios on different ports and working perfectly.

Basically, if you want to keep using that system for the telemetry on the Taranis, you’ll have to either stick with Copter 3.2.1 and OpenTX 2.0.x or ask to the vendor to provide a solution.

[quote=“luisvale”]I’m only referring to OpenTX 2.0.x.
The script is NOT the only part that is responsible for the telemetry on the Taranis. In fact is the dumbest of the 2 parts of the solution.

The part that is running on the Teensy does all the heavy lifting.

A common issue with Copter 3.2.1 was that the telemetry wouldn’t be sent to a specific port, because the Teensy doesn’t “request” for that to be sent. When the Teensy is in the same port as a telemetry radio, the GCS requests data to be sent (with the frequencies set by the SRx parameter) and so the Teensy also picks up that data stream. If the Teensy is alone in a telemetry port the SRx parameters come into play and must be enabled (or on Mission Planner go to the OSD configuration and manually enable OSD).

On 3.3 several things have changed on the messages that are sent on the telemetry stream, and the program running on the Teensy does not know about this, so either sends gibberish to the radio, which in turn the script won’t understand, or send anything at all. When using OpenTX 2.1.x there’s an additional problem with the new telemetry system that started with 2.1, but I won’t go into that now.
Also the serial ports on 3.3 are more versatile and can perform several functions other than GCS telemetry, and must be correctly enabled and configured.

On one of my PixHawks I have both the Teensy and telemetry radios on different ports and working perfectly.

Basically, if you want to keep using that system for the telemetry on the Taranis, you’ll have to either stick with Copter 3.2.1 and OpenTX 2.0.x or ask to the vendor to provide a solution.[/quote]

AHHHHHHHHHH Finally I get it!!! [ well sort of ha ] Only took 4 months!!! Thanks for the detailed answer!!!

I will ask the vendor for a solution. He said it works fine on his copter with 3.3 but he must not have tried it with a GCS telem radio at the same time. Does it matter which is in which telem port on the pixhawk or is that irrelevant? Probably not I’m guessing. When it’s all working it sure is slick. I can’t see ever flying without the taranis telemetry it’s so much info right there in your hands I really don’t feel comfortable flying without it anymore. Thanks again.

I would recommend a laptop or a tablet, or even a Smartphone running either APM Planner or Tower to have telemetry in a proper way. I bought a cheap Android tablet with a stand attached to my Taranis.

The purpose of the system with the Teensy began as a basic telemetry system that could replicate at least the same parameters as a OSD could provide. The fact that some basic telemetry is on the radio is just a duplication of the GCS that is more suited to the way I use the drones.

Any external solution like the Teensy and the various OSD’s is always following the evolution of Copter, and usually something breaks from major version to major version, until someone comes along and does the required changes. On top of that the Teensy has an additional problem that also has to handle changes on OpenTX, so the Teensy must shoot to two targets, that have different release schedules…

I’m involved, with some other enthusiasts, on bringing the original solution to do as much as it did before with Copter 3.3 and OpenTX 2.1.x, but it’s not finished yet.

Regarding the comment that is working with 3.3 I sincerely doubt that, just as a small example, try to engage flight mode 17 (called Brake) on APM Planner and see what happens :slight_smile: on the Taranis :slight_smile:

edit: regarding the port. Just to make it easy for you, try to have the Teensy in parallel with the telemetry radio and better to use Telem1 port. If not viable just plug the Teensy on Telem2 and set the appropriate parameters on the Full Parameter List.

[quote=“luisvale”]I would recommend a laptop or a tablet, or even a Smartphone running either APM Planner or Tower to have telemetry in a proper way. I bought a cheap Android tablet with a stand attached to my Taranis.

The purpose of the system with the Teensy began as a basic telemetry system that could replicate at least the same parameters as a OSD could provide. The fact that some basic telemetry is on the radio is just a duplication of the GCS that is more suited to the way I use the drones.

Any external solution like the Teensy and the various OSD’s is always following the evolution of Copter, and usually something breaks from major version to major version, until someone comes along and does the required changes. On top of that the Teensy has an additional problem that also has to handle changes on OpenTX, so the Teensy must shoot to two targets, that have different release schedules…

I’m involved, with some other enthusiasts, on bringing the original solution to do as much as it did before with Copter 3.3 and OpenTX 2.1.x, but it’s not finished yet.

Regarding the comment that is working with 3.3 I sincerely doubt that, just as a small example, try to engage flight mode 17 (called Brake) on APM Planner and see what happens :slight_smile: on the Taranis :slight_smile:

edit: regarding the port. Just to make it easy for you, try to have the Teensy in parallel with the telemetry radio and better to use Telem1 port. If not viable just plug the Teensy on Telem2 and set the appropriate parameters on the Full Parameter List.[/quote]
I really appreciate your response I think I get the idea whats wrong with the script I’m using. No big deal I’ll wait until all that gets sorted out thanks for your input into the fix. I had no idea until you pointed it out that it’s a multi issue problem so it needs a multi issue [ Teensy, Taranis, copter 3.3 ] solution.

I know what you mean about a legit GCS but… I will just say one of the biggest reasons I like the teensy / Taranis telemetry solution is the fact I can see it so good. I too have bought killer tablets only to be disappointed I can’t see the damn thing outside on a bright day. The Tarainis is… old school LCD??? screen??? I can see the darn thing evening bright sun. There is a reason the Taranis is so popular. I’m a big fan myself. The teensy telemetry makes it rock even more.

[quote=“luisvale”]

edit: regarding the port. Just to make it easy for you, try to have the Teensy in parallel with the telemetry radio and better to use Telem1 port. If not viable just plug the Teensy on Telem2 and set the appropriate parameters on the Full Parameter List.[/quote]

My teensy is not in parallel it’s simply in telem2 I have 3dr radio in telem1 :]
Thanks for your help :]

Problem solved… this was the solution

The solution, in part, was to cut the TX wire OUT of the Teesny going to the RX of the Pixhawk