Click this for NoviceGuard main page
If you haven't "met" NoviceGuard yet.... start with the introduction?. That will open in a new tab or window... just close it to come back to here.
Besides the "reference" material relating to NG_PwrDemand_0", etc, which follows, there is another page which attempts to address sundry odds and ends broadly relating to powering a NoviceGuard. That will open in a new tab or window... just close it to come back to here, if it isn't what you want.
If you have not already visited the page introducing the ideas behind specifying some "standard" NoviceGuard use power demand/ supply scenarios, please feel encouraged the page where the need for different NoviceGuard power demand/ supply scenario definitions is explained.
Stay here, if you are ready for the main reference for what "NG_PwrDemand_0", means. (And "NG_PwrDemand_1", etc.)
The power flow that an Arduino can tolerate is limited. In perhaps slightly too simple terms, but as a rule of thumb: No single input/output pin should have more than 10mA flowing through it. (Slightly more may be allowed, if you are working at 3v3. Current is only a proxy for power if everything is at a single voltage. The pages which speak of 10 mA being appropriate are strangely quiet on the subject of voltage. They may date from when there were only 5v Arduinos.)
The total current (at 5v) flowing in or out of the Arduino's input and output pins should not exceed 100mA.
These are not the absolute maxima. They are reasonable "everyday" limits.
In the hope of providing a standard frame of reference, some power demand/ supply scenario "names" have been created. They create hierarchy. The names are start "NG_PwrDemand_" (for NoviceGuard Power Demand...) to distinguish these terms from those associated with other hierarchies.
NG_PwrDemand_0 will be for a NoviceGuard with almost nothing (see below) plugged into any of the daughter board sockets, nothing plugged into the twelve way connector, no power other than that coming in via the programming cable, and with the LEDs on the input lines either simply absent, or disabled by leaving jumpers JN0 through JN3 open.
The jumper JPwrDauSrcSel9 needs to set to connect its middle pin to the lower ("Ard") outer pin. (This connection will be present even without pins, unless you have cut the thin trace between them on the underside of the board... which you must do, if you fit pins to the jumper location. Until you wish to use power from SkForExtSupply9, you don't need to fit those pins.) (There's a page about all the options for supplying power.)
Please don't underestimate the use which can be had from an Arduino plugged into a NoviceGuard configured for NG_PwrDemand_0. I developed a program to control a loom with one.
I said "almost nothing plugged into the daughter board sockets". For NG_PwrDemand_0, you do need 10k resistors between the center and bottom pins of SkN1 and SkN3. This is discussed in more detail at the page on inPUR, inPLR pull up resistors.
NG_PwrDemand_1 is almost the same as NG_PwrDemand_0, but carefully selected daughter boards may be plugged in. And even then, then numbers of them must be limited.
However, the daughter boards must either not use the Vcc available from the daughter board socket, or only make limited use of it. (All of the current for the NoviceGuard, the Arduino, and the daughter boards is coming from the "big" PC, across the USB port in NG_PwrDemand_1. The 10mA/pin, 100mA total for i/o pins rule is not something you have to worry about in respect of the current used by the daughter boards from Vcc... but the USB port's limits must be respected. (Of course, the daughter boards also connect to an i/o pin, and any current there DOES have to be considered in relation to the 10mA/ 100mA rules.)
If you are willing to connect a power supply to the NoviceGuard via a barrel jack (or wires) connected to SkNG_PwrDemand_2 a vast range of new opportunities open up, because you are no longer powering everything through the Arduino.
As was true for the first time under NG_PwrDemand_1, under scenario NG_PwrDemand_2, users may plug daughter boards into the NoviceGuard. (This is an illustration of a general rule. Anything you can do in a "lower" power demand scenario is allowed in a "higher" scenario.
You still may not, note, plug in any twelve way modules. (The term "daughter board" should be reserved for the ones for the 5 way connectors.)
It will still be necessary to take some care over power demands. More to be said on this.
To be "in" the NG_PwrDemand_2, the thin trace on the back of the board between the middle and lower pins of JPwrDauSrcSel should have been cut, pins soldered in, and a "hat" in place connecting the center pin of that jumper set to the upper pin, "Ex" (External power to daughter boards)
This scenario is reserved for situations involving modules plugged into the twelve way connector on the bottom edge of the board. I can't, off the top of my head, think of any particular power demand considerations unique to using the twelve way connector... but it is early days.
To work in NG_PwrDemand_3 conditions, the same requirements as those for NG_PwrDemand_2 apply.
Although it isn't a power demand issue, you need to be aware that the lines brought to the twelve way socket are not conditioned or protected in any way. Furthermore, until more can be done than is present in NovGrdCore at 17 May 15, you will have to use some pinMode statements, if you want to use any of the relevant lines in other than their default mode. (I would avoid encouraging the use of pinMode statements, because inappropriate use will breach the protections built into the NoviceGuard system.)
Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes, just a few "No attribute" issues, arising from Google code.
....... P a g e . . . E n d s .....