Hello FreeCalypso community, I have written the first draft of the FCDEV3B User's Manual that covers the current state of the hardware and firmware. You can read it here:
https://www.freecalypso.org/members/falcon/fcdev3b/fcdev3b-userman-1.5.pdf Anyone who is considering buying an FCDEV3B should read this manual so you know exactly what you'll be getting and what you'll be able to do with it. At the present time we have just two hardware blemishes, i.e., defects relative to the original design intent: * The sleep mode bug is still there, but it is hidden from the user by both Citrine and Magnetite firmwares being built with DISABLE_SLEEP=1. Given that these are development boards, they will almost always be powered from a supply that ultimately comes from AC mains power, rather than a battery, hence it is very unlikely that having sleep modes disabled will have any practical negative impact on any users, but from my perspective as the Mother, I need to get to the bottom of this sleep mode bug before we can use the FCDEV3B design as a basis for further FreeCalypso hardware product designs. * The loudspeaker acoustic volume is much quieter than I was hoping for. When it comes to the speaker loudness issue, I need to emphasize that the FCDEV3B was designed to be a development board, i.e., a platform for FreeCalypso firmware developers, rather than a building-block component for people to integrate into their whatever designs. If I had been making a building-block modem module, I would have simply brought out the analog audio signals as they come out of the Iota chip, without additional amplifier circuits, and let the user decide what to do with them - that's what I am going to do on the FCM01 (FreeCalypso modem in the SMT module form factor copied from BenQ M32) if anyone ever steps forth to fund that idea. But that is not what we have on the FCDEV3B - instead the FCDEV3B has an extra audio amplifier circuit (copied from TI's Leonardo schematics) between the EARN&EARP output from the Iota ABB and the two-post header where one can actually connect a loudspeaker. The reason why that extra amplifier circuit is there is because of my FC-fw-developer-oriented design intent: I wanted to make the speaker loud enough so that I (with my FC firmware developer hat on) can make test calls during fw development and testing iterations with the board sitting on a lab bench in front of me (and not held up to my ear), and still be able to comfortably hear the call downlink audio. A 32 ohm earpiece speaker of the kind that the Iota ABB can drive directly won't be loud enough for such usage, hence the extra audio amplifier circuit to drive a beefier 8 ohm loudspeaker. I know that what I want is possible because TI did it on their D-Sample platform - a platform specifically for firmware development, just like my design intent for the FCDEV3B. The D-Sample has the same Calypso+Iota chipset as our FCDEV3B and other FC targets (the different RF is besides the point), and TI must have used an external amplifier between one of Iota's outputs (can't tell which one) and the speaker in the handset part of the kit similar to the one in the Leonardo schematics. When I power the D-Sample board from the same supply as I use for the FCDEV3B (remember that our choice of the big orange power input connector was copied from TI's own development boards), get it connected to the network and make a test call, I can comfortably hear the call downlink audio while sitting in front of the lab bench with the hardware setup, without lifting the D-Sample handset part out of its cradle. But the Soberton SP-1510 speaker (part picked arbitrarily from Digi-Key) I have tried connecting to our current FCDEV3B boards is much quieter: the acoustic volume I get out of it is what I would expect from a 32 ohm earpiece speaker driven directly by the Iota ABB, not from an 8 ohm speaker driven by an external amplifier. Obviously I am missing something, but then I readily admit that I am essentially clueless when it comes to audio and speakers. I've got an idea for an experiment to shed some light on this speaker loudness mystery by narrowing down the diffs between our FCDEV3B and TI's D-Sample. On the D-Sample the speaker resides in the handset part, and this handset is attached to the main board via a DB44 connector (44 pins in 3 rows in a DB-sized shell). While we don't have any schematics for the D-Sample, we have such for the I-Sample, as well as a PADS PCB file for the E-Sample. The handset part hasn't changed much in this development platform evolution, so we know with reasonably good confidence which pins on that interface carry the loudspeaker and microphone wires. I have just ordered a free-hanging (solder cup termination) female DB44 connector from Digi-Key, to mate with the male connector on the D-Sample handset part. When this female connector arrives, I am going to solder wires to the pins where I expect the speaker connection to be and connect the other end of these wires to speaker connector J312 on the FCDEV3B, with the effect of connecting the loudspeaker driver circuit on our board to TI's D-Sample handset speaker. Then check the resulting acoustic loudness. The objective of this experiment is to differentiate between poor choice of the physical speaker part vs. issues in our loudspeaker driver circuit. So that's on the speaker loudness issue. When it comes to the sleep mode bug (the other defect), my plan of attack is to narrow down the diffs between Openmoko's working original and our defective semi-clone thereof. I have already ruled out the power supply vs. directly attached battery hypothesis proposed by Kent del Pino - I ruled it out by taking a bare GTA02 motherboard sans case (I got two such boards as scrap from GolDeliCo), powering it from a bench PSU via long wires and not-so-great alligator clips on the contacts meant for the battery, and observing that the sleep mode bug does not occur - while it does occur on FCDEV3B boards powered from the same PSU. The big tantalum cap at C323 which Kent has been picking on is also not the problem, as the D-Sample board has exactly the same arrangement with the same cap in singular quantity, using the same power input connector as we use, but does not exhibit the sleep mode bug. My next experiment will be to buy another batch of Calypso and Iota chips from my trusty Chinese supplier, this time with RoHS balls (the ones I have on hand from 2013 which have been used for the current board builds have SnPb balls), and build another batch of FCDEV3B boards with RoHS solder. Chips with SnPb solder balls can't be a problem in themselves, as they are used on the D-Sample board from 2002 which does not suffer from the sleep mode bug, but perhaps I got chips from a bad batch. Openmoko used RoHS chips and solder, hence it is one more diff between their version and ours which we should try eliminating. If we build another batch of FCDEV3B boards with RoHS chips and solder but the sleep mode bug remains, the next experiment will be to populate Openmoko's original Samsung K5A3281 flash+RAM chip instead of our much larger Spansion S71PL129NC0HFW4B copied from the Pirelli DP-L10. If changing to the smaller flash+RAM chip makes the sleep mode bug go away, it does not mean that I would be happy to give up the extra RAM and flash capacity, but having the culprit narrowed down would greatly aid further work toward a solution. Please remember that the Pirelli DP-L10 which uses the exact same huge flash+pSRAM chip does not exhibit the sleep mode bug. With these thoughts, I am off to bed. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
