Re: [PATCH] common : bring back some details about technology

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]

Hi Benoît,

On 10/22/2010 09:01 AM, "Benoît Monin" wrote:
> Hi Aki,
> 
>> De : Aki Niemi
>>
>> Hi,
>>
>> 2010/10/21 "Benoît Monin" <benoit.monin@gmx.fr>:
>>> diff --git a/src/common.c b/src/common.c
>>> index b5b9a6f..d571d81 100644
>>> --- a/src/common.c
>>> +++ b/src/common.c
>>> @@ -655,15 +655,15 @@ const char *registration_tech_to_string(int tech)
>>>         case ACCESS_TECHNOLOGY_GSM:
>>>                 return "gsm";
>>>         case ACCESS_TECHNOLOGY_GSM_COMPACT:
>>> -               return "gsm";
>>> +               return "gprs";
>>>         case ACCESS_TECHNOLOGY_UTRAN:
>>>                 return "umts";
>>>         case ACCESS_TECHNOLOGY_GSM_EGPRS:
>>>                 return "edge";
>>>         case ACCESS_TECHNOLOGY_UTRAN_HSDPA:
>>> -               return "hspa";
>>> +               return "hsdpa";
>>>         case ACCESS_TECHNOLOGY_UTRAN_HSUPA:
>>> -               return "hspa";
>>> +               return "hsupa";
>>>         case ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
>>>                 return "hspa";
>>>         case ACCESS_TECHNOLOGY_EUTRAN:
>>
>> Do you need to know if the cell supports high speed uplink, downlink
>> or both; or in fact, when uplink or downlink is active (i.e., channel
>> allocated)? Currently the API is telling you the former, and
>> supporting the latter would require changes not only in the D-Bus API,
>> but also in the driver API.
>>
> The API is fine as-is, we just need a bit more details about the
> technology in use. It will be purely informative in our application
> anyway.
> 
>> As a side note, I think I was originally proposing using the
>> generation tags, but either way works for me. That is, I consider it
>> 3.5G when at least HSDPA is available.
>>
> I was just thinking out loud about a "generation" field, I don't have
> any need for it. And it can be obtained from the technology (correct
> me if I'm wrong) :
> 

The way AT modems report technology is totally bizarre.  Daniel Wagner
played quite extensively with HSO and technology reporting, but we
failed to come up with a nice solution due to the stupid firmware on
these devices.

This is when we then decided to use 2g/3g/4g information only in the
NetworkRegistration atom and give the currently active bearer technology
in the ConnectionManager atom.  Nobody has had time to do the latter.

Regards,
-Denis