FCDEV3B sleep mode bug update

[Mychaela Falconia]

Hi DS!

> First of all, congratulations on this new breakthrough!

Well, it is not quite a breakthrough yet, only a hypothesis (so far
unproven) that FDP going low during sleep and driving the flash reset
is the culprit, but the fact that the Pirelli has FDP disconnected
from this flash reset line is strong evidence in support of it.  We
still need to test it properly to be certain.

> About the new batch of FCDEV3B: as this would be quite expensive,
> don't you think it'd be perhaps best to set this money aside for the
> next step of FC hardware, namely the handset?

Yes, I will need to give it some more thought.  At the minimum though,
we still need to do the probing test on a decased Pirelli motherboard
(where an unpopulated 0R footprint can be used as a test point) to
confirm if indeed Calypso's FDP output does what I think it does, and
the surgery experiment on an FCDEV3B to see if my proposed change will
make the problem go away.  Even if we end up never making a corrected
FCDEV3B batch, knowing the fix would be valuable for answering
potential buyer inquiries, and of course we would need the same fix
for the HSMBP, hence knowing it would be a great peace of mind.

> As I imagine the costs
> to create a handset would be very large and may require a lot of
> cash upfront, every amount would count.

Actually I do not currently anticipate a single large upfront cost
that has to be paid all at once, instead over the course of the year
or two that it will take me to do the design, I anticipate having lots
of little expenses here and there, primarily for hiring outsourced
help for various little steps which would be too difficult for me to
do on my own.  Here are some examples:

* I am currently in the process of evaluating LCD modules from 3
  different vendors, or more precisely, in the process of ordering
  sample pieces for evaluation.  The cost of these sample pieces
  themselves is negligible, but in order to evaluate them, I may need
  to make a little LCD test board.

* As far as serial interfaces go, I am pursuing the following
  arrangement: the MODEM UART will be brought out on the handset's USB
  port via a CP2102 or FT232R chip, combined with charging, whereas
  the IrDA UART will be brought out to a debug connector together with
  JTAG.  The debug connector will take an FPC cable going to a
  FreeCalypso debug adapter board, and the latter will be nothing more
  than an FT2232D adapter with the special connector.  The principle
  is exactly the same as Openmoko's debug board, but the debug connector
  pinout and form factor will be copied from the Pirelli.  I will need
  to have the modified FT2232D adapter board and the FPC cable made,
  and I will test these pieces against a decased Pirelli motherboard
  ahead of our own HSMBP.  Building the debug tooling for our HSMBP
  ahead of the main device itself is the hardware engineering analogue
  of test-driven development in software, where you write the tests
  ahead of the production code to which they apply.

* Once I get to doing the schematic-level design of the HSMBP itself,
  I would really like to be able to get some hired help from someone
  who is more of an EE than I am.  I would like to have a backlight
  driver circuit that produces the same current through the LEDs
  regardless of the battery state of charge and thus the voltage; a
  plain series resistor won't do the trick, and I would like the help
  of a real EE (which I am not) to come up with a smarter circuit,
  ideally one that is also more efficient than a voltage-dropping
  series resistor.  I may need similar EE help in some parts of the
  audio subsystem and with the charging circuit.

* I am tired of being held hostage to proprietary tools, hence my plan
  with the HSMBP is to bite the bullet and do it properly in a FLOSS
  PCB layout tool.  KiCad is a turn-off for me, but pcb-rnd has been
  making great progress lately, and it appears to be very close to a
  state where it could do the needed job.  But I will probably need to
  offer some $$$ to a pcb-rnd developer to implement some finishing
  touches which we need but which others apparently don't need, and
  which would therefore not get implemented organically.

As you can see, there will be a cost associated with each of these
steps, but they are relatively small costs which would need to be paid
to different people for entirely unrelated jobs, and can therefore be
spread out over time.  I will write more later, but I am very tired
right now, so I am just getting this reply out with my current not-
quite-finished thoughts.

M~