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://firstname.lastname@example.org/.Mychaela Falconia mychaela.falconia at gmail.com
Hi Harald, > (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. 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. > 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~