17 Feb
2011
17 Feb
'11
3:23 p.m.
Hi list,
After some break finally I managed to describe and commit all changes made to MT6235 Linux
port during last one and the half month.
Currently I got full Angstrom Linux distribution running with UI.
Now you can run everything what I'm writing below without changing Sciphone's
original firmware. Just use osmocon to load U-Boot to RAM and SD card which has rootfs
(with Linux kernel placed in /boot/uImage).
For the beginning I chose OPIE, which runs on both versions of Sciphone - with 32MB and
64MB of RAM.
OPIE is based on Qtopia which is lightweight and runs pretty fast on MT6235.
When you run OPIE on Sciphone G2 it works as full blown PDA. In OPIE there is no telephony
support.
I also ran X window server with blackbox and matchbox window managers.
It runs fine with this difference that sometimes I got oops messages concerning memory on
phones with 32MB of RAM . I'll investigate it in the future.
Next step is running SHR and Android (probably only on 64MB versions).
Android will be working very slow, but from marketing point of view "Android" is
magic word so I guess it'll bring more interest into project.
For building Linux distributions I chose OpenEmbedded where you can build a lot of Linux
variations.
To be able to do this I prepared patch which adds Sciphone G2 target and adds U-Boot and
Linux kernel repositories from OsmocomBB project.
All details regarding OE are described on wiki:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
With above patches you're able now to build Linux distribution with any configuration
by yourself (Angtrom, SHR, QTE, OPIE, GPE, etc.).
Video presenting how Angstrom Linux with OPIE is running on Sciphone G2 is placed under
following link:
http://www.youtube.com/watch?v=-_guRruQi0I
As you can see, there is already new OsmocomBB logo. When it's on white background, it
means that U-Boot is running, when it's on black background it menas that Linux is
starting up.
On above video I used phone (32MB of RAM) which has only U-Boot flashed, everything else
is running from SD card.
Unfortunatelly OPIE has a lot of elements on boarders of screen (scrolling, application
close, etc.) and Sciphone's touchscreen has pretty bad quality and it doesn't work
well. You have to be patient while operating it. In the middle of screen it works pretty
well. I'm going to improve touchscreen driver, so hopefully it'll work better.
I prepared ready to load images from above presentation for people who want to try it out
without building:
http://downloads.qi-hardware.com/people/marcin/sciphone_g2_mt6235/images/
Below is short status what's going on now in Linux work.
Peripherals which are already running under Linux:
1) GPIO
2) clocks
3) timers
4) SD card
5) LCD frame buffer
6) touch screen
7) keypad
8) NAND - not yet finished under Linux as I had no motivation to finish it (it fully runs
under U-Boot)
9) RTC - not yet integrated
10) U-Boot has been rebased to newest version and commit history was cleaned -
preparations for mainlining of Sciphone G2 port
Topics on which we're working now:
1) rebase Sicphone's kernel to newest version
2) USB
3) Audio - needs to know how DSP is working
4) Android porting
I hope above software will also run on your devices.
BR,
Marcin
17 Feb
17 Feb
3:57 p.m.
<SNIP awesome announcement details>
First I'd like to just say it's awesome that you are doing this, I've
been following the various efforts to get open software on phones, and
your progress is heartening.
Unfortunatelly OPIE has a lot of elements on boarders of screen (scrolling,
application close, etc.) and Sciphone's touchscreen has pretty bad quality
and it doesn't work well. You have to be patient while operating it. In the
middle of screen it works pretty well. I'm going to improve touchscreen
driver, so hopefully it'll work better.
One thing you might want to look into is translating the touchscreen
interface into a touchpad interface. I use this setup when using VNC
to connect to a desktop system remotely from my phone, and having the
absolute events translated to relative events seems to be the most
usable option for interacting with the tiny desktop elements.
Thanks,
Kevin
<SNIP awesome progress details>
BR,
Marcin
4:12 p.m.
Hello.
On Thu, 2011-02-17 at 16:23, Marcin.Mielczarczyk(a)tieto.com wrote:
After some break finally I managed to describe and commit all changes made to MT6235
Linux port during last one and the half month.
Currently I got full Angstrom Linux distribution running with UI.
Now you can run everything what I'm writing below without changing Sciphone's
original firmware. Just use osmocon to load U-Boot to RAM and SD card which has rootfs
(with Linux kernel placed in /boot/uImage).
Nice progress. :)
For building Linux distributions I chose OpenEmbedded
where you can build a lot of Linux variations.
To be able to do this I prepared patch which adds Sciphone G2 target and adds U-Boot and
Linux kernel repositories from OsmocomBB project.
All details regarding OE are described on wiki:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
Are you planning to change the OE patch soon or would you like to get it into
the OE tree? If you are fine with its current state I could review it for you
and push it when it is ready. (Well, Holger could do it as well but I think he
is busy enough :))
regards
Stefan Schmidt
18 Feb
18 Feb
8:56 a.m.
Hi Stefan,
Are you planning to change the OE patch soon or would
you like to get it into the OE tree? If you are fine with its
current state I could review it for you and push it when it is ready. (Well, Holger could
do it as well but
I think he is busy enough :))
For initial support of Sciphone G2 this patch is sufficient and I don't plan to change
anything at the moment.
Probably while building new features there will be need to add new options, but then I can
create incremental patches.
In this case I'm definitely fine to get this patch in OE tree. You can only change PV
variable in "linux-mtk_git.bb" recipe to 2.6.37 wich will be available on
OsmocomBB repository today.
Thank you for support.
BR,
Marcin
9:11 a.m.
Hello.
On Fri, 2011-02-18 at 09:56, Marcin.Mielczarczyk(a)tieto.com wrote:
Good.
Are you planning to change the OE patch soon or
would you like to get it into the OE tree? If you are fine with its
current state I could review it for you and push it when it is ready. (Well, Holger could
do it as well but
I think he is busy enough :))
For initial support of Sciphone G2 this patch is sufficient and I don't plan to
change anything at the moment. Probably while building new features there will be
need to add new options, but then I can create incremental patches.
Indeed. Thats easy enough.
In this case I'm definitely fine to get this patch
in OE tree. You can only change PV variable in "linux-mtk_git.bb" recipe to
2.6.37 wich will be available on OsmocomBB repository today.
Great. I will do some review and testing tomorrow to get the patch in.
Thank you for support.
No problem.
regards
Stefan Schmidt
17 Feb
17 Feb
4:42 p.m.
Coincidently, I had rebased Marcin's kernel to 2.6.37. You can find it
under "target/linux/mt623x" of this OpenWRT port:
http://ac.nl.eu.org/mt623x/
Regards,
André
On 17/02/11 15:23, Marcin.Mielczarczyk(a)tieto.com wrote:
1) rebase Sicphone's kernel to newest version
18 Feb
18 Feb
8:59 a.m.
Coincidently, I had rebased Marcin's kernel to
2.6.37. You can find it under "target/linux/mt623x" of this
OpenWRT port: http://ac.nl.eu.org/mt623x/
Thanks for information. Wolfram Sang have written me already that he also rebased Sciphone
G2 kernel to newest one without issues, so I don't expect problems here. Today
I'll commit rebased kernel to OsmocomBB repository.
BR,
Marcin
2:40 p.m.
Hi Marcin,
awesome work again! One comment:
Today I'll commit rebased kernel to OsmocomBB
repository.
Please don't rebase against linux-next again. Latest tag should be fine
(2.6.38-rc5 as of now); Russell has a devel-branch you can check your
patches against shortly before sending them (when they are ready).
Regards,
Wolfram
10:40 a.m.
This is a very nice effort. I have an HTC Kaiser running FroYo, and I would
like to add some observations based on this phone, which is more capable in
every respect than the G2. The Kaiser is just barely adequate. While the G2
can run Linux, and by extension, Android, it's just too underpowered to make
it usable, IMHO. I haven't seen Android on more modern hardware, but I
imagine it would be similar in responsiveness to the iPhone 4, which is VERY
smooth. It's too bad that there doesn't seem to be any alternative that is
responsive enough on lighter, but still capable, hardware like this.
11:17 a.m.
There isn't any good open source alternative to run on this but one
could be crafted I guess. There's Meego which has a Qt interface that
could be slimmed down and should run on Qt on the framebuffer and
there's also some open source Qt stuff for Symbian that might be
portable to Linux.
This is just an idea but I'm planning on investigating this as it
certainly sounds better to me than Android. I like Qt and C++ better
and it's better option for such a low end configuration anyway.
P.S. : Sorry for the offlist response , damn gmail
- Hide quoted text -
On Fri, Feb 18, 2011 at 2:40 AM, Scott Weisman <sweisman(a)pobox.com> wrote:
This is a very nice effort. I have an HTC Kaiser
running FroYo, and I would
like to add some observations based on this phone, which is more capable in
every respect than the G2. The Kaiser is just barely adequate. While the G2
can run Linux, and by extension, Android, it's just too underpowered to make
it usable, IMHO. I haven't seen Android on more modern hardware, but I
imagine it would be similar in responsiveness to the iPhone 4, which is VERY
smooth. It's too bad that there doesn't seem to be any alternative that is
responsive enough on lighter, but still capable, hardware like this.
11:32 a.m.
Guys,
this is a mailinglist about runnign custom Free Software on the _Baseband_
processor of a telephone.
Please keep it on-topic. This is not a discussion forum for the various
official or unofficial Linux ports to application processors in phones
(like htc-linux, iphone-linux, Openmoko, OpenEZX, etc.)
Thanks.
--
- 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)
11:50 a.m.
Maybe it's more blue sky than current focus, but these goals are on the wiki
page (http://bb.osmocom.org/trac/wiki/MasterPlan) as long term goals:
- Port some minimalistic RTOS that already supports ARM7TDMI well to the
Calypso
- Attempt to move L2 from PC into the phone
- Attempt to move l3 from PC into the phone
Maybe the page needs to be updated if the above are no longer goals of the
project.
Scott
On Fri, Feb 18, 2011 at 12:32 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Guys,
this is a mailinglist about runnign custom Free Software on the _Baseband_
processor of a telephone.
Please keep it on-topic. This is not a discussion forum for the various
official or unofficial Linux ports to application processors in phones
(like htc-linux, iphone-linux, Openmoko, OpenEZX, etc.)
Thanks.
--
- 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)
1:19 p.m.
On Fri, Feb 18, 2011 at 12:50:37PM +0200, Scott Weisman wrote:
Maybe it's more blue sky than current focus, but
these goals are on the wiki
page (http://bb.osmocom.org/trac/wiki/MasterPlan) as long term goals:
- Port some minimalistic RTOS that already supports ARM7TDMI well to the
Calypso
- Attempt to move L2 from PC into the phone
- Attempt to move l3 from PC into the phone
Maybe the page needs to be updated if the above are no longer goals of the
project.
I don't understand your comment. The ARM7TDMI that we are talking about is
the _baseband_ processor. The long-term goals still exist as they stand in
the wiki.
What has been discussed previously on this thread (and triggered my response)
was running Linux on HTC phones and the like. That was about the _applicaiton_
processor.
Marcin's work is different, as we are talking about a port of Linux to the (in
this case ARM926EJS) _baseband_ processor of a phone.
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)
2:42 p.m.
I have to apologize, because I think I am missing something here. Does the
G2, or any of the phones that OsmocomBB currently supports, have more than
one ARM CPU? I vaguely recall reading an email on this list that one of the
ways the G2 was able to keep costs down was not have separate baseband and
app CPUs. Plus, all the wiki pages I've read, seem to indicate not.
I don't understand your comment. The ARM7TDMI that we are talking about is
the _baseband_ processor. The long-term goals still
exist as they stand in
the wiki.
What has been discussed previously on this thread (and triggered my
response)
was running Linux on HTC phones and the like. That was about the
_applicaiton_
processor.
Marcin's work is different, as we are talking about a port of Linux to the
(in
this case ARM926EJS) _baseband_ processor of a phone.
3:27 p.m.
From what I understand MT6235 has just one ARM926EJS processor and a
DSP. This probably means that the it runs both the application and
the GSM stack on a single CPU , right ?
I read in an article about Symbian that it's able to do this because
it's a realtime OS but to my knowledge Linux is not ( hence the GSM
stack runs on a second processor in Android phones ). Now I also know
there's a realtime Linux kernel but the question is would it be
possible to run both the application and GSM stack together on the
MT6235 under Linux.
Please excuse my question if they're newbish.
Thanks.
On Fri, Feb 18, 2011 at 6:42 AM, Scott Weisman <sweisman(a)pobox.com> wrote:
I have to apologize, because I think I am missing
something here. Does the
G2, or any of the phones that OsmocomBB currently supports, have more than
one ARM CPU? I vaguely recall reading an email on this list that one of the
ways the G2 was able to keep costs down was not have separate baseband and
app CPUs. Plus, all the wiki pages I've read, seem to indicate not.
I don't understand your comment. The ARM7TDMI that we are talking about
is
the _baseband_ processor. The long-term goals still exist as they stand
in
the wiki.
What has been discussed previously on this thread (and triggered my
response)
was running Linux on HTC phones and the like. That was about the
_applicaiton_
processor.
Marcin's work is different, as we are talking about a port of Linux to the
(in
this case ARM926EJS) _baseband_ processor of a phone.
3:52 p.m.
On Fri, Feb 18, 2011 at 3:27 PM, Marius Cirsta <mforce2(a)gmail.com> wrote:
From what I understand MT6235 has just one ARM926EJS
processor and a
DSP. This probably means that the it runs both the application and
the GSM stack on a single CPU , right ?
I read in an article about Symbian that it's able to do this because
it's a realtime OS but to my knowledge Linux is not ( hence the GSM
stack runs on a second processor in Android phones ). Now I also know
there's a realtime Linux kernel but the question is would it be
possible to run both the application and GSM stack together on the
MT6235 under Linux.
Please excuse my question if they're newbish.
Under Linux probably not, under RT Linux maybe. Depends on the amount
of work done by DSP, CPU load by applications etc... Nothing prevents
you to implement stack and applications handling on the single CPU
except performance limitations (but you should have in mind memory
isolation, security issues, etc).
As a matter of fact, what becomes more and more attractive now days
are L4 hypervisors, which could separate BB and APP system in the
separate containers, running on the same CPU.
BR,
Drasko
BR,
Drasko
6:57 p.m.
Hi,
On Fri, Feb 18, 2011 at 03:52:53PM +0100, Drasko DRASKOVIC wrote:
As a matter of fact, what becomes more and more
attractive now days
are L4 hypervisors, which could separate BB and APP system in the
separate containers, running on the same CPU.
The only reason why commercial companies (most notably ST-Ericsson) with
proprietary GSM stacks use this is to make sure they don't have to release any
of their proprietary code under GPL.
There is absolutely no technical reason why you cannot do a GSM L1 inside
the regular Linux kernel. You just have to do it in a GPL-compatible way :)
--
- 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)
9:04 p.m.
On Fri, Feb 18, 2011 at 6:57 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi,
On Fri, Feb 18, 2011 at 03:52:53PM +0100, Drasko DRASKOVIC wrote:
There is always a way to insert your PS code in some FOSS system and
keep it closed. You can use any BSD licensed system.
Apparently with L23 you can do this with Linux, since you are in the
userspace, so you do not have to link with GPL'd kernel. L1 can be a
baremetal app running side by side with your kernel.
I would not say that L4 is used only to close code. It gives you
opportunity to clearly separate several systems running on the same
core, and have them communicate between themselves in a standardized
and secure way. It can also serve as a powerful HAL and can come into
play with security requirements. I think we'll be looking a lot of
into this in the future... but that's just my $0.2.
BR,
Drasko
As a matter of fact, what becomes more and more
attractive now days
are L4 hypervisors, which could separate BB and APP system in the
separate containers, running on the same CPU.
The only reason why commercial companies (most notably ST-Ericsson) with
proprietary GSM stacks use this is to make sure they don't have to release any
of their proprietary code under GPL.
6:55 p.m.
On Fri, Feb 18, 2011 at 07:27:59AM -0700, Marius Cirsta wrote:
From what I understand MT6235 has just one ARM926EJS
processor and a
DSP. This probably means that the it runs both the application and
the GSM stack on a single CPU , right ?
It's actually 2 DSP cores. But yes, your last statement is correct.
I read in an article about Symbian that it's able
to do this because
it's a realtime OS but to my knowledge Linux is not ( hence the GSM
stack runs on a second processor in Android phones ). Now I also know
there's a realtime Linux kernel but the question is would it be
possible to run both the application and GSM stack together on the
MT6235 under Linux.
Don't believe marketing crap by any company (or the Symbian foundation) ;)
Layer 2 and Layer 3 of GSM have no realtime requirements, it's only the L1
that has. Running L1 inside the kernel in IRQ priority should solve all those
problems. If not, we can still use the FIQ to pre-empt all the other IRQs
in the kernel.
Layer2 + Layer3 then run as regular userspace programs on top of the kernel.
The entire' "realtime vs. non-realtime" debate often seems nothing but
a religious and/or marketing war.
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)
7:54 p.m.
On Fri, Feb 18, 2011 at 7:55 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
I usually don't but since I have only basic knowledge in telecom I
thought what they said was true and it did acutally make sense.
On Fri, Feb 18, 2011 at 07:27:59AM -0700, Marius
Cirsta wrote:
Didn't read the datasheet that well it seems.
From what I understand MT6235 has just one
ARM926EJS processor and a
DSP. This probably means that the it runs both the application and
the GSM stack on a single CPU , right ?
It's actually 2 DSP cores. But yes, your last statement is correct.
I read in an
article about Symbian that it's able to do this because
it's a realtime OS but to my knowledge Linux is not ( hence the GSM
stack runs on a second processor in Android phones ). Now I also know
there's a realtime Linux kernel but the question is would it be
possible to run both the application and GSM stack together on the
MT6235 under Linux.
Don't believe marketing crap by any company (or the Symbian foundation) ;)
Layer 2 and Layer 3 of GSM have no realtime
requirements, it's only the L1
that has. Running L1 inside the kernel in IRQ priority should solve all those
problems. If not, we can still use the FIQ to pre-empt all the other IRQs
in the kernel.
Layer2 + Layer3 then run as regular userspace programs on top of the kernel.
The entire' "realtime vs. non-realtime" debate often seems nothing but
a religious and/or marketing war.
Thanks for these clarifications , it answers my question. I do have
another one though , out of curiosity. Why do most if not all Android
phone have a separate core for running the GSM stack ? Even MT6516 has
a dedicated ARM 7 core. I cand think of the advantages being isolation
of the GSM stack and keeping it hidden and proprietary but until now I
thought it was a must.
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)
8:56 p.m.
On Fri, Feb 18, 2011 at 7:54 PM, Marius Cirsta <mforce2(a)gmail.com> wrote:
Thanks for these clarifications , it answers my
question. I do have
another one though , out of curiosity. Why do most if not all Android
phone have a separate core for running the GSM stack ? Even MT6516 has
a dedicated ARM 7 core. I cand think of the advantages being isolation
of the GSM stack and keeping it hidden and proprietary but until now I
thought it was a must.
As I said, it is mostly performance issue.
11:22 a.m.
Marcin,
I can only second the other people who have commented: Congratulations
on your great work!
It's good to see that you have still been on track. I was already starting
to wonder after the comparatively long period of silence.
Unfortunately I still haven't had much time to work on the GSM side of the
MTK chipset - though I've spent some 2 days and think I have a farily good
understanding of the architecture and the required drivers for the analog/RF
side.
The biggest unknown part so far is the ARM/DSP shared memory interface, and
the "API" (rather an ABI) that is used to exchange information on it.
I have done some initial research, but given my high workload with other
(interesting + paid) GSM protocol R&D related work, I still cannot make
any promises when we'll actually see some progress here.
If anyone else feels interested to dive into it, feel free to do so.
Especially the RF transceiver driver, TDMA timer driver, etc. should all
be possible to develop right now based on the documentation that is available.
Those of you with a Racal 6103 or similar device should also be able to take
measurements and test the drivers, i.e. whether it tunes to the right Tx
frequency, whether the TDMA timer are firing at the right point in time (power
ramp up/ramp down, ...)
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)
11:46 a.m.
The biggest unknown part so far is the ARM/DSP shared
memory interface, and the "API" (rather an ABI) that is used to exchange
information on it.
I agree, as I have the same problem here to run audio.
I have done some initial research, but given my high
workload with other (interesting + paid) GSM protocol R&D related work,
I still cannot make any promises when we'll actually see some progress here.
No problem.
If anyone else feels interested to dive into it, feel
free to do so.
Especially the RF transceiver driver, TDMA timer driver, etc. should all be possible to
develop right now based on the documentation that is available.
I'm gonna dive into this topic.
That's something where I don't have experience so it'll take me some time to
understand it, but it's worth effort.
As I mentioned some time ago I had adventure with L2/3 development and I'm gonna
refresh my knowledge. I'm also eager to try something new, so I'll be satisfied
stepping down into RF part.
BR,
Marcin
1:23 p.m.
Marcin,
On Fri, Feb 18, 2011 at 12:46:23PM +0200, Marcin.Mielczarczyk(a)tieto.com wrote:
I'm happy to hear this. The problem sort-of is: Do you have the kind of
measurement equipment to facilitate that kind of development? In order to
e.g. test the VCO/PLL / Transmit code, you would have to have something like
a spectrum analyzer or a scope that can go up to at least the GSM900, preferrably
up into 1800/1900 MHz.
If you want to test the receive side, something like a GSM signal generator (HP
8922, Racal 6103, R&S CMD 55) would be great, as they can transmit a well-known
bit pattern (all-1, all-0, 101010101010 and the like) on a configured ARFCN,
then configure the RF Transceiver (MT61400 and you can watch the analog
baseband signal on an oscilloscope and determine if it mathes the expected singal.
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)
If anyone else
feels interested to dive into it, feel free to do so.
Especially the RF transceiver driver, TDMA timer driver, etc. should all be
possible to develop right now based on the documentation that is available.
I'm gonna dive into this topic.
That's something where I don't have experience so it'll take me some time to
understand it, but it's worth effort.
1:46 p.m.
I'm happy to hear this. The problem sort-of is:
Do you have the kind of measurement equipment to facilitate that kind of development?
In order to e.g. test the VCO/PLL / Transmit code, you would have to have something like
a spectrum analyzer or a scope that can go up to
at least the GSM900, preferrably up into 1800/1900 MHz.
If you want to test the receive side, something like a GSM signal generator (HP 8922,
Racal 6103, R&S CMD 55) would be great,
as they can transmit a well-known bit pattern (all-1, all-0, 101010101010 and the like)
on a configured ARFCN, then configure the RF Transceiver
(MT61400 and you can watch the analog baseband signal on an oscilloscope and determine if
it mathes the expected singal.
I have access to such equipment.
I have access to Agilent Spectrum Analyzer E4405B (9kHz - 13.2GHz) and Rohde&Schwarz
CMU200 (Universal Radio Communication Tester, it also has spectrum analyzer).
In this case there're no obstacles to start, only matter of time available for this
project.
BR,
Marcin
4827
days inactive
4828
days old
baseband-devel@lists.osmocom.org
24 comments
9 participants
participants (9)
-
André Černâk -
Drasko DRASKOVIC -
Harald Welte -
kevin granade -
Marcin.Mielczarczyk＠tieto.com -
Marius Cirsta -
Scott Weisman -
Stefan Schmidt -
Wolfram Sang