[Ovmsdev] Things are getting louder (was: Awfully quiet out there)

Stephen Casner casner at acm.org
Sun Feb 18 04:18:26 HKT 2018


Mark

Thanks for the details of the module supply options.  As I said, from
my perspective the cost difference for the AnalogLamb device should be
easily supported by the intended market and not worth all the grief
you and China team have gone through.  No matter, it's great that we
now have a solution that gets us where we want to be so production can
start.

                                                        -- Steve

On Sat, 17 Feb 2018, Mark Webb-Johnson wrote:

>
> Things available:
>
> * Espressif WROOM32. 4MB flash.
> * Espressif WROVER. 4MB flash + 4MB SPIRAM.
> * Clones for both the above (based on open source designs).
> * Analog Lamb ALB32-WROVER. WROOM32 format module with 4MB flash + 4MB SPIRAM. 8MB flash version available. 16MB flash version also supposedly available, but always on back order.
> * Analog Lamb WROVER. WROVER format module with 4MB/8MB/16MB flash + 4MB SPIRAM. 8MB and 16MB versions are custom order.
> * Custom hacked WROVER modules. Shield removed, then 4MB->16MB flash upgrade performed.
>
> Early attempts at hacking failed. Probably baked the chips trying to get the shield off. It is a big hunk of metal. We seem to have improved, and have had more success. However, I wouldn't want to make 100 that way.
>
> We are going to use Analog Lamb WROVER with 16MB flash + 4MB SPIRAM for the first production run. We have a couple of samples of these, and they work well. Exactly the same as the custom hacked ones we made ourselves. They build these themselves and will simply replace 4MB flash chip with 16MB chip during production, then put the shield on.
>
> A 4MB WROVER module is about us$4. A 16MB WROVER from AnalogLamb is close to us$10. BOM cost difference is <us$1. So, yes we are looking into making our own because of cost.
>
> Regards, Mark
>
> > On 17 Feb 2018, at 8:02 AM, Stephen Casner <casner at acm.org> wrote:
> >
> > Mark,
> >
> > I went back and reread all your messages about WROOM32 and WROVER and
> > AnalogLamb because I had not internalized all the tradeoffs.  I guess
> > the development that allowed reaching a successful v3.1 design was
> > finding an acceptable source for WROVER modules with 16MB flash
> > inside.  Are these espressif WROVER modules that are modified by a
> > third party, or is that third party building up their own from the
> > open-source design?  (You said nobody is making these as standard
> > products.)  And if the latter, are you considering building your own
> > because you could lower the cost?
> >
> > To me, it seems silly that espressif did not just put the 16MB flash
> > in the WROVER to start with unless there is a significant difference
> > in the price of 4MB and 16MB chips.
> >
> > A few days ago you were waiting for samples of the 16MB WROVER modules
> > because your attempts to update existing modules were "hit-and-miss".
> > I guess the 16MB modules must not have arrived yet since you resorted
> > to hand-soldering your own.  Congratulations on finally achieving a
> > good result!  You said these 16MB WROVER modules are significantly
> > more expensive, but I don't know how to quantify that.  If it is $10
> > or less and so long at the lead time is not "who knows when", I would
> > have given in a long time ago considering all the grief you and the
> > China team have gone through.  Clearly having both flash and RAM
> > inside the module is the best solution.
> >
> >> Thanks Steve, for all that 'module memory' work - I hope Espressif
> >> accept it upstream because it is incredibly useful.
> >
> > Indeed, just last evening @projectgus gave me a "LGTM" for my changes
> > after I had addressed his requests in response to the initial PR.  I
> > think that means my changes go into the "review and merge queue" but I
> > don't know how long until that merge happens.  This latest version
> > does require an API change which means another flag day for our code.
> > The change is to put all the parameters into a struct rather than
> > having a too-long list of function parameters.  I have that in a local
> > branch of ovms at the moment.
> >
> >                                                        -- Steve


More information about the OvmsDev mailing list