Re: Bug/Oversight in gatchat/gatresult.c with negative numbers
On Fri, Aug 06, 2021 at 10:02:18AM -0500, Denis Kenzior wrote: > > 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. I would go with g_at_result_iter_next_signed_number() to reflect that the value isn't necessarily negative. // Martin ___ 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, 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: 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
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 Thanks... will go back to Quectel... (!) Cheers, 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, 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 ___ 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 27/07/2021 15:38, Denis Kenzior wrote: Hi Alex, On 7/20/21 11:11 AM, Alex J Lennon wrote: Hi all, I'm doing a bit of work with Ofono again, extending support for a Quectel EG91 - handling additional cell strength information which seems necessary for LTE. I'm using Quectel's AT+QCOPS which is returning some negative signal strengths and after some investigation I've spotted that gatresult::g_at_result_iter_next_number() doesn't handle negative numbers. AT commands do not have a concept of negative numbers. v.250 Section 5.3.1: may be a string of one or more characters from "0" through "9" representing a decimal integer value. Commands that expect a are noted in the description of the command (see clause 6). I don't recall any other vendor using negative values in AT commands. If you want to add a negative number parser to GAtChat, then please make it a separate method, so that it is very clear that a vendor 'extension' is being worked around. Regards, -Denis Hi Denis, 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" This is quite interesting as aside from the parsing, Ofono seems to rely on negative numbers being errors (e.g. src/netmon.c) What are your thoughts? This being correct, one would have thought other modem manufacturers would report in the same manner. Cheers, 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 Sebastian, Please see below: On 27/07/2021 15:38, Denis Kenzior wrote: Hi Alex, On 7/20/21 11:11 AM, Alex J Lennon wrote: Hi all, I'm doing a bit of work with Ofono again, extending support for a Quectel EG91 - handling additional cell strength information which seems necessary for LTE. I'm using Quectel's AT+QCOPS which is returning some negative signal strengths and after some investigation I've spotted that gatresult::g_at_result_iter_next_number() doesn't handle negative numbers. AT commands do not have a concept of negative numbers. v.250 Section 5.3.1: may be a string of one or more characters from "0" through "9" representing a decimal integer value. Commands that expect a are noted in the description of the command (see clause 6). I don't recall any other vendor using negative values in AT commands. If you want to add a negative number parser to GAtChat, then please make it a separate method, so that it is very clear that a vendor 'extension' is being worked around. Regards, -Denis The team at Ofono are suggesting that Quectel (EG91) should not be returning negative numbers in AT command responses These are returned to an AT+QCOPS command where signal strength is given. Can you comment? Thanks, 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, On 7/20/21 11:11 AM, Alex J Lennon wrote: Hi all, I'm doing a bit of work with Ofono again, extending support for a Quectel EG91 - handling additional cell strength information which seems necessary for LTE. I'm using Quectel's AT+QCOPS which is returning some negative signal strengths and after some investigation I've spotted that gatresult::g_at_result_iter_next_number() doesn't handle negative numbers. AT commands do not have a concept of negative numbers. v.250 Section 5.3.1: may be a string of one or more characters from "0" through "9" representing a decimal integer value. Commands that expect a are noted in the description of the command (see clause 6). I don't recall any other vendor using negative values in AT commands. If you want to add a negative number parser to GAtChat, then please make it a separate method, so that it is very clear that a vendor 'extension' is being worked around. Regards, -Denis ___ ofono mailing list -- ofono@ofono.org To unsubscribe send an email to ofono-le...@ofono.org
