[Bitpim-devel] Re: [Bitpim-user] Trouble transitioning to brew mode

[Roger Binns]

- It'd be nice if the protocol log had a timestamp on it. That would help
see where timeouts are legitimate vs. "timing out without trying to read any
data", which I suspect here...

Good suggestion. I will add it. The timeouts are always timeouts. There
is no code that can generate that message other that doing a serial read
or write and getting a time out. The timeout management is done as part
of the OS, not bitpim.

- What does a *working* protocol log look like? Anyone have one that
doesn't contain private data that they could share? Is this question better
suited for the developer list?

I recommend getting the USB to serial cable. The straight USB cable
has issues. At the driver level it just arbitrarily stops returning data
until the serial connection is reset. One user has confirmed that
FutureDial acknowledged a bug in the driver.

BitPim does not retry stuff to work around buggy drivers for several
philosophical reasons. You are welcome to debate this on bitpim-devel.

Suspicion: Could TrueSync be sending *only* the brew-mode commands, and
could BitPim be failing on the USB cable because it expects AT-style and
brew-style commands to work on the same serial port?

Good conspiracy theory but not true.

That would jibe with
reports that BitPim works better with the serial cable than the USB cable,
even when proper Windows drivers are installed;

It works better with the serial cable as the driver doesn't have bugs in it.

it does make me wonder how
anybody could have got BitPim to work on the USB cable, though.

It does work with the USB cable as well unless a driver bug is hit. I
have one machine where it is only hit in the phonebook, and another
machine where it always works perfectly unless I send a file to the
phone.

To give you more of an idea what happens:

There are three sets of protocol commands. One is straight forward modem
commands (aka AT commands). These instruct the phone to dial numbers, hang
up, and can also return that version information stuff.

The other two are very similar. One is used to manipulate the embedded filesystem
and the other to manipulate the phonebook. They can be intermingled and
for the purposes of this discussion will just be called Brew commands.

The behaviour of the phone differs based on whether you are using the USB to serial
cable or the straight USB cable:

USB to serial:

For the modem commands to work, the port (Menu-8-6-2) needs to be set to RS232.
You can switch to brew mode by sending an AT modem command, at which point the
port will say 'closed' but still work fine for brew stuff. In fact I think brew
stuff will work no matter what the port setting says.

There is no way to get out of brew mode back to modem mode without going back into
the port menu and setting it back to RS232.

Straight USB:

Two devices are installed. One is a modem device and it only accepts modem
commands. The other 'diagnostic' device accepts only brew commands. This
is what you should point bitpim at.

You have to be in modem mode for the version information to work. The version
info stuff is not used by Bitpim in any way, and requires a port setting (USB to
serial) or different device (straight USB). I only put this feature in out of
curiousity and have removed it from 0.6 since it just confuses people, while
others obsess over it, and it serves no useful purpose, and you can find out
the information in the phone menu anyway.

So how does bitpim change modes? It flings every possible command at every
speed until it finds something that works. It is ordered on the assumption
that the phone is already in brew mode.

You can see this for yourself. Go to this link: http://tinyurl.com/hzxz

Scroll down to just about half way through the file and you should see some
functions named _setmodebrew, _setmodelgdmgo, _setmodephonebook etc. You
can see exactly how they try and what they care about.

If you believe it can be done better (eg a different order, adding timeouts),
please join the bitpim-devel, look in the archives for how to check out the
code and we will work on it.

Roger