Hi Mychaela,
On Sun, Apr 09, 2017 at 01:22:03AM -0800, Mychaela Falconia wrote:
Harald invited me to share this news with this list,
so here it goes:
thanks for the update!
Now the following part is bad news for me, but
probably good news for
you guys: right now OsmocomBB works on this board to the point of
being able to connect to the live commercial GSM network in my part of
the world, send and receive SMS and make a call, but my own preferred
firmware is not currently able to the connect to the network (fails in
the FB/SB acquisition step) because of the lack of VCXO calibration.
this is good news, indeed. I'm quite sure you will get your preferred
firmware working, too.
* TI's TCS211 firmware for the Calypso (the basis
for FreeCalypso)
expects per-unit RF calibration to be performed on the production
line, and the VCXO calibration appears to be the most critical step:
if I delete the VCXO calibration files on an Openmoko-made GTA02,
the modem stops working (fails to acquire FB/SB in the network search
just like on my FCDEV3B), whereas all other RF calibration files can
be deleted and it still works. Hence I reason that the lack of this
VCXO calibration is the cause of my current inability to connect to
the network from my board using my preferred firmware.
Now here is the part I don't understand: how are
you able to get away
with not requiring RF calibration in OsmocomBB?
RF calibration generally is required for [spectrum, regulatory]
conformity. For example, the transmit power OsmoocmBB currently uses on
phones is more or less "random" in a sense that we have simply used one
value that worked with one given unit of a C123, and assume that all
other C123 are not too far off from that value. In reality, this can
easily mean quite large discrepancy between intended transmit power and
actual measured transmit power.
For the proof-of-concept / lab type use that was the primary target for
OsmcoomBB this was sufficient. See the dbm2apc_gsm900[] table for the
power calibration values which most definitely are wrong on all but one
phone.
Also, for the VCTCXO: We don't use any calibration here at all. I am not
even sure what exactly is calibrated in the Motorola or Openmoko
firmware. you can see our AFC code in layer1/afc.c is simply using some
constants for the slope and normalization in order to pull the frequency
towards its intended target, based on the measured frequency error.
The absolute accuracy of the VCTCXO doesn't matter, all that matters is
the relative difference between the local clock and the recovered clock
from the FCCH, and we use that to compensate.
So where is the catch? There must be some good reason
why TI's TCS211
fw requires VCXO calibration, and when the fw is redesigned to not
require such calibration as you seem to have done in OsmocomBB,
something else (something important probably) must be sacrificed.
No idea, maybe it's simply some temperature curve? I suppose reading
your "preferred firmware" source code should reveal more details what
this data is actually used for.
Doesn't it simply work if you copy the calibration data from a working
phone (like GTA02) to your FCDEV3B ?
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)