--- /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.

--- /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.