FreeCalypso GSM MS development board built and mostly works

Mychaela Falconia mychaela.falconia at gmail.com
Sun Apr 9 09:22:03 UTC 2017


Hello fellow GSM baseband hackers,

Harald invited me to share this news with this list, so here it goes:
the FreeCalypso project's GSM MS development board with the TI
Calypso+Iota+Rita chipset, called FCDEV3B, has been built, and it
mostly works, although there are still some issues being debugged.
Pictures of this board can be seen here:

https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7580.jpeg
https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7581.jpeg

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.

To run OsmocomBB on my board, the same version of layer1.highram.bin
that is currently built in board/gta0x works unchanged on the FCDEV3B,
as my board design is derived from Openmoko GTA02.  Both Calypso UARTs
are equally accessible on header pins, so use whichever you prefer -
tweak board/gta0x/init.c if you prefer to use the IrDA UART - for
example, if you wish to use the external serial port when running the
same layer1.highram.bin on Openmoko hardware.

The on-board SIM socket wired to the Calypso+Iota chipset works - I
used this native SIM socket (not an external SIM adapter) for the real
SIM used to connect to Operator 310260's live commercial GSM network,
and SMS sending and receiving worked without a hitch.  After several
tries I was also able to dial and connect a voice call - it took
several tries, but voice calls from OsmocomBB have always been
unreliable for me, even on pre-existing Calypso targets where they
work flawlessly with the official firmware.

However, the voice path has not been tested yet, as the hardware is
not complete enough for it yet.  I designed the FCDEV3B with the intent
of being able to make test calls from the lab bench without needing
anything except the board itself, and for this purpose there is a
loudspeaker driver circuit and a microphone input circuit on the board,
based on TI's Leonardo schematics.  However, the actual loudspeaker
and microphone themselves aren't on the board, instead there are
headers meant for connecting them.  At some point I will need to
acquire some loudspeaker and microphone parts, wire them up to the
headers and test these on-board audio circuits, but right now there
are higher priorities.

The following parts do not work properly yet:

* There is a flash + external RAM chip on the board, the same part as
  used in the Pirelli DP-L10, with the gigantic capacity of 16 MiB of
  flash and 8 MiB of RAM.  The external RAM works (I can run the large
  FreeCalypso firmware entirely from RAM without flashing), and the
  flash works in that I can erase, program and verify images in both
  banks of the flash - it is organized as two chip select banks of
  8 MiB each.  However, some strange problems happen when booting
  FreeCalypso fw that has been flashed - I will need to hook up JTAG
  (and exercise that hardware path) in order to debug it further.

  I am guessing that this problem affects only FreeCalypso and not
  OsmocomBB, as it is my understanding that you guys have no interest
  in producing firmware that runs fully on the baseband processor,
  instead of an attached PC host, and for the purpose of running your
  teensy-tiny L1 you don't need any flash or external RAM at all.
  (Sure, one can build a flashable version of this little L1, but what
  is the point of doing so if you still need to run osmocon in order
  to talk to it?)

* 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?  As I understand it,
the requirement that each individual GSM MS unit must be RF-calibrated
in production was not specific to TI Calypso, but is a general
industry-wide requirement, or at least was in that time period.
Per-unit calibration adds to the production test time, time is money,
and the calibration equipment (R&S CMU200 is the industry gold standard)
is not cheap either - so there is a non-trivial cost to this calibration
requirement.  So I figure that there must have been some good reason
for TI and other mainstream GSM MS chipset manufacturers to require
per-unit RF calibration - if they could have dispensed away with this
calibration requirement like you did in OsmocomBB, they surely would
have done it.

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.  So
what is the good reason for requiring accurate VCXO calibration, and
what is sacrificed when one cheats on this requirement like you seem
to be doing?

Viva La Revolucion,
Mychaela aka Spacefalcon the Outlaw


More information about the baseband-devel mailing list