Hello FreeCalypso community, Earlier this week I gave the go-ahead to Technotronix to assemble the next batch of FCDEV3B boards. They told me that the assembly price would be the same whether we do all 12 remaining boards at once or just another 8 at first and then the remaining 4, so I told them to do another 8 boards for now.
These new boards are expected to be done some time in late August or early September, and I have been working on the automated production test, batch programming and calibration software for our FreeCalypso device production line: when the boards first arrive from Technotronix, they are naturally untested, and we absolutely need an automated and efficient way to program them with the current production firmware image, verify that they boot correctly, initialize their FFS and run the RF calibration procedure with the CMU200 that exercises the RF tract in both directions for each band. For the first batch of our boards I did all of these steps manually as I reconstructed the lost theory and developed new tools for each calibration step, but it is now time for proper production line automation. The software used on the FreeCalypso device production line currently consists of 3 parts: 1) The same regular FC host tools which are used by our community firmware tinkerers and empowered end users, i.e., fc-loadtool to program the fw image and erase any previous garbage, rvinterf to talk to the newly made board as it boots for the first time, fc-fsio to format and initialize its FFS and set its IMEI etc; 2) FreeCalypso RF calibration tools (fc-rfcal-tools) to perform all of the RF calibration steps that require the CMU200, also serving as a pass/fail test for the RF tract; 3) An in-house FC production shell (fc-prod-shell) that does little more than invoke all of the previously listed programs in the right order; this fc-prod-shell produces a sufficiently high-level operator interface so that the duties of the FC production line operator can be performed by someone who does not necessary know FreeCalypso innards and does not even need any real Unix/Linux command line skills. Part 3 (the streamlined shell for minimally-skilled production line operators) will remain internal to my family company for the time being, as there is absolutely nothing that anyone could possibly do with this software except set up a competing production factory, and it does not do anything which you couldn't trivially do by simply invoking the right tools from the fc-host-tools and fc-rfcal-tools suites. However, part 2 (fc-rfcal-tools) is now public: https://bitbucket.org/falconian/fc-rfcal-tools While I am not too happy about the possibility that our Iranian "friends" (the ones who made their own bastardized derivative of Openmoko's GTA02 while constantly striving to bypass and undercut the FreeCalypso core team at every step instead of working with us) may take this software and use it toward their purely self-serving ends without contributing anything back to our community, I feel that we have reached the point where the value of having the community review this code and possibly help the FC production team with our needs outweighs the negative of making it easier for the Iranians to screw us. Hence the public release I just made. The primary purpose of fc-rfcal-tools software is to be used on the FreeCalypso device production line to test and calibrate the devices we make and sell, and it absolutely requires a R&S CMU200 RF test machine to do anything useful - if you don't have a CMU200, all you can do with this sw is stare at the source code and adore its beauty. :) However, if someone does have the needed R&S CMU200, there are, at least hypothetically, some potential legitimate use cases for the fc-rfcal-tools software besides setting up a competing device production factory: * There exists a slight possibility (unknown to me if such a thing ever happened in reality, but it is at least hypothetically possible) that some hapless Openmoko FreeRunner (or even GTA01) user may have ruined their FFS through careless playing with modem flashing software, especially in pre-FreeCalypso days when this modem was treated as a "thou shalt not enter" forbidden zone and modem flashing software (TI's FLUID, running under Windows) was only available on a hush-hush, whisper-whisper basis. Any FC community member (not just me) should be empowered to open a repair service bureau that can recalibrate Openmoko devices among other services. * Back in the days when non-smart cellphones were repaired rather than discarded, it appears that some of those repair service centers had CMU200 stations for recalibration. It is conceivable that some of the RF calibration parameters may drift over time, thus once again a repair service bureau offering recalibration may be a perfectly legitimate offering. * There are some alien Calypso devices (not made by us or by our predecessor Openmoko) on which we can at least kinda-sorta run our FC firmware, but on which we are unable to grok their original factory calibration data. Mot C1xx phones are the prime example. If we ever get our FC firmware working on Mot C139 (or some other C1xx) in a usable manner, but we are still not able to retrieve their original RF calibration values, we would be running with an uncalibrated radio like we currently do on those phones. If some member of our community steps up to offer new RF calibration (with a CMU200) for FreeCalypso- converted C1xx phones, more power to them. With the public release of fc-rfcal-tools out of the way, here are the remaining calibration-related issues I still need to get resolved: * I recently reran the calibration on a board which I had previously calibrated (as part of testing fc-prod-shell), and was surprised to see that the RF power measurements reported by my CMU200 are now 0.5 dB less than they were previously. At first I thought something was wrong with the FCDEV3B, but then I realized that it is a result of the work I did on the CMU200 itself: I replaced the Rx/Tx module inside to fix the broken main signal generator (the Rx part of the original Rx/Tx module was fine, but the Tx side was dead), and the instrument now reports different RF power readings, 0.5 dB less than before. Which raises the question: are the new measurements low by 0.5 dB relative to the real truth, or were the old ones high by 0.5 dB relative to the real truth? Or is the real truth something else altogether? * My current Tx levels calibration profiles (see txlevels/fcom1* and doc/Tx-cal-theory in the just-released fc-rfcal-tools tree) were created under the assumption that the numbers which my CMU200 reported prior to the internal module swap were the real truth, i.e., what the FCDEV3B transmitter actually puts out. But if the previous numbers were actually high by around 0.5 dB and if the numbers I'm getting now are closer to the real truth, then these profiles are NOT correct. :-( Thus I am reaching the conclusion that I really need to get my CMU200 calibrated, and if I am not able to afford official calibration (which will most likely be the case), at least do an informal calibration: find someone who can lend the use of a *trustworthy* signal generator (i.e., one whose output level is reliably known with 0.1 dB or at least 0.5 dB precision), connect it to my CMU and see what the latter reports. And given the level of precision I am working with, I also need to confirm that the insertion loss of my coax (between the CMU200 and the DUT) really is what I think it is, and if such assurance is not possible with the cheap coax I am currently using, possibly replace it with a more expensive metrology-grade one. At this point I could really use some help from the community with getting my CMU200 and the interconnecting coax calibrated, but in order to be useful, the help would need to be at least somewhat local to me in Southern California. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community