OsmocomBB hardware migration to SDR

Craig Comstock craig_comstock at yahoo.com
Fri Jun 24 11:02:22 UTC 2016


Thanks Herald!

I was trying to design a very basic working hardware so that more debug/diagnostic capabilities were available such as JTAG and maybe monitor any pin coming out of mt6260 with a scope/analyzer. 

My other hope was to leverage the existing firmware such as embedded at or linkit os/api to confirm the hardware a bit and give me something I could write the UI for earlier.

Basically if I use the sim800h that is a working phone. I break out all if the pins it provides and I hope I have more visibility inside. Granted I suppose with sim800h I no longer have access to that critical dsp/arm interface? I'm not sure.

Thanks again for the encouragement. I did just get fernly running on my dfrobot shield with a sim800h in it! Reported as a 6260, so "game on."

> On Jun 24, 2016, at 3:14 AM, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Craig,
> 
> good to hear that you're working on something as exciting as MTK support
> of OsmocomBB.
> 
>> On Thu, Jun 23, 2016 at 02:56:39PM +0000, Craig Comstock wrote:
>> I hope to make a usable phone. Currently my plan is to dig into the MT6260 as
>> started by the fernly/fernvale project. Current target is the SIM800H which
>> contains the MT6260. I saw both that sysmocom has a $150 fernvale setup and
>> Lime SDR has a USB bare-board for $250+ but I have to stick with something that
>> is "phone" like and so am working on designing a small SIM800H/MT6260-based
>> phone which can be expanded and/or used to experiment.
> 
> I would strongly encourage you not to spend time in designing more
> hardware rather than working on the software side of things.
> Understanding the DSP/ARM interface of mediatek baesband chips is the
> primary key into creating a L1 adaptation of OsmocomBB that works on
> such hardware.
> 
>> If there was something like LimeSDR that was small and less expensive I would
>> go that route. I imagine there will be before long. :)
> 
> I don't think a General Purpose SDR solution will lead to a usable
> phone.  The GP SDR is too large and power hungry to begin with, and
> then you need a host processor that can do all the signal processing,
> and you're suddenly talking more about an embedded PC rather than a
> battery powered phone.
> 
>> Meanwhile, I'd definitely like to contribute as I can to MS software/
>> osmocom-bb. I will do what I can.
> 
> Pleaes do so.  I'm happy to review and give feedback.
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)


More information about the baseband-devel mailing list