Pixhawk RC Not Active Please Help, Won't Recognize RC Signal, Motor Spins Connected Direct to X8R

Hello again,

As I've yet to get much a response on previous post regarding a pixhawk which has the error code "Radio control not active", however it is most certainly active. as I can connect a motor to the 3 pin slot on my X8R and can sing the motor effectively.

Not to sound negative, but I'm really at my wits end with this pixhawk and its trouble some lack of response for an rc signal. I have this particular pixhawk in my X8 I require for mapping in the near future and it simply refuses to recognize an rc signal.  I have tested my frsky ppm encoder with no avail n'or will my 3dr ppm encoder. It did work previous to this with both the frsky sbus-ppm encoder as well as the 3dr ppm encoder.

I travelled with the auto pilot and upon attempting flight back in December after flashing the latest firmware at the time, it then would no longer recognize a signal? Its kinda disappointing considering my other pixhawks have worked perfectly out of box with the same exact setup without the need for any encoders but simply direct from sbus. 

I would hate to have it just sit on a shelf after the amount that Ive invested into getting it to work (ppm encoders, plus cost of all electronics such as gps ect...) and it hasn't ever worked properly. 

If any one would have advice on how to maybe test what may be occurring that would cause the pixhawk not to pick up a signal would be very very much appreciated, or perhaps anyone who may know how to trouble shoot the autopilot themselves (maybe an individuals in the toronto area?), as I require this particular drone in order to complete my research and would not want to spend to much more.

Thanks in advance for any advice, suggestions or feedback it is very appreciated!

Craig P. 

Views: 3987

Replies to This Discussion

Hi there,

we've recently had the same problem like the thread opener. After the update to arducopter 3.2.1 there was nomore PPM-input signal visible in Mission Planner. We've contacted 3DR support and asked them to replace the board.

- We tried different PPM receivers with this problematic Pixhawk (no solution of the problem)

- We tried all receivers on another Pixhawk (cross-check) - all reaceivers work just fine

- We tried to flash Arduplane and Arducopter again in order to clear all memory (no solution)

- We tried to use the Standard_RX-to-PPM Converter... (no solution)

Finally we contacted 3DR support and asked them to replace the PCB. They refused to do so... Anyhow they suggested we should try the following:

- Flash Ardurover (YESS!!! PPM works in Ardurover, so there is obviously no hatrdware issue)

- Flash ArduCopter 3.1.5 (YESS!! PPM works as well!)

- Flashing any newer version than ArduCopter 3.1.5 will result in PPM not working

Dear fellows: Seems like a specific hardware revision of the Pixhawk PCBs is not compatible with the lastest firmwares. Because 3DR specifically suggested to install 3.1.5 they certainly seem to know about that issue but they are not willing to admit that there is a problem with ther hardware/compatability. 

That is really really poor focus on customer satisfaction. :-(

Hope the post helped some people to recover their "broken" pixhawks with an firmware old as the hills.

Cheers!

careyer

my pixhawk  is working fine on 3.2.1 

i have 2 quads one with PPM 3DR RX-to-PPM Converter and the other one is by frsky S-bus to ppm port

fred... obviously only specific board revisions are affected. Most Pixhawks work fine with the latest software unless you have bad luck and have one of those intermediate board revisions (2.3, 2.4, 2.4.3, 2.4.5... don't know for sure yet which revision exactly is affected) on the way to the final revision 2.4.6

For a reference take a look here and see how many different board layouts for the same pixhawk exist:

https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPX4%2FHardw...

I'm not sure if I should be happy to see this thread expanding but at least we are drawing more attention to the game 3DR is trying to play.

Seems the better choice, for business, is to move on to one of the more advanced, US produced FC like FixHawk, CUAV, PixHack, etc.    PixHawks are produced in MEXICO

I would prefer not to use FC like Naz. 

Can you guys please post successful RC TX/RX systems that are compatible with Pixhawk?

Hi @careyer, I no longer see these post cause I'm no longer a part of the pixhawk group, as I have gotten out of the pixhawk based systems...

However after a year with the faulty board and constant emails debating the issue with 3DR, it was a terrible nightmare I must say (especially when I first got the faulty board when the pixhawk was originally released and none of their engineers could say for certain if sbus should work or not with frsky receivers), but in the end they replaced the pixhawk (not without taking a month or two to do so, but after a year of already waiting it didn't matter at that point I guess).

I had several other pixhawks over the years since its release and they've all worked fine, unlike the one in question that had the issues, so this could definitely be the indicator that throughout the life of the pixhawk the changes been made to internal parts (sensors, supplier,layout, ect..) without acknowledging the effect of the differences, which could have resulted in this variation in hardware compatibility...Although it seems sort of shady to change the internal design without indicating (labelling) such in some way (pixhawk 1.1 perhaps to pixhawk 1.2?)....

3DR support doesn't seem to be to knowledgeable, but rather a call centre relaying communication between the consumer and the company, since they never seem to have an answer.......which makes the whole process more frustrating than anything.... 

So perhaps continue to communicate with support, and maybe you'll find an individual who will offer to test it at the very least (since its highly doubtful they'll admit fault)....

Best of Luck...

I have once more contacted 3DR support and told them, that obiously there is a problem/incompatibility 3DR knows of but does not want to admit. Otherwise the 3DR support engineer would not have been able to tell me spot on the last version of ArduCopter (3.1.5) that will work (in all newer versions >3.1.5 PPM-input will fail).

They just told me that my Pixhawk is out of waranty and they wont replace it. Very very poor customer support man! They know that there is an issue with specific boards but still do not want to take responsibility.

I investigated a bit further into this issue and found out that Pixhawk has two separate CPUs ...the main CPU and an I/O coprocessor. When using 3.1.5 firmware (which works) there are no error messages in the logs. When updating to a newer version a log file will be written to the SD card claiming "IP4IO error, IP4IO start failed". This IO-co-processor is usually flashed together with the main CPU when updating the firmware but obviously this update-process fails on newer versions of the firmware. There is also a PX4IO.bin file on the SD card which is usaually written to the processor and then deleted from the card.


See the coincidence? No working I/O co-processor --> no PPM-Input! Trying to find a way now to get that PX4IO.bin file into that processor right now!

@Careyer, yeah I've pretty much given up on 3DR....I'm currently awaiting a response from Vu about seeking a refund for my Solo if they cannot overnight me a gimbal, since I'm beyond unsatisfied and frustrated in waiting for a gimbal, since its virtually useless without one (I think 4 months of waiting with a 2000$ closet ornament its time to draw the line)....I emailed Vu yesterday so hopefully he responds today, if not then I will escalate this further, since they have no choice but to honour their satisfactory/unsatisfactory promotion (especially after their consistent false claims throughout the Solos launch).

Their actions are seemingly becoming more and more shady as time goes on and I can't see how a company can continue to operate this way without it eventually having negative repercussions (legal, loss of customer base, ect...)

They originally said that to me also, so I set it aside for months and bought several others, then looking at this bricked pixhawk sitting there one  day I decided to continue to go after support (new support people) on the issue till they finally gave in and offered to test it (actually at first they offered me 10% discount on a new one which I basically laughed at the guy over, because the exchange rate from USD to CAD alone is more than 10%, so it was more of an insult that anything). However I did have to pay for shipping costs to get the broken pixhawk to 3DR. At which point it took another month or two to respond saying it is dead and they'll send me another when they get more (which took even more time).

I should also note that I did record a video showing all possible hardware tests and many software tests to show that it is the unit and that it worked prior, so they could not deny the cause and effect (update incompatibility), also emails since first having the issues, so they could not say I never tried to contact them when it first happened.

Many of 3DR consumers can be found here and 3DRpilots, so they tend to shy away from negative discussions regarding their actions, so making more people aware of the issues may encourage them to also take better action and be helpful.

Sorry I can't be more helpful with the software side of things, as thats definitely not an area I excel at, however thats good you have determined such, so perhaps it is the co processor itself that has been change (new brand or different model) that is not compatible with the newer code. Perhaps some changes made to the bulk of the code in order to make way for newer features is causing the co processor to fail?

Another option could be to swap out the sd card for one of a greater flash rate to see if that has any effect? I know in the original pixhawk batch they had sd card issues with the cards not being as capable as required. I did change sd card to a go pro rated card and it did have a some positive effectt, although I don't think it was the only or primary solution to the problem.

Hope you get this resolved!

Best of Luck,

Craig.

SBUS is always enabled and always Ch 1-16. The binding process you refer to determines how the PWM outputs to the normal pins are allocated.

Short update: The co-processor was indeed the problem. When flashing new firmware both the main-processor and the co-processor get updated. Somehow the updated for the co-processor failed resulting in a broken RC-input. Flashed the co-processor seperatly and everything is fine. Hoeever 3DR was not a big help here. The bastards knew where the problem was and did not tell me. GRRRR!!!!

Hello

I have the same problem. How do you flash the co-processor separately?

Thanks

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service