Would like to share some experience trying to calibrate VCXO. I ran the
manual process with CMU200 and everything went okay, just like Mychaela
described. I got different numbers but within the same range and with
similar trend. However an attempt to go against the live network did not
work, the network was starting LUP and apparently could not decode bursts.
So far I stopped any further attempts and will study CMU200 procedures how
to setup proper BS simulation.
The unit I acquired seems to be in good working order and I have 10 MHz
GPSDO connected to it as an external reference.
On Wed, Apr 5, 2017 at 3:22 AM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:
> Hello FreeCalypso community,
>
> Today I have received the 8 assembled FCDEV3B boards from Technotronix,
> and I have powered up one of them. Here are the parts that work:
>
> * The power on/off control in the Iota ABB works: pressing the PWON
> button causes the green LED to turn on and powers up the Calypso,
> pressing the RESET button causes the LED to turn off while the button
> is depressed and turn back on when it is released, power-cycling and
> hard-resetting the Calypso as expected.
>
> * The Calypso chip is alive and the versions of its boot and DSP ROMs
> are as expected: I can run fc-loadtool -h fcfam on either /dev/ttyUSB0
> or /dev/ttyUSB1 (two Calypso UARTs behind my FT2232D adapter), induce
> the boot sequence via either the PWON or the RESET button, and our
> loadagent happily loads and runs. The boot ROM version is 0300 like
> on all other Calypso devices we work with, and the DSP ROM version is
> 3606 as it should be, confirmed when booting FC Magnetite firmware -
> see below.
>
> * The Spansion flash+pSRAM chip copied from the Pirelli DP-L10 also
> works: once in fc-loadtool, I can operate on both of its flash banks,
> and I successfully loaded our FC Magnetite fw image built for the
> fcdev3b target into the flash.
>
> * The firmware boots and is alive on both UARTs: standard AT command
> interface on /dev/ttyUSB0, RVTMUX on /dev/ttyUSB1. There is, however,
> some strange issue with booting from flash (as opposed to fc-xram)
> which I need to investigate further before I can make any intelligent
> observations: it appears that when booting from flash, the fw first
> crashes on boot with an undefined instruction exception, reboots, and
> then boots successfully on the second or some subsequent cycle. So
> far this issue has not been a stopper: usually it does boot after all,
> and the one time I couldn't get it to boot from flash, I booted a
> RAM-based version of the same fw via fc-xram. But of course the issue
> needs to be investigated and solved, and I will probably use JTAG for
> this investigation.
>
> * With a workaround, I was able to bring up the SIM interface, and it
> works: I was able to retrieve the number of my test SIM and see its
> phonebook and SMS storage.
>
> Now here are the problems encountered so far:
>
> * There is a defect in the PCB layout which my Iranian contacts did
> for us on a barter basis when we didn't have the money to hire a PCB
> layout professional on commercial terms: the headers for MCSI, UARTs
> and JTAG (from left to right in this order) are too close together,
> i.e., there is too little gap between adjacent headers. As a result,
> when a ribbon cable is connected to the dual UART header in the middle
> (the most critical of the three), this cable gets in the way of
> connecting to MCSI or JTAG on either side of it.
>
> So far I have connected only the UARTs, but when I need to connect
> JTAG as well (which will be soon as I'll need it in order to
> investigate the mysterious boot issue), I will have to forego the
> convenience of ribbon cables and use individual single wire
> connections as a workaround. Ditto when we reach the point of
> playing with MCSI. A pita, but it will allow us to proceed forward
> with the bring-up.
>
> * The mysterious boot issue described above.
>
> * Without additional workarounds, issuing an AT+CFUN=1 command to the
> fw to bring up the radio and SIM interfaces causes an immediate
> reboot without any indication as to what the problem may be,
> suggesting a problem with the power supplies on the board. However,
> if I issue an AT%SLEEP=0 command (disable all sleep modes) before the
> AT+CFUN=1, then the latter succeeds and the SIM becomes accessible
> as described above.
>
> I need to investigate further what happens in the processing of the
> AT+CFUN=1 command and where the deep sleep or possibly other sleep
> modes come into play.
>
> Finally, the big one: once I was able to get the SIM up with AT+CFUN=1
> after disabling sleep with AT%SLEEP=0, my next try was to bring up the
> radio with AT+COPS=0. Alas, no joy there: from my cursory reading of
> the log (see below), the modem is unable to acquire the frequency burst
> on any of the chan
