The uart 0 is switched between the usb and the telemetry port if you see the data stream at the serial 0 but not usb
it may be the usb circuit is bad . When usb is not pluged in the baudrate is switched to 38400 baud and you can run the CLI through the serial port. This is the fix for apm2's with broken USB connectors that were beefed up in 2.5
It will not have the reset function so MP firmware update does not work and you will have hit reset button to get arduino to upload
The switched baudrate is 57600 not 38400
You can connect mission planner ( mavlink) on the serial 0 as well . Change the speed in MP next to the connect button to 57600. You could also edit the serial 0 speed in arduino to someting slower and use the USB , it could have someting to do with the pc your running MP on .
Thanks for the info John.
I've tried connecting with USB on three different computers and I had the same result.
- Macbook Pro - running Vista under parallel
- Macbook Pro - running XP SP3 under parallel
- Acer notebook - running XP SP3
I will try the serial 0...
I had a similar issue that has taken me 2 days to solve. I think I have found the bug that causes this. I will need to give a brief history because the answer is not something I can give as a step by step fix. You will need to frig around until you find the exact sequence that works for you. I will need to write what looks unrelated at first.
First is that I have 2 APM2's
One is my quad but is a few firmware releases back because I had no time this summer to work on it..
Second board is for my airplane but has gone unused since I received it back at the beginning of 2012. So the firmware is very old and factory default.
It was this second airplane one I decided to build as a test stand for testing peripheral hardware/software with. It would not communicate with the CLI or mission planner. In the CLI it said the port comm 3 was open, but would not respond to any commands.
After messing around for hours, I opened windows device manager I checked that the board was recognized and went into admin properties and saw I could interrogate the board hardware ID# etc. From there I decided to change the port from comm 3 to unused comm 7 and also 10.
Back in MP I opened the command box to see the details when I hit connect comm 7. Suddenly it began giving me at least the board ID comm etc but error and timeout filled connections At least now the board identified itself. Now I went to the CLI and still keeping the mission planner command window open I could see it identify itself and in the CLI now I got the test list. The test list was not working 100% but would send and receive the test results along with some random garbage.
Progress finally. Bur try as I might that was as good as it got. So at this point I decided to try my quad APM2. I got very similar issues with it but not an exact match on behaviour. This lead me to believe there were two important variables. Different versions of the mission planner and different versions of APM firmware. So my conclusion was to play around until I could get it to communicate on a comm port long enough to upgrade the firmware.
Now this is why I can't give anyone a step by step fix. I don't know the exact combination. The important part is to keep the command window open so that you can see what responds and what doesn't line by line. All I can say is through the CLI, I was able to get the firmware on the APM upgraded and put it back on comm 3. Now everything works like it should and the clue I got was using windows device manage to interrogate the board to ensure it worked at that level first first. Next was in keeping open the command window in the MP and comparing the lines responding back from my 2 APM's that had very different revision levels. making sure the usb/comm hardware got reset and the values you test with stuck.
I got similar results using uart0.
Occasionally the connection work and I manage to get most of the parameters but it always end with a comm error message...
I also have an APM 1 which work just fine so I doubt that the problem is related to my computers...
Any other idea?
This APM 2.5 is about to do his maiden flight ...by the window.
So on the serial 0 at 57600 baud you had the same problem ? You could edit the Speed down to like 300 and literally watch each parm sent.
I take it that you are loading with arduino with no problem ? if that works at 115200 sending over 128k and reading it back to verify it one would have to think the apm is ok.
Have you tried older versions of Mission planner or the latest I do not know if their is something different for the 2.5 board, I imagine you are pretty fustrated by now have you asked about a RMA for the board
I got an RMA for the board. Because I could not read the IMU using CLI, it seems there might be something wrong with the IMU. So after sending it back I am still waiting on a reply of what happened to it.
I've since my last response. I've discovered that for some reason the low numbered comm ports are erratic. Sometimes they work and other times they don't. Even though they show to be available something just isn't right. Since I moved to using port 8-10-16 etc., I haven't had this problem.
First is this is on my laptop and later I'll make my point on saying this.. Now this isn't a total fix but it certainly for me removes one point of failure. The second regarding the port baud rate is still causing problems. I have only had 100% success by using 57600 baud.
Because I have two sets of everything. I can confirm that if you are beginning with old firmware and trying to come up to the latest, that you must begin with 9600 baud. No matter how many times I reset and begin the process again, it is not stable with anything but 9600. Once I update then 57600 is solid. For me at least.
I suspect that it is possible that some issues are dependant on the computer you have. For my laptop I used Win7. My early suspicion is that hardware timing of the comp you use does have an effect on stability. I think it is more important than the OS. My other comp is completely different from hardware to the OS and I get completely different errors. But doing what I did with the laptop and I get the same success. This is why with the baud rate change and port number used, changes results and degree of success or failure. That's why I'm beginning to think there is a hardware timing factor involved, along with possibly (or not) other as of yet, identified variables. At least now, for me at least, I can consistently get it to load and work (Just not at 115200, yet).
Did you have any success on this issue? I´m having exactly the same problem and tried everything, but no success at all. Please tell me if you got rid of that error message, ok? Thanks a lot!
With help from 3D Robotics, I found a problem with the accelerometers.
The "INS" CLI test was failing (hanging).
The replacement board they've sent me worked right away.