Hi Aki, > De : Aki Niemi > > Hi, > > 2010/10/21 "Benoît Monin" <benoit.monin(a)gmx.fr&gt;: >> 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) :