Calypso vs. SDR PHY

Mychaela Falconia mychaela.falconia at
Thu Nov 16 06:58:08 UTC 2017

Vadim Yanitskiy <axilirator at> wrote:

> So, I think, Motorola C1XX phones remain the primary hardware
> back-end for now, thus would be better to tell people about them.

Except that Mot C1xx phones with 900+1800 MHz bands are no longer
available except occasional single units here and there, so I assume
that you meant to say that Calypso devices (Calypso in general rather
than Mot C1xx specifically) remain the primary hw back-end, and that
it is a good idea to tell people about the availability of new Calypso
devices that aren't Mot C1xx phones.

As a side-by-side comparison between Mot C1xx phones vs. the newly
made FreeCalypso FCDEV3B hardware for the purposes of running
OsmocomBB, the differences are:

* You need to run a different version of OsmocomBB's layer1: instead
  of running the version built in board/compal_*/layer1.*, you need to
  run the board/gta0x/layer1.highram.bin version.

* Running the gta0x version of layer1 on the FCDEV3B is technically
  cheating, as the FCDEV3B is not Openmoko GTA0x - it is very very
  close, but not identical.

* If you are going to exercise voice call functionality and would like
  to hear the call downlink audio come out of the loudspeaker connected
  to the FCDEV3B (you'll need to procure the actual loudspeaker part
  yourself) in the same way how it comes out of the earpiece speaker
  on Mot C1xx phones, you will need to make a tiny change to the code
  in board/gta0x/init.c to configure Calypso GPIO 1 as an output and
  to drive this output high.

If the OsmocomBB community wishes to support the FCDEV3B as a hardware
target, someone in the OsmocomBB camp (i.e., not me) will need to
decide whether to use the same gta0x target for both actual Openmoko
GTA0x devices and for the FCDEV3B, or to bifurcate the two.  The
concerns with using the same gta0x target for both GTA0x and FCDEV3B
devices are:

* Calypso GPIO 1 should be configured as an output on both targets
  (the current OsmocomBB code incorrectly leaves it as an input), but
  it performs different functions on the two hw platforms.  On my
  FCDEV3B it controls the loudspeaker amplifier like on TI's own
  D-Sample and Leonardo development boards and needs to be driven high
  to enable it, but on Openmoko devices it is an interrupt to the
  application processor of the phone.  I don't know if anyone cares
  about running OsmocomBB on OM devices, and what will happen if the
  code is changed to assert GPIO 1 high.

* If you guys ever get around to making use of the factory-written
  per-unit RF calibration values on the devices you run on, you will
  need to know whether you are running on GTA0x or FCDEV3B hardware:
  while the FFS (flash file system) format is exactly the same, the
  physical flash location of this FFS is different.

This factory RF calibration is another big issue in itself.  In
producing my own FreeCalypso hardware I have expended a very
significant effort to produce per-unit RF calibration that is no worse
than that which was done by the historical Calypso device manufs like
Openmoko, Pirelli and Motorola.  Every FCDEV3B board which I offer for
sale has passed a calibration procedure in which the DUT was connected
to a Rohde&Schwarz CMU200 Universal Radio Communication Tester (the
exact same professional RF test equipment that was used by all of the
big guys in the days of yore), and the following RF parameters are
precisely calibrated for each individual unit:

* The VCXO frequency as a function of the AFC DAC control value, for
  use by the advanced AFC algorithm implemented by TI for use in
  production firmwares;

* The correct APC DAC values to produce each of the Tx power levels
  specified in the GSM 05.05 spec for all 3 supported bands, putting
  each Tx power level exactly where it needs to be per spec, within
  the tolerances given in the spec;

* The "magic gain" constant needed in order to determine the actual
  input level in dBm from the DSP's power measurement, for each of the
  3 supported bands;

* The per-channel variation in this "magic gain" constant caused by
  the irregularities in the passband of the SAW filters, needed for
  proper RSSI reporting.

Thanks to this proper RF calibration, I have a very high confidence
that the radio operation of my FreeCalypso devices when running the
official FreeCalypso Magnetite firmware is 100% correct per all of the
relevant official specs, and that my hw+fw combo would pass FCC/etc
certification and type approval testing if someone were to cough up
the $$$ for it.

All other Calypso devices that are currently supported by OsmocomBB
(Mot C1xx, Pirelli DP-L10, Openmoko GTA0x) also had the same kind of
per-unit RF calibration performed at their respective factories, with
the results saved either in the FFS in TI's format (in the case of OM
GTA0x) or in some proprietary flash data structure (in the case of
Mot C1xx and Pirelli DP-L10), but OsmocomBB fails to make use of these
data on any target, even on those on which the location and format of
these factory RF calibration values are well-known.

I naturally have my reservations about expending the effort to
calibrate each hardware unit I produce with utmost diligence, only to
sell them to people who are going to run firmware that completely
ignores these factory RF calibration values and runs with some
hard-coded off-the-wall numbers instead.


More information about the baseband-devel mailing list