UPDATE: See this post (https://lowpowerlab.com/forum/moteino/moteino-usb-reduce-ftdi-current-on-sleep/msg24073/#msg24073) and this post (https://lowpowerlab.com/forum/moteino/moteino-usb-reduce-ftdi-current-on-sleep/msg24064/#msg24064) later in the thread for an important update of differences between these higher consumption DIY Moteinos and stock Moteinos made by LowPowerLab. Essentially this behavior was only reproduced on the DIY Moteinos, not on any stock LPL Moteino-USB. The culprit appears to be the initial diode used in the DIY design, which replaced with the LPL recommended diode - reverts to the expected low current consumption.
While testing power draw by the FTDI, it appears that the Atmega328P's TX pin reverse powers the FTDI through its RX pin and keeps it in idle state, which results in some slightly higher current consumption on the Moteino USB. I modified an R5 Moteino USB by adding a voltage lever shifter -- Texas Instruments SN74LVC1T45 which has a VCC isolation feature. This was able to reduce that extra current draw to almost 0 when USB is unplugged. Current draw of the modified Moteino USB in deep sleep (WDT on) is around 6.6uA, almost same as the actual Moteino's 6.5uA. Device works normally when USB is plugged in.
SN74LVC1T45 Datasheet: http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf
This is modification is based on a stack exchange answer I found here: https://electronics.stackexchange.com/a/141560/147274
The idea is pretty straight forward on how it's connected:
(https://i.imgur.com/pbtTwTZ.png)
It isolates side A from side B when one of the input voltages is 0V as the ports are at high impedance in this state. When USB is connected, FTDI goes back to 3.3V, and normal activity is resumed.
Here are some pics:
(https://i.imgur.com/05IanI1.jpg)
(https://i.imgur.com/mwQRhhb.jpg)
The part is about $0.50. Just putting it out there if someone is looking for such a solution.
EAGLE files available here: https://github.com/AKstudios/MoteinoUSB-LP
-AK
Thanks for the contribution!
Will consider this for a future revision.
You're welcome!
Here's the EAGLE library for the part: https://github.com/AKstudios/EAGLE-Libraries-by-AK/blob/master/lbr/SN74LVC1T45.lbr
Awesome ;)
Although I reckon this level shifting might be done with just 1 transistor.
Quote from: Felix on January 31, 2018, 09:10:50 PM
Awesome ;)
Although I reckon this level shifting might be done with just 1 transistor.
N-channel MOSFET, and a pull-up resistor on the FTDI_RX if there isn't one already.
Mark.
Quote from: perky on February 01, 2018, 07:00:13 AM
N-channel MOSFET, and a pull-up resistor on the FTDI_RX if there isn't one already.
Mark.
Hi,
I don't see where putting N-mosfet and a pull-up resistor to lock sinking current by FTDI_RX, could you be more explicit ?
Thanks
EDIT : maybe your proposal deals only about the level shifting function
Tie the N channel MOSFET gate to FTDI3.3V, tie the source to FTDI_RX, tie the drain to D1_TX, put the pull-up between FTDI_RX and FTDI3.3V. When the FTDI is powered up D1_TX will flow through the MOSFET onto FTDI_RX (using the intrinsic diode initally when pulling low). When the FTDI is powered down the gate will be at 0V and the MOSFET will block current from the D1_TX to FTDI_RX. See diagram below.
Mark.
Edit: It's actually debatable whether pull-up is really needed, as when the FTDI is powered up the source cannot go lower than 3.3V - Vgs(th) when the D1_TX is at a logic 1. So if a low gate threshold MOSFET is chosen such that (3.3V - Vgs(th)) > Vih then the pull-up wouldn't be needed.
Thank you for the schema.
To my mind, as Vgs is a typic value and can be slightly different, and if you removed LDO of your moteino and use a lower supply than 3.3V, the pullup resistor is highly recommended if you don't want to test each mosfet before using it.
Are you sure the "non saturated" Vgs phase will not slower the transition between low and high state and reduce the bauds transmission ?
The unidirectionnal level shifting is still a good option with only one SOT-23-6 component.
It's actually the response of the intrinsic diode to pull it low then the turn on time of the MOSFET, but the impedance of the driver is low and the capacitance of the gate is low too. It won't have an appreciable slowing down effect at serial baud rate frequencies. I would put a pull-up on for the same reasons you said just to be safe, you also need a noise margin too which would mean even lower Vgs(th).
BTW this technique is used with I2C for level shifting and isolating powered down I2C buses from each other, that's good for at least 400kHz fast mode I2C:
https://www.nxp.com/docs/en/application-note/AN10441.pdf
Mark
Update on this: I tested perky's circuit and voila! The MOSFET even gets rid of the 0.1-0.2uA power consumption of the unidirectional level shifter as well.
Here's the circuit recreated in EAGLE:
(https://i.imgur.com/fmE2vrK.png)
Here are some images:
(https://i.imgur.com/v15Shyx.jpg)
(https://i.imgur.com/DxQD5K6.jpg)
Board files here: https://github.com/AKstudios/MoteinoUSB-LP
Nice low-cost improvement for the MoteinoUSB!
Excellent, good work! ;)
Maybe same idea could be used on PCB with I2C sensors, so it will be possible to cut-off power of these sensors instead of put them in standby or powerdown mode when they still burn some µA... Without this tip, I2C bus will power sensors and it's useless to cut-off power pins.
are SDA and SCL both drived by sensors or only SDA, and SCL by moteino ?
I would cut both... but remember, that you may have external pullup resistors (internal might not be enough for correct operation at 3.3v), which would also need to be cut from the sensor
Quote from: Uncle Buzz on February 14, 2018, 06:56:03 AM
Maybe same idea could be used on PCB with I2C sensors, so it will be possible to cut-off power of these sensors instead of put them in standby or powerdown mode when they still burn some µA... Without this tip, I2C bus will power sensors and it's useless to cut-off power pins.
are SDA and SCL both drived by sensors or only SDA, and SCL by moteino ?
Already used for I2C when powering down devices and logic level shifting:
https://www.nxp.com/docs/en/application-note/AN10441.pdf
Mark.
perky - how would you use that app note for powering down the bus? It's clear on how to do level-shifting, not sure how to power down the I2C bus without the resistors still consuming power.
pullup resistors are on the powered side of the bus, only the I2C sensor is isolated by mosfet while it's power is shut off.
The mosfets don't put the bus at 0V, but isolate the sensor side to avoid power come back to the sensor via the I2C bus.
Quote from: akstudios on February 16, 2018, 08:13:52 PM
perky - how would you use that app note for powering down the bus? It's clear on how to do level-shifting, not sure how to power down the I2C bus without the resistors still consuming power.
With reference to Fig 1 in that app note, imagine the MCU on the
right hand side and the sensor on the
left hand side and both at 3.3V. There are pull-up resistors on both sides. If the sensor on the left were to be powered down, the MOSFET diodes will be reversed biased and the MOSFETs would be off thereby isolating it from the MCU.
There are variants on this, it's possible to have two 'back to back' MOSFETs and have each side at different or the same voltages, and when powered down isolates itself from the other bus. See this article:
http://www.poulpetersen.dk/xfiles/cir/gbi2ciso.html
Mark.
Quote from: perky on February 17, 2018, 08:21:21 AM
...
There are variants on this, it's possible to have two 'back to back' MOSFETs and have each side at different or the same voltages, and when powered down isolates itself from the other bus. See this article:
http://www.poulpetersen.dk/xfiles/cir/gbi2ciso.html
The back to back configuration is common in LiPo protection circuits. See attachment...
Tom
Guys,
I tried to reproduce the higher consumption in the MoteinoUSB, but to my surprise I was not able to.
I used various sketches including the DeepSleep and the one below, all resulting in a ~6.5uA draw on a MoteinoUSB.
This is regardless how the TX/RX serial pins are used (as GPIO set to HIGH, or as Serial printing data).
I tried this with recent R6 and older R4 MoteinoUSBs from 2013 as well. Both perform identically, 6.5uA in WDT sleep.
I recall seeing higher consumption on MoteinoUSBs some years ago (10-20uA?) and I attributed it to the FTDI chip at that time without doing further optimization, now I cannot reproduce that same scenario, so it's possible it could have been an IDE/board definition thing, but I cannot pinpoint the difference. Since I tried an older '13 FTDI chip I have no reason to believe any changes in the FTDI chip has historically caused higher consumption.
//***********************************************************************************************************
// Sample sketch that achieves the lowest power on a Moteino of ~6.5uA
// Everything is put to sleep including the MCU, the radio (if any) and the FlashMem chip
//**** SETTINGS *********************************************************************************************
//#define WITH_RFM69 //comment this line out if you don't have a RFM69 on your Moteino
#define WITH_SPIFLASH //comment this line out if you don't have the FLASH-MEM chip on your Moteino
//***********************************************************************************************************
#include <LowPower.h> //get library from: https://github.com/lowpowerlab/lowpower
#define LED 9 // Moteinos have LEDs on D9
#define FLASH_SS 8 // and FLASH SS on D8
#if defined(WITH_RFM69) || defined(WITH_SPIFLASH)
#include <SPI.h> //comes with Arduino IDE (www.arduino.cc)
#if defined(WITH_RFM69)
#include <RFM69.h> //get it here: https://www.github.com/lowpowerlab/rfm69
RFM69 radio;
#endif
#if defined(WITH_SPIFLASH)
#include <SPIFlash.h> //get it here: https://www.github.com/lowpowerlab/spiflash
SPIFlash flash(FLASH_SS, 0xEF30); //EF30 for 4mbit Windbond chip (W25X40CL)
#endif
#endif
void setup () {
#ifdef WITH_RFM69
radio.initialize(RF69_915MHZ,2,100);
radio.sleep();
#endif
#ifdef WITH_SPIFLASH
if (flash.initialize())
flash.sleep();
#endif
for (uint8_t i=0; i<=A5; i++)
{
#ifdef WITH_RFM69
if (i == RF69_SPI_CS) continue;
#endif
#ifdef WITH_SPIFLASH
if (i == FLASH_SS) continue;
#endif
pinMode(i, OUTPUT);
digitalWrite(i, LOW);
}
//Serial.begin(115200);
pinMode(0, OUTPUT);
digitalWrite(0,HIGH);
pinMode(1, OUTPUT);
digitalWrite(1,HIGH);
pinMode(LED, OUTPUT);
digitalWrite(LED, HIGH);
delay(20);
digitalWrite(LED, LOW);
delay(20);
digitalWrite(LED, HIGH);
delay(20);
digitalWrite(LED, LOW);
delay(20);
digitalWrite(LED, HIGH);
delay(20);
digitalWrite(LED, LOW);
delay(20);
}
void loop ()
{
//optional blink to know radio/flash sleeping went OK
digitalWrite(LED, HIGH);
//LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_OFF);
delay(1000);
digitalWrite(LED, LOW);
//LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_OFF);
//digitalWrite(LED, HIGH);
//LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_OFF);
//digitalWrite(LED, LOW);
//sleep MCU for 8seconds
LowPower.powerDown(SLEEP_2S, ADC_OFF, BOD_OFF);
//LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
}
I ended up making a new revision of MoteinoUSB (R7) which includes the footprints for the mods discussed in this thread. However these will not be populated and the MoteinoUSB R7 will be equivalent to the previous revision at least for now or until further proof that R6 is higher consumption somehow. Those users interested in exploring this topic further can simply add the n-mosfet/resistor to the new R7 if they like to do so, here's an example of a modded R7 with the extra n-mosfet and 10k resistor (left of the LDO):
(https://i.imgur.com/TYTo48i.png)
Feedback and more discussion is welcome and if someone does find a way to reproduce this I am curious to find out !
QuoteI recall seeing higher consumption on MoteinoUSBs some years ago (10-20uA?) and I attributed it to the FTDI chip at that time without doing further optimization, now I cannot reproduce that same scenario,
A while ago, I thought I noticed the same thing - higher current consumption on a USB Moteino with no USB cable connected and the board powered with an external supply. I figured it might be the on-board FTDI chip drawing some additional current, but, like you, I haven't been able to reproduce it. Both the regular Moteino and the Moteino USB draw ca. 6µA to 7µA in the sleep mode.
This is curious. The OP seems to have shown there was some leakage into the RX of the FT231X. The datasheet however has this as a 5V tolerant input, with no dependence on any power net. So technically the FT232X could be powered down and there would be no leakage.
However the FT231X datasheet says there are 200k pull-ups on the UART control signals to VCCIO, "When the FT231X is in reset, the UART interface I/O pins are tri-stated. Input pins have internal 200kΩ pull-up resistors to VCCIO, so they will gently pull high unless driven by some external logic"
So, this could explain why a high on the RX pin when the FT231X is powered down could possible cause leakage. The question is why do you now see something different? I'm wondering whether there has been a silicon revision to fix this such that the pull-ups are disabled when it is powered down. It's not mentioned in any errata though. Maybe the leakage isn't sufficient to turn on some logic in the device in some devices but is on others.
It would be interesting to measure what the VCCIO voltage is on a Moteino-USB (with a high impedance probe obviously).
Mark.
Update on this: I have to add that I've only ever seen this leakage on custom DIY Moteinos I've made on my own and one MoteinoUSB R4 I had lying around that I extensively messed around with. All Moteino products I've used R4 onward, including the latest boards have the advertised current draw of 6-7uA out of the box, MoteinoUSBs included.
Somehow, my DIY Moteinos always have some leak into FT231X RX pin unless I do the isolation/mosfet mod, at which point it goes down to ~6.5uA. I've even tried using Arduino UNO bootloader (optiboot) and DualOptiboot, but still the same results. I've also tried other packages of the chips (i.e., QFN package for both: ATmega328P-MU and FT231XQ) and there's still some 100-120uA in power down mode which goes away after the isolation/mosfet mod.
Not sure what I'm doing wrong, but here are the files on git if anyone wants to take a look at point out the obvious that I may be missing: https://github.com/AKstudios/FSK_USB_Gateway
(Note that I don't populate the 10K pull-up on radio SS pin as I have a socket to program the bootloader on chips, so it's not leakage via the pull-up)
So just to reiterate: Moteino and MoteinoUSBs are able to achieve 6-7uA in its lowest power state out of the box. LowPowerLab FTW! :D
P.S. My apologies to Felix for making him spend time to do the mod, but maybe it'll help later on in case it's not the boards, but some batch of FTDI chips with some specific firmware.
I've had a quick look, it seems you have not wired up the diode between VBUS and VIN around the FT231X on the schematic. The PCB does though appear to have the diode. Are you using two versions of the PCB?
I'm not sure if its a valid thing to do to have the VIN high impedance and drive the Vout of the LDO with 3V3, this I think would tend to drive VIN up towards 3V3 which might cause excessive quiescent current in the LDO. There is an A version of the MCP1703that might be a little different.
Mark.
When I thought I was seeing a higher sleep mode current with the Moteino USB, I also looked at the schematic. It appears to show a resistor of unspecified value between Vin and Vbus. The Shottky diode doesn't appear to be connected to anything. BTW, the reverse current on the diode is "Max 0.001mA" according to the spec sheet.
perky, DonpK - the diode is the resistor labelled "SHOTTKY" in the schematic. Since it's the same footprint as an 0805 resistor, I just reused a resistor symbol but physically placed a diode there on the actual board. The grey diode symbol underneath the "resistor" is just that - a symbol showing the polarity of the actual diode. Moteino schematic has it setup the same way btw, just uses an 0603 diode. Attaching the Moteino schematic for reference.
(https://i.imgur.com/yFgpHTH.png)
Actually -- very good point about the diode reverse current. I was using this (https://www.mouser.com/ProductDetail/AVX/SD0805S040S0R5?qs=jCA%252bPfw4LHZwphObYhjVUA%3D%3D) diode (SD0805S040S0R5), but it appears to have 0.1mA as leakage! Never realized that. I switched over to a SD103AW (https://www.diodes.com/assets/Datasheets/ds11013.pdf) and now the reverse current seems almost negligible.
I assembled a fresh board, burned bootloader and tested a sleep sketch with latest libraries -- getting the 6-7uA without mosfet mod now. Still not sure how the mosfet on RX is able to remove this on other boards if the FTDI was being back-powered by the diode leakage current.
Using the Moteino schematic and BOM as recommended by LPL will definitely give you the low power as advertised.
This forum rocks :D
(https://i.imgur.com/BcHDRRr.jpg)
Quote from: akstudios on August 27, 2018, 01:26:55 PM
Using the Moteino schematic and BOM as recommended by LPL will definitely give you the low power as advertised.
Great to see this come to a conclusion, now I remember it was indeed a different diode that I observed caused higher consumption on an old MoteinoUSB (probably on the first revision).
Well done!
I noted earlier that the FT231X has 200k pull-ups on the inputs on the UART signals to VCCIO. Maybe the combination of that current plus the leakage through the diode was enough to parasitically power the chip, but remove one of them (i.e. use a low leakage diode, or stop the RX pin leakage via the 200k resistor by isolation) and the problem goes away?
Mark.
Felix,
Just out of curiosity, at what date did you start shipping Moteino USB with the lower current consumption? I'm wondering whether I have any of the older units with the higher consumption.
PS. As I was typing this message on the Forum I got a Warning that a new reply had just been posted that I might want to look at before posting mine. Cool feature!
Quote from: DonpK on August 27, 2018, 01:41:32 PM
Felix,
Just out of curiosity, at what date did you start shipping Moteino USB with the lower current consumption? I'm wondering whether I have any of the older units with the higher consumption.
PS. As I was typing this message on the Forum I got a Warning that a new reply had just been posted that I might want to look at before posting mine. Cool feature!
I can't quite be sure of this. It must have been pretty early on, but I could be wrong. I have been using this current diode for years though.
It is not really an issue on most boards and to be honest in most use cases - the reason being that MoteinoUSB and MoteinoMEGA-USB was generally speaking designed to be USB powered/connected (I think that's how it even became a product - after people asking, for convenience purposes), and in most cases (even talking to customers) it appears to be used as such.
It can certainly be battery connected instead. So maybe I was not completely concerned with this from the beginning, although once I found the higher MoteinoUSB consumption I now recall that I made it a priority and traced down the issue to the diode and replaced it on all my designs at that point.
Quote from: akstudios on August 27, 2018, 01:26:55 PM
Actually -- very good point about the diode reverse current. I was using this (https://www.mouser.com/ProductDetail/AVX/SD0805S040S0R5?qs=jCA%252bPfw4LHZwphObYhjVUA%3D%3D) diode (SD0805S040S0R5), but it appears to have 0.1mA as leakage!...
No wonder it's shown as a resistor!
BTW, are you really using 47 ohm resistors for the LED current limits?
Quote from: TomWS on August 27, 2018, 02:47:59 PM
No wonder it's shown as a resistor!
BTW, are you really using 47 ohm resistors for the LED current limits?
Hah! Good one.
Nah, I'm using 1k ohms on the actual board. Reused resistor symbols from some of my older projects and forgot to change the value in schematic. I mean, it shines brighter if you do use 47 ohm..
Quote from: perky on August 27, 2018, 01:36:32 PM
Well done!
I noted earlier that the FT231X has 200k pull-ups on the inputs on the UART signals to VCCIO. Maybe the combination of that current plus the leakage through the diode was enough to parasitically power the chip, but remove one of them (i.e. use a low leakage diode, or stop the RX pin leakage via the 200k resistor by isolation) and the problem goes away?
Mark.
Yes, this is definitely it. Initially I thought the internal pull-ups were limited to a different package, but both are functionally the same. Blocking current from both sides makes it goes away.
My guess is that the diode leakage allows VBUS (i.e. the VCC input of the FX231X) to rise. This is the input to a 3.3V regulator inside the FT231X, which could well have a clamping effect on it's 3.3V output and keep it below a threshold that enables some logic. Since VCCIO is also connected to that 3.3V output, any leakage from an input could cause it to rise *if* VCC is high enough. So, putting a low reverse current diode in, or blocking the leakage from the RX input, makes it work.
It would be interesting as to what happens both to the VCC input and the VCCIO during failure.
Mark.