Re: FCDEV3B project status
Hi DS, > This is the message I get with sh linked to dash: > ./configure.sh: 19: [: unexpected operator Aha! In Classic UNIX the correct form of the string equality test operator in [ is '=', not '==', and I had it correct everywhere except that one spot: the use of '=' for equality testing is so counter- intuitive that my subconscious mind made me type '==', and apparently bash accepts this non-canonical but so much more intuitive form... I just pushed the fix in the form of changing that '==' to the canonical '='. > I may be wrong, but this is perhaps simply due to the loss caused by the > cable connecting the DUT and the CMU200. You would need to characterize > the cable to know the loss (which could vary depending on the frequency). Yes, of course I thought about this issue, but another related consideration is that the CMU200 itself may be out of calibration: it is a used unit from ebay with unknown calibration history. When I originally bought this unit back in March, I opted for this cheap one rather than one of the more expensive "calibrated & warranty" listings because I needed to climb the CMU200 learning curve first; now that this curve-climbing is done, I can look into getting a properly calibrated setup, either by getting my current CMU200 professionally calibrated or by buying another unit with proven calibration history, whichever will be more economical. But if I am going to get my existing CMU200 professionally calibrated, I need to resolve the non-working main RF generator problem first, i.e., figure out which internal module is defective and replace that module: replacement of internal modules requires subsequent recalibration, so the proper order of steps is to replace whatever module needs replacement first, and then get the unit (re)calibrated. So many necessary to-do steps for just one Mother... > Also looking at http://wera.cen.uni-hamburg.de/DBM.shtml 31dBm corresponds > to 7.93V rms whereas 33dBm is 9.98V rms, which seems quite high and indeed > the power supply could be responsible too. Another important factor to consider is that I had to crank the APC DAC all the way to 900 to get that 31.11 dBm out, and all available evidence tells me that the APC DAC is not supposed to be cranked this high. The calibration tables read out of the several GTA02 and Pirelli units I looked at all have the APC DAC setting for the highest power level in each band somewhere around 600, and in my own run of fc-rfcal-txbasis for the 900 MHz band (output quoted in my previous post) the output numbers stop really increasing once the DAC gets to 600. In my 1800 and 1900 MHz fc-rfcal-txbasis runs they stop really increasing around DAC=700 instead. (What is fc-rfcal-txbasis? Those with trusted access to the temporarily-private FC RF calibration sw can read doc/Tx-cal-theory.) Right now I am just gathering data points, and the next data point I really need is to see what my CMU200 will measure when connected to an Openmoko-made and calibrated GTA02. The special adapter needed for connecting to the RF test port on the GTA02 is in order from Digi-Key and is supposed to arrive 20170602, but I might have my CMU200 down for repair or calibration at that time, so the wait may be even longer... Once again, so many required tasks for just one Mother. M~ ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FCDEV3B project status
Hi Mychaela, > Where do the scripts expect bash? Please tell me the specifics and > I'll fix it, as I never intended to depend on bash. This is the message I get with sh linked to dash: ./configure.sh: 19: [: unexpected operator I'm not sure why this error is printed, your code looks 100% fine to me. Probably something wrong with dash. > APC DAC=900: 31.11 dBm I may be wrong, but this is perhaps simply due to the loss caused by the cable connecting the DUT and the CMU200. You would need to characterize the cable to know the loss (which could vary depending on the frequency). Also looking at http://wera.cen.uni-hamburg.de/DBM.shtml 31dBm corresponds to 7.93V rms whereas 33dBm is 9.98V rms, which seems quite high and indeed the power supply could be responsible too. --DS ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FCDEV3B project status
Hi DS, > Two very minor issues I ran into while compiling: > - on Ubuntu and I presume Debian, /bin/sh links to dash instead of > bash. The configure scripts expects bash, this is trivial to fix. Where do the scripts expect bash? Please tell me the specifics and I'll fix it, as I never intended to depend on bash. > - mokosrec2bin has to be in PATH. I found it in freecalypso-reveng > and compiled it into /opt/freecalypso/bin See doc/Compiling in the fc-magnetite source, lines 30-32. > Now regarding the issue of the VCXO calibration, this is slightly less > easy than I thought since the signal emitted by the DUT is not a pure > signal but GSM bursts. I'll have a look into GNU Radio which has blocks > for GSM provided by gr-gsm. When calibration is done the "official" way, i.e., with a CMU200, the CMU is indeed used in the GSM-specific mode (the GSM-specific, MS- specific, per-band software options must be installed on the CMU200), rather than the generic RF analyzer mode, for both VCXO and Tx power level calibration steps (i.e., for both frequency offset and power measurements), as indeed the DUT transmits GSM bursts in both cases - the only thing that GSM MS hardware can transmit! I've said it many times before, but I'll reiterate: I do not expect FreeCalypso users or even hard-core FC firmware developers to do their own RF calibration, as it is really a *factory* job to be done by *hardware manufacturers*. But if you would like to do your own calibration with GNU Radio instead of a CMU200 just for fun, go for it! :-) I got the VCXO calibration under control back in April, so the board that went to DS had its VCXO already calibrated before it left my lab. Rx "magic gain" calibration was quite easy once I got the Aux Tx generator working on my CMU200 as a substitute for the non-working main RF gen, and it is non-critical anyway as the difference between compiled-in GMagic numbers and properly calibrated ones is tiny. All that is left to be done now is the calibration of Tx power levels. My current stumbling block in that direction is that the highest Tx power levels I can get out of the FCDEV3B no matter how high I crank up the APC DAC are still below the maximum spec-defined power levels. Here is what I am currently getting in the 900 MHz band: APC DAC=70: 0.82 dBm APC DAC=100: 8.83 dBm APC DAC=150: 15.08 dBm APC DAC=200: 18.69 dBm APC DAC=300: 23.38 dBm APC DAC=400: 26.35 dBm APC DAC=500: 28.49 dBm APC DAC=600: 30.20 dBm APC DAC=700: 30.76 dBm APC DAC=800: 30.91 dBm APC DAC=900: 31.11 dBm In the 1800 MHz band: APC DAC=70: -1.70 dBm APC DAC=100: 5.28 dBm APC DAC=150: 11.07 dBm APC DAC=200: 14.88 dBm APC DAC=300: 19.85 dBm APC DAC=400: 23.21 dBm APC DAC=500: 25.62 dBm APC DAC=600: 27.63 dBm APC DAC=700: 28.77 dBm APC DAC=800: 28.96 dBm APC DAC=900: 29.09 dBm In the 1900 MHz band: APC DAC=70: -2.38 dBm APC DAC=100: 4.71 dBm APC DAC=150: 10.74 dBm APC DAC=200: 14.48 dBm APC DAC=300: 19.08 dBm APC DAC=400: 22.04 dBm APC DAC=500: 24.27 dBm APC DAC=600: 26.00 dBm APC DAC=700: 27.31 dBm APC DAC=800: 27.54 dBm APC DAC=900: 27.62 dBm Per the spec, our MS is supposed to put out 33 dBm at the highest power level in the EGSM band and 30 dBm in the DCS and PCS bands, but as you can see in the measurement results above, we are not able to get that high. My planned next steps in this investigation are as follows: 1. See if the VBAT power supply voltage fed to the FCDEV3B makes a difference. Right now I am using one of our super-convenient compact power supplies (the same kind as I sent to DS), and it puts out about 3.7 V. I also have a lab bench power supply on which I can tune the voltage with a knob (for example, see what happens at 4.2 V, corresponding to a fully charged battery), but I sent that power cable to Serg back in April, so I need to make another one. 2. Connect my CMU200 to the RF test port on an Openmoko-made and Om- calibrated GTA02 and see what power levels our "golden reference" hw puts out. I already ordered the necessary RF connection adapter when I got paid on Friday, and now I am waiting for it to arrive. M~ ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FCDEV3B project status
Hi Mychaela, This is extremely good news! On my end, I've been able to test the FCDEV3B board you sent me, and I'm happy to report everything appears to be working fine! I've recompiled fc-magnetite for fcdev3b in the hybrid configuration and flashed it. Then I tried enabling the radio and do a network egistration, which worked without issues. Then I sent an SMS which was also successful. Two very minor issues I ran into while compiling: - on Ubuntu and I presume Debian, /bin/sh links to dash instead of bash. The configure scripts expects bash, this is trivial to fix. - mokosrec2bin has to be in PATH. I found it in freecalypso-reveng and compiled it into /opt/freecalypso/bin Now regarding the issue of the VCXO calibration, this is slightly less easy than I thought since the signal emitted by the DUT is not a pure signal but GSM bursts. I'll have a look into GNU Radio which has blocks for GSM provided by gr-gsm. In any case, it's really great to see FreeCalypso hardware working so well! You've put a lot a work into it, and it's a great success :-) --DS ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
Re: FCDEV3B project status
Hello FC community, I am pleased to announce that the situation with REcon has been worked out and that I will be giving a presentation about FreeCalypso this summer at a major conference: https://recon.cx/2017/montreal/ I also got the reimbursement from them for my flight cost, and I have just placed the order with Digi-Key for both the Molex crimping tool I am going to use to make proper UART and JTAG connection cables for our boards, and the adapter for connecting to the RF test port on Openmoko devices. I will use the latter to connect an Om-made and Om-calibrated GTA02 to my CMU200 and verify my calibration setup: see how my own GMagic calibration for each band compares against the one made at Om's factory, and how the Tx power levels calibrated by Om compare against the spec values, against what I am able to produce on the FCDEV3B and against TI's D-Sample board. Speaking of the D-Sample (TI's historical development platform of which I managed to score one back in 2015), that board has the same power input connector and the same SMA RF interface as our FCDEV3B (I deliberately chose the same connectors and a few other parts for our design as TI used on their historical dev platforms), so I can use almost the same hardware setup with the D-Sample as with our own board. I still have no way to build my own firmware for this D-Sample, as it has Clara RF and an earlier Calypso chip version, so I'm limited to running the ancient 20020917 fw it came with, but TI's L1/RF Test Mode command interface had not really changed in all those years, and so both fc-tmsh and my temporarily-unpublished RF calibration software work just fine with this ancient fw on the D-Sample! I plan on doing some more work on the calibration software this weekend, or maybe even tonight. Hasta la Victoria, Siempre, Mychaela aka The Mother ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
