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/.
Mychaela Falconia mychaela.falconia at gmail.comHello fellow GSM baseband hackers, Harald invited me to share this news with this list, so here it goes: the FreeCalypso project's GSM MS development board with the TI Calypso+Iota+Rita chipset, called FCDEV3B, has been built, and it mostly works, although there are still some issues being debugged. Pictures of this board can be seen here: https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7580.jpeg https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7581.jpeg Now the following part is bad news for me, but probably good news for you guys: right now OsmocomBB works on this board to the point of being able to connect to the live commercial GSM network in my part of the world, send and receive SMS and make a call, but my own preferred firmware is not currently able to the connect to the network (fails in the FB/SB acquisition step) because of the lack of VCXO calibration. To run OsmocomBB on my board, the same version of layer1.highram.bin that is currently built in board/gta0x works unchanged on the FCDEV3B, as my board design is derived from Openmoko GTA02. Both Calypso UARTs are equally accessible on header pins, so use whichever you prefer - tweak board/gta0x/init.c if you prefer to use the IrDA UART - for example, if you wish to use the external serial port when running the same layer1.highram.bin on Openmoko hardware. The on-board SIM socket wired to the Calypso+Iota chipset works - I used this native SIM socket (not an external SIM adapter) for the real SIM used to connect to Operator 310260's live commercial GSM network, and SMS sending and receiving worked without a hitch. After several tries I was also able to dial and connect a voice call - it took several tries, but voice calls from OsmocomBB have always been unreliable for me, even on pre-existing Calypso targets where they work flawlessly with the official firmware. However, the voice path has not been tested yet, as the hardware is not complete enough for it yet. I designed the FCDEV3B with the intent of being able to make test calls from the lab bench without needing anything except the board itself, and for this purpose there is a loudspeaker driver circuit and a microphone input circuit on the board, based on TI's Leonardo schematics. However, the actual loudspeaker and microphone themselves aren't on the board, instead there are headers meant for connecting them. At some point I will need to acquire some loudspeaker and microphone parts, wire them up to the headers and test these on-board audio circuits, but right now there are higher priorities. The following parts do not work properly yet: * There is a flash + external RAM chip on the board, the same part as used in the Pirelli DP-L10, with the gigantic capacity of 16 MiB of flash and 8 MiB of RAM. The external RAM works (I can run the large FreeCalypso firmware entirely from RAM without flashing), and the flash works in that I can erase, program and verify images in both banks of the flash - it is organized as two chip select banks of 8 MiB each. However, some strange problems happen when booting FreeCalypso fw that has been flashed - I will need to hook up JTAG (and exercise that hardware path) in order to debug it further. I am guessing that this problem affects only FreeCalypso and not OsmocomBB, as it is my understanding that you guys have no interest in producing firmware that runs fully on the baseband processor, instead of an attached PC host, and for the purpose of running your teensy-tiny L1 you don't need any flash or external RAM at all. (Sure, one can build a flashable version of this little L1, but what is the point of doing so if you still need to run osmocon in order to talk to it?) * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso) expects per-unit RF calibration to be performed on the production line, and the VCXO calibration appears to be the most critical step: if I delete the VCXO calibration files on an Openmoko-made GTA02, the modem stops working (fails to acquire FB/SB in the network search just like on my FCDEV3B), whereas all other RF calibration files can be deleted and it still works. Hence I reason that the lack of this VCXO calibration is the cause of my current inability to connect to the network from my board using my preferred firmware. Now here is the part I don't understand: how are you able to get away with not requiring RF calibration in OsmocomBB? As I understand it, the requirement that each individual GSM MS unit must be RF-calibrated in production was not specific to TI Calypso, but is a general industry-wide requirement, or at least was in that time period. Per-unit calibration adds to the production test time, time is money, and the calibration equipment (R&S CMU200 is the industry gold standard) is not cheap either - so there is a non-trivial cost to this calibration requirement. So I figure that there must have been some good reason for TI and other mainstream GSM MS chipset manufacturers to require per-unit RF calibration - if they could have dispensed away with this calibration requirement like you did in OsmocomBB, they surely would have done it. So where is the catch? There must be some good reason why TI's TCS211 fw requires VCXO calibration, and when the fw is redesigned to not require such calibration as you seem to have done in OsmocomBB, something else (something important probably) must be sacrificed. So what is the good reason for requiring accurate VCXO calibration, and what is sacrificed when one cheats on this requirement like you seem to be doing? Viva La Revolucion, Mychaela aka Spacefalcon the Outlaw