This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Craig Comstock craig_comstock at yahoo.comThanks 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)