Please read the "Getting Answers" link I provided. All the above should have been in your first post, to provide context.
No one would be able to answer that without knowing what the device is, or what its protocol is.
A better question would be "Why does there appear to be extra characters in the debugger, and are they really there in the serial output?".
The debugger question might be answered by getting the length of the string in the debugger, and showing that value. If that length excludes the spurious extra characters, then it's a debugger issue (a bug or possibly an antifeature). If the length includes the spurious characters, then something else is wrong.
Once again, this is the Break It Down principle. A string has two characteristics: its length and the characters it contains. If the display of contained characters appears wrong, then look at the length to see how much of what's displayed is real.
Addressing the question of "Are they really there in the serial output" would require getting the data out the serial port, in an observable or actionable form. That is, in a way it can be seen or acted upon.
There are diagnostic tools for this, but their cost varies a lot. A simple one is to set a slow baud rate and drive an LED through a current-limiting resistor. A small speaker or amplifier/speaker combination can also work. Different patterns of characters have recognizable audio characteristics.
Another simple approach is to loop the TX to the RX pin, and see what comes in. This will transfer the data all the way through the AMSerialPort classes, out to the driver, and out the USB-to-serial chip. That makes it a pretty good test for the software elements, especially if you add a blinkenlite LED on the looped-back TX pin.
Other tools include small oscilloscopes, logic analyzers, data-capture devices, and line analyzers. For example, a microcontroller with a serial-port driving a 2-line LCD display can receive and display text like a tiny line-analyzer. Here's a tiny handheld scope:
http://www.gabotronics.com/
Personally, I wouldn't even be trying to send actual command-strings until after I'd proved that the basic serial-port functionality worked, by writing a test program. I'd use TX-RX loopback, and have it write a progressive series of characters, which it also reads back (separately, to avoid deadlock) and verifies.
Writing test programs isn't nearly as much fun as making stuff move on command, but writing tests (especially basic functional tests) is an essential part of engineering.
If the spurious characters are preserved, and appear in the NSData (and the NSData length reflects their presence), then you have confirmation that the characters are really there in the NSString, and aren't just a debugger artifact.