FCDEV3B bring-up status

Mychaela Falconia mychaela.falconia at gmail.com
Mon Apr 24 18:57:00 UTC 2017


Hi DS,

> This is an excellent suggestion and I did just that, using a board from
> pldkit. It works very well and I wrote a README for those interested in
> doing the same. Please have a look at
>
> https://www.freecalypso.org/members/ds/ftdi/

Thank you for implementing my idea.  I am going to update
doc/High-speed-serial in freecalypso-tools with this additional
option, and include a link to your implementation.

Meanwhile, I am still working on developing an automated process for
production RF calibration of FreeCalypso hardware devices starting
with FCDEV3B.  The VCXO calibration which I've done manually on one of
the FCDEV3B boards is just the first step, the complete calibration
process required for a fully spec-compliant product also includes Rx
and Tx calibration for each band, and even the VCXO step alone is too
much of a pain to do manually for every board, hence I need to develop
automated calibration before I can finally send a properly calibrated
board to everyone who is waiting for one.

If you look in the freecalypso-tools repository, you will find that I
wrote a bunch of calibration-related notes under doc/RF-cal.  You may
find them to be interesting reading if you are curious about the
calibration adventure.

I am using the CMU200 as my choice of RF test station; I started by
operating it manually through the front panel and that is how I got
that manual VCXO calibration done, but I am now learning how to
operate it programmatically so I can automate the process.  The
industry standard way of controlling such instruments is through GPIB,
but one nice thing about the CMU200 is that it supports not only the
classic GPIB way, but also offers the option of control via SCPI
commands over RS-232.  I chose the RS-232 option to eliminate the need
for exotic hardware and equally exotic drivers and libraries - with
RS-232 I can just write plain old C code without any library
dependencies that talks to a serial port.

I have now learned enough CMU200 SCPI commands to make frequency
offset measurements for the VCXO calibration step and to run its RF
signal generator (will be needed for the next step of Rx calibration),
and now I am starting to implement the code that will test this
knowledge.  I started writing the fc-cmu200d Test System Interface
Daemon that will talk to the CMU200 via RS-232 and present a local
socket interface with higher-level commands; the actual calibration
automation programs will then connect to the latter interface - see
the doc/RF-cal/Architecture write-up.

I need to finish this fc-cmu200d (right now it is just a skeleton,
none of the actual functionality has been added yet), test it manually
with a netcat-like tool talking to its local UNIX domain socket, and
only then we shall reach the point of being able to write the first
automated calibration program for the VCXO step - and then the other
two calibration steps (Rx bands and Tx bands) still need to be
learned...  So there is still a ton of work to be done, and I
guesstimate that it may take me another month or two with the limited
time budget I have for this project - like most people, I have an
entirely separate job to pay my bills.

Aside from RF calibration, we still have the mysterious flash boot
issue on our boards, as well as a power supply issue that requires us
to disable sleep as a workaround.  I suspect that the current
measurement jumpers in the VBAT path may be the culprit.  I added
those jumpers with the idea of being able to characterize the current
draw of the chipset and of the RF PA at different VBAT voltages, in
order to support various kinds of powering arrangements in potential
future FreeCalypso products, but these inserted jumpers in the power
current path may be causing a problem - the power supply current has
to go through these jumpers, they may be adding too much resistance,
and these inserted jumpers are after the big 1000 uF capacitor.

Right now the inserted current measurement jumpers take the form of a
two-post header with a shorting block placed on the pins, and I wonder
if this arrangement may be adding more resistance into the VBAT
current path than is allowed.  One of my planned experiments is to
remove the header pins and solder jumper wires directly into the
corresponding plated through holes on the PCB, using the thickest
gauge wire that will fit into those holes, and see if this change
improves the situation.  But I would like to get a better insight as
to exactly what happens during flash boot on our boards in their
present state before I try any hw modifications, in order to do that I
would like to experiment with JTAG, and for that I am waiting for some
"dupont" jumper wires (female to female) to arrive from Hong Kong.  I
could probably find the needed jumper wires more locally (and thus
faster) with some looking, but right now I am not in a hurry on that
front as the RF calibration software development work still needs to
be done no matter what, and it is not blocked by the flash boot issue
or the sleep issue.

Once we get both RF calibration and the flash boot/power issues solved,
two more steps will be needed before the FCDEV3B can be considered to
be complete:

* There is a loudspeaker driver circuit on the board connected to the
  chipset's EARN&EARP (analog audio output) pins, and a microphone
  input circuit connected to the MICIN&MICIP (analog audio input) pins.
  But the actual loudspeaker and microphone have not been added yet (I
  have not even picked out suitable parts), thus those circuits are
  currently completely untested.  When we reach that point, I will need
  to pick some suitable loudspeaker and microphone parts, connect them
  to the board (the interface takes the form of two-post headers), and
  exercise those audio circuits.  (Can someone else do this test?  As
  I understand it, Serg is not interested in analog audio, but maybe
  someone in Harald Welte's OsmocomBB club will get to trying it
  before I do.)

* The digital audio routing option via MCSI also needs to be exercised,
  and the first step toward that end is to put an oscilloscope probe
  on the MCSI_CLK pin to see if the DSP is operating the MCSI in
  master or slave mode.  Perhaps Serg can do this experiment ahead of
  me.

Hasta la Victoria, Siempre,
Mychaela aka The Mother


More information about the Community mailing list