[BitPim-devel] Phone Detection Scheme

[d***@netzero.com]

Based on Roger's suggestion, I'm looking for a good way of auto detecting phones. To do this properly and reliably, I think that each phone model would have to implement its own detection routine. As part of coming up with a good infrastructure for this, I'm polling developers of what they think they'd need to code the detection routine for their phones. In particular, I'm collecting for the following info:

1. What's your phone manufacturer & model?
2. How many comm ports would your phone need?
3. What mode(s) would your phone to be in (MODEMODEM, MODEBREW, MODEPHONEBOOK, etc)
4. I assume your phone can return its ESN, which can be used to associate it with a personalized name (if specified).

As an example, for the Samsung A310/A650/A670, the detection routine would need 1 commport, need to be in MODEMODEM and can return its ESN. The detection scheme is pretty simple: switch to MODEMODEM, check for correct manufacturer and correct model, if so get the ESN and return.

Please throw in any other ideas you may have on this thing.

-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 d***@netzero.com
Based on Roger's suggestion, I'm looking for a good way of auto
detecting phones. To do this properly and reliably, I think that each
phone model would have to implement its own detection routine.

I would suggest a different approach.

Gather information from the system such as what USB devices and
com ports are connected, and send various Brew and AT command
sequences to the ports (do the latter part in parallel so it doesn't
take all day).

Each phone module should then be able to rule itself out completely
or be able to make a better determination based on the ports it
sees available as well as AT command/Brew command responses.

Since you like a challenge, here is some code for you to integrate
as well that will auto-detect new ports being plugged in or removed.
I have excerpted from the code I use to hibernate my machine when it
has finished writing a DVD (the dvd software ejects the disc and
that shows up as a device removal).

First of all you need to change the window procedure for a window.
I'd suggest the main one.

# save the old window proc
self.oldwndproc = win32gui.SetWindowLong(self.GetHandle(),
win32con.GWL_WNDPROC,
self.MyWndProc)

Then define a new window procedure.

def MyWndProc(self, hwnd, msg, wparam, lparam):

if msg==win32con.WM_DEVICECHANGE:
type,params=DeviceChanged(wparam, lparam).GetEventInfo()
self.OnDeviceChanged(type, **params)
return True

# Restore the old WndProc. Notice the use of win32api
# instead of win32gui here. This is to avoid an error due to
# not passing a callable object.
if msg == win32con.WM_DESTROY:
win32api.SetWindowLong(self.GetHandle(),
win32con.GWL_WNDPROC,
self.oldwndproc)

# Pass all messages (in this case, yours may be different) on
# to the original WndProc
return win32gui.CallWindowProc(self.oldwndproc,
hwnd, msg, wparam, lparam)

Make a self.OnDeviceChanged function that will be called with the relevant
information.

def OnDeviceChanged(self, type, name="", drives=[], flag=None):
self.Log("%s: name %s, drives %s, flag %s\n" % (type, name,`drives`,flag))

This is the code that decodes the device change parameters into something
useful.

class DeviceChanged:

DBT_DEVICEARRIVAL = 0x8000
DBT_DEVICEQUERYREMOVE = 0x8001
DBT_DEVICEQUERYREMOVEFAILED = 0x8002
DBT_DEVICEREMOVEPENDING = 0x8003
DBT_DEVICEREMOVECOMPLETE = 0x8004
DBT_DEVICETYPESPECIFIC = 0x8005
DBT_DEVNODES_CHANGED = 7
DBT_CONFIGCHANGED = 0x18

DBT_DEVTYP_OEM = 0
DBT_DEVTYP_DEVNODE = 1
DBT_DEVTYP_VOLUME = 2
DBT_DEVTYP_PORT = 3
DBT_DEVTYP_NET = 4

DBTF_MEDIA = 0x0001
DBTF_NET = 0x0002

def __init__(self, wparam, lparam):
self._info=None
for name in dir(self):
if name.startswith("DBT") and not name.startswith("DBT_DEVTYP") and getattr(self,name)==wparam:
self._info=(name, dict(self._decode_struct(lparam)))

def GetEventInfo(self):
return self._info

def _decode_struct(self, lparam):
if lparam==0: return ()
format = "iii"
buf = win32gui.PyMakeBuffer(struct.calcsize(format), lparam)
dbch_size, dbch_devicetype, dbch_reserved = struct.unpack(format, buf)

buf = win32gui.PyMakeBuffer(dbch_size, lparam) # we know true size now

if dbch_devicetype==self.DBT_DEVTYP_PORT:
name=""
for b in buf[struct.calcsize(format):]:
if b!="\x00":
name+=b
continue
break
return ("name", name),

if dbch_devicetype==self.DBT_DEVTYP_VOLUME:
# yes, the last item is a WORD, not a DWORD like the hungarian would lead you to think
format="iiiih0i"
dbcv_size, dbcv_devicetype, dbcv_reserved, dbcv_unitmask, dbcv_flags = struct.unpack(format, buf)
units=[chr(ord('A')+x) for x in range(26) if dbcv_unitmask&(2**x)]
flag=""
for name in dir(self):
if name.startswith("DBTF_") and getattr(self, name)==dbcv_flags:
flag=name
break

return ("drives", units), ("flag", flag)

print "unhandled devicetype struct", dbch_devicetype
return ()

Roger

[Jim Jacobsen]

Is there a way I can get off of this mailing list?

----- Original Message -----
From: "Roger Binns" <***@rogerbinns.com>
To: <bitpim-***@lists.sourceforge.net>
Sent: Wednesday, April 06, 2005 12:59 AM
Subject: Re: [BitPim-devel] Phone Detection Scheme

Post by Roger Binns

Post by d***@netzero.com
Based on Roger's suggestion, I'm looking for a good way of auto
detecting phones. To do this properly and reliably, I think that each
phone model would have to implement its own detection routine.

I would suggest a different approach.
Gather information from the system such as what USB devices and
com ports are connected, and send various Brew and AT command
sequences to the ports (do the latter part in parallel so it doesn't
take all day).
Each phone module should then be able to rule itself out completely
or be able to make a better determination based on the ports it
sees available as well as AT command/Brew command responses.
Since you like a challenge, here is some code for you to integrate
as well that will auto-detect new ports being plugged in or removed.
I have excerpted from the code I use to hibernate my machine when it
has finished writing a DVD (the dvd software ejects the disc and
that shows up as a device removal).
First of all you need to change the window procedure for a window.
I'd suggest the main one.
# save the old window proc
self.oldwndproc = win32gui.SetWindowLong(self.GetHandle(),
win32con.GWL_WNDPROC,
self.MyWndProc)
Then define a new window procedure.
type,params=DeviceChanged(wparam, lparam).GetEventInfo()
self.OnDeviceChanged(type, **params)
return True
# Restore the old WndProc. Notice the use of win32api
# instead of win32gui here. This is to avoid an error due to
# not passing a callable object.
win32api.SetWindowLong(self.GetHandle(),
win32con.GWL_WNDPROC,
self.oldwndproc)
# Pass all messages (in this case, yours may be different) on
# to the original WndProc
return win32gui.CallWindowProc(self.oldwndproc,
hwnd, msg, wparam, lparam)
Make a self.OnDeviceChanged function that will be called with the relevant
information.
self.Log("%s: name %s, drives %s, flag %s\n" % (type,

name,`drives`,flag))

Post by Roger Binns
This is the code that decodes the device change parameters into something
useful.
DBT_DEVICEARRIVAL = 0x8000
DBT_DEVICEQUERYREMOVE = 0x8001
DBT_DEVICEQUERYREMOVEFAILED = 0x8002
DBT_DEVICEREMOVEPENDING = 0x8003
DBT_DEVICEREMOVECOMPLETE = 0x8004
DBT_DEVICETYPESPECIFIC = 0x8005
DBT_DEVNODES_CHANGED = 7
DBT_CONFIGCHANGED = 0x18
DBT_DEVTYP_OEM = 0
DBT_DEVTYP_DEVNODE = 1
DBT_DEVTYP_VOLUME = 2
DBT_DEVTYP_PORT = 3
DBT_DEVTYP_NET = 4
DBTF_MEDIA = 0x0001
DBTF_NET = 0x0002
self._info=None
if name.startswith("DBT") and not
self._info=(name, dict(self._decode_struct(lparam)))
return self._info
if lparam==0: return ()
format = "iii"
buf = win32gui.PyMakeBuffer(struct.calcsize(format), lparam)
dbch_size, dbch_devicetype, dbch_reserved = struct.unpack(format, buf)
buf = win32gui.PyMakeBuffer(dbch_size, lparam) # we know true size now
name=""
name+=b
continue
break
return ("name", name),
# yes, the last item is a WORD, not a DWORD like the hungarian

would lead you to think

Post by Roger Binns
format="iiiih0i"
dbcv_size, dbcv_devicetype, dbcv_reserved, dbcv_unitmask,

dbcv_flags = struct.unpack(format, buf)

Post by Roger Binns
units=[chr(ord('A')+x) for x in range(26) if

dbcv_unitmask&(2**x)]

Post by Roger Binns
flag=""
if name.startswith("DBTF_") and getattr(self,
flag=name
break
return ("drives", units), ("flag", flag)
print "unhandled devicetype struct", dbch_devicetype
return ()
Roger
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[d***@netzero.com]

Post by Jim Jacobsen
Is there a way I can get off of this mailing list?

http://lists.sourceforge.net/lists/listinfo/bitpim-devel

-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!

[d***@netzero.com]

and send various Brew and AT command sequences to the ports

Something all phones, or majority of them, should be able to understand? Do you know what those commands are or do we need to collect them?

Each phone module should then be able to rule itself out completely
or be able to make a better determination based on the ports it
sees available as well as AT command/Brew command responses.

Like a detection routine with data provided by the calling routine?

there is some code for you to integrate as well that will auto-detect
new ports being plugged in or removed

At first scan throught it, the code appears to work on Windows only, does it also support Linux and the Mac? Would this also be an improvement over the initial capability, which would have the users to intiate the auto detection process?

Also, any improvements to comscan that we need to make?

-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]

Post by d***@netzero.com

and send various Brew and AT command sequences to the ports

Something all phones, or majority of them, should be able to understand? Do you know what those commands are or do we need to collect them?

These AT commands are probably fairly standard:

AT+GMM (Model)
AT+GMI (Manufacturer)
AT+GMR (Revision)
AT+GSN (ESN)
and probably a number of others.

The format of the responses may vary. In partiular GMR, does not seem
to have a standard format. On one old Samsung, it returns the PRL,
but not on others.

For "Brew" commands, the "firmwarereponse" (see p_brew.p) packet seems
to be pretty standard. But again, the reponse will vary in content
and size from phone to phone.

Stephen

[Roger Binns]

Post by d***@netzero.com
At first scan throught it, the code appears to work on Windows only,
does it also support Linux and the Mac?

It is 100% Windows only! You can't do anything remotely like that
on Linux, although if they ever figure out DBUS then maybe one day.
There is something similar on Mac, but I looked at the APIs and
encouragement from a Mac bigot about how simple it all was and
decided I had way better things to do with my life and time.

Post by d***@netzero.com
Would this also be an improvement over the initial capability, which
would have the users to intiate the auto detection process?

I view this from the user interface backwards. BitPim should
just say "auto" by default and if I plug a phone in, it should
change within a second or two to give the details "Roger's Phone.
LG VX4400, Verizon Wireless on COM27"

If I unplug the phone and put a different one in then that should
be picked up automatically as well. I should never have to tell
BitPim what phone is connected, where it is connected etc.

If I happen to have two phones plugged in, then it can ask me
which I want to use at the point that I do a Get/Send.

The above is all how it should end up. We don't have to be there
initially, but instead just make sure the individual steps
taken head in that direction.

I also got a response from a user interaction desginer so we'll
see what they have to say about redoing the whole interface.

I hope they will be able to come up with something better than
an FMA style treeview or anything else I can think of.

Roger

[d***@netzero.com]

Post by Stephen Wood
AT+GMM (Model)
AT+GMI (Manufacturer)
AT+GMR (Revision)
AT+GSN (ESN)

We could either create a lookup table for these, or pass the responses to the phone modules. Do you know of any phone on our list that does not support these commands?

Post by Stephen Wood
For "Brew" commands, the "firmwarereponse" (see p_brew.p) packet seems
to be pretty standard.

Can you get any useful info out of any of these BREW commands? Something along the line of manufacturer, model, etc. ??

-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 d***@netzero.com

Post by Stephen Wood
AT+GMM (Model)
AT+GMI (Manufacturer)
AT+GMR (Revision)
AT+GSN (ESN)

We could either create a lookup table for these, or pass the responses
to the phone modules.

Make a dictionary and use them as they keys (eg if the phone responds
to 'AT+GSN' then there will be a key with that name, and a corresponding
value).

Post by d***@netzero.com
Do you know of any phone on our list that does not support these commands?

For AT commands the phone will always respond with OK or ERROR so
it doesn't matter. It is up to the phone module to work out what
is meaningful.

Post by d***@netzero.com

Post by Stephen Wood
For "Brew" commands, the "firmwarereponse" (see p_brew.p) packet seems
to be pretty standard.

Can you get any useful info out of any of these BREW commands? Something
along the line of manufacturer, model, etc. ??

Sometimes. Just take the binary response and make it a key in
the dictionary as well. Phone modules can look for whatever
sequence of bytes make sense to them.

Also add in the contents of some files if you can get the phone into
Brew mode. That can help identify the carrier. For example
with a VX8000 I can work out the carrier based on the contents
of the brew/version.txt file. There are some other files in
nvm/nvm whose contents can be used to work out the carrier.

The general idea is that you gather up as much information as
possible (in parallel from the openable ports), dump it all in
a dictionary and have the phone modules work out if their phones
are present. Other modules can try to work out the carrier.

Roger

[d***@netzero.com]

Post by Roger Binns
The general idea is that you gather up as much information as
possible (in parallel from the openable ports), dump it all in
a dictionary and have the phone modules work out if their phones
are present. Other modules can try to work out the carrier.

I'll give it a try with those generic AT commands and BREW's firmwarerequest/response and see how far that'd get us.

-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!

[d***@netzero.com]

Post by Roger Binns

For "Brew" commands, the "firmwarereponse" (see p_brew.p) packet >>seems to be pretty standard.

Sometimes. Just take the binary response and make it a key in
the dictionary as well. Phone modules can look for whatever
sequence of bytes make sense to them.

Do we know if all phones can get in & out of DM/BREW mode without rebooting? As part of this detection scheme, should I always get a phone into DM mode to get the firmwareresponse data?

-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]

here is some code for you to integrate as well that will auto-detect
new ports being plugged in or removed.

The code has been integrated and it works very well. I was impressed! BitPim detects and recognizes my phone as soon as it's plugged in. Too bad the Mac & Linux guys won't have this feature :-)

-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
Too bad the Mac & Linux guys won't have this feature :-)

It can also be done on Mac by anyone who wants to fight the
various APIs (they are the usual pseudo-object orientation using
only C) plus layers of abstraction and other crud.

In theory we could poll the usb device list behind the scenes
using the existing libusb code. Unfortunately the libusb api
does memory management really badly (it isn't clear who owns
the memory lists and they can be replaced or leaked by various
calls).

I did just try dbus on my Linux box, but it doesn't seem to
provide events for hardware addition/removal.

Roger