Card.attn restarting my host and notecard when running under battery

Hi All,

Was wondering if anyone else has seen this.

I am implementing a low power solution based on the use of the EN pin on the Host (Feather M0) and the Notecarrier AF

I have wired up ATTN pin to the EN pin of the host. I can send the bellow command to the notecard and it will pull the host EN pin low and power down the host.

  J * req = NoteNewCommand("card.attn");
  JAddStringToObject(req, "mode", "sleep");
  JAddNumberToObject(req, "seconds", 30);

The problem I am experiencing is that my codes works perfect when the host or notecarrier is powered by USB port but when I power the Notecarrier using a battery upon sending the card.attn the notecard and host get restarted ?

Anyone seen this or have any ideas ?


My best guess at the moment is the notecard is restarting (as seen by the red LED blink pattern) itself for some reason which releases the ATTN pin and causes the host to wake-up.

So why would enabling sleep mode for card.attn cause the notecard too reboot ONLY when running under battery ?

Has to be some kind of bug. If I have both the battery and usb connected to the Notecarrier everything works as expected. I am running the latest firmware.

Hey @ssozonoff sorry for the trouble, and for the delayed reply. What you’re looking to do is possible, but is not straightforward with the Notecarrier-AF, which has a power supply that was not designed to also manage the power supply of a connected Feather. If you’re looking to restart a host and Notecard using card.attn, your best bet is to use a Notecarrier-AL. Sorry again for the confusion, and I’ll be in touch over PM as I would like to send you a few additional Notecarriers for your trouble. Thanks again for your patience.

Hi and thanks for the quick response.

But I am not looking to restart the Notecard ? I simply would like the ATTN pin of the Notecard/Notecarrier to pull the EN pin of the host low (for duration X) but maybe I need to have a look at the schematic of the Notecarrier AF ? I must be missing something :slight_smile: I think I am starting to understand.

So I guess the way I need to do this is put the Feather in deep sleep instead and wake it up using ATTN.


Hey @ssozonoff you can find the schematic here in the AssemblyDrawing.pdf file.

See below. The 3V3 supply on the AF powers both the Notecard and Feather, the the F_EN pin goes to the Feather EN and EN on this 3V3 supply. You can test this yourself by removing the Feather from the AF and pulling EN to ground, which will disable the Notecard.

There are a few other particulars to consider here with the AF and running on batter and in sleep mode, including needing a level-shifter on SCL/SDA to isolate the Notecard and Feather when the Feather is powered off. We’re considering improvements in a future spin of the board, but your best bet right now is to run off an AL if you’re looking to sleep a battery-powered host.

Thanks. I am assuming with the Swan I will have the same problems ? Bummer cause I just ordered another AF + 2 Swans …

I just tested putting the Feather M0 to deep sleep and waking it up with ATTN. Seems to work but I am not yet getting the lower current consumption I would expect to see. Seeing 9mA

Thanks for your help.

@ssozonoff yeah, the constraint here is with the AF power supply, not the PS on an individual MCU. Even with the AL, you’re going to want to add a bi-directional level-shifter like this one from Adafruit. To use this particular level-shifter, you can hook side A to the Notecard/Notecarrier with VCCA powered by VIO, and the B side to a Feather powered by the Feather’s 3V3 output. That will allow you to shut down the I2C bus without drain when the Feather’s power is killed by the enable pin.

1 Like


Thanks and I guess this is pretty much the same answer for the following experiment.

I powered the Feather M0 + Notecarrier AF from the Feather’s JST battery connector (I realise this is not recommended per your documentation). In this case I am able to shutdown the Feather’s regulator by pulling the EN pin low. Non the less I still consume around 10mA.

Testing the feather on its own and connecting the EN pin to GND I am able to reduce the power consumption to around 70uA.

My understanding is that the I2C bus should only consumer current when its sending data and otherwise its in a high state.

Kind thanks,

Following on from the previous I am now swapping over to the Swan board which I received today. First thing of interest is it seems that if you power the Swan from its JST connecter it will not power the Notecarrier at all contrary to the Feather M0.

See below. The 3V3 supply on the AF powers both the Notecard and Feather, the the F_EN pin goes to the Feather EN and EN on this 3V3 supply. You can test this yourself by removing the Feather from the AF and pulling EN to ground, which will disable the Notecard.

So I am assuming I can cut the EN trace on the top side of the AF PCB in order to isolate it from the AF’s PS and hence only affect the Feather board when I pull it low with the ATTN pin. This would avoid everything restarting. I realise it does not address your comment about isolating the I2C lines.


@ssozonoff If you will attach a picture (PDF, diagram, hand drawn picture, etc…) of you proposed modification, I will try cutting the trace on mine, so you don’t need to test your theory on your own hardware.


Hi Zak,

Here is a picture of what I am proposing.


1 Like

@ssozonoff It works!

Cutting the trace you identified above, allows the Notecard to successfully power down the host MCU, without disabling itself. Furthermore, I was able to witness the power draw from a LiPo (connected at the BAT JST terminal) averaging slightly less than 50uA.

As noted before, even with this modification, the Notecarrier-AF cannot achieve the same optimal performance as the Notecarrier-AL, due to its inability to isolate the I2C lines. Using the same test sketch with a Notecarrier-AL averaged slightly less than 12uA.

Great detective work!

Hi Zak,

Thanks for confirming this, its great information you have provided here.
For me it boils down to a tradeoff between a fairly compact prototype sleeping with a bit more current consumption versus a solution built up of several PCB’s and hanging wires going between them but more efficient in sleep mode. I have yet to decide which one I will go with.

Kind thanks,

1 Like

Can you just confirm what you were using as a Host ? The test you performed on the AL was with the I2C isolation circuit ?


Me again,

I am unable to obtain 50uA with the AF carrier and a Swan as the host using ATTN → EN pin too shut the swans regulator down. This is with the modified AF board per discussion above.

Any tips.


Hi Serge,

I was using the Swan as a host, and I did not isolate the I2C circuit. The Notecarrier-AL provided the power for both components via the BAT JST plug.

I used jumper wires to connect the following pins on Notecarrier-AL → Swan.

  • <BAT → BAT
  • GND → GND
  • SCL → SCL
  • SDA → SDA
  • ATTN → EN

Also, you will need to wait for all the initializations to complete, before it drops into idle and achieves low power.


NOTE: I used a Current Ranger to determine the amperage.

Hi Again,

When I tested the Notecarrier-AF…

I was using the Swan as a host, and I did not isolate the I2C circuit. The Notecarrier-AF provided the power for both components via the BAT JST plug.

I plugged the Swan into the Feather socket, and used a jumper wire to connect ATTN → EN.


  • Do you have any way to confirm your modification worked as expected?
  • Did you wait for a few minutes (2-5) to make sure the Notecard had done all initializations and handshaking it requires on cold boot?
  • Is your Notecard connected with Notehub?
  • Are you connecting using a periodic connection?

If the modification would not work as expected then everything would simply reboot and nothing in the host would never be idle.

I have waited yes and it settles down at around 240uA which is way higher then what you are seeing, I am using a Joulescope. As mentioned I have connection set to off so notecard should be idle.

I will keep testing and see if I can come up with better results. I will also get around to test the AL but wanted to first see what the best results are I can get from the AF. I would at the very least like to see the same you are seeing.