<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
<BR>
Thanks for the good advice Jonathan, we managed to get one more step forward last night!<BR>
<BR>
<BR>
Basically the prolific USB-to-Serial cables would only support "standard" baud rates as discovered earlier. The FTDI chipsets seem to allow arbitrary rates and all we needed to do was switch out the cable for one of the more expensive ones still sitting in the bin. Incidentally this explains why the Arduino Decimillia would let me choose 133333 baud but the UNO would not - the UNO has a different chip.<BR>
<BR>
<BR>
Now in software I can capture a packet stream with the RC in the "neutral" position, play it back to the transmitter we originally pulled out, and when the helicopter is powered on it will recognize and sync to the software-driven transmitter.<BR>
<BR>
The problem is, if I then try switching to sending packets recorded in a throttle position at which the helicopter would take off, the helicopter merely loses sync and reconnects without powering up the blades.<BR>
<BR>
I've tried using the trim buttons to measure the absolute minimum step in voltage between "no fly" and "fly" and sending those two packets in sequence, just to verify the microcontroller on the transmitter chip isn't throwing away the data when the difference between any two packets is too high.<BR>
<BR>
<BR>
The suspicion is that there might be a "I'm going to change now" packet which is transmitted between changes that we're failing to reproduce.<BR>
<BR>
<BR>
Currently the next step is to pull up both the original RC and the software sources under Tony's software analyzer to examine the complete stream from one change to another. We've managed to learn how to use the Tektronix logic analyzer here at the studio but it doesn't have enough memory to record a session at a high enough resolution to give us an answer.<BR>
<BR>
Incidentally with Jake's help the voltage levels of both the RC circuit and the FTDI USB-to-Serial cable were pulled up under and oscilloscope and verified to be outputting the same voltage (approximate 3.3v)<BR>
<BR>
<BR>
Any further suggestions anyone might have on things to check would certainly be appreciated!<BR>
<BR>
<BR>
Cheers<BR>
<BR>
Steve<BR>
<BR>
<BR>
On Fri, 2010-11-19 at 14:44 -0800, Jonathan Foote wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Get a usb-serial converter with the FTDI chipset. I think this is standard on the Arduino. <BR>
<BR>
Get PyUSB <A HREF="http://bleyer.org/pyusb/">http://bleyer.org/pyusb/</A>, which talks directly to the FTDI drivers.<BR>
<BR>
From the app note <A HREF="http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-05_BaudRates.pdf">http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-05_BaudRates.pdf</A><BR>
a 133333 baud rate is supported with a divisor of 22.5, so you should be able to call PyUSB<BR>
h.setBaudRate(133333). (Note, I haven't actually tried this.)<BR>
<BR>
Or, if you feel like hacking Windows .INF files, you can alias the 115200 UART setting to actually run at 133333 following the instructions in the app note.<BR>
</BLOCKQUOTE>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Steve Castellotti<BR>
Puzzlebox Limited
</TD>
</TR>
</TABLE>
</BODY>
</HTML>