Calypso vs. SDR PHY

historical

Hi Harald,

> (5) somewhat ties into (4): One goal was always to run also 'mobile'
>     inside a phone and have a FOSS-based telephone.  Nobody has had
>     the time + endurance to get there, and I doubt it will still happen
>     at this point.

Regarding the last part (doubting that a FOSS-based mobile phone will
still happen at this point), it most certainly will happen, but unless
you beat me to it, it will happen with FreeCalypso firmware rather
than OsmocomBB.

But right now you do have a great opportunity to beat me to that goal.
In FreeCalypso land the biggest current blocker on the road toward a
usable untethered phone is my unwillingness to start hacking TI's
demo/prototype UI code to fit into the 96x64 pixel LCD space on Mot
C1xx phones and do all of the upfront debugging in this reduced-screen
environment, without first bringing this UI up in its original 176x220
pixel form - TI targeted the 176x220 pix LCD on their D-Sample board.
The liberated copy of TI's TCS211 fw we are working with (the world's
sole surviving copy of any TCS211 fw to the best of my knowledge) has
TPU driver code only for Rita RF and not Clara, hence no ability to
use the original D-Sample board which I do have.  Thus the only way I
can get the 176x220 pixel LCD on a FreeCalypso device for my UI
development path is to design and build a new board, a successor to
the FCDEV3B, adding that LCD and the standard buttons and other usual
handset peripherals.  It'll probably take me another year or two.

But you are not using TI's original code, hence you have no need for a
platform with a 176x220 pixel LCD; if you are developing the UI from
scratch yourself, you can go directly to whatever LCD size is your
desired target, such as 96x64 for the Mot C1xx family.  So if you
really want to show the world how much better OsmocomBB is than
FreeCalypso and how your reimplement-from-scratch approach is superior
to my liberated proprietary source direct reuse approach, then your
chance is NOW, before I build that next FreeCalypso board with my
desired 176x220 pixel LCD to do it my way.

> > The qty-1 retail price for one of my FCDEV3B boards is
> > $500 USD; if someone were to order a large batch (say, 100 boards),
> > I am reasonably confident that the per-unit price can be brought down
> > to $300 USD or maybe even lower,
>
> Having done a fair amount of electronics manufacturing in this kind of
> quantity, I would seriously be surprised if you'd still be at that kind
> of pricing in a MOQ-100 situation.

Tt was much more of a guess on my part than an estimate.  I haven't
started seriously looking into what a reasonable "large" batch size
would be and how much it would cost, as I need to resolve some
outstanding issues first, most notably the sleep mode bug.  The
current FreeCalypso workaround is to disable all sleep modes in the
fw, and of course firmwares like OsmocomBB that have no sleep mode
capability in the first place are completely unaffected, but I need to
get to the bottom of that mystery before I seriously think about
producing any kind of large batch.

> The source code is out there.  Apparently none of the (at some point many)
> OsmocomBB users has ever seen significant enough need to research and
> understand the format of those calibration tables

Just so we are clear, the format of the RF calibration tables used by
mainline TI->Openmoko->FreeCalypso firmwares is not any kind of secret,
and there is nothing that needs to be "researched" there.  The people
who work professionally on the official firmware for the Calypso
chipset (employed formerly by TI and presently by Falconia Partners
LLC) naturally understand the meaning of every number in every RF
calibration data structure.  Of course if OsmocomBB people don't
understand the meaning of these numbers, that's a different story...

For anyone who does wish to study the official L1 code created by the
same people who created the chips it is meant to run on, the source
for the official FreeCalypso fw (formerly TI's official fw) is public,
including 100% C source for all of L1 (it used to be binary objects in
that sole surviving copy of TCS211, but it has been reconstructed back
to full C source form in FC), so you can see all of the structure
definitions and all of the code that uses these RF parameters in
genuine C form, no reverse eng of any kind needed.  I have even
published the source for the in-house production calibration software
(my own original work) that is used at Falconia Partners LLC to
generate these RF calibration numbers with the help of a CMU200 RF
test station, so you can see not only the code that makes use of
various RF calibration parameters, but also the process by which they
come into being.

It is true that Mot C1xx phones use a different format of Mot/Compal's
own invention, not TI's, but just earlier today I finished implementing
the utility that extracts the useful numbers from Mot/Compal's
proprietary flash data structures and converts them to the mainline
TI/FreeCalypso format.  You can find it in my freecalypso-tools Hg
repository:

https://bitbucket.org/falconian/freecalypso-tools

> and make use of them from OsmocomBB.

This part could indeed be very difficult, as your code architecture
(which I haven't studied too closely) is probably very different from
the official one.

However, I am now considering an alternative approach.  The people who
have expressed an interest in my FCDEV3B hardware but who say that
they need to use OsmocomBB rather than FC firmware are typically
researchers who are looking for the researcher-oriented functionality
of OsmocomBB's L23 software, but I haven't seen any indication that
they are particularly attached to OsmocomBB's specific implementation
of layer1.  Therefore, I am considering implementing an adapter or
gateway process that would allow OsmocomBB's L23 to connect to
FreeCalypso L1 instead of OsmocomBB's own.  I haven't done any serious
feasibility study yet, but I now feel that it would be worth looking
into.

M~