Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
Hi Alex, Yeah I think you are right and I am getting really irritated with them giving me the run-around tbh. I sympathize, been there ;) Yeah ok - what name do you suggest? So there's a few things you can do actually: - We do have g_at_result_next_unquoted_string. You could try using that to obtain the negative and then just sscanf/strtol or whatever to convert it. - We also have g_at_result_iter_raw_line() which can give you the raw result line. It should be trivial to come up with some sscanf magic to parse the result. - Just add a new g_at_result_iter_next_negative_number. Or if you come up with a more descriptive word than negative, feel free. Also there's a bigger problem here I think, which is that if I parse negative values and try to pass them back via e.g. netmon interface then Ofono is treating anything negative in there as an error. oFono uses 27.007 as the interface between the driver and the core (and also for DBus API). If it isn't defined in 27.007, then your driver has to sanitize it to a range that is defined in 27.007. In your case any negative value would just be converted to a '0' which means < -140. And the DBUS implementation is unsigned for values based on the thinking that AT responses are non-negative. See above, the DBus implementation would be untouched. If you need to *actually* know whether is -142 or other range that is not currently supported by 3GPP 27.007, then that is a bit nastier problem. So actually there are a number of invasive changes that seem to need to be made to support negative numbers? Hopefully not? Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
On 06/08/2021 15:44, Denis Kenzior wrote: Hi Alex, OK - they say it's fine and you say it's not. I don't have the time to be the middle-man here. I'm fairly certain your vendor's firmware is not following the relevant standards, but it sounds like they don't want to fix it. What can I do? :) Yeah I think you are right and I am getting really irritated with them giving me the run-around tbh. Although I'd like to, clearly I won't be able to contribute this Quectel support upstream. Why does it even matter? I told you very early on that it would be acceptable to add a new g_at_result_* method that handles negative integers. Regards, -Denis Yeah ok - what name do you suggest? Also there's a bigger problem here I think, which is that if I parse negative values and try to pass them back via e.g. netmon interface then Ofono is treating anything negative in there as an error. And the DBUS implementation is unsigned for values based on the thinking that AT responses are non-negative. So actually there are a number of invasive changes that seem to need to be made to support negative numbers? Alex ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
Hi Alex, OK - they say it's fine and you say it's not. I don't have the time to be the middle-man here. I'm fairly certain your vendor's firmware is not following the relevant standards, but it sounds like they don't want to fix it. What can I do? :) Although I'd like to, clearly I won't be able to contribute this Quectel support upstream. Why does it even matter? I told you very early on that it would be acceptable to add a new g_at_result_* method that handles negative integers. Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
On 06/08/2021 15:20, Denis Kenzior wrote: Hi Alex, Denis - I am being directed to the ITU 36.133 spec here https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2420 Sure, same document/section where 27.007 refers to for . But unfortunately 27.007 only defines the range 0..97 where 0 is < 140 dbm. How 3GPP decides to represent values between 156 and 140 is up to 3GPP. If your vendor is using negative integers in AT commands, then that is a vendor extension and not something that is permitted by ITU v.250. This document defines this in 9.1.4 I can't see where RSRP_-17 is defined anywhere but the strong implication to me is that this number should be -17 Can you confirm where it states that these numbers cannot be negative numbers as I cannot find that requirement. V.250 Section 5.3.1. Notice that 27.007 never uses negative integers, there's a reason for that. Regards, -Denis OK - they say it's fine and you say it's not. I don't have the time to be the middle-man here. Although I'd like to, clearly I won't be able to contribute this Quectel support upstream. Thanks anyway, Alex ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
Hi Alex, Denis - I am being directed to the ITU 36.133 spec here https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2420 Sure, same document/section where 27.007 refers to for . But unfortunately 27.007 only defines the range 0..97 where 0 is < 140 dbm. How 3GPP decides to represent values between 156 and 140 is up to 3GPP. If your vendor is using negative integers in AT commands, then that is a vendor extension and not something that is permitted by ITU v.250. This document defines this in 9.1.4 I can't see where RSRP_-17 is defined anywhere but the strong implication to me is that this number should be -17 Can you confirm where it states that these numbers cannot be negative numbers as I cannot find that requirement. V.250 Section 5.3.1. Notice that 27.007 never uses negative integers, there's a reason for that. Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Independent Call Girls in Jaipur
https://www.provenexpert.com/nidhi-chopra/ https://innovation.cccb.org/web/nidhichopra3435/home/-/blogs/independent-escorts-in-jaipur-with-russian-call-girls?_33_redirect=https%3A%2F%2Finnovation.cccb.org%2Fweb%2Fnidhichopra3435%2Fhome%3Fp_p_id%3D33%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_count%3D1 ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Independent Call Girls in Jaipur
Hey there sweetie, my name is Pooja Sharma and I am an exotic and very pretty 21-year-old independent call girl who will do it all with you without any rush or drama. Take advantage of this opportunity and meet me now for a go in bed unlike any other one you have ever had. https://hi.streetgirls.in/ https://hi.streetgirls.in/jaipur-escort-girls ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
How do I install a Canon printer?
ij.start.canon is a platform for getting the canon printer driver. Canon offers a diverse group of printer categories. Choose the right printer to get the stunning print quality which provides easy-to-use software with improved wireless connectivity. Install printer setup online or a disc to operate your Canon printer. Visit to download printer drivers and start setting up your printer device. https://ijstartcannonx.com/ ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
On 03/08/2021 15:28, Denis Kenzior wrote: Hi Alex, I have been chasing this up with Quectel and they tell me this the correct implementation. "QCOPS and QENG command show the RSSI、RSRP and SINR value of the network, this is in accordance with the 3GPP TS regulations, so it is normal for negative numbers to be displayed.image" So the image shows the value for '0' if -140 dbm ... '95' if dbm is -46 to -45 etc. (what is actually sent over AT commands) is never negative. Isn't the image supporting my earlier assertion: 'AT commands do not have a concept of negative numbers'? oFono exposes the value from 3GPP: "byte ReferenceSignalReceivedPower [optional, lte] Contains the Reference Signal Received Power. Valid range of values is 0-97. Refer to in 27.007, Section 8.69 for more details. " Regards, -Denis Denis - I am being directed to the ITU 36.133 spec here https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2420 This document defines this in 9.1.4 I can't see where RSRP_-17 is defined anywhere but the strong implication to me is that this number should be -17 Can you confirm where it states that these numbers cannot be negative numbers as I cannot find that requirement. Thanks, Alex ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
