Calypso vs. SDR PHY

Harald Welte laforge at
Sun Nov 19 08:20:58 UTC 2017

Hi Mychaela,

On Sat, Nov 18, 2017 at 07:03:51PM -0800, Mychaela Falconia wrote:

> > (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.

FreeCalypso is *not* FOSS, and hence does not qualify regarding my
statement above.  It's not compliant to the FSF's Free Software
Definition, nor the Debian Free Software Guidelines, nor under and OSI
approved license for Open Source.  Hence, neither Free Software nor Open

You may not care about that, and it is your free choice to do so, which
I do respect.  However, the vast majority of people has a pre-existing
notion about what FOSS is.  And calling FreeCalypso FOSS is what I
strongly object to.

> But right now you do have a great opportunity to beat me to that goal.

People with an interest in OsmocomBB have that opportunity.  I personally
have no time for that, and I have different priorities (otherwise I would
have worked on this already some 5-7 years ago, when creating OsmocomBB
in the first place).

> > 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.  

Anything that is not clear / obvious to the people involve needs to be

> 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.  

And those people - like anyone else on the planet - are happily invited
to contribute related patches to OsmocomBB, if they care about it.

It appears that you care about OsmocomBB not using the calibration tables,
and based on the 7 years of OsmocomBB history, nobody among the OsmocomBB
users seems to care sufficiently to work on it.  That's sad, but it is
a fact.  People do have tons of other projects and responsibilities, and
steps towards regulatory compliance for a highly experimental project
like OsmocomBB apparently was not on the top priority list.

> Of course if OsmocomBB people don't
> understand the meaning of these numbers, that's a different story...

Hence, either the people who understand it contribute a patch, or
the "OsmocomBB people" need to research the topic, or it will not

> 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,

I am sure by now everyone on this list is aware of that.

> 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:

Thanks a lot, I'm sure this is an excellent pointer in case somebody
wants to go ahead and implement reading of the calibration tables.

> 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.

Sure, the MS-side L1CTL interface can most likely be implemented for
various different L1 implementations.  It's what has been done by
various groups publicly and privately before.  Last but not least, the
new virtphy takes the same approach: Simulate L1 in a way that's
completely transparent towards L23.

L1CTL is very simple and was crated very ad-hoc at the time, so be
warned if you think it's not very elegant: It isn't :/

For sure it's much more work than reading + processing the calibration
values, AFAICT.

Kind Regards,

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list