CSD and GPRS on FCDEV3B with Magnetite

[Mychaela Falconia]

Hello FC community,

I just got to play a little with CSD and GPRS, which was not possible
prior to our own FCDEV3B hardware.  CSD and GPRS have been standard
(though perhaps advanced and optionally included) features of TI's
official modem fw, and they are included in FreeCalypso Magnetite,
although not in Citrine and most certainly not in OsmocomBB.  But even
though we have had TI's code for CSD and GPRS in our Magnetite fw all
along (and in leo2moko prior to that), there was no practical way to
exercise this functionality prior to our FCDEV3B hw.  TI's implementation
of CSD and GPRS presents the associated data channel (as well as the
AT command interface for dialing CSD calls and establishing GPRS
connections) on the Calypso chip's MODEM UART, and we could not get to
this UART channel on any of our pre-existing hw targets:

* On the Pirelli the Calypso's MODEM UART signals are wired to an
  unpopulated FPC/FFC connector footprint; access would require
  disassembling a phone to shreds, soldering the normally-unpopulated
  debug connector onto the board, and then making a special FPC/FFC
  debug adapter - and the LCD module can't be put back on properly
  with that debug connector populated.  Alternatively one can solder
  little wires directly to the pads on the PCB, but the phone still
  cannot be put back together properly in that state, and the 0.5 mm
  pad spacing would make such a hack difficult.

* On the FreeRunner the Calypso's MODEM UART goes to the phone's AP.
  I was previously able to dial CSD calls using a terminal program on
  the AP, and presumably the Openmoko community had GPRS working once
  upon a time back when that community existed, but it was not a
  convenient environment for my needs as a modem fw developer.

* On the C139 the MODEM UART is the only one that is brought out, not
  the other one.  We could not give up the debug trace interface, so
  we gave up the standard AT command interface with CSD and GPRS
  instead.

The FCDEV3B solves this problem by bringing out BOTH Calypso UARTs on
the dual UART header, and the FT2232D adapter boards we use with our
FCDEV3B present both UARTs to the host as two /dev/ttyUSBx serial
devices under a single USB device.  With no other USB-serial devices,
ttyUSB1 is the Calypso's IrDA UART, i.e., the port to which you connect
with rvinterf, but there is also a classic ASCII AT command interface
on ttyUSB0.  By connecting to the latter one can conveniently play
with CSD and GPRS.

I have played a little with GPRS last weekend, and I just played some
more with both GPRS and CSD.  Here are my findings:

* GPRS works on our FCDEV3B modem with both classic/l1reconst and
  hybrid configurations of FC Magnetite, i.e., not only with the same
  binary blob version of the G23M protocol stack that was used by
  Openmoko (which was fully expected to work given that it worked for
  Om), but also with the full source version of G23M PS which we took
  from TCS3/LoCosto - the latter is much more exciting, as the GPRS
  functions of this L23 PS version have *never* been exercised before!
  With both l1reconst and hybrid fw versions running on the board, I
  was able to connect to the Internet and check my Gmail over the GPRS
  connection provided by the FCDEV3B modem, with no other Internet
  connection available on my laptop during the test.

* It is worth noting that TI had reworked the architecture of their
  GPRS code at some point in between 20070608 (the build date of the
  binary blobs version used by both us and Om) and 20090327 (the date
  of our full source TCS3/LoCosto version): the new version adds a new
  protocol stack entity named UPM that didn't exist before, and
  reworked the SM and SNDCP entities to work with this new UPM.  We
  don't have a corresponding source for the old 20070608 way, so the
  new GPRS code with UPM is what I've integrated in the TCS2/TCS3
  hybrid config of Magnetite - it is definitely delightful to see this
  previously untested code working without any apparent problems.

* Outbound (MO) CSD calls work with the l1reconst config of Magnetite,
  i.e., with 20070608 G23M blobs, to the best of my currently limited
  ability to test them.  I used to test CSD by calling NIST's time-by-
  modem service (ACTS) at +1-303-494-4774, but that test depends on
  the gateway between Operator 310260's GSM network and PSTN (land
  lines) doing the magic to translate CSD to analog modem emulation,
  and that gateway seems to have either been shut down or fallen into
  disrepair, as I keep getting the NO CARRIER error most of the time.
  When I make a CSD call to my own POTS line, my POTS phone does ring,
  so perhaps I can make mobile-to-land CSD work if I connect my trusty
  USR Courier to my POTS line and get it configured correctly, but I
  haven't got around to it yet.

* Mobile-to-mobile CSD calls seem to be much more reliable than
  mobile-to-land, for understandable reasons: for mobile-to-mobile CSD
  the network does not have to do anything more than pass 240-bit
  frames every 20 ms from one end to the other, whereas for mobile-to-
  land CSD to work there has to be a gateway somewhere that emulates
  the tones and modulation schemes of an analog modem.  But in order
  to test mobile-to-mobile CSD properly I would need two FCDEV3B
  modems up and running simultaneously, with two SIMs (two lines on
  the family plan) dedicated to this test, and I am not ready to
  pursue such an elaborate setup yet.

* Interestingly enough, it IS possible to test mobile-to-mobile CSD to
  a limited extent by placing a CSD call from an FCDEV3B (or from a
  Neo FreeRunner, from TI's D-Sample or from one of a few pre-existing
  phones with an AT command interface) to a Pirelli DP-L10 running its
  original proprietary fw.  When Pirelli's fw receives a CSD call, the
  phone rings, and the displays says "Incoming data".  I conjecture
  that if one were to connect to the MODEM UART via that unpopulated
  connector footprint on the PCB, buried deep inside the phone, there
  might be a working AT command interface lurking in there, such that
  one could answer the incoming CSD call with ATA and get the data
  connection, but I don't feel like doing the necessary level of
  hardware surgery to test this hypothesis.  In any case, if I simply
  press "Accept" to answer the incoming CSD call when the display says
  "Incoming data", I get a CONNECT response on the CSD originating
  end, suggesting to me that the CSD connection establishment was
  successful, but there is no way to test the data path with an
  unhacked Pirelli running its original fw on the receiving end of the
  CSD call.

* The same CSD call test that works with the l1reconst config (dialing
  a call from the FCDEV3B to the number of the SIM in my end-user-hat
  Pirelli running one of the original proprietary fw versions) did not
  work with the hybrid config, and the AT command channel got stuck in
  a non-functional state, requiring a reboot via RVTMUX.  To be
  debugged later; the bug seems more likely to be in the ACI layer
  than somewhere deeper in the protocol stack.  The TCS2/TCS3 hybrid
  config of Magnetite uses the TCS3 version of ACI: we do have the
  source for the TCS211 version, but attempting to graft the TCS211
  version of ACI atop the TCS3 version of G23M would be more trouble
  than shaking the bugs out of the TCS3 version of ACI, hence I am
  taking the latter approach.

That's all from me for now - back to preparing for the REcon
presentation in two weeks.

Hasta la Victoria, Siempre,
Mychaela aka The Mother