common : bring back some details about technology
Hi Aki,
Quoted 26 lines
De : Aki Niemi
Hi,
2010/10/21 "Benoît Monin" <[email protected]>:
Quoted 21 lines
src/common.c +0
-0@@ -655,15 +655,15 @@ const char *registration_tech_to_string(int tech)case
ACCESS_TECHNOLOGY_GSM:
return "gsm";
caseACCESS_TECHNOLOGY_GSM_COMPACT:
- return "gsm";
+ return "gprs";
caseACCESS_TECHNOLOGY_UTRAN:
return "umts";
caseACCESS_TECHNOLOGY_GSM_EGPRS:
return "edge";
caseACCESS_TECHNOLOGY_UTRAN_HSDPA:
- return "hspa";
+ return "hsdpa";
caseACCESS_TECHNOLOGY_UTRAN_HSUPA:
- return "hspa";
+ return "hsupa";
caseACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
Quoted 9 lines
Quoted 2 lines
return "hspa";
caseACCESS_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.
Quoted 4 lines
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) :
gsm -> 2G
gprs, edge -> 2.5G
umts -> 3G
hsdpa, hsupa, hspa -> 3.5G
lte -> 4G
--
Benoît.
Hi Benoît,
Quoted 41 lines · Benoît Monin
Hi Aki,
Quoted 26 lines
De : Aki Niemi
Hi,
2010/10/21 "Benoît Monin" <[email protected]>:
Quoted 21 lines
src/common.c +3
-3@@ -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 :Quoted 9 lines
src/common.c const char *registration_tech_to_string(int tech) · line 669
Quoted 2 lines
src/common.c +0
-0return "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.
Quoted 8 lines
Quoted 4 lines
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