Re: FreeCalypso progress update
Hi DS! > This is excellent news! The calibration report looks really good too. Further update: I got an email from R&S saying that the unit has been shipped, and tracking indicates that I should be getting it on Monday. > Apparently your unit has a WCDMA option installed? Yes, it does, and it is not a particularly rare option: most CMU200 units on ebay are configured similarly to mine, including GSM, UMTS (WCDMA), a B11 or B12 OCXO and an AuxTx generator (either B95 or B96). Some also have additional hw and sw for CDMA2000, although mine doesn't have it. I am not really interested in the Verizon/Sprint- style Amerocentric, SIM-less, non-international CDMA2000 standard, but UMTS is a different story - given that UMTS belongs to the same larger family as GSM and given that TI did have a dual-mode GSM+UMTS protocol stack which I would love to liberate some day, I certainly like having UMTS/WCDMA RF testing capability. > Although it's not > really needed for Calypso or even LoCosto, perhaps it might come in > handy if you'd like to venture into 3G I would *love* to be able to venture out into 3G/UMTS land and build dual-mode phones and modems with the user having absolute total control over the network search preference order (prefer 2G over 3G or vice-versa), but the biggest current obstacle in that direction is the lack of a protocol stack implementation for UMTS. Most people in the "I want a libre phone" scene keep lamenting about low-level hardware specifications for chips being withheld, but they keep missing the much bigger problem. Even if Qualcomm or MTK or whoever were to release the full register etc docs for one of their chips, that full documentation would still be mostly useless without the source code for their complete turnkey product implementation. Cellular protocol stacks of end user product quality (as opposed to toy quality like OsmocomBB) are among the most complex software works in the world, and I consider it absolutely infeasible to even think of trying to implement one from scratch, even if there is an underlying hw platform with absolutely perfect and complete documentation. A job like this would require 1000 person-years minimum. Instead I firmly believe that the only practically feasible way to gain a libre mobile solution for 3G/UMTS that would be no worse than what we currently have for GSM/2G with FreeCalypso would be to obtain and liberate the source code for some *already existing* commercial implementation of the necessary protocol stack, similarly to how our current 2G solution came about. But there is an even further complication. Suppose we were to find some firmware source from, say, MTK that supports 3G. If the vendor is someone other than TI, that firmware's internal architecture would be completely different from TI's, all surrounding software tooling would need to be completely different, meaning that absolutely all of the work we have done in FreeCalypso would need to be thrown out, and we would have to restart from scratch working our way around the other vendor's software architecture and paradigm. Thus based on the reasoning above, what I really want is a 3G/UMTS protocol stack in full source form not just from anyone, but specifically from TI. As far as I know, TI's 3G implementation never saw much widespread use (unlike their 2G stuff which used to be super- popular), as TI killed that baby and threw everything in the trash just as they were getting their 3G code into good shape. Given how little life that code saw outside of TI (if any at all), I'm guessing that the only way to get a hold of it would be to find someone at TI who remembers that they once were in that business and convince them to sell it. It needs to be kept in mind that back in 2008-2009 TI were actively looking for someone to buy their unwanted Wireless Terminal Chipset Business Unit - for someone to buy that entire division wholesale, that is - but when they *failed* to find an interested buyer (both MTK and Qualcomm already had their own stuff, and no one else saw any point in trying to compete with them based on TI's lagging stuff), they threw everything in trash. Given that they currently make ZERO money from the "IP" which they threw in the trash, I don't see why a rational manager would refuse to sell it, but finding someone who would think rationally would probably be the most difficult part... Hasta la Victoria, Siempre, Mychaela aka The Mother ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FreeCalypso progress update
Hi Mychaela, This is excellent news! The calibration report looks really good too. Apparently your unit has a WCDMA option installed? Although it's not really needed for Calypso or even LoCosto, perhaps it might come in handy if you'd like to venture into 3G (after all, the GSM network will be turned off eventually). --DS ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FreeCalypso progress update
Hi DS! > Many thanks for the update, Mychaela. Do you think R&S might be > convinced to lower their quote by letting them know you are just > a single individual in charge of a FOSS project, not a very large > corporation with billions of $? Good news: the issues with our CMU200 have been resolved without having to involve any expensive repairs. The technical person at R&S (as opposed to the non-technical customer service front end people who originally gave me that outrageous price quote) told me there were two issues: 1) The tech fellow said that there were two ribbon cables loose inside the unit. I am quite sure that I did not pull any ribbon cables loose when I was replacing that Rx/Tx board, so either they came loose in shipping, or someone was tinkering inside this unit with insufficient clue prior to me. Once the fine folks in Maryland reconnected those cables, the EEPROM reads which originally failed started working. 2) I don't know what kind of tables are stored in which EEPROM, but the helpful gentleman from R&S said: > After further review, it appears the RXTX module that was replaced had > incorrect tables loaded (probably from its previous location). We were > able to complete corrections and load them to the EEPROM's. After this > was done, the unit worked fine. Of course it is a given that whatever tables were loaded in the EEPROM on that transplanted Rx/Tx board had to be incorrect for the new put-together CMU200 configuration and needed to be corrected through calibration - but I am guessing that because of the transplant, they were incorrect in some more serious way that R&S's "regular" calibration procedure was not prepared for. In any case, the outcome is that the incorrect EEPROM tables have been corrected, the unit has been fully calibrated, and they already sent me the calibration certificate with detailed tables and charts of the unit's exact performance after the calibration, which look beautiful: https://www.freecalypso.org/members/falcon/calibration/CD_5000-309076293.pdf They haven't told me if they already shipped the calibrated CMU200 back to me or if they are still in the process of packing it or doing the paperwork or whatever, but it shouldn't be much longer before it is back in my motherly FreeCalypso lab. They haven't charged my card yet, but I expect the charge to be what I originally agreed to for the calibration - $1405.00 USD, which is perfectly reasonable for the perfect calibration and semi-repair job they did, not the other $6415 repair quote which was NOT reasonable. Hasta la Victoria, Siempre, Mychaela aka The Mother ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FreeCalypso progress update
Many thanks for the update, Mychaela. Do you think R&S might be convinced to lower their quote by letting them know you are just a single individual in charge of a FOSS project, not a very large corporation with billions of $? About SMS btw, it reminded me of a bug (or rather lack of feature) on my old Nokia phone (circa 2001): it does not handle single messages composed of multiple SMS correctly, showing them separately instead. This is typically something where the ability to fix the code, which FreeCalypso provides, really helps. --DS ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
FreeCalypso progress update
Hello FC community,
I've been asked for a status update, so here it is...
My primary FreeCalypso activity right now is exchanging emails back
and forth with Rohde&Schwarz people at their service center in
Maryland - I sent my CMU200 to them to have it externally calibrated,
as I had no way of knowing where its measured and generated signal
power levels stood relative to the real truth. The good news on that
front is that they already sent me an incoming test report showing the
state of the unit as it came to them, and among other things that
report shows the power level offsets which I was after, i.e., exactly
how the power level measurements reported by this CMU200 and the
signal levels it generates differ from the true value. Thus even if I
take the option of having them send the unit back to me without doing
anything to it, I can use the numbers from their report to adjust the
power levels in our software (fc-cmu200d).
There is also a complication, however, in that the non-technical front
end customer service people told me that the unit needs repairs before
it can be calibrated, accompanied by an exorbitant price quote for
said repairs. Thankfully they also offered the option of sending the
unit back to me without doing anything to it for half of the original
calibration price quote (which I would be OK with as the price for the
report giving the very important power level offset data which we
didn't have before and had no other way of obtaining), and I may very
well end up going with that option - but first I am trying to extract
as much technical info out of them as I can regarding what they think
is wrong with this CMU200 beyond it being out of calibration after the
internal module swap which I did to repair it earlier. The process of
extracting this additional technical info out of them is moving
slowly, and it will probably be another few days before we reach a
decision as to whether they are going to send the instrument back to
me as-is or if we are going to agree to some reasonably-priced repair
or calibration services.
On the FCDEV3B front, we now know that we can fix the sleep mode
problem by populating the smaller flash+RAM chip that was used by
Openmoko; the next step in the investigation is to figure out if we
can make the sleep mode problem go away *without* giving up our larger
RAM and flash capacity copied from the Pirelli DP-L10. Between the
back-and-forth with R&S Maryland and other life business (outside of
FreeCalypso) which I need to attend to, it will probably be another
couple of weeks before I'll be ready to schedule the next hardware
rework experiment session with Technotronix, but the actual experiment
plan is already set: we are going to try upping the bypass capacitors
on the V-FLASH and V-SRAM power nets. (Note that these are the
internal power nets from Iota regulators to the memory IC, *not* the
input power to the board or the SIM power net which someone on this
list kept harping about some months back.)
In between all of the above, I am using my idle cycles in between
interrupts to progress slowly toward the end user phone goal, i.e.,
working on various software pieces that are needed toward that goal,
but which are currently missing or broken. There is little in the way
of sequential ordering: there is a large set of software pieces which
need to be implemented or fixed, all of them are needed before we can
have any kind of usable phone, but they can be worked on in any order
for the most part. Thus I pick the piece to be worked on based on
feelings.
Right now I am tackling SMS storage and the tools needed for working
with this storage. The code we got from TI has non-broken support
only for storing messages on the SIM, both received and sent ones, in
both AT command modem and self-contained handset configurations.
There is also a provision for storing messages in the Calypso device's
own flash file system ("on the phone" or in the modem, depending on
one's point of view), but it is broken; TI's UI code never attempts to
enter this mode, and commanding it with AT+CPMS would put the SMS
subsystem into a non-working state.
The current broken implementation of in-modem or "on the phone" SMS
storage ("ME" storage in AT+CPMS terms) is based on the old and highly
inefficient PCM API from Condat, and for this reason I am not
particularly interested in trying to fix it in its present form -
instead I would like to reimplement it in my own different way. Aside
from changing the way in which the storage is implemented in terms of
FFS facilities (flash usage and access efficiency issues), I would
like to add a local timestamp to each stored message. When SMS
storage is implemented according to the public and vendor-neutral GSM
standards, i.e., when the messages are stored on the SIM, received
messages only have a network timestamp set by the SMS Service Centre
(the network component that does the store and forward), whereas sent
messages have no timestamps at all.
Re: FreeCalypso progress update
Hi Josh, Thanks for participating in the discussion :) With regards to FPGAs, my understanding is that it would require porting all of TI's DSP code from C64x to VHDL, plus some massive work on the RF frontend to deal with digital IQ instead of analog IQ. There would also be problems with power consumption I believe (making it less for mobile applications). So it's feasible but probably very hard. --DS On Wed, Aug 02, 2017 at 11:01:02PM +0100, Josh Branning wrote: > Hi, > > As a lurker. You probably already know this but just a word of advice, > > In regards to the FPGA board, you will probably be after the ICE40, > as AFAIK, it is the only one with an open source toolchain (that is, > if it meets your requirements). > > Josh > > > P.S. > > I would be also be interested to know the feasibility of a > semi-complete open hardware/software cellular modem/sdr could be > built out out of this (or this sort of) FPGA. I know there is open > source verilog code for an generic FM receiver out there, and am > aware that all-digital phase locked loops and pulse width modulation > can work in silicon (with a few issues). I also realize that some > companies are already selling similar (lime micro) albeit with a > closed toolchain and HDL code ... so perhaps. ¯\_(ツ)_/¯ > ___ > Community mailing list > Community@freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FreeCalypso progress update
Hi, As a lurker. You probably already know this but just a word of advice, In regards to the FPGA board, you will probably be after the ICE40, as AFAIK, it is the only one with an open source toolchain (that is, if it meets your requirements). Josh P.S. I would be also be interested to know the feasibility of a semi-complete open hardware/software cellular modem/sdr could be built out out of this (or this sort of) FPGA. I know there is open source verilog code for an generic FM receiver out there, and am aware that all-digital phase locked loops and pulse width modulation can work in silicon (with a few issues). I also realize that some companies are already selling similar (lime micro) albeit with a closed toolchain and HDL code ... so perhaps. ¯\_(ツ)_/¯ ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FreeCalypso progress update
Hello FC community, Time for yet another status update: * In terms of priority, my current highest one is getting the next batch of 12 FCDEV3B boards assembled. As I already mentioned, I have decided to *not* wait for the resolution of the sleep mode hw bug, i.e., not block the assembly of the next batch of boards until this issue is resolved, thus unless some miracle happens, these next boards will most likely also suffer from the sleep mode bug, and sleep will need to be disabled for reliable operation - I will ship those boards out with a firmware image that has sleep disabled by default. Running with sleep modes disabled should be perfectly acceptable for all of the major uses for which the FCDEV3B is intended, where it is powered from a supply that ultimately takes the power from AC mains, as opposed to truly mobile operation on a battery: given the form factor and interface requirements of these boards (the need for control from a computer), it is difficult for me to imagine how someone could use one of these boards in a truly mobile application where battery life and thus sleep modes would matter. It should be possible to run the FCDEV3B on a battery, connected to a laptop that also runs on its battery, to test mobile functionality like cell reselection, location updates and handover, but such tests are expected to last hours, not days, thus once again the higher battery draw in idle mode due to not working sleep modes should not be a real issue. * Investigating the sleep mode hw bug and doing everything we can to try to fix it is still on the agenda, but it is something I plan on working on after we make the next batch of boards, not before. Based on this reasoning, my plan to buy my own oscilloscope for my home lab is still on, but in terms of allocation of my personal funds it will once again be after the assembly of the next batch of 12 boards. I plan on covering the assembly cost of this next batch (probably somewhere around $1200 USD, assuming that Technotronix charge me the same per-board price as on the previous batch) with my own funds: I still owe boards to a couple of people who have contributed to the initial crowdfunding campaign, so I am not going to ask anyone for any more money until I fulfill those obligations, which I plan on doing from this next batch. * The only issues that remain to be resolved before I give the go-ahead to Technotronix to assemble the next batch of boards are the on-board loudspeaker and microphone circuits. The next step on this front is that I need to have the J312 two-post header desoldered from one of my current test boards and to have the wires from the speaker soldered in its place. I may need to make a trip to Technotronix for this rework, or I might be able to convince the lab technician at my day job to help me. Once the loudspeaker is connected reliably, I will do one more round of loudness tests and will most likely end up needing to up a pair of 0402 resistors from 10 kOhm to 18 kOhm to increase the gain of the amplifier. The needed 18 kOhm resistors are on order from Digi-Key. * The microphone circuit has not been tested at all yet, as I am focusing on the loudspeaker first. If the loudspeaker works but the microphone does not, I may go ahead with the next batch of boards anyway and tell people who need voice input functionality to use the external digital voice interface (MCSI) for it. * Speaking of MCSI, *after* I assemble the next batch of boards and buy my own oscilloscope, I am going to use that scope to determine empirically whether our Calypso DSP puts MCSI into master or slave mode when commanded into what TI called the "Bluetooth headset" mode. Once we know whether it is master or slave (the critical piece of knowledge needed before anything else can be done), I plan on getting one of the readily available and inexpensive FPGA boards, connecting it to the MCSI signals on our FCDEV3B, and building a demo project on that FPGA board that proves a working digital audio interface to our FreeCalypso modem. * Once I get my own o'scope and get back to the investigation of the sleep mode hw bug, a very important avenue of investigation will be comparing the scope-observed behaviour at various test points on our FCDEV3B against an Openmoko-made GTA02, which is essentially the same hw, but does NOT exhibit the bug. Toward that end, I performed a very important experiment last night: on the bare GTA02 I have which I have powered from a bench supply via alligator clips on the battery connector, I have reflashed the firmware to our own FC Magnetite which can take AT commands over RVTMUX (over the external headset jack), inserted a SIM into the socket on that bare GTA02 MB (the exact same SIM with which AT+CFUN=1 causes a self-reboot on FCDEV3B boards with small sleep enabled), and confirmed that the same AT+CFUN=1 command succeeds on this bare GTA02 MB with all sleep modes enabled. This confirmation is important because it disproves t
FreeCalypso progress update
Hello FC community, It's time for an update on the various things I am working on. In no particular order: * I plan on getting my own oscilloscope for my home lab some time in the next few weeks. I don't have a close enough relationship with any of the hardware people at my day job to use one of their scopes for my personal project, thus in order to do any o'scope probing on our FreeCalypso boards, I need to buy my own scope and set it up at home. My preliminary accounting tells me that I have enough money to buy a scope on ebay (I will have more accurate accounting when I come home this weekend), but the expected delay of a few weeks is because of physical space issues in the room at my home that serves as my FreeCalypso hardware lab, and those space issues stem from the CMU200 problem. I had to take my CMU200 apart in order to check the power levels at the internal Tx path interface from the Rx/Tx board to the RF FE, and right now it sits in my room in a dismantled state, taking up far more space than it would if it were put back together. I didn't want to reassemble and then re-disassemble it a bunch of times, so I left it in the dismantled state while waiting for a replacement Rx/Tx board. That replacement module is on its way to me from a seller in Sweden, but appears to be stuck at postal customs in New York. :-( Once I get my own scope and learn how to use it, I plan on using it for at least two purposes in our project: (1) probing to see if I can spot a transient voltage drop on one of the power rails in connection with the sleep mode self-reboot bug discussed on this list a few days ago, and (2) investigating what should be a digital audio interface on the MCSI pins in the so-called "Bluetooth headset" mode. Having our FreeCalypso modem present a digital voice channel as an alternative to the classic analog one is an important feature for some of our prospective commercial users, and it is also an important feature for us to use in convincing people like the Neo900 project to offer a variant with our FreeCalypso modem instead of their usual proprietary one: those proprietary modems do have digital voice channel interfaces, and it is those digital interfaces, not analog, that are used by projects like Neo900. It appears that we can get a digital voice interface out of the Calypso in the so-called "Bluetooth headset" mode, and I feel that we should seize this opportunity. The problem though is that this digital voice channel is something that almost no one cared for back in the days when Calypso was current, the capability appears to have been added as an afterthought in order to support building Bluetooth-enabled dumbphones with the Calypso, and the details aren't documented anywhere. Therefore, we need to reverse- engineer those details, and this reverse eng process will need to start with putting an oscilloscope probe on the MCSI_CLK line to see if the DSP code we are running (combination of the DSP ROM plus the downloaded patch code we took from TCS211) puts the MCSI into clock master or clock slave mode. * I am waiting for some loudspeaker and microphone parts to arrive from Digi-Key. If they arrive on Friday like FedEx Ground tracking says they should, then I hope to be able to test the loudspeaker driver circuit on our FCDEV3B this Sunday and the microphone input circuit the following week. If the loudspeaker driver and microphone input circuits on our FCDEV3B work, then I will feel comfortable with *finally* releasing the assembly of the next batch of 12 boards. Specifically, I plan on *not* blocking this next batch assembly pending the resolution of the sleep mode bug or pending the completion of the MCSI investigation. Root-causing and solving the sleep mode bug may take a very long time and lots of expensive trial and error, and it is not acceptable for our entire project to remain blocked dead in the meantime. Therefore, we'll have to live with a software workaround in the form of disabling sleep modes, much like Openmoko did with their bug #1024 for the two years or so before they finally fixed it. And for those who would like to use our FCDEV3B modems stationary on a lab bench powered from a supply which itself feeds on AC mains power, it won't make any difference whether the modem has working sleep modes or not. It similarly makes no sense to keep further board assembly on hold while we figure out how the digital voice interface over MCSI works. The mystery to be solved here is how our TCS211 DSP code configures things inside the Calypso chip; at the board level we do nothing more than bring the MCSI signals out to header pins, thus I do not expect any problems at the board level when it comes to MCSI. * As discussed on this list many times before, our current FCDEV3B was originally designed to be a development board, not a module to be integrated into other people's projects as a component - while it is certainly possible to use it in the latter fashion, it is abso
