FCDEV3B project status

Mychaela Falconia mychaela.falconia at gmail.com
Mon May 29 07:58:00 UTC 2017


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~


More information about the Community mailing list