[Bitpim-devel] Diagnostics and modem port

[Ivan Komarov]

Hello bitpim-devel,

What is difference between diagnostics and modem port? I'm trying to
read data from Motorola 270c and code goes on this brunch:

if firsttwo=="Y\x0c" and data==firsttwo:
# we are getting an echo - the modem port has been selected
# instead of diagnostics port
raise common.CommsWrongPort("The port you are using is echoing data back, and is not valid for Brew data. Most likely you have selected the modem interface when you should be using the diagnostic interface.", self.desc)

How set this port ?

[Roger Binns]

Post by Ivan Komarov
What is difference between diagnostics and modem port?

The Qualcomm chipsets effectively have two different sources
of data. One of them is the modem stuff and the other is
the diagnostics mode stuff.

When a company makes a phone they choose what to do about that.

Every single company except LG decided to expose one interface
which is initially connected to the modem source and the
AT$CDMG command is used to connect to the diagnostics stuff.
The only way to get back to modem is to reboot the phone.

On the LG phones with true USB ports, they decided to have
two USB interfaces (this is known as a composite device in
USB terminology). One USB interface is connected to the modem
and the other is connected to the diagnostics stuff. Consequently
both can be used and there is no need for mode switching or
rebooting (in theory). On the same LG phones when using the
serial interface, it behaves like all the other phones with
the AT$CDMG command to switch.

Some users decide that they know better than BitPim's auto
detection stuff and insist on using the USB modem interface on
their LG phones. What happens is that the AT$CDMG command
has no effect and when BitPim sends the diagnostics mode
commands, they get echoed back (which is default behaviour
for the modem AT command processor) instead of being understood.

That particular code was added because so many users decided
that they knew better when they didn't, and to explicitly
detect this happening.

Roger

[Jim Smith]

FYI, although Sanyo's call alarm limit is 15, I put 17 in BitPim to see what
would happen. The log said it downloaded all 17 (0-16) to the phone. The
phone seemed to ignore the extras, and works fine, but this could
potentially be a problem.

[Stephen Wood]

I had forgotten that I hadn't dealt with what to do if there are too
many entries. (You will see the same thing if you try to write more
than 100 regular events.) My plan was to sort the entries by date, and
then start writing the entries that have not occurred yet, starting with
the soonest. If all the slots have not been filled when all the events
yet to occur have been written, then past events will be written
starting with the most recent.

Thanks for bringing this up! Stephen

Post by Jim Smith
FYI, although Sanyo's call alarm limit is 15, I put 17 in BitPim to see what
would happen. The log said it downloaded all 17 (0-16) to the phone. The
phone seemed to ignore the extras, and works fine, but this could
potentially be a problem.

[Jim Smith]

Post by Stephen Wood
My plan was to sort the entries by date, and
then start writing the entries that have not occurred yet, starting with
the soonest. If all the slots have not been filled when all the events
yet to occur have been written, then past events will be written
starting with the most recent.

The other synchronizing programs that I'm familiar with, FoneSync and
DataPilot, only synchronize from the current day forward. They don't mess
with past events at all. DataPilot lets you set a range with a maximum from
the current day to six months in the future. Maybe that would simplify
things for you.

Jim