Replies to This Discussion

Permalink Reply by Vernon Barry on April 29, 2012 at 5:26am

Chris, My experience and several others is IDENTICAL to Muthanna's. I have 2 boards. One from the very first batches of APM 2.0s and then one that just came. I actually bought the second one because of this problem on the first one and was worried I somehow damaged the board, but because I discovered the workaround of using the other port and at the time, the extremely long backlog of APM 2.0 boards made me not want to send the board in since it still worked. So to say I was a little POd to find the new board did the exact same thing, and then further, I'm not alone and that at least 5 to date in the last few weeks had the same problem. So unless you want to see these boards coming back and ticked off people, I would at least mention the workaround port. I think most of us just want to fly, and this isn't a showstopper, but not having wireless telemetry and not knowing the troublshooting is making the new guys extremely frustrated. In other words, there are a lot of things to set up to get wireless coms, and a bad port with no alternate instructions leaves those guys in the dark.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on April 29, 2012 at 8:20am

Vernon: If you have a defective board, please return it for replacement. You can get a RMA by emailing help@3drobotics.com

Before I do, can you confirm that you definitely don't have the USB cable plugged in when you're testing this? Sorry to ask the obvious question, but I didn't see you mention this in your comments above.

I've we've tested dozens of boards and never seen this problem, so I'm mystified by what it might be. If you can return the board, the engineers can look at it and see if they can find the issue, to ensure that the QA process can catch it going forward.

I'd much rather catch it at the source than further complicate the manual, especially if we can make this unnecessary going forward.

• ▶ Reply

Permalink Reply by Grant Olivier on May 2, 2012 at 5:04am

I just want to get this straight as well regarding the mapping of serial ports on the APM2 (V 2.4.1). Can someone confirm the following:

Description; Label on Board; Physical position on PCB; Mapping in source code

USB/FTDI; None; USB connector below SD IF;  FastSerialPort0(Serial):  #define xxx_PORT 0 

GPS Port; UART1; Next to IN1; FastSerialPort1(Serial):  #define xxx_PORT 1 

Telemetry Port (When USB not connected); UART0/2;  Next to OUT8; FastSerialPort3(Serial);  #define xxx_PORT 3 

Telemetry Port (Hardwired); UART2; Side of board next to RESET; FastSerialPort3(Serial);  #define xxx_PORT 3

Why would the telemetry port (either UART0/2 or UART2) not be named  a logical FastSerialPort2(Serial); #define xxx_PORT 2?  

• ▶ Reply

Permalink Reply by Karl on May 23, 2012 at 4:51pm

My 2.4.1 board appears to have no micro traces in place (I have a second that is identical with no traces) and the UART does not work. Can connect with USB and flies fine, have a separate issue with the TX/RX LED's that I think may be related. Can you include within the WIKI a good high resolution image of the PCB's so that all the relevant default micro links are visible ? I have a feeling I have to solder a few back in....

• ▶ Reply

Permalink Reply by Muthanna A. Attyah on June 14, 2012 at 10:42pm

Just to update on this issue, I purchased a new APM2 board (2.4.1) and it was working out of the box without any issue. I kept using UART0 instead of UART0/2 on my old board. Here is a photo of my new board on testing mat :)

 

• ▶ Reply

Permalink Reply by Ahmed Hassan on August 16, 2012 at 12:51am

OK, after i was able to establish a link via the hardwired UART0 port, now i just can't. I wonder WHY. it was able to fetch parameters then eventually fail due to (link isn't fast enogh), but i thought it would work using full battery and ESC power as stated by some other client. Now, it won't connect at all!! I even soldered the UART0/2 MUX, but with no success!!

PLEASE, HELP !! and can anyone explain a workaround or a procedure to follow to detect where the failure is ? and what about the failed MUX problem i read in another thread ?! 

• ▶ Reply

Permalink Reply by Ahmed Hassan on August 16, 2012 at 1:35am

OK, it worked again via the hardwired UART0 only. and by reversing the TX and RX>>>>>>>>>>> WTH ?!

• ▶ Reply

Permalink Reply by AS on January 29, 2013 at 4:48pm

Hi Ahmed!

did you flip any switch in your board? like a master to slave switch? those have tendency to reversing the TX and RX!

• ▶ Reply

Permalink Reply by AS on January 29, 2013 at 4:51pm

Hi Guys!

I'm having the same problem as you! The Uart0/2 stopped sending data to my xbee! I haven't tried the UART0 solo... If that does not work do you have other solutions?

I'm also having some sort of problem when loading a new firmware, when verifying it gives me a strange error, something related to the port not being found or in use, I am not sure! Tomorrow I will post a picture.

Best Regards,

AS

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page