Re: [PATCH v2] Skip unsolicied CREG/CGREG correctly while checking GPRS attach status
Hi Tonny, In your proposed patch, it bypass the unsolicited response only if the 2nd number after +CGREG: is not single digit, however if the lac is single digit, we will still get the wrong state number. The lac is given as a 2 byte number and should always be printed as four hexadecimal letters. If this is not the case, then you should have a serious talk with your vendor. So I still believe we should check whether we are at the end of the return string before parsing the unquoted lac and ci. If we are at the end of the string, then this is a unsolicited code and we should ignore it. How do you think? I'm against this, if you really want to guard against this, then use the approach similar to comprehension_tlv_iter_copy in src/simutil.[ch]. You can use that to 'peek' ahead and figure out whether the response contains 3 or 4 elements. But again, you would not be having this issue in the first place if your vendor followed standards ;) Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Specify vendor ID for Huawei modem while creating GPRS context
Hi Tonny, But it seems to me the gprs context will be pass to modem plugins, so we need to set the vendor code for Huawei modems, because it sends unquoted strings. No, you don't. You are confusing gprs atom and the gprs-context atom. Grep for VENDOR in drivers/atmodem/gprs-context.c if you do not believe me. There is no vendor specific code in the atmodem gprs-context driver. For example, please correct me if wrong, when the network registration status changed, ofono will invoke modem's set_attached() to handle the modem attach/detach. Then, in gprs_attach_callback() in src/gprs.c, it will invokes modem's attached_status() to check the modem state, which has vendor dependent code in it. Most importantly, after ofono sending AT+CGREG? to query the solicited response, the at_cgreg_cb() requires the correct vendor ID so that at_util_parse_reg() knows whether the lac and ci are quoted strings or not? Did I misunderstand? Thanks. As I mentioned before, this is needed for the gprs atom driver which handles the CGREG parsing. Not for gprs-context driver. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/5] Call Counters (2nd)
Hi Remi, Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult. My take here is that a granularity of 1 minute is enough. There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT. let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes. As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not flush them to disk frequently. We do not need to implement the billing policy for that. This is only about the total talk time. If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane. Sure. We don't wants this. So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time. The requirement is that the user cannot deduct (much) talk time from the call counters. is actually everybody in agreement here that we talk about actual time spent on the phone talking? Denis and myself clearly see it that this is a sensible approach to overall call counters. And if that is the case, then this maps closely to what PA has to track anyway. The more and more we talk about this, the more and more it makes sense to me to do this as a plugin to PA that stores the overall call time values into Tracker. And then can also be reset via Tracker. This would satisfy all my concern that I have from an process wakeup and IO utilization overhead and battery consumption point of view. Doing this every 10 seconds and displaying it on a per second level sounds insane to me. So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me. You do realize that this is NOT the feature we are talking about here. The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it. The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough. Showing minutes, as in flushing the counters every 60 seconds might work, but I'd rather make this a configurable knob. That said, I do believe the stored value has to be more precise than minutes. Otherwise per call error may add up far too quickly. I don't see this as a problem at all. This does not add up. So if you loose 59 seconds in a 4 hours call, then that is pretty much statistically irrelevant. And that is only the case if you magically loose your battery. In case you run out of battery or end the call properly, you will still get the accurate counter to the second. Since the device management daemon or oFono will inform you about it. What you should really ask yourself is what you present to the user. If you use your phone for 3 phone calls that are less than three seconds, you might wanna display seconds. However in that case you have the accurate counter when ending the call in the first place. If you loose your battery and have not used the phone longer than a minute, why bother. This is not the problem that needs to be solved. If you spent something crazy like 60 hours on the phone per month and then loose 59 seconds, it makes no difference either. At that point that inaccuracy is statistically irrelevant and can be ignored. And again, this is only a problem if you battery magically gets loose and flies away. Otherwise you are accurate to the second. So in conclusion having an IO sync of the ongoing call every 60 seconds seems to be reasonable enough. And at the same time you keep a down to the second call time in case of a healthy device. With all this in mind. How often does someone magically loose the battery and then goes complain to someone about a big difference in the bills. Or is this more an esoteric feature request. Can we not try to solve this sensible without going overboard and trying to solve world hunger ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2] Skip unsolicied CREG/CGREG correctly while checking GPRS attach status
Hi Denis, On Sat, Dec 11, 2010 at 10:52 PM, Denis Kenzior denk...@gmail.com wrote: Hi Tonny, In your proposed patch, it bypass the unsolicited response only if the 2nd number after +CGREG: is not single digit, however if the lac is single digit, we will still get the wrong state number. The lac is given as a 2 byte number and should always be printed as four hexadecimal letters. If this is not the case, then you should have a serious talk with your vendor. Well, if this (i.e. lac are 4 hex-digits) is the case, then I totally agree with you that it could ignore unsolicited response properly in at_util_parse_reg() for my case. Thank you so much for the coach :) Best Regards, Tonny ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Specify vendor ID for Huawei modem while creating GPRS context
Hi Denis, No, you don't. You are confusing gprs atom and the gprs-context atom. Grep for VENDOR in drivers/atmodem/gprs-context.c if you do not believe me. There is no vendor specific code in the atmodem gprs-context driver. Yes, my bad, I misunderstood the program flow... So, is huawei_post_online() in plugins/huawei.c the right place to pass the vendor ID while calling to ofono_gprs_create()? Together with the patch to fix parsing of unquoted CGREG, now I can get the CGREG status correctly from the Huawei modem. :) Thanks! Best Regards, Tonny ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Specify vendor ID for Huawei modem while creating GPRS context
Hi Tonny, On 12/11/2010 10:37 AM, Tonny Tzeng wrote: Hi Denis, No, you don't. You are confusing gprs atom and the gprs-context atom. Grep for VENDOR in drivers/atmodem/gprs-context.c if you do not believe me. There is no vendor specific code in the atmodem gprs-context driver. Yes, my bad, I misunderstood the program flow... So, is huawei_post_online() in plugins/huawei.c the right place to pass the vendor ID while calling to ofono_gprs_create()? Yes, I fixed this now as well. Together with the patch to fix parsing of unquoted CGREG, now I can get the CGREG status correctly from the Huawei modem. :) Thanks! My earlier patch has been applied, so please test the upstream version and report back any problems. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
Adding Infineon modem selftest to the plugin. It executes couple of AT commands, and based on the responses, it continues with ifx modem enabling or powers the modem down. didn't we conclude that the modem should do all these by itself? My understanding is that the modem executes these. And not that we have to trigger them. The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
Hi Waldo, Adding Infineon modem selftest to the plugin. It executes couple of AT commands, and based on the responses, it continues with ifx modem enabling or powers the modem down. didn't we conclude that the modem should do all these by itself? My understanding is that the modem executes these. And not that we have to trigger them. The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. I am not aware of the conclusion. My understanding is still that the modem firmware is suppose to do its selftests all by itself. So what is the reasoning behind doing these selftests from the host. Right now I am failing to see the benefit of these. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
