Just updated to the latest Home Assistant version 2024.1.3 and the USB port that my serial gateway was changed from USB0 to USB1 and I need to change this setting inside of HA, but I can't find the location to change the MySensors integration to make this change.
I can create another serial gateway device in HA and assign it to USB1, but then I would need to re-add all my sensors. I would like to avoid this.
So, anyone know of where I can change the serial gateway port from within HA?
Reporting back.
I previously had working a REV1 PCB of a battery powered sensor node; powering the nRF radio directly from the battery. No capacitor on the radio needed.
I built up the REV2 of the sensor PCB which included nice things like a power switch and and a reset button, etc. Radio was powered directly from the battery just as before, but the was not receiving signals from the gateway. Put the pro-mini back on the REV1 PCB and it was working. Only difference was the switch in the path between the radio and the battery. I measured the resistance between the battery input and the radio Vcc with a 121GW multimeter.
REV1 board (no switch): 0.03 ohm
REV2 board (with switch): 0.5 ohm
The switch had added a tiny bit of resistance. I shorted out the switch on the REV2 board and radio was working. I added a 10 µF cap to the radio just for good measure, also added a 220 µF polymer cap near the battery, again for good measure. and things have been stable ever since.
Lesson learned; extra resistance in the power path can add enough voltage drop to destabilize the radio (when the radio wakes up/switches between Tx and Rx, etc). A capacitor can help with the problem. And another best practice, I believe, is to make the Vcc path as low resistance as possible.
@magpern
Yep, I'm just setting up a new MySensors network and I'm having the exact same problem. Did you manage to fix it?
Maybe some setting the GW? I'm using a VeraPlus for a controller.
My solution was to use a low drop out voltage high ripple rejection ratio voltage regulator 3V0 to power the PIR. That special voltage regulator is fed from the booster 3V3, that keeps the voltage to the PIR rock solid. The booster is noisy especially when the arduino goes from sleep to wake and back.
Sorry, just getting around to try to get MYSController setup and I can't seem to get it sorted out to connect to my serial GW that is attached to my VeraLite.
Here is what I have done to try to get connected:
ser2net -C 5003:raw:0:/dev/ttyACM0:115200
I also tried
ser2net -C 5003:raw:0:/dev/ttyUSB0:115200
Next I launch MYSController on my PC and in the config window under TCP/IP tab set the IP to the IP of Vera and port to 5003.
Hit connect and I get the following....
2/17/2016 13:04:54 INFO Connected to 192.168.0.108:5003
2/17/2016 13:04:54 INFO Unknown message, Msg=
Port already in use by another process, dc=1
2/17/2016 13:04:54 RX
Port already in use by another process
For those of you have have done this before...any suggestion?
A couple of questions.
@darazs Good to know. I think the output of the booster is very dependent on the current draw and, of course, every booster is a little different.
@mrlynx
Downside to using 3xAA would be size.
@Andreas-Maurer
I would prefer to use the 3 pin header and not have wires coming from multiple places, but you are correct.
This post outlines how to run a PIR sensor with 2xAA batteries and use interrupts to sleep a 3V3 8 MHz Arduino between both tripped and not-tripped states. This seems pretty straight forward, however there are a couple subtleties.
Here, I will describe how I overcame this problem by modifying the PIR to work at 3V0.
Steps:
PIR PCB modification
The board should look like the photo shown below
Prepare the power source for the PIR
Figure 1. Comparison of the output of the 3V3 booster and the LDO 3V0 regulator while the Arduino is sleeping. AC coupled scope termination. Note: the LDO is multiplied by 100 and offset for clarity.
Figure 2. Motion at around 1100 ms causes the PIR output to go high and the Arduino to wake up. Note the output from the booster quiets down and the output from the LDO is smooth. PIR and LDO outputs are offset for clarity.
Figure 3. Entering sleep once the PIR goes from tripped to non-tripped state. Once the Arduino starts to sleep, the output from the booster becomes noisy, while the LDO is smooth. PIR and LDO outputs are offset for clarity.
Here is my example code (nothing fancy and much of it is borrowed from various places).
//This program will test the PIR using interrupts
#include <avr/sleep.h>
#include <avr/interrupt.h>
void setup()
{
Serial.begin(115200);
pinMode(3,INPUT);
digitalWrite(3, LOW);
pinMode(4,OUTPUT);
//Signal PIR startup by flashing an LED
digitalWrite(4,HIGH);
delay(5000);
digitalWrite(4,LOW);
delay(200);
}
void loop()
{
//Come out of sleep and read state of PIR pin
bool flag = digitalRead(3);
if (flag == true)
{
Serial.println("tripped");
digitalWrite(4,HIGH);
}
else
{
Serial.println("not tripped");
digitalWrite(4,LOW);
}
delay(100);
sleepNow();
}
void sleepNow()
{
Serial.println("Entering Sleep");
// Set pin 3 as interrupt and attach handler:
attachInterrupt(1, wakeUp, CHANGE);
delay(100);
// Choose our preferred sleep mode:
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
// Set sleep enable (SE) bit:
sleep_enable();
// Put the device to sleep:
sleep_mode();
// Upon waking up, sketch continues from this point.
sleep_disable();
}
void wakeUp(void)
{
detachInterrupt(1);
}
One last thing, it is necessary to attach a pull-down resistor on the PIR output pin in order to help the signal line go low when transitioning to the non-tripped state.
@hek okay, I guess I was being stupid....
With this msg constructor...
MyMessage msgVolt(CHILD_ID_VOLT, V_VAR1);
With this type def...
float batteryV = sensorValue * 0.003363075;
I had the following thinking that I had turned on auto ack...
gw.send(msgVolt.set(batteryV, 1));
but that sets the decimal places to "1". So, if I want to set the decimal places to "2" and enable auto ack it would look like this...?
gw.send(msgVolt.set(batteryV, 2),1);
Thanks again.
Hey guys,
Just wondering if someone would be so kind as to help me figure out how to use setters to send a payload with more decimal places than the standard custom variable.
I saw that perhaps I could construct the msg "on the fly", but I don't know the proper syntax to get that accomplished. Even easier, I would simply like to send a custom variable with two decimal places (or however many one should like). Right now the default is a single decimal place as I gather from the data that is being sent currently.
In the plainest terms, I would like to send the battery voltage in a format X.XX using a custom variable, but using the standard custom variable constructor the payload is X.X.
Thanks for your help.
Awesome, when I order new boards I will include this feature. One question, does your implementation require the use of both SDA and SCL pins or just SDA? I think I prefer the larger SOT-23 package that only has SDA pin. I guess simply, one-wire or I2C?
Thanks.
Thank you for this excellent work. I look forward to using it in my network. I just have a couple questions regarding setting up the GUI. I've read through this thread several times, but still have a couple of gaps in my understanding.
Is the gateway that interfaces with the GUI an additional gateway which listens to, and sends node messages and updates? That is, additional to one that is interfaced with the controller (in my case a serial gateway connected to a Vera controller)?
If my the answer to my first question is, yes, it is an additional gateway, is the code defining the operation different such that is does not interfere with the 'true' gateway? Or is the code the same (standard serial gateway sketch) but simply does not interfere?
Do the nodes require the MYSBootloader in order to show up in the 'messages' tab, or will 'messages' tab show all node traffic regardless of bootloader? Of course for over the air (OTA) sketch updates it needs the MYSBootloader.
Are these the correct steps to setup operation:
a) download and extract the files.
'b) place the bootloader folder into /arduino/hardware path such that the MYSBootloader and the associated boards show up in the 'tools->boards' menu.
c) connect an Arduino with the gateway sketch to a computer using a USB cable (for the serial connection).
d) run MYSController.exe (on windows) and select the COM port of the serial gateway in the configuration.
e) hit connect and node traffic will show up in the 'messages' tab.
If this is correct (and now that I write it down) it seems pretty straightforward, but I didn't see it explicitly described elsewhere. Sorry to be such a beginner, and thanks for straightening me out if I'm incorrect in any step.
One more thing...the actuator magnet I'm using is 1/4" diameter x 1/16" thick. (6.35mm x 1.56mm). So, I think this actuator magnet is also much smaller.
@gadu sure! But these are 1/10 the cost (good for when one needs ~30-40), and I'm not sure the commercial ones can be changed from normally closed to normally open with sense magnet nearby like this example. BTW, this one is 10mm x 32mm, so about the same size as in the first link you suggested.
Hi everyone,
I'd like to show you a recently completed project. A reed switch-based sensor that can be implemented either normally open to normally closed. (I like normally open (with sense magnet) for low/no current draw, but normally closed (with sense magnet) can also be realized).
If one does a bit of research on reed switches, it can be found that the switches can utilize two magnets for making a normally open switch (without sense magnet) a "normally closed" switch (without sense magnet).
The idea is to drill a 7/16" hole in the jamb of a door and imbed the reed switch, then imbed a magnet into the door to complete the install. One wouldn't even know it is there; I would have a node close by to connect directly to the switch in the wall, (for me, new construction will allow this). Have a look, let me know your thoughts.
I have designed a PCB and case (3D printed) for the switch. The PCB is straight forward, I'll leave that to anyone who'll want to replicate it, but the case took a few revs. Here is the prototype.
Figure 1. Side view of the switch PCB. The switch is the glass tube; on the other side, I super-glued a magnet to the PCB to change the switch from normally open to "closed" (conducting). In this configuration the switch is closed (conducting), and when another magnet (sense magnet) is brought near (must be opposite polarity) the switch changes to open.
Figure 2. Reed switch PCB and case.
Figure 3. Reed switch fitting into case.
Figure 4. Reed switch inside case. ready to be inserted into drilled hole in door jamb. The wires would travel to a node through a smaller hole at the end of the case. (if that makes sense). The sense magnet will be brought close to the 'top' of the cylinder when the door is closed making the switch 'open'. In this configuration, I believe a burglar would have a very hard time cutting wires that are inside a wall, so, no worries and I value normally low power (no current) operation.
Here is the SketchUp file used to create the 3D print...you should install the "export to .STL" extension and then print away. The PCB is 1.6 mm thick. ReedSwitch_WorkingSet.skp
Oh, and for those in the USA, I get the magnets from K&J Magnetics
A question for you in your setup...where is your antenna positioned relative to other nearby objects?
I've noticed that there are several examples here and elsewhere where the PCB antenna is positioned over a metallic object or over another PCB with copper traces or ground plane. After talking with an antenna expert, he commented that doing so can de-tune the antenna, from 2.4 GHz to something like 2.2 GHz, which will greatly reduce the efficiency (and therefore range).
@axillent said:
@bjornhallberg said:
The xc6210 looks promising though! What's the catch here?
I'm using for a long time xc206, it s one of the best to power NRF24
xc6210 should be also good. Any good proposals on pricing?xc6206 i was purchased $5 per 100pcs
Just to add another option...I've been using the Fremont Micro Devices USA FT531JA. It has higher ripple rejection ratio than either of the above and is ~$20 for 100. Not as cheap as the xc6206, but much, much better ripple rejection. So, just another option that I found, it also has the same pin-out as the xc6210!! So, we can try them both with the same PCB design, cool.
@johnr said:
And I also had to change transmit power from max to high.
Any idea why changing from max to high made it work? Do you think that the max setting was drawing more current than what you were supplying?
This was also my method (using an oscilloscope to integrate the current), but...I found it difficult to measure the very low currents...µA range with an oscilloscope (these are very high quality Tectronics units, we have many at work, but there is some DC offset even though I calibrated the probe, yada yada yada). So, on some more recent measurements I used a Keithley bench multimeter with averaging. I guess the final test is to see how long the batteries (or battery) actually last.
Just thinking out loud...did you remove the diode from the PIR? I removed both the PIR regulator and diode and run it off a boosted 2AA (3.3V) circuit and it works fine, so far....It seems the radio, when it powers up, causes some kind of voltage irregularity. Maybe a bigger low ESR cap? I found that adding caps between the VCC and GND pins of the radio reduced the magnitude of the voltage oscillation from a booster, but adding the 220 µF low ESR cap reduced the magnitude and frequency, and improved the radio communication greatly. I know that is not your problem, but it seems that it could all be related.
Just wondering if the gateway inclusion push-button needs an external pull-up resistor. I looked at the code (older code 1.3 something) and didn't see internal pull-ups enabled, yet in the instructions it does not mention to hook up an external pull-up resistor. Please advise...I have designed a gateway PCB with an external pull-up because I didn't see internal pull-ups enabled in the code.
Nice work. What printer do you have? I 'invested' in the MOD-t from NewMatter, an Indiegogo campaign product. I have a Makerbot at work that I 'practice' with. My father uses a service at his local library that will do 3D prints for him; check around your local area.
Here is what I did...
Removed the regulator and the diode. Jumpered from the anode of the diode to the location of the output of the 3v3 regulator. Works perfectly, and I can still utilize the original power supply pin! (good for using a standard 3 pin female header, no messy wires). Oh, and make sure your 3v3 power source is clean; boosters are notorious for having significant noise on top of the DC.
I have designed a PCB shield for the pro-mini, radio, and various sensors based on the the XC9140 chip. I will be powering the radio directly from 2xAA batteries. Boards should be here any day now and I'll check out the design. The XC9140 is not a bad chip from what I can tell, and it is cheap from Digikey, see posts above for BOM.
Okay, did the toggle test using the delayMicroseconds() method. I tested 96 µs, 1000 µs, and 10 ms and all were very close to the set delay, pins 6, 5, and 4 respectively. (@ 8 MHz the delay is a multiple of 8 µs).
It must be the fact that I'm trying the MySensors temperature sketch 'gatewayless'. I wonder if I can modify the sketch to not wait for an ACK. Of course, when I get a scope at home the 'gatewayless' operation will not be needed.
Don't underestimate the power of SketchUp. The main problem with SketchUp is that it is easy to get started, but takes a long time to master. I'm still learning and I've been a casual user for 5 years, or so. Our architects used SketchUp to design every last detail of our new house. And I have done some very fine precision work on rope tension holders that print perfectly.
...Now getting the printer settings correct is another story...
I use SketchUp for my 3D prints. You will need to install a couple plug-ins, a converter to stereo-lithograph file (.stl), and also useful to get the 'round corners' and 'soap-skin and bubble' plug-ins. Check out the MOD-t on Indiegogo, I'm getting one of those printers. Currently, I use a Makerbot.
Okay, I actually got the pingpair sketch to work using the new library!
The problem was that the new RF24 library does not return a bool for the read method like in the previous library, it's return is void. So, I changed the following code...
if ( role == role_pong_back )
{
// if there is data ready
if ( radio.available() )
{
// Dump the payloads until we've gotten everything
unsigned long got_time;
bool done = false;
while (!done)
{
// Fetch the payload, and see if this was the last one.
done = radio.read( &got_time, sizeof(unsigned long) );
}
to...
if ( role == role_pong_back )
{
// if there is data ready
if ( radio.available() )
{
// Dump the payloads until we've gotten everything
unsigned long got_time;
//bool done = false;
//while (!done)
//{
// Fetch the payload, and see if this was the last one.
radio.read( &got_time, sizeof(unsigned long) );
//done = radio.read( &got_time, sizeof(unsigned long) );
//the new library does not work like this any longer.
//}
And it compiled and I got successful ping-pong action. I don't know if this is entirely correct; or if I'm using the read method correctly. Anyone with more coding expertise care to comment?
What sketch are you guys using for testing communication between two radio nodes? In the library that is downloaded with version 1.3 I had been using the 'pingpair' sketch. But in the library that is downloaded with version 1.4, I cannot find the pingpair sketch.
So, for those who like version 1.4 with the updated RF24L01 library, what sketch do you use to test the communication? How do I set it up? It seems that version 1.4 library needs to be modified so that these valuable sketches work, but I could be doing something wrong.
I have tried using the 'GettingStarted' sketch under the RD24 lib, but that doesn't seem to work. Plus I like the simplicity of the 'pingpair' sketch better anyway. I'm assuming that the sketches need to be modified to work with the new RF24 lib, right?
I am having no luck with this new version 1.4...
Hi guys,
I checked again, with another scope (1 GHz Tektronix) and I get 1.44s total time. It must be hardware or software related, not measurement related. Any other ideas to fix? I need to run the node without a gateway, because the measurement must be made off-site from vera and the gateway.
Indeed, a pro-mini clone. I thought that A6 and A7 might be too much to squeeze in. I'm thinking of a 3x5 cm board.
Yea, for the voltage dividers, one for measuring the battery level. And two for something else, possibly an IR-based reflective optical sensor. And anything that has a higher output voltage.
Hmm...haven't heard of using nRF's IRQ to D8, can you still wake a sleeping node with this configuration? I guess I just don't have a full grasp on the concept. I just a beginner, so the more I learn the more dangerous I get!
Right, the main sensor on this board is the PIR; which is why I want an interrupt pin to that sensor. However I'd like to also use the magnetic-based sensors also as the main sensor and interrupt.
The PIR, Dallas, DHT22 are separate from the other 'future-proof' region, this should become clear once the layout is complete.
Anyone have a solid answer on whether the DHT22 needs an external pull-up resistor?
Gentlemen,
For anyone who is interested I have attached a schematic of my proposed "shield". Have a look if you so choose, and if you notice something wrong or incorrect, please let me know. One thing I'm not sure is...does the DHT22 temperature/humidity sensor need an external pull-up resistor?
@a-lurker yea, I know everyone likes v1.4. I had some trouble initially, probably related to the voltage ripple on the radio, and I haven't migrated over to v1.4 since discovering the solution to the radio power supply problem. I will try v1.4 again soon; I hope.
Okay, here is the code...
#include <Sleep_n0m1.h>
#include <SPI.h>
#include <EEPROM.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#include <RF24.h>
#include <Sensor.h>
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
unsigned long SLEEP_TIME = 3; // Sleep time between reads (in seconds)
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
Sensor gw;
Sleep sleep;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
boolean metric = false;
void setup()
{
sensors.begin();
gw.begin();
// Send the sketch version information to the gateway and Controller
//gw.sendSketchInfo("Temperature Sensor", "1.0");
// Fetch the number of attached sensors
numSensors = sensors.getDeviceCount();
// Register all sensors to gw (they will be created as child devices)
//for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// gw.sendSensorPresentation(i, S_TEMP);
//}
// metric = gw.isMetricSystem();
}
void loop()
{
sensors.requestTemperatures(); // Fetch temperatures from Dallas
delay(100);
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int> ((metric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed and no error
if (lastTemperature[i] != temperature && temperature != -127.00) {
gw.powerUp(); // Powerup introduces a small delay (which is missing in radio.write powerup)
// Send variable (using registered shortcut) to gw
gw.sendVariable(i, V_TEMP, temperature, 1);
//lastTemperature[i]=temperature;
lastTemperature[i]=temperature-100;//Force a reading every time; Added by Erik
//Serial.println(temperature); //Added by Erik
}
}
// Power down the radio. Note that the radio will get powered back up
// on the next write() call.
delay(500);
gw.powerDown();
sleep.pwrDownMode(); //set sleep mode
sleep.sleepDelay(SLEEP_TIME * 1000); //sleep for: sleepTime
}@Zeph Oh yea, use a wet tile saw for slicing PCBs like butter, very smooth edge too.
@Zeph I have a DHT-22 and my pin spacing is 0.1".
I was thinking of connecting the PIR and DHT-22 directly to the PCB and building a case around it. Of course, I could also use wires to remote the DHT-22 or PIR, but I like the option of direct connecting.
Oh yea, and where are you getting the DHT22 for $3? I need to use these due to the low humidity here in the desert. The DHT11 only goes to 20% and we a lower than that much of the year.
@Bandra Exactly what I was going to do. Nice!
Question: Since pin D3 is in great demand (the only available intrupt pin for waking the pro-mini) how did you decide what sensors have access? I think only one sensor can connect to the D3 pin, right? I suppose the door reed switch sensor gets priority, or does distance get the D3 pin?
Right now I'm leaning to the PIR motion sensor getting the D3 pin. I think it's the only way to run a motion sensor off a 'sleeping' pro-mini, right?
Here is what I'm currently thinking...
From the bottom...a 2xAA battery pack, the pro-mini under the PCB in question, and a PIR, temp/humidity, and the radio. I'll break-out the other pins for some other things too, but this is the main function. I could replace the temp/humidity with the Dallas.
Thoughts?
@marceltrapman Clarification: I'm running the 'China' 3.3 V booster and powering a standard radio both directly from the 2xAA batteries. The 3.3 V booster powers the pro-mini clone and the Dallas temperature sensor.
Yes, I modified the code to run the node 'gateway-less'. That is, I commented out much of the void setup() so that it would enter the void loop() and do it's thing. So, yes it is most definitely maxing out the retries.
I'll post the code...but, can someone let me know how to format the code for the forum...I don't want blast the code in the normal text box!
Hi guys,
I had a chance to connect a sensor node to an oscilloscope over the last couple of days, and also to a couple of meters (Fluke and Keithley). I'd like your opinions as to the sleep/wake/TxRx cycle that is shown in the trace below.
As is evident from the figure, the entire wake/TxRx cycle is around 1.44 s. I assume that the large current (measured voltage with a 10x probe across a ~5 ohm resistor) is the radio TxRx portion. And the initial current is the wake, but why it drops between is a mystery.
Anyway, here are my numbers from the meters using an Arduino pro mini clone 3.3V running the temperature sensor sketch (1.3 library) using 2xAA through a booster ('China no LED') radio run directly from batteries.
No modification: current from battery: 2.24 mA, current to pro-mini: 1.63 mA
Remove LED: current form battery: 144 µA, current to pro-mini: 104 µA
Remove LED and regulator: current from battery: 48 µA, current to pro-mini: 23 µA
Wow, this is great, with an improved booster and 2xAA is should have a year easy.
Thoughts?
Yes, I'm thinking of a similar project. I might have time to hammer out a PCB design tomorrow, we'll see. I will include a booster on the PCB though, the XC9140A331 that I measured and posted on the "Efficiency of Voltage Boosters" thread. I would also like to use either the DHT-22 module (it gets dry here in the desert) or the Dallas, also include a PIR sensor, run off 2xAA Eneloops. I like the waterproof box you found.
New data on the XC9140A331 3.3 V voltage booster. This looks like a nice IC with low quiescent current and an improvement over the stock "china" 3.3 V booster.
This option can be purchased from Digikey for $0.90, with a total bill of materials of $1.34 (in quantity, minus a PCB). It is also a nice size SOT23-5, not too small to hand solder.
Thoughts?
Nice find, this seems to suggest that it is optimal to have the radio hang off the edge of the shield/pcb with nothing under and limited components to the sides. This is the configuration I was think of implementing anyway.
I have a few free (I mean absolutely free) digital multimeters from Harbor Freight here in the US, among others. For the stuff we're doing an oscilloscope is next on my list of home equipment (at work we have everything under the sun). Anyone have a good option? I've been considering a USB version, but would rather find a used digital Tektronix on ebay.
@axillent I totally agree with the radio being very sensitive to noise and voltage ripple on the power pins. I have had great improvements with running the radio on battery directly.
I know that the 4.7 microF electrolytic recommended on the MySensors store does very little to help.
When I powered the radio from the booster I was getting poor reception and many failed messages; I didn't have any tantalum capacitors on hand, so I tried to look at suppressing the voltage ripple of the power to the radio using the beastly 220 microF polymer capacitors and it worked well.
I think we have come to the same conclusion...voltage ripple to the radio is bad, suppress it any way you can and one will have better results.
@Bandra Great, would you be able to share your run times so that we can get some real world data? That is, how long can you run a node before the battery is discharged?
I was thinking about making a board using one of the high efficiency boosters listed in the first post, if they prove their worth. I get my components in on Saturday, so sometime next week I should have preliminary results.
Good to see new activity on this thread again.
@axillent Unless there is some EMI coupled into the power leads of a battery connected radio, or current draw from the battery can't keep up with demand, I don't see why a capacitor is needed. In fact, the product brief for the nRF24L01+ states that it is designed with an on-board voltage regulator and permits operation with a coin-cell battery. Is there something I'm missing?
Also, regarding capacitors, I think you mean 220 microF is 'overkill' or 'more-than-enough', rather than 'too-much'. Right?
Anyway, here is a comparison of aluminum polymer capacitors of different capacitance. Note how the 220 microF cap is cheaper and has lower ESR than either the 10 microF or the 47 microF, and is only slightly larger in physical size.
Tantalum on the other hand has a quite high ESR, on the order of ohms, not good for suppressing voltage ripple according to this document.
That being said, ceramics may be the way to go for sub-100 microF as they are lower cost, smaller, and very low ESR; above 100 microF ceramics get very expensive, ~$4 for a 220 microF.
Yes, you got the result from the booster voltage ripple test correct, the 4.7 microF is the one recommended from the MySensors store, and the other 220 microF is a high-end audio electrolytic. The low ESR is here. Here is the data,
Now, with that being said; why power the radio from the booster at all? I would submit, for battery powering a sensor node, that one should simply connect the radio directly to the battery (2xAA). The Arduino seems to be less sensitive, but still need to test. Connecting the battery directly also is more efficient, no power loss through the booster.
My observation was, at a range of ~few feet, that I would get ~20-70% radio communication fails in the 'pingpair' sketch with the radio powered by the booster, and 100% success radio powered from 2xAA batteries, and 100% success radio powered by booster with the low ESR capacitor mentioned above. I didn't have any lower capacitor values to test (actually, I think I might have a 150 microF as well, but no lower values).
I also tested the 5 V -to- 3 V step-down regulator from the MySensors store and that is dead flat, no voltage ripple (~1-2 mV noise). But, that is also power inefficient, however it is a good option for a plug-in node or gateway.
Well, I thought I would re-post the data and try to summarize the thread that was lost.
Objective: Run a sensor node for a year on batteries. Wake period ~2 - 5 minutes.
Approach: Use a voltage step-up converter to boost the voltage from 1 or 2 AA batteries to 3.3 V or 5 V required by the two flavors of pro-mini clones.
Problem: Even though folks have discovered methods to put the sensor node into a deep sleep mode which draws ~100 - 200 microA; the efficiency of the step-up modules prevent realization of such a low current draw; rather, at that low current draw the efficiency of the step-up converters yields ~1-2 mA. See figures,
The good news here is that the cost efficient step-up converters from China are just as efficient as the SparkFun NCP1402 when the LED is disabled.
Solution: The search was on to find a more power efficient step-up converter. Here are some that I and other folks found.
TPS61222 - These are pretty small though.
TPS61097 - These are sort of expensive.
XC9140AXX1 - These look promising.
SC120 - Also cost effective, but may not be as efficient as the above.
I have ordered the parts to construct boosters using the TPS61097-33 and XC9140A331 and will report back to the forum with the results.
Everyone - does that summarize the original post sufficiently?
Bummer. This loss over that time period totally erased my existence on this forum. I'll be re-posting all the data I've collected under similar topic names.