Replies to This Discussion

Permalink Reply by Tom in ON on April 2, 2012 at 9:52pm

Matt,

Did you fix the issue?  I have a similar problem

• ▶ Reply

Permalink Reply by Matt Palmer on April 2, 2012 at 11:49pm

Hi Tom,

No luck I'm afraid, still hangs at the same point. I emailed DIY drones and they suggested loading code via Arduino as a test. I haven't got round to it yet.

Am leaning towards a hardware failure as it initialized fine in the previous bench tests.

Cheers,
Matt.

• ▶ Reply

Permalink Reply by Tom in ON on April 3, 2012 at 4:32pm

Thanks to all others who also helped eliminate other potential problems.  The problem was that even though I read and re-read the instructions I did not notice that I need to uncomment that line in the APM_Config.h file. Didn't even notice that line at all. It took 3 minutes to get it all working.

 

# define CONFIG_APM_HARDWARE APM_HARDWARE_APM2
 

• ▶ Reply

Permalink Reply by Djalma C Jr on May 7, 2012 at 9:01pm

Hi all

 

Everything was working perfectly (5 months ago) and started to not connect more! I see that is a recent problem!

Can anyone help and set the cause of the problem? 

Thanks

• ▶ Reply

Permalink Reply by Jason Lyons on May 25, 2012 at 1:35am

Djalma, I'm getting the same problem.  I initially hooked up my APM1 awhile back, but didn't have any hardware to test it with.  Fast forward to today and now I can't even get APM planner to connect to it.  Granted some things may have changed with the software since I last tried to use it but not sure what I'm doing wrong (I'm following all the instructions).

• ▶ Reply

Permalink Reply by Jeffrey Knickelbein on July 10, 2012 at 12:38am

I have the same problem. I initially tried Series 1 XBee PRO modules, but I had trouble with the modem control lines. I have now tried Series 2 XBee (not PRO) modules at 115200 baud and 57600 baud and I can't get past the getParamList problem. When I connect via the Terminal interface on the APM Planner, all the comms seems to be working, although it does not decode the data. After I try connect and it fails, I see that some data does get through correctly because the AH changes if I tilt the APM2. I did all the X-CTU tests with the two modules and the range test works fine. This is the error message I get. It says the link is too slow.

I read on the Digi website that you need to specify the Destination Address for both modules to get the fastest response. I had trouble with the Coordinator delaying the data to the router. After I specified the destination addresses that fixed the problem.

It would appear as though the timeouts on sending data between the APM Planner and the APM airborne side is too strict. Maybe the XBee modules delay the data transmission too much before getting the response on the ground. I have tried various configurations on the XBee and is hasn't made any difference. Even the delay before transmission is set to zero.

• ▶ Reply

Permalink Reply by Mark Barbee on August 13, 2012 at 8:40pm

Recently I have had similar problems. Arducopter v2.7.1  / APM2 / Mission Planner 1.2.5

They occurred when I was trying to implement my OSD and wireless telemetry. All components are 3DR - 900mhz radio, MinimOSD 1.1 with MinimOSD_19_MAV10.

The "your serial link isn't fast enough" error would occur when I would try to connect via telemetry OR USB i.e. no connection possible. You must not have USB connected if you want to connect via telemetry but my telemetry was not connecting even when USB was disconnected. USB was not connecting when the telemetry was plugged to the APM2 in port UART 0/2. You can use one OR the other as they share the same port. The "Using the 3DR Radio for telemetry with APM 2" instructions direct you to use the multiplexed UART port 0/2 for your radio telemetry connection. I did this and connected my OSD to UART 0 (on the edge). As soon as I set it up this way the connection problems began. I spent a lot of time working through this and there were issues with "no heartbeat" on the OSD as well(you need to use the MinimOSD_19_MAV10 OR Arducam_19_MAV10 firmware with the v1.1 board).

The solution was to simply connect the OSD to UART 0/2 and the 3DR radio to UART port 0 (on the edge of the board). This combined with making darn sure (as another post mentioned) your baud rates are the same on the radios, Mission Planner, and in device manager in Windows will get you going.

• ▶ Reply

Permalink Reply by Jeffrey Knickelbein on August 13, 2012 at 11:45pm

I connected the XBee onto the port UART0 on the edge and hey presto it worked. I had a damaged pad on the UART0/2 solder pads after I removed a link which seems to connect to the edge connector. As you say, the MUX only allows one UART connection to the ground station at a time, with the USB one taking preference.

• ▶ Reply