Hi Jack,
since we have struct like this...normally there are three possibilities
1) only enable
2) only disable
3) enable and disable
for case 1 and 2 its direct...we just send the list for enable/disable
but for case 3...i ignore the disable case...and only consider the enable
case...since the underlying filter is overwritten(i.e if i do multiple
calls the last call made is considered and it over writes all the previous
calls.)
On Sat, Mar 11, 2017 at 4:06 AM, Jack Yu <jac...@google.com> wrote:
> I see the point that due to the nature of the structure, the client needs
> to make multiple calls to complete the configuration. I think we can simply
> this in the future.
>
> In the other hand, I am wondering if the code schema from/to in the
> structure is really needed or not? At least in AOSP we always hardcode them
> to 0 and 255.
>
> On Mon, Mar 6, 2017 at 10:53 AM, Robert Greenwalt <rgreenw...@google.com>
> wrote:
>
>> Jack, what do you think of their interpretation of the parameters?
>>
>> On Mon, Mar 6, 2017 at 6:23 AM, Giri J <sesha.giri.n...@gmail.com> wrote:
>>
>>> yeah thats true
>>>
>>> if i see the 3gpp spec
>>> CSCB=[<mode>[,<mids>[,<dcss>]]]
>>>
>>> so mode is applied on the complete set of mids and dcss.
>>> but as per the struct mode is applied in every range.
>>>
>>> so we have to consider only one range and ignore rest...or we need to
>>> rectify the structure.
>>>
>>>
>>> On Friday, 21 January 2011 01:00:32 UTC+5:30, Rajesh Kadhiravan Nagaiah
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have some doubt on how to package the response value for the GSM
>>>> cell broadcast configuration use case.
>>>>
>>>> According to 3GPP TS 27.007, the AT cmd to Select Cell Broadcast
>>>> Message Types +CSCB, is of the following format
>>>> for eg to get the CBS configuration
>>>> +CSCB?
>>>> +CSCB: <mode>,<mids>,<dcss>
>>>> eg: +CSCB: 0,"0,1,5,320-478", "0-3,5"
>>>>
>>>> If we take the <mids> in the above example, the service id values can
>>>> be of both range values (320-478) and specific service id
>>>> values(0,1,5).
>>>> Same goes for the <dcss> code scheme values.
>>>>
>>>> The RIL reponse parameter for RIL_REQUEST_GSM_GET_BROADCAST_SMS_CONFIG
>>>> is
>>>> "data" is a const RIL_GSM_BroadcastSmsConfigInfo **
>>>> "datalen" is count * sizeof(RIL_GSM_BroadcastSmsConfigInfo *)
>>>>
>>>> The struct RIL_GSM_BroadcastSmsConfigInfo has following parameters
>>>>
>>>> typedef struct {
>>>> int fromServiceId;
>>>> int toServiceId;
>>>> int fromCodeScheme;
>>>> int toCodeScheme;
>>>> unsigned char selected;
>>>> } RIL_GSM_BroadcastSmsConfigInfo;
>>>>
>>>> In the above structure it accepts only from and to range values. This
>>>> leaves only the following way to pack the values and send.
>>>>
>>>> count = 4 (mids count = 4, dcss count =2)
>>>>
>>>> BroadcastSmsConfigInfo[0]
>>>> fromServiceId: 0 toServiceId: 0
>>>> fromCodeScheme: 0 toCodeScheme: 3
>>>> selected:0
>>>>
>>>> BroadcastSmsConfigInfo[1]
>>>> fromServiceId: 1 toServiceId: 1
>>>> fromCodeScheme: 5 toCodeScheme: 5
>>>> selected:0
>>>>
>>>> BroadcastSmsConfigInfo[2]
>>>> fromServiceId: 5 toServiceId: 5
>>>> fromCodeScheme: 0 toCodeScheme: 0
>>>> selected:0
>>>>
>>>> BroadcastSmsConfigInfo[3]
>>>> fromServiceId: 320 toServiceId: 478
>>>> fromCodeScheme: 0 toCodeScheme: 0
>>>> selected:0
>>>>
>>>> This may not be the right way, as it is not easy for the client app
>>>> to interpret it as such.
>>>>
>>>> Shouldn't be easier to have represent both service id and code scheme
>>>> values as strings in the RIL_GSM_BroadcastSmsConfigInfo pass the
>>>> <mids> and <dcss> values as such, rather than from to values
>>>> for eg:
>>>> typedef struct {
>>>> char* serviceId;
>>>> char* codeScheme;
>>>> unsigned char selected;
>>>> } RIL_GSM_BroadcastSmsConfigInfo;
>>>>
>>>> or to represent it as integer arrays and fill in the array with
>>>> corresponding values(convert range values to specific values, for eg:
>>>> 1-5 -> 1,2,3,4,5) and include both the service id and code scheme
>>>> counts as part of RIL_GSM_BroadcastSmsConfigInfo ?
>>>>
>>>> for eg:
>>>> typedef struct {
>>>> int* serviceId;
>>>> int* codeScheme;
>>>> int serviceIdCount;
>>>> int codeSchemeCount;
>>>> unsigned char selected;
>>>> } RIL_GSM_BroadcastSmsConfigInfo;
>>>>
>>>> BR,
>>>> Rajesh
>>>
>>> --
>>> --
>>> unsubscribe: android-porting+unsubscr...@googlegroups.com
>>> website: http://groups.google.com/group/android-porting
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "android-porting" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to android-porting+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
>
> --
> Thanks,
> Jack
>
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
