| View previous topic :: View next topic |
| Author |
Message |
Indio192
EVDO Fledgling
Joined: 03 Jun 2006
Posts: 24
|
 Posted: Mon Aug 25, 2008 10:30 am Post subject: KR1 signal strength - what it really is. |
 |
|
I have completed the reverse engineering of the KR-1 software routine, Priority, that manages the evdo connection. In reviewing and testing my C code to make sure it correctly emulates Priority, some interesting features about the KR-1 operations are revealed. This note describes the signal strength display.
For those who don't want to read the details, the bottom line is that the KR-1 never reports a true evdo signal strength (also known as rssi). The value reported is based on a comparison of ping times taken at regular intervals (about 1 minute). Furthermore, there are errors in the algorithm used to compute this pseudo signal strength. For more details, read on.
True evdo signal strength (rssi) is obtained by issuing an AT+CSQ command to the modem. The modem responds with a signal strength value over the range 0 to 31, or a 99 which indicated no signal (I am not sure what is the difference between a signal strength of 0 and a value of 99). The problem is, you can only issue AT commands to the modem when the modem is not busy, i.e., not connected to the Internet. So, there is no practical way to get a true evdo signal strength after the modem has connected. There may be some modems that have more than one port, that allows you to interrogate them while they are connected, but that possibility is not covered by the KR-1 software.
The KR-1 does issue an AT+CSQ command just before the modem is connected to the network. This is done in the chat script used to make the evdo connection. However, due to a programming oversight, the response is never recorded and is lost. The KR-1 Project people modified the linux busybox chat utility so that it would write the response of an AT+CSQ command to the file /var/ppp/CSQ. This file is read by Priority during signal strength calculation. However, chat only writes this file when the utility is invoked with the verbose (-v) option. Unfortunately the evdo options file omits the verbose option when it invokes chat to make the initial evdo connection. This results in the /var/ppp/CSQ never being created. As a result, Priority always uses a default CSQ value of 31 (100% or 10 bars).
But if CSQ is always 10 bars, then why do we see signal strength values less than 10 bars? Read on.
As stated above, AT+CSQ commands cannot be sent to the modem when it is connected. Therefore, some other method must be devised to give signal strength. The KR-1 Project chose to use ping times as a signal strength indicator. Just after the evdo connection is established, Priority calculates a base ping time using one of the DNS ip addresses. It sends 10 pings and stores the average ping time and max ping time in global variables. Then, as Priority cycles through at approximately 1 minute intervals, this same address is pinged and the result compared to the initial average ping time to compute a pseudo signal strength. If this value is less than the bogus CSQ, it is written to a file for use by the signal strength display routine in the web server. (There is an error in the routine Priority uses to compute signal strength, but I see no point in going in to the details here.) So, what you see in the web interface is never a true rssi – it is a pseudo signal strength based on ping times and even that is wrong.
While using ping times is not an accurate indicator of signal strength, it may provide an indicator of web performance. Or it may not indicate anything at all. You'll have to decide how much faith to put in KR-1's signal strength display.
In my rewrite of Priority, I would like to do a better job of providing a signal strength value. However, there are limits on what can be done. I will fix the call to chat so that the verbose option is used to obtain at least one valid rssi. For the subsequent signal strength calculations, I will have to use a ping time method normalized to the initial CSQ value. I'm currently testing various algorithms. I'm open to suggestions.
Jim |
|
| Back to top |
|
 |
Mackieman
EVDO Junkie
Joined: 31 Oct 2005
Posts: 490
|
| Posted: Mon Aug 25, 2008 11:19 am Post subject: Re: KR1 signal strength - what it really is. |
|
|
| Indio192 wrote: | | For those who don't want to read the details, the bottom line is that the KR-1 never reports a true evdo signal strength (also known as rssi). The value reported is based on a comparison of ping times taken at regular intervals (about 1 minute). Furthermore, there are errors in the algorithm used to compute this pseudo signal strength. For more details, read on. |
For the record, that point was explained when RK1006 was rolled out with the psuedo signal strength feature. See this post.
| Indio192 wrote: | True evdo signal strength (rssi) is obtained by issuing an AT+CSQ command to the modem. The modem responds with a signal strength value over the range 0 to 31, or a 99 which indicated no signal (I am not sure what is the difference between a signal strength of 0 and a value of 99). The problem is, you can only issue AT commands to the modem when the modem is not busy, i.e., not connected to the Internet. So, there is no practical way to get a true evdo signal strength after the modem has connected. There may be some modems that have more than one port, that allows you to interrogate them while they are connected, but that possibility is not covered by the KR-1 software.
The KR-1 does issue an AT+CSQ command just before the modem is connected to the network. This is done in the chat script used to make the evdo connection. However, due to a programming oversight, the response is never recorded and is lost. The KR-1 Project people modified the linux busybox chat utility so that it would write the response of an AT+CSQ command to the file /var/ppp/CSQ. This file is read by Priority during signal strength calculation. However, chat only writes this file when the utility is invoked with the verbose (-v) option. Unfortunately the evdo options file omits the verbose option when it invokes chat to make the initial evdo connection. This results in the /var/ppp/CSQ never being created. As a result, Priority always uses a default CSQ value of 31 (100% or 10 bars).
But if CSQ is always 10 bars, then why do we see signal strength values less than 10 bars? Read on.
As stated above, AT+CSQ commands cannot be sent to the modem when it is connected. Therefore, some other method must be devised to give signal strength. The KR-1 Project chose to use ping times as a signal strength indicator. Just after the evdo connection is established, Priority calculates a base ping time using one of the DNS ip addresses. It sends 10 pings and stores the average ping time and max ping time in global variables. Then, as Priority cycles through at approximately 1 minute intervals, this same address is pinged and the result compared to the initial average ping time to compute a pseudo signal strength. If this value is less than the bogus CSQ, it is written to a file for use by the signal strength display routine in the web server. (There is an error in the routine Priority uses to compute signal strength, but I see no point in going in to the details here.) So, what you see in the web interface is never a true rssi – it is a pseudo signal strength based on ping times and even that is wrong.
While using ping times is not an accurate indicator of signal strength, it may provide an indicator of web performance. Or it may not indicate anything at all. You'll have to decide how much faith to put in KR-1's signal strength display.
In my rewrite of Priority, I would like to do a better job of providing a signal strength value. However, there are limits on what can be done. I will fix the call to chat so that the verbose option is used to obtain at least one valid rssi. For the subsequent signal strength calculations, I will have to use a ping time method normalized to the initial CSQ value. I'm currently testing various algorithms. I'm open to suggestions.
Jim |
You're correct on most all accounts. The one note I would make is that I believe the AT+CSQ value is actually used in the initial calculation that determines the number of bars to display. I don't believe it is stored in memory as you suggest, but was rather made a session variable that is used once and discarded as it is then out of date. I'm not 100% sure on that point as I didn't physically write the software myself (I designed the feature). It would not surprise me if the verbose option was omitted leading to a false initial reading. I can assure you that this was not the intention of the design.
As you mentioned, there is only so much that can be done within the KR1 environment. As I remember it, I spent several days banging my head against my office wall figuring out how to come up with something resembling signal strength since we couldn't pull AT+CSQ while the card was connected. I am not a software or electrical engineer so what you see today is the best that I could come up with.  At the time, D-Link was uninterested in trying to engineer a solution this issue which left it to me to solve. Fate of the free world in my hands, etc.  
I knew we were sending verification pings and so I hypothesized that we could count the loop time of the pings being sent by the router and wrote a pretty basic algorithm to convert those values into the bars that are displayed. There are four possible sites that the ping utility uses, one after the other in the event of a failure. Sprint blocked ICMP to its DNS servers so we also included google and I think dlink.com so that there were options if one of the ping attempts timed out due to blocked ICMP.
The actual output of that algorythim is an integer, 0 through 10. It is certainly not a perfect way to display signal strength and we knew that when we released it, which is why it was documented as such and never purported to be accurate. I think you're right in that there is a certain amount of faith involved, but there is some basis to the thought.
With CDMA RF links, PPP connection quality is somewhat proportionally related to the quality of that radio connection. I simply took this a step further and inferred that if your ping is really bad, you probably have poor RF coverage. I believe some thought was given to the difference between a Rev. 0 and a Rev. A connection was made as well, given that Rev. A was still fairly new when KR1 and RK1006 was released.
As a bit of an easter egg, to support a particular KR1 customer, there is a hidden page that displays the values for that customer's application to parse, min, max, and actual. Bonus points if you can find it.
KR2, on the other hand, is quite a bit different. We no longer send pings of any kind since the engineering quality is much higher on KR2 and they aren't needed. Without going into a lot of detail, there are actually other methods querying devices that utilize a Qualcomm chipset while they are connected. KR2 employs some of those methods with success. |
|
| Back to top |
|
|
Indio192
EVDO Fledgling
Joined: 03 Jun 2006
Posts: 24
|
| Posted: Mon Aug 25, 2008 2:34 pm Post subject: |
|
|
mackieman,
Thanks for the kind reply. I did not mean to criticize the choices make during the KR-1 development. I realize there were, and still are, limitations. I am, however, a bit appalled at how poorly D-Link implemented the concepts given to them.
Thanks for the tip on the Qualcom chips and the possibility of sending AT$QC... commands while the card is connected. I had a test program on my KR-1 that allowed me to send AT commands - I just never thought about trying to send one when the card was busy. I will load it back on and try a few more things.
I was aware that the webserver would try to read the CSQ value off the file /var/ppp/CSQ, but I never looked into exactly where that feature was used. Guess I'll have to look again. I love Easter egg hunts.
Jim |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Sprint Rev A USB: Compass 597
Sprint Rev A ExpressCard: Merlin EX720
Purchase an V740 Rev A ExpressCard
Sprint U727
CTR350 Router $99
CradlePoint PHS300
Purchase a MBR1000
Purchase an EVDO Booster Antenna
Purchase a LinkSys 3GV2 Router
Purchase an EVDO Amplifier
Your Mac EVDO Experts
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
