[BitPim-devel] Phone auto-detection

[Roger Binns]

Joe,

Please can you do some more updates the phone detection code.

Firstly see if you can talk to all the ports in parallel (ie
use multiple threads) otherwise things get quite slow. (In
the short term you could also set the timeout to one second
instead of the default 3).

The code seems to believe it can send AT commands at anything
and seems to wait an infinite amount of time for responses.
With the LG diagnostics interface, this should not be done.
I'd recommend filtering the list of com ports first and
only send AT commands to modem devices (ie not to serial
devices) The current code hangs (well I had to control-C
BitPim after 4 minutes) when sending AT commands to the
diagnostic interface of an LG phone.

It is a good idea to put something in the log since users
won't see the console output. I'd be happy for it to be a
lot and be verbose until the feature is reliable.

You should also only grab the list of ports that at least
one phone module has in its auto-detection list. That will
avoid talking to ports we know that no phone model is interested
in. (I can assure you that BitPim can only confuse my GPS :-)

Do not send AT$CDMG. If sent on the USB modem interface of
an LG phone, it switches the diagnostics to use the serial
interface (most LG phones can be talked to over a serial interface
or a composite USB interface). Once that switch has happened
then the phone can't be talked to unless the user goes in and
changes some settings in a hidden service menu.

Roger

[Roger Binns]

It looks like the auto-detect mode isn't remembered if you
exit BitPim and restart. It is probably worth having
such a mode, and when BitPim starts do a round of detection
in case the user plugged in the phone before starting BitPim.
(I have so many USB ports the chance of the phone being in
same place is almost zero :-)

Roger

[Joe Pham]

Post by Roger Binns
Firstly see if you can talk to all the ports in parallel (ie
use multiple threads) otherwise things get quite slow.

I was thinking about that but haven't had a chance yet.

Post by Roger Binns
In the short term you could also set the timeout to one second
instead of the default 3

It is currently set to 1 (that was one of the first things I changed). Not sure if that actually has any effects. Will verify it.

Post by Roger Binns
The code seems to believe it can send AT commands at anything

That's what it does now.

Post by Roger Binns
seems to wait an infinite amount of time for responses.

commport should have timed out, not sure what happened there.

Post by Roger Binns
I'd recommend filtering the list of com ports first and
only send AT commands to modem devices

Will try that.

Post by Roger Binns
It is a good idea to put something in the log since users
won't see the console output.

It currently prints messages to the console. Will redirect that and other messages to the log display.

Post by Roger Binns
You should also only grab the list of ports that at least
one phone module has in its auto-detection list.

You mean like a union of likely ports of all phone modules?

-Joe Pham



______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!

[Joe Pham]

Speed up the detection process a tad with the following updates:

- Only try the AT commands on modem ports.
- Use threading when available.
- Bail if first attempt to send AT command fails.

Will try next:
- You should also only grab the list of ports that at least
one phone module has in its auto-detection list.


-Joe Pham



______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!

[Roger Binns]

Post by Joe Pham
- Use threading when available.

The simplest way of doing this is to use two Queue.queue objects.
On one of them, keep putting port "objects". Have some number
of worker threads (eg 5) do blocking gets from that queue and
then try the commands on the port.

Use the second queue to place the results from the worker thread.
To keep the UI updated, have the worker threads use wx.CallAfter
to call a method in the UI thread which will count the result
queue and give a percent complete as well as detect when all
the results are in.

Post by Joe Pham
- Bail if first attempt to send AT command fails.

Be somewhat careful with this. With the LG phones when talking
over a serial connection you have to try at least 19200, 38400,
115200 and 230400 assuming they are even in modem mode. Or you
can just stick to the rule of never sending modem commands to
non-modem ports, and just defer to the logic I'll be writing
which may work.

Post by Joe Pham
- You should also only grab the list of ports that at least
one phone module has in its auto-detection list.

This should be fairly easy as the comdiagnose code already
does the heavy lifting. I also think you should limit the
ports passed to the detect phone method to those that the
phone would claim. This helps ensure the interface detection
code remains correct especially if people aren't using
auto detect for whatever reason.

Roger

[Joe Pham]

Post by Roger Binns
The simplest way of doing this is to use two Queue.queue objects.

The approach that I took is sligthly different: instantiate a thread for each modem port, let them loose, and wait for them to finish.

Post by Roger Binns
Or you can just stick to the rule of never sending modem commands to
non-modem ports

Strictly modem ports at this point. As a side note for Samsung phones, the Susteen/Datapilot/CQX driver would not work with this scheme since it shows the port as a serial vice modem port. Users would have to stick with the Samsung USB/CDMA driver to take advantage of the auto-detect feature. The Susteen/Datapilot/CQX driver works fine otherwise.

Post by Roger Binns
I also think you should limit the ports passed to the detect phone

method to those that the phone would claim.

The likely ports are already being passed to detectphone, in addition to the available ports.

-Joe Pham



______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!

[Joe Pham]

Roger, please let me know what I else I can update to help with the LG detection. Stephen, I assume your Samsung & Sanyo ones are fine, for now?

-Joe Pham



______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!

[Stephen Wood]

The Sanyo and Samsung detection was working OK a few days ago. I'll
try it again tonight to make sure it is still OK with recent changes.

I did have an intermittent issue that detection would sometimes not
work, even though other operations with the phone would work. I
didn't get a chance to look at it too much, but I know that in those
cases, phone_detect did not get any data from the phone.

sendatcommand should send some stuff to the protocol log. I don't see
anything in the protocol log, so I'll see if I can understand why. It
would be useful to have the protocl logging for phone detection so
that when it doesn't work for someone, we can have them send the
protocol log. (It will be useful for the Sanyo phones since I had to
guess at the detection strings for some of them.)

Stephen

Post by Joe Pham
Roger, please let me know what I else I can update to help with the LG detection. Stephen, I assume your Samsung & Sanyo ones are fine, for now?
-Joe Pham

[Roger Binns]

Post by Joe Pham
Roger, please let me know what I else I can update to help with the LG
detection.

Nothing at the moment. I just have to find the time. (I've been
working long hours, have a horrid commute and the company just got
taken over!)

The main issue for the LG phones is just the complexity with access
possible via true serial or direct USB with multiple interfaces. It
does already work with true serial, except I need to double check that
the modem commands are sent at various speeds, and brew mode is exited
as necessary.

USB mode requires sending the phonebook init and extracting the right
bytes for each model, as well as ensuring that modem commands sent to
the modem interface are not used for detection.

Roger

[Joe Pham]

Post by Stephen Wood
sendatcommand should send some stuff to the protocol log. I don't see
anything in the protocol log

The protocol logging should be working now.

-Joe Pham


______________________________________________________________________
Speed up your surfing with NetZero HiSpeed.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.netzero.com/surf to sign up today!