A correction:

As usual, my memory is less than stellar.  Just a bit ago I wrote:

Next to test: how much further does it drop if the Atmel is put into ADC off and PWR_DOWN and how low can it go if I remove the LEDs.)

Well, when I went back to look at my sketch, I found that it already but the Atmel in ADC off and PWR_DOWN (with the transceiver awakened by CAN activity and MCU sleep, MCU sleep interrupted by activity on the CAN transceiver RxD pin and the MCP-2151 awakened by MCU activity ).  So the 9+ mA in my previous post is mostly the parasitic load of the not-too-useful power LED and whatever loss occurs having +5V connected to the output of an input-less linear regulator - everything else is sleeping pretty soundly.

Ciao,
Lenny

Good news, and a bit easier to check than I thought.  I didn't have to modify a cable or lift a pin on the USB  mini-B jack.

I realized that I had a Nano on which I'd substituted a through-hole Shottkey for a fried D1.  I just lifted one leg of that diode and put an ammeter between a 5V source and the 5V pin so that I could measure current with the USB plug connected or disconnected.  Disconnecting the USB cable causes a roughly 9 mA drop in consumption.  Not as good as one might think from the difference between the "typical" FT232Rl consumption of 15mA and it's USB standby of 70 microA, but the converter clearly does go to a low power mode when there is no USB signal.  Moreover, the actual FT232 current of this particular chip with only the USB heartbeat running may be closer to 9 mA than 15 mA -- I have no way to know.

In any case, I am happy with this result.

(BTW, my setup also has MCP 2151 and 2551 CAN controller and transceiver connected to the Nano.  Putting the controller and transceiver into sleep mode drops total consumption from 36.5 to 17.8 mA (with USB connected) or from 27.4 to 9.3 mA with (USB disconnected), so I also now know that the base consumption of an awake Nano is approximately 18mA with USB connected, and 9+ mA without.  Next to test: how much further does it drop if the Atmel is put into ADC off and PWR_DOWN and how low can it go if I remove the LEDs.)

Ciao,
Lenny

Doesn't the following, quoted from http://www.beyondlogic.org/usbnutshell/usb2.shtml#SuspendCurrent imply that the FTDI should drop current draw if the USB cable is disconnected?

Entering Suspend Mode

A USB device will enter suspend when there is no activity on the bus for greater than 3.0ms. It then has a further 7ms to shutdown the device and draw no more than the designated suspend current and thus must be only drawing the rated suspend current from the bus 10mS after bus activity stopped. In order to maintain connected to a suspended hub or host, the device must still provide power to its pull up speed selection resistors during suspend.

Ciao,
Lenny

Taking a look at the pcb layout, it seems as though disconnecting pins 4 and 20 from the +5V line would be close to impossible, at least for me.  They are bottom copper directly under the FTDI chip, which is of course under the MCU on the other side.  A physical intervention would require de-mounting the USB-serial chip and then re-flowing it and that's not something I'm about to try.  Yes, Lefty, tying those traces to the USB power rather than the 5V post regulator would be less cumbersome than using a switch or jumper.

Time to figure out what it means to say that a host goes to USB standby, what the various power modes D0, D1 etc. mean, and whether the Windows API would give me a simple means to do it.

I guess the other thing I should do is to make up a USB cable with the 5V line opened so that I can measure current from an external 5V with the PC in various states: connected, standby, hybernate, un-plugged.

Ciao,
Lenny

Yes, Grumpy, that's the way I read it too, but was just hoping that someone wold say - "well, if the USB cable is disconnected it does go to USB standby even if it has Vcc; we just forgot to mention that in the data sheet".  Looks like the only way to remove the drain of the USB-serial converter is to cut the trace that feeds its pins 4 and 20.  Haven't yet looked to see how hard that wold be to do, or whether it would be possible to add a jumper.  Ciao, Lenny

Not having found any information on how USB standby is invoked in the data sheet, I went to FTDI's web site.  The only thing I found there was:

How does FTDI handle USB suspend?

USB suspend is controlled by the USB host telling telling the peripheral device to go to suspend.

The FTDI drivers do not force the FTxxx devices to go to suspend.

If the USB data bus is idle for >3ms the USB host should put the FTxxx into suspend.

Which still leaves me in the dark (but not hopeful) about what happens if the USB cable is unplugged.
Ciao,
Lenny

Yes, Lefty, the data sheet says that current drops into the uA range in "USB suspend", but search as I may I cannot find anything in the data sheet that says under what condition it goes into USB suspend (by itself? When USB is disconnected?  Under program control?).  Ciao, Lenny

The USB-serial converter chip gets its power only from the USB jack, so it won't draw power if you feed the Nano via either Vin or 5V.

Ciao,
Lenny

That last statement is not true. The USB serial converter chip gets it's Vcc power from the same bus that the 328P chip does, so it's always powered up no matter what the board is using as a voltage source.

Thank you lefty.  Yes, it seems that the converter Vcc is the same 5V bus!  Which leads me to a couple questions:

(1) If the MCU is put in PWR_DOWN sleep, how much does the FT232 still draw?

(2) Is there a way to eliminate the consumption of the FT232, or put it to sleep, short of cutting the trace to its pin 28?

AGAIN, A BIG THANKS FOR THE HEADS UP!

Ciao,
Lenny

The Nano lacks a DC coaxial connector, but it does have the Vin and ground pins.  If you want to run it at 7-12V, just connect + to Vin and - to ground.  As mentioned above, you can also safely power the Nano by connecting 5V to the 5V pin, BUT be sure that you use a well-regulated 5V supply.  Absolute maximum Vcc is 6 V and some poorly regulated supplies may exceed this, especially if your mains voltage is not all that stable. 

The USB-serial converter chip gets its power only from the USB jack, so it won't draw power if you feed the Nano via either Vin or 5V.

Ciao,
Lenny

The following all refers to some experimenting I've done with the Atmega328 as used in the Nano.  I don't know if, or whether, it also applies to other MCUs such as that on the Mega.  I also post it with the forewarning that what I'm saying is the result of my experimenting and not from some deep reading of ATMEL data sheets -- if there is something stupid here PLEASE post back so that I can correct my thinking (and my circuits before I fry something).

In any sleep mode more economical than idle, the MCU clock is disabled.  Hence, in sleep modes, such as PWR_DOWN the external interrupt pins (pin 2=interrupt 0 & pin 3=interrupt 1) respond only to a level, rather than pin-change, interrupt.  Given that interrupt mode can be LOW, ANY CHANGE, FALLING or RISING (0b00, 0b01, 0b10 or 0b11 in the 2 relevant bits of EICRA), one naturally thinks that only LOW can be used as a level interrupt, and every example that I've seen uses exactly that to interrupt sleep via a hardware interrupt pin.

Actually, I had missed the fact that these are the only four interrupt modes, I just assumed that there was one called HIGH as well.  In this case, I'm glad that I didn't read carefully because it turns out that LOW is not the only level interrupt that one can use.  While the MCU can not read edges without the clock, ANY CHANGE, FALLING and RISING modes will actually interrupt if pin2 (or pin3) are pulled high (from being held down with a resistor to ground) by a signal that lasts long enough.

For other reasons that I'll talk about elsewhere, I had a 5V signal that I was hoping to use for a hardware interrupt.  While I could have inverted that, e.g. with a single FET, I like to keep parts count as low as possible figuring that each component added is another component that can fail.  So, not realizing that HIGH is not an available interrupt mode (and that HIGH is defined in Arduino.h as 0b01 just like ANY CHANGE) I did the following:

Code:

// In the calling program:
// ...
      byte old_ADCSRA;
      old_ADCSRA = ADCSRA;
// ...
      if (SleepTimeElapsed){
        MASTER_SLEEP ();
// returns here after interrupt
        Serial.println (F("MASTER_WAKE run"));
        ADCSRA = old_ADCSRA; // restore ADC to state it was in before sleep
      }
// ...
// and the sleep procedure and ISR are:
void MASTER_SLEEP (){
  Serial.println (F("MASTER_SLEEP called"));
  delay (10); // some time needed for serial print
  // disable ADC
  ADCSRA = 0; 
  set_sleep_mode (SLEEP_MODE_PWR_DOWN);
  sleep_enable();
// make sure we can't interrupt before we go to sleep,
  noInterrupts ();
  attachInterrupt (0, MASTER_WAKE, HIGH);
/*
Arduino.h enumerates:
 #define CHANGE 1
 #define FALLING 2
 #define RISING 3
 #define HIGH 0x1
 #define LOW  0x0
*/
 // turn off brown-out enable in software
  MCUCR = _BV (BODS) | _BV (BODSE);
  MCUCR = _BV (BODS);
  interrupts ();
  sleep_cpu ();
} // end of MASTER_SLEEP

void MASTER_WAKE (){
  sleep_disable();
}  // end of MASTER_WAKE

and it works.  The MCU goes PWR_DOWN when MASTER_SLEEP is called, and comes back to life if pin 2 is pulled high by a push button switch.

Now there are a couple important notes to add, and others here may want to point out other reasons to not use this.

(1) A programming consideration.  DO NOT do detachInterrupt (0) in the ISR.  If you do, the MCU will wake up BUT may not reliably actually interrupt; it sometimes comes only part way awake.  If you need to actually detach this pin to use it for something else, do so a bit downstream in the calling program to make sure there's time for the clock to come back on line.

(2) A hardware consideration.  Make sure your design can not pull the pin HIGH if the MCU is not powered!  As with other CMOS, applying power to an input pin when there's no power to the chip will destroy the pin.  Obviously, this is not a problem with the internal pull-up resistors, nor with an external resistor to the MCU's 5V pin, but it could be a definite problem if you are using an external signal to the pin.

Ciao,
Lenny

Zabaat,

What are those nice robust-looking connectors on your last photo?

Ciao,
Lenny

The 2551 can be put to sleep from the MCU (pin 8 = RS pulled HIGH), but I think you would need voltage shifting to make it work reliably with the due.  Ciao, Lenny

da un ferramenta ben fornito trovi tutto quello che vuoi...

scritto da qualcuno che non abita in una piccola (bellissima) città dell'arte!

Ciao,
Lenni

Guigliemo,

grazie, il link a RS ma ha dato la parola chiave "microviti".  Cercando su ebay.it troviamo fornitori con prezzi più raggionevoli (almeno se non andiamo sotto 1,6 mm). 

http://www.ebay.it/sch/i.html?_trksid=p5197.m570.l1313&_nkw=microviti&_sacat=0&_from=R40

L'assortamento più variegata sembre d'essere da novarametalli (= ferramenta 7su7):

http://stores.ebay.it/Ferramenta-7su7/microviti-modellismo-elettroni-/_i.html?_fsub=919396011&_sid=89757371&_trksid=p4634.c0.m322

Ciao,
Lenny

M3 è disponibile in qualsiasi ferramenta.  Ma sul Eagle, il diametro del foro, almeno sul Nano, è di solo 1,5 mm.  So che viti 1,5 esistono ma non so dove comprarle.  Ciao, Lenny