Member Since: October 18, 2009
Country: United States
"this board allows you to utilize a microSD card at full speed" -- a dubious claim, as this breakout board uses a legacy SPI interface, instead of a native SD interface which cards require for full-speed operation.
I tie XPD_DCDC to RESET on all of my ESP8266EX-based designs, and I need a FET on the reset pin to be able to pull it down -- it sinks 30 or 40 mA of current, which most MCUs can't provide. I don't remember if the high current consumption is due to the RESET pin alone, or due to tying it to XPD_DCD, but it's worth checking with a multimeter to see that it's actually "trying" to pull the pin down.
Also, if I remember correctly, Windows has a nasty bug that prevents you from toggling one of the control lines (I think it's DTR) by itself -- i.e., you have to set the control line to the new state, then toggle the other control line to actually update that state. My memory is foggy, but it's either specific to USB CDC devices, or COM ports in general. May want to look into it.
This isn't bad for a first revision, but this design has a few nasty bugs that SparkFun should address:
For most MCUs, the reset pin is a high-impedance input. However, the ESP8266EX's reset pin sinks a crap ton of current when pulled down to ground (I don't remember if this is only the case when RESET is tied to XPD, or if it happens regardless). I design with the ESP8266EX SoC a lot, and I always put a FET on the reset pin to be able to pull it down. Definitely a nasty omission on SparkFun's part.
I really wish this board were designed with battery power in mind. SparkFun should have tied XPD_DCDC to the reset pin -- otherwise, you can't put the ESP8266 into deep sleep mode. It uses a ridiculous amount of current otherwise. I know that they've at least broken out the pin, but there's really no reason not to jumper it to reset -- users can cut the trace if they really need that extra GPIO input. And what's with the AP2112 regulator? It's got nasty-high quiescent current -- do you really need a 600mA regulator that's stable with 1uF of output capacitance to drive a 150mA part that you hung a 10uF off of it? Strange choice, but maybe that's all they have laying around?
Also, that PCB antenna shouldn't have any ground pour on the side (read TI's appnote), and those traces don't look like they're matched to 50R -- are those designed as microstrip or CPW? I wonder what kind of performance they're getting out of the RF section of that board.
I totally agree. If you're measuring AC line voltage currents, I wouldn't recommend using this PCB -- the layout is downright dangerous. Whoever designed this board has obviously never done any mains voltage designs before, as this violates every creepage/clearance rule I've ever seen.
It's Linux, so of course you could do that -- but since it's an embedded platform, you'd typically just compile your custom app on your big, fast computer and deploy it with scp/sftp, debugging with gdb. Most IDEs make this operation seamless.
All modern ICs are 1.8V compliant, and generally have lower power consumption when operated at that voltage. It's time to throw away your 1980s CD-series logic chips and move into this century.
It's not a matter of speed, it's a matter of interfacing. The processor doesn't have a serial or parallel camera interface block on the chip, so you can't interface an image sensor to it without an external FPGA/CPLD.
I totally don't see any advantage of an SD card form-factor versus this. It's about the same size, and what's the difference between putting an SD connector on a board or a 70-pin Hirose, other than the fact that you get a ton more I/O with this option?
I'm really glad they ditched the SD form factor.
While LiPo batteries have a voltage of roughly 2.5 to 4.2V, they drop off fairly quickly after they hit 3.5V, which means using this part in a 3.3V project will run the converter in the extremely inefficient (~75%) step-down region for most of the time. Consequently, I wouldn’t recommend using this part for 3.3V projects that are LiPo-powered.
Most designs I’ve seen actually just use a buck converter to step-down the voltage – when the battery voltage drops below 3.3V, the converter will track the input voltage. This may seem counter-intuitive, since you don’t “squeeze out” all the juice in the battery – however, the increased efficiency of the buck solution means you get longer battery life overall.
One article I read indicates at 300 mA output current, a buck converter got 9 more minutes of battery life than a buck-boost converter of similar configuration: http://www.eetimes.com/document.asp?doc_id=1273123&page_number=3
Obviously, if you’re building something with ultracaps or other low-voltage stuff with UVLO disabled, this is a great part to use. And it definitely shines at 5V output – I’d just stay away from using it in a 3.3V configuration with LiPo batteries.
While LiPo batteries have a voltage of roughly 2.5 to 4.2V, they drop off fairly quickly after they hit 3.5V, which means using this part in a 3.3V project will run the converter in the extremely inefficient (~75%) step-down region for most of the time. Consequently, I wouldn't recommend using this part for 3.3V projects that are LiPo-powered.
Most designs I've seen actually just use a buck converter to step-down the voltage -- when the battery voltage drops below 3.3V, the converter will track the input voltage. This may seem counter-intuitive, since you don't "squeeze out" all the juice in the battery -- however, the increased efficiency of the buck solution means you get longer battery life overall.
One article I read indicates at 300 mA output current, a buck converter got 9 more minutes of battery life than a buck-boost converter of similar configuration: http://www.eetimes.com/document.asp?doc_id=1273123&page_number=3
Obviously, if you're building something with ultracaps or other low-voltage stuff with UVLO disabled, this is a great part to use. And it definitely shines at 5V output -- I'd just stay away from using it in a 3.3V configuration with LiPo batteries.
No public wish lists :(