# HG changeset patch # User Mychaela Falconia # Date 1550341811 0 # Node ID a7707c17451053bb738a9f064b2e398493b081d9 # Parent 42575bc59702a61e9c76e3b60e08f3ff2e36e585 pirelli/{rssi,txcal}: results of the Pirelli to CMU200 experiment diff -r 42575bc59702 -r a7707c174510 pirelli/rssi --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/pirelli/rssi Sat Feb 16 18:30:11 2019 +0000 @@ -0,0 +1,50 @@ +I have been wondering for a long time now how the RSSI bars displayed in end +user phone UIs correspond to actual Rx signal levels; Pirelli's RSSI icon on +the left side of the home screen can go up to 6 bars, but it was not clear at +all what these bars actually correspond to. I just did an experiment to shed +some light on this issue: I took a decased Pirelli motherboard and connected it +to our CMU200 instrument via the RF test port which Pirelli's mobo has like +most phones. Pirelli's RF test port is of the Murata SWD/SWF type, same as +Openmoko GTA0x and Motorola C139, and we have a test probe for these ports with +precisely known insertion loss numbers, thus combined with the properly +calibrated CMU200 instrument and our "main" SMA cable for which we also have +precisely known insertion loss numbers (it is the setup we use to calibrate our +FCDEV3B modem boards), it is a very trustworthy setup. I varied the downlink +signal level put out by the CMU200 and observed the bars displayed by Pirelli's +fw on the home screen, and this is what I got: + +transition from 5 to 6 bars at -75 dBm +transition from 6 to 5 bars at -80 dBm + +transition from 4 to 5 bars at -85 dBm +transition from 5 to 4 bars at -90 dBm + +transition from 3 to 4 bars at -92 dBm +transition from 4 to 3 bars at -97 dBm + +transition from 2 to 3 bars at -97 dBm +transition from 3 to 2 bars at -102 dBm + +transition from 1 to 2 bars at -104 dBm +transition from 2 to 1 bars at -105 dBm + +at -110 dBm it is marginal: sometimes 1 bar, sometimes 0 bars, sometimes no srvc + +Looking at TI's reference firmware which Pirelli's fw must be based on, the Rx +signal strength is passed from L1 to the G23M PS in the form of RxLev numbers +that go into GSM 05.08 measurement reports (the standard [0,63] range with 0 +corresponding to -110 dBm), ALR does no transformation, and RR passes these +RxLev numbers to the Rx driver in the Condat drivers layer, which then converts +them to the "bars" numbers for the UI. Pirelli's fw most likely retains this +architecture, and their modified version of the Rx driver appears to have the +following thresholds or somewhere around there: + +RxLev >= 35: 6 bars +RxLev >= 25: 5 bars +RxLev >= 15: 4 bars +RxLev >= 10: 3 bars +RxLev >= 5 or maybe 6: 2 bars +RxLev abysmally low: 1 bar + +The 5 dB hysteresis seen in my CMU200 experiment is probably caused by the +RSSI_MIN_DIFFERENCE logic seen in rr_csf.c in our TCS3-sourced version. diff -r 42575bc59702 -r a7707c174510 pirelli/txcal --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/pirelli/txcal Sat Feb 16 18:30:11 2019 +0000 @@ -0,0 +1,11 @@ +In the same experiment in which I connected our CMU200 instrument to a decased +Pirelli motherboard (see rssi) I also observed the Tx power levels put out by +this phone in the PCS band by commanding the phone (by way of the CMU200 acting +in the role of a BTS in signaling mode) to transmit at each PCL from 0 to 15 +and observing the actual power measured by the CMU200. Here are the findings: +the Pirelli puts out 29.2 dBm at the highest PCL 0 (spec number is 30 dBm), +whereas for all other PCLs the measured power was within 0.2 dB of the spec +number. Thus it appears that Pirelli's Tx calibration was done like TI's +LoCosto, with only the highest power level shifted down by 0.8 dB while all +others are spec numbers. This is a smaller fudging than that which was done by +Openmoko and which we currently replicate on our FCDEV3B modems.