16 Nov
2017
16 Nov
'17
6:30 a.m.
Hello Mychaela,
First of all, my congratulations! I have been watching the project
you lead for some long time, and it's great to see your achievements.
As I understand it, there are two reasons for why the
original
incarnation of OsmocomBB (prior to the recent addition of SDR PHY
support) used Calypso phones as its physical transceiver instead of
USRP-style SDR devices: (1) the work done by the Calypso DSP is
already done, hence there was less work for OsmocomBB developers to
do, and (2) Calypso phones used to be dirt-cheap, whereas SDR devices
cost some non-trivial money.
Yeah, moreover I think when OsmocomBB was initiated, the prices of
available SDR hardware were higher, than today...
Thus with the cost of an SDR device and that of a
newly made Calypso
device being comparable (or as things stand presently, the Calypso
option is more expensive), is there any remaining reason to use
Calypso devices as opposed to SDR PHY for OsmocomBB? In other words,
is there any solid technical reason (not involving cost) to prefer a
Calypso device over SDR PHY for OsmocomBB purposes, or is there not?
Personally, for research and development purposes I would preffer SDR.
The main reason is that my research scope isn't limited by GSM only,
there are other pretty interesting technologies like Iridium, TETRA,
GMR, and of course UMTS followed by LTE.
Which translates into: is there any reason to support
running OsmocomBB
on FreeCalypso hardware and to market such hw to the OsmocomBB
community, or would it be better to tell people that if they want
OsmocomBB, they should use an SDR PHY, and leave FC hardware for
people like me who are interested in end use applications (as opposed
to hacking) using TI-based FC firmware?
SDR PHY isn't finished yet. We only managed to get actual burst
transmission working only a couple of weeks ago. At the moment,
both AGC and Timing Advance loops are missing, and TX power is
not high enough to 'deal' with real base stations...
So, I think, Motorola C1XX phones remain the primary hardware
back-end for now, thus would be better to tell people about them.
One argument I have heard against the use of SDR for
GSM MS role is
that SDR devices supposedly have a difficult time retuning every
4.615 ms, and thus would have a difficult time connecting in the MS
role to a GSM network that employs frequency hopping. Is there any
truth to that argument, or has that problem already been solved? Are
there any other areas in which a chipset like the Calypso that is
specifically designed for the GSM MS role would perform better than an
SDR device of the kind that are viable cost competitors against newly
made Calypso hardware?
Yeah, both frequency popping and neighbour power measurement are the
hard topics for SDR PHY. There are some ideas how to implement that,
but right now we are keeping this problem aside until all the rest
is done ;)
With best regards,
Vadim Yanitskiy.
16 Nov
16 Nov
7:58 a.m.
New subject: Calypso vs. SDR PHY
Vadim Yanitskiy <axilirator(a)gmail.com> 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.
M~
8:33 a.m.
New subject: Calypso vs. SDR PHY
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.
Sure, I meant Calypso devices in general. The main idea is that
SDR PHY is far from the state at which it could be used by
OsmocomBB users nowdays. It's in R&D and testing state.
With best regards,
Vadim Yanitskiy.
18 Nov
18 Nov
1:51 p.m.
New subject: Calypso vs. SDR PHY
fwiw, my interest leans towards cheap and accessible.
So my unreasonable goals are:
1 - port osmocom-bb to fernvale
2 - use that port and adjust for $5 sim800 modules
3 - make nuttx-bb for those cheap 6261 based watches
4 - make a custom board/device
cheers,
Craig
8:30 p.m.
New subject: Calypso vs. SDR PHY
Hi Mychaela,
On Wed, Nov 15, 2017 at 10:58:08PM -0800, Mychaela Falconia wrote:
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.
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 and make use of them from OsmocomBB.
It's sad, but that's the state of affairs, even 7 years into the project.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
19 Nov
19 Nov
4:03 a.m.
New subject: Calypso vs. SDR PHY
Hi Harald,
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.
(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. 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~
9:20 a.m.
New subject: Calypso vs. SDR PHY
Hi Mychaela,
On Sat, Nov 18, 2017 at 07:03:51PM -0800, Mychaela Falconia wrote:
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
Source.
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.
Anything that is not clear / obvious to the people involve needs to be
"researched".
(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.
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. 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
happen.
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:
https://bitbucket.org/falconian/freecalypso-tools
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6:41 a.m.
New subject: adjust gnu arm toolchain directions for newer gcc (7.2.0-14)
Hi all,
Just got a new laptop and was trying to build and run fernly (for fernvale/mtk6260) and
found that arm-none-eabi toolchain from debian (9ish I think... PureOS is what I am using)
doesn't run succesfully. This is a known issue. What really caused me trouble was when
I went to use the gnu arm toolchain instructions on the osmocom wiki I ran into problems.
My PureOS machine has gcc 7.2.0-14. I wonder if we should add some instructions to the
wiki about patches needed and maybe update the shell script to automate these changes if
we can isolate them to a particular version of gcc?
https://osmocom.org/projects/baseband/wiki/GnuArmToolchain
PROBLEM with cfns.gperf fixes
FIX:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ec1cc0263f156f70693a62cf1…
PROBLEM: a few tex problems in gcc docs, @tex should appear at a line beginning
FIX: https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02100.html
PROBLEM: newlib.../libc/sys/arm/trap.S:88: Error: lo register required -- `sub
ip,sp,ip'
FIX: https://sourceware.org/ml/newlib/2011/msg00140.html
FIX: add --disable-newlib-supplied-syscalls
Craig
2357
days inactive
2360
days old
baseband-devel@lists.osmocom.org
7 comments
5 participants
participants (5)
-
Craig Comstock -
craig＠unreasonablefarm.org
-
Harald Welte -
Mychaela Falconia -
Vadim Yanitskiy