MAPGPS wrote:
I have compiled Interceptty for ARM, and it can run on my AR.Drone to simulate a "fake" /dev/ttyPA2, logging NavData.
Unfortunately Interceptty has not yet implemented ioctl() calls, thus program.elf can not trigger NavData via ioctl(). Need to find a new serial port sniffer.

After a few hours figuring how to compiling static interceptty (autoconf and automake is something unknown for me) I've been able to run it on the drone. And it worked as expected and I could sniff data from ttyPA1 (ttyPA2 is broken, this thread started on that) and get the some interesting stuff. I even managed to power the motors (uncontrolled, but they rotated ).
As said above, ioctl() TCGETS and TCSETS calls just set tty parameters, as stty does. Interceptty is can try to run stty (-s parameter) but program.elf does it rigth, so no need to worry about this. The ioctl() TCFLSH calls I saw are due the broken navboard and shouldn't happen in normal operation.
Here on some commands and snips.

wiredrat wrote:
After a few hours figuring how to compiling static interceptty (autoconf and automake is something unknown for me) I've been able to run it on the drone. And it worked as expected and I could sniff data from ttyPA1 (ttyPA2 is broken, this thread started on that) and get the some interesting stuff. I even managed to power the motors (uncontrolled, but they rotated ).

So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

scorpion2k wrote:
So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

I'm so sorry. Didn't got a new Navboard yet and I can't get up my drone. However, I'm very interested on that.

scorpion2k wrote:
So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

I would like to do the flying test and get the data to you on this Wednesday (I'll have free time then).

hi everybody! any news on sniffing motor protocol? I've used the following command cat /dev/ttyPA2 > /dev/ttyPA1 hoping to use continuously streaming navdata to get any response from motors but all I got was a lightshow with diodes. will try to use interceptty

Last edited by polari_jet on 14 Feb 2011, 21:51, edited 1 time in total.

polari_jet wrote:hi everybody! any news on sniffing BLC protocol? I've used the following command cat /dev/ttyPA2 > /dev/ttyPA1 hoping to use continuously streaming navdata to get any response from motors but all I got was a lightshow with diodes. will try to use interceptty

Yes. MAPGPS provided me an interceptty dump. With this I was able to analyze all control commands (except for firmware flashing).

For now, I can initialize the motors and control the Speed + LEDs. Sadly, this only works until a Cutout is detected. Seems like the UART is switched off then and I haven't yet figured out how to enable it again.

scorpion2k wrote:
For now, I can initialize the motors and control the Speed + LEDs. Sadly, this only works until a Cutout is detected. Seems like the UART is switched off then and I haven't yet figured out how to enable it again.

Best regards.

With motor Cutout detected, AR.Drone will get into Emergency state (all LEDs are Red).
To get rid of Emergency state, you can send AT command:
AT*REF=1,290717952

All LEDs will turn to Green again.
(I guess program.elf will send something to /dev/ttyPA1 once it received that AT command)

(I guess program.elf will send something to /dev/ttyPA1 once it received that AT command)

This was also my first assumption, but ttyPA1 is dead once a Cutout was detected. As they use a single-wire UART for motor connection there must be some open collector circuit. I assume that this circuit is deactivated with the cutout signal. Even toggling the motor specific GPIOs does not change this state. I think, to re-enable it some other GPIO pin must be used.
At least restarting program.elf resets the cutout state without sending any relevant command to ttyPA1. I will have to add some printk' to the GPIO driver to see what happens there.