fixing slow param download over radios on Pixhawk

[Andrew Tridgell]

I've pushed some patches to enable flow control on the Pixhawk telemetry
UARTs. That fixes the slow parameter download over 3DR radios with
MissionPlanner.

Note that to get the full benefit of the changes you need to
enable RTSCTS on the 3DR radios. Unfortunately MissionPlanner doesn't
have a checkbox for that radio option at the moment. I've asked MichaelO
to add one.

Bill, if you have a 3DR radio setup tool in APM Planner then can you
add a RTSCTS option too?

Alternatively it could be called "hardware flow control".

Cheers, Tridge

[Peter Plischka]

Andrew, now the 3DR radio no longer works when it is only connected with TX, RX, GND +5 V.

I have no Telemetry on UART1 and UART2.
The use of RTSCTS is probably now default.

Peter

[Andrew Tridgell]

Hi Peter,

> Andrew, now the 3DR radio no longer works when it is only connected with TX,
> RX, GND +5 V.

right - if you make your own cables and don't use the normal pixhawk 3DR
DF13 6 pin cable with RTS/CTS then you will need to set the new
BRD_SER1_RTSCTS or BRD_SER2_RTSCTS options to 0 to disable the use of
hardware flow control. We're going to need some wiki docs to explain
this before any new releases.

Randy and I discussed what the default should be and thought that the
number of people who make their own DF13 cables for Pixhawk would be
small, so that smaller group of people would need to set a
parameter. Otherwise if we had it off by default we would need to get
everyone who does have the standard cable setup to set an option to
enable RTSCTS.

btw, is there some reason you don't connect all 6 pins to your 3DR
radio?

Cheers, Tridge

[Peter Plischka]

Yes, I understand.

I use home-built radio modules. They have no RTSCTS connection.
Many friends use Wi.232 modules. They also have no RTSCTS connection.

When RTSCTS option is the default, a lot of people are excluded.
I would leave everything as it was.

If it is documented in the wiki, we can always decide whether we want to use RTSCTS.

I was just surprised. I had flashed the latest version, drove to my airfield and had no telemetry.

Peter

[Peter Plischka]

Still forgot:

On the telemetry port 2 is usually only an OSD connected.
That have no RTS / CTS.

But, there must be another solution yet.
The first 150 parameter are transmitted very quickly.
Only the rest goes so slow.

Peter

[Andrew Tridgell]

Hi Peter,

I've now worked out a way to auto-detect if the RTS pin is connected and
working in software, so I've changed BRD_SER1_RTSCTS to be 2 by default,
which is interpreted as "auto". If it detects no flow control is
available it will disable flow control about one second after starting
up.

btw, if you really can't connect up hw flow control on your radio then
you could just disable ECC in the radio config. That will speed up
parameter download a lot. The slow download is largely a result of the
air rate with ECC being 32 kbps, whereas the serial port is running at
57.6kbps.

It is far better to use hw flow control however.

Cheers, Tridge

[Robert Lefebvre]

Tridge, do I understand correctly, that anybody experiencing this problem can go into the radio setup, and just disable ECC?  At least as an interim fix?

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Tridgell]

> Tridge, do I understand correctly, that anybody experiencing this problem
> can go into the radio setup, and just disable ECC? At least as an interim
> fix?

That will tend to reduce the problem, yes. Using flow control is better,
but disabling ECC will give more bandwidth (ECC chews half the
bandwidth) and that tends to reduce the problem.

Cheers, Tridge

[Peter Plischka]

Hi Andrew,

yes Autodedect sounds good.
I just disabled ECC. The transfer then takes on the PIXHAWK only about 2 sec. With ECC, it takes about 15 seconds

However, this corresponds not to the ratio of 32 kbps to 57.6kbps.
The long wait has yet to have a different reason.


Peter

[Peter Plischka]

Autodedect works for me, Andrew. This is a good solution.
 
Now not a few hundred people will be locked out.

Peter

[Andrew Tridgell]

> However, this corresponds not to the ratio of 32 kbps to 57.6kbps.
> The long wait has yet to have a different reason.

it is not a linear relationship. What happens is the internal buffer on
the radio overflows as parameters are being sent too fast from the
Pixhawk. This corrupts the packets and causes MissionPlanner to have to
do a bunch of inefficient retries. Disabling ECC just lowers the
probability this this will happen by making the buffer drain twice as
fast.

Cheers, Tridge

[Robert Lefebvre]

So disabling the ECC, does that have risks?  Could you have for example... uploading waypoints, and a significant error occurs?  Or changing PIDS during tuning?

Is is not possible to speed up the air rate at the expense of range?

How hard is it to hook up the flow control?  (Sorry for the newbie question, but I don't understand this part well).

Just trying to figure out if we can recommend something to new users that is a quick fix, but still safe, until we arrive at the final solution.

Thanks,

Rob

[Andrew Tridgell]

Hi Robert,

> So disabling the ECC, does that have risks?

It will reduce the percentage of packets that get through when you are
in a very noisy RF environment or right on the limit of the range of the
radio.

> Could you have for example... uploading waypoints, and a significant
> error occurs?

all packets are checksummed at the MAVLink level and at the radio
level. The difference with ECC is that if a small number of bits are bad
the ECC code can fix them and still deliver the packet. If bits are bad
without ECC then the packet is discarded instead. You still won't get a
bad packet through (to within the probability of the two CRCs).

protocols like waypoint upload have acks that ensure that lost packets
are resent.

> Is is not possible to speed up the air rate at the expense of range?

I chose 64kbps air rate as the default as I found that is the sweet spot
for these radios. Higher air rates reduce the range quite a lot.

> How hard is it to hook up the flow control? (Sorry for the newbie
> question, but I don't understand this part well).

If you use normal 3DR radios with their normal 6 pin DF13 connectors
then there is nothing more to do. You will get full flow control as soon
as you update your firmware.

If you build your own radios or cables then you need to hookup all 6
pins to get full flow control.

> Just trying to figure out if we can recommend something to new users that
> is a quick fix, but still safe, until we arrive at the final solution.

I think we've arrived at the final solution :-)

All existing setups should now work, plus people who do have flow
control cables (which is anyone who uses the standard cables that come
with the radios) will get the additional benefit of flow control.

Cheers, Tridge

[Andrew Tridgell]

> Autodedect works for me, Andrew. This is a good solution.

thanks for testing Peter, and also thanks for pushing for a better
solution to this!

[Peter Plischka]

No problem, Andrew.
Meanwhile, the solution runs on multiple PIXHAWKs without error.

Peter

[Robert Lefebvre]

So the fix is in trunk, and users will get it on the next update (might be a little while on Copter)?  But you need all 6 wires.   Disabling ECC is totally safe and is an interim fix, only effect being reduced throughput at the limits, but no risk of errors.

I got that right?

Thanks,

Rob

[Andrew Tridgell]

> Disabling ECC is totally safe and is an interim fix, only effect being
> reduced throughput at the limits, but no risk of errors.

yes, though the reduced throughput could be enough that you lose the
link from the GCS to the aircraft if you are in a noisy RF environment.

I normally fly with ECC off because it allows for higher telemetry
stream rates, and gives me more bandwidth for images over MAVLink. I set
the default of ECC=1 in SiK as it gives maximum range which is usually
more important for most users.

Cheers, Tridge

[Randy Mackay]

 

     Yes, I think that’s right.  It’ll certainly be a while until AC3.2 is ready.

 

-Randy

--