Yeah I’ve read that, and like Allister, I note the circuit diagram and the fact that Telem1 is special → and have continued to run my RFD900x (or ux) from Telem1 BUT I do lower the output as Allister suggests.
I’m not dismissing that statement lightly without having considered all the factors in my situation.
On other flight controllers that have all ports supplied equally and in parallel, I’ve also powered an RFD900x (@ 27db) directly off the serial port, having considered the output of the power brick and the actual circuit diagram of the flight controller. I’m monitoring the Vcc too.
I’m lucky in a way, that my licensing or restrictions will never allow me to go BVLOS so there’s no chance of me testing the RFD limits and needing their full power, but people I know do that all the time and do use a separate BEC to ensure a full power RFD900.
Shawn, something interesting. I activated RTS CTS on the rf900 and noted it was active on the pixhawk parameter too. It would connect much slower. It would wait until the waiting for connection time went to 5 seconds before connecting. And then occasionally I would get mission planner freeze telemetry.
Took RTS CTS off both parameter and RF900 and now smooth. No delay in connecting either.
From my understanding RTS CTS is about sending incomplete packages of info? Is that right?
Note shawn i ended up turning off the SBAS satellites because you had said that might be an issue in another thread etc. It did reduce the satellites to 15 from 30, but again no difference.
I’ve seen that with establishing a connection too, but not in all cases, so I’m not sure exactly what’s going on. I didnt notice a big issue with the throughput once the connection worked, but I could be wrong.
The RTS/CTS means the devices wont blindly send data into space if the other end is not ready to receive it. It’s perfectly Ok to leave them off, just be sure to re-read any paramater changes or mission uploads to ensure changes where saved as expected - best to do this anyway.
The radio setting to avoid is the Op Resend - which is about trying to resend packets that had been missed or corrupted. Usually with our sort of data that is not important, as the packets will be replaced by updated data in the next fraction of a second anyway.
Hi Jeff,
There’s a couple of things I’ve found that I didnt see before, because I was looking at the serial port issues.
So now I see a few things that can be updated since you’ve gone through upgraded firmware versions.
Some of this will help, and some is just good practice for your flight controller:
@406FPV
When we did the original Pixhawk design, the telemetry port was designed to provide power to the 100mW 3DR radio. The Pixhawk 2 / Cube and many other autopilot designs have have carried this capability forward (and in some cases improved on it). 100mW was no problem, but then along came 1W radios and every once in awhile that is a problem.
The current spike during transmit can cause the power supply rail going to the microcontrollers in the autopilot to brown out. It is not the average current that is the issue. It is the spike during transmit that is the issue. If you have 1A continuous current draw and then you transmit on a 1W radio, some day, some flight, you are going to have a bad day. Similarly we see people powering too many CAN devices off the CAN bus or too many LEDs and causing brownouts.
There is no way to know how many ESCs or radios or GPSs or LIDARS somebody is going to try to power off of the autopilot. Meanwhile most people will not make the effort to test, measure, and ensure that their devices stay within the limitations of the autopilot 100% of the time across 100% of the temperature range and across 100% of their battery voltage, so a blanket statement “Don’t ever do this” is the safest option.
It is probably fine but it is up to you to demonstrate and ensure across the flight envelope that it is not a problem with your batteries and your power supplies and your wiring and your other devices.
Back in 2014 Patrick Koegler from KDE got mad at me because we did not provide a way to power his optically isolated ESCs from the autopilot. Like I told him then, I will tell you now “It is an autopilot not a power supply.”
First, I think I need to apologize to the OP for derailing this thread, but I think this is an important discussion.
Second, just to get this out of the way: I do take responsibility for my drone’s setup and configuration. If I learn anything significant one way or the other I will share those lessons with the community, but I won’t come back here blaming anyone for my own choices. Now on with the show…
Thank you @CraigElder for the explanation. It’s very useful to see how these controllers have evolved to the amazing systems we have today!
I take your point. And to a certain point I agree. It makes sense why things like the servo rail are un-powered. That’s not the roll of the flight controller.
But, the manufacturers have really muddied this.
On the Cube standard carrier board, the Telem1 port has a dedicated 1.5A filtered power supply. According to the docs, this is only for Telem1, so no other issues relating to the number of other serial or CAN devices connected.
The RFD radios claim ~0.8A max draw, at max power output. And they supply a wire harness that goes directly to the Telem port for data and power. (I will acknowledge the 900ux has a cable that splits out the power, but the latest 900xV2 is still shipping with the single cable)
I understand that those numbers are subject to tolerances and some variability but these are two quality manufacturers so I think it’s reasonable to expect that their specifications are acceptably “close enough”.
So as a consumer I see a 1.5a supply with a 0.8a max load. That’s a comfortable safety margin.
I totally take your warning regarding the CAN ports and remaining serial ports. If you plug the 900x into Telem2 or GPS2 you’re asking for trouble. And the warning should be more clear about the power for the CAN ports, especially as CAN devices become more common for the average user. Since all those other ports share a 1A supply that seems to me to be the bigger issue.
I think the warning could be a little more clear or should come with more explanation. “Don’t ever do this” sounds like it was written by a lawyer trying to wiggle out of a situation, and doesn’t address the current hardware configuration.
TLDR: Why spend the time and money for a dedicated 1.5a power supply and then say “Don’t ever do this”?
That’s an important detail if they did, but the RFD website does say peak.
Power Supply: +5 V nominal, (+5 V min, +5.5 V max), ~800 mA peak at maximum power
So I still feel the question is reasonable: If the cube has a dedicated 1.5A filtered power supply for Telem1, why should we never use it to power an 800mA peak device? What should it be used for?
