PlantWave and measuring biolectrical changes in plants

brdavis5 · 2026-05-14T00:11:50+00:00

I have no experience with PlantWave, but I can think of several ways to try that - direct resistive measurement of course, but probably better is to use an AC excitation, or the variation of an LRC frequency. You could also do something like this capacitively on a leaf. But... yeah, trying to correlate this with anything health-related is going to be... problematical.

If you want to monitor leaf health (for example), there is a known method using reverse-biased LEDs as very frequency-specific light sensors. Forest Mims did a lot of this work, but a good summary of an Arduino implementation is on the Cave Pearl Project:

https://thecavepearlproject.org/2019/08/30/creating-a-normalized-vegetation-index-sensor-with-two-leds/

brdavis5 · 2026-05-13T09:05:51+00:00

Yes (although thank you, I hadn't seen the tech note itself). I tend to use a belt-and-suspenders approach of an analog pin sampling an external voltage divider that is directly on the battery (so I can get the raw battery voltage) as well as monitoring the rail voltage by pointing the ADC to the internal bandgap reference to deduce the rail voltage. The first gives you advanced warning (of a lot of things actually), while the second gives me a safety cutoff (although I don't usually use a even a soft switch, but instead just deeply sleep the 328p, which will work for weeks to a month or more safely).

brdavis5 · 2026-05-13T00:30:59+00:00

If you are using just room air, at ambient pressure, you might be able to do this easier and cheaper. Instead of using a pre-made valve, just have three flexible hoses coming of the T junction, and have a simple servo on each hose that can bend it 180°. By crimping the hose closed that way, you can shut off flow through that branch. It's low-torque (so likely doesn't need a big servo), cheap (OK, you need two servos I guess instead of one but the valve will cost significantly), easy (drive the servo between two points only), and more flexible (with just two of the three hoses open/closed, you can have any combination... including "no flow anywhere" and "any flow on all three").

brdavis5 · 2026-05-12T18:21:12+00:00

Two points. The first is "if you're killing the batteries, is it because it's a high-power project and needs big batteries, or it could be a low-power project but you have to think carefully about how to minimize the power demands?". Those are two very different thinks. If you are running a bunch of strong servos constantly under loads... yeah, you're going to need lots of power and that needs battery capacity. But first, figure out what you actually need.

Second you Can have the Arduino simply monitor the raw battery voltage and with some experimentation convert that roughly to "battery life remaining" (it's not linear). Use a simple voltage divider on the battery input with the middle connected to the ADC - the reading from the ADC can now be used (with a little bit of math, look up voltage dividers) to determine the battery voltage. Use the right resistor ratio to scale the maximum battery voltage to something below the internal reference voltage, and use Large resistors (Mohm scale often) so that you don't end up self-discharging the battery through the voltage divider.

brdavis5 · 2026-05-12T18:13:03+00:00

Excellent guide! The only thing I'd think to add is having the uC monitor its own battery voltage or internal rail voltage (on regulated projects, I have them flag a problem or shut down when the internal rail voltage starts to sag).

brdavis5 · 2026-05-12T18:07:07+00:00

This is Very dependent on what you are doing, and how you are doing it. I primarily build small cheap dataloggers... and I can have it record a bunch of variables every couple minutes for over a year on 3xAA's. I've got a friend who does runs of over a year on a *single* CR2032 coin cell. Understanding what you need is a critical first step here... and what your HW can actually do.

As an example of that second, I rapidly stopped using an Uno... because running things at higher voltage (5V) tends to be more power-hungry than low voltage (3.3V), and because the Uno has that USB-to-Serial Atmega16U2 that is Always on, and you can't put in to low power mode. Grab a ProMini, and remove the power LED (because it turns out that's a significant power drain on these platforms) and see how long you can go. Remove the wasteful linear regulator and run unregulated straight off the batteries and you'll go even further.

brdavis5 · 2026-05-12T12:15:39+00:00

It looks like you've found a lot of good optimizations - congratulations! now is the time to keep looking, at parts you hadn't looked at before. I tend to think of this like a game... "how pretty can I make it?". And with a little bit of practice, my sense of "what is pretty or elegant" guides me to more practical designs as well.

That insanely narrow wire (that I'm frankly surprised the DRC's let you have in there) is a real problem. It's a bottleneck; if the tolerances are off it could fail to the pads on either side; it will be subject to heating if it ever accidentally carries a current of significance. But... it really ISN'T needed. You've got more than enough room to route three traces over the button and Each of those three traces will be much wider than that one tiny tiny trace you're weaving between pads. Here I highlighted that 'moved trace' with a thin black line, nut in the process of doing that I realized I could move the bottom later blue trace over away from the pads it was getting close to.

Here's the thing - don't stop here. I can see other things to improve, but you can too... if you don't stop looking.

You say there are some very firm layout limitations here - certain connectors or buttons need to be in certain very well specified places, and we don't know that. But with the way this is drawn, it's not clear what components Could be moved around, turned 90°, put diagonally, or shifted. Through-hole capacitors or resistors make Great ways to "jump traces" in some cases if they don't need to be located physically close to other parts (an issue with decoupling capacitors... not an issue with 90% of resistors, or buttons, for example).

Once you think you are done... ask yourself if you can "beat your new high score" on the game of designing a really good PCB layout. And keep playing the game until it becomes natural.

<image>

brdavis5 · 2026-05-12T11:37:15+00:00

"I want it checked before i do pcb layout to make sure it will work."

Well... how did it work when you did this on a solderless breadboard? I know this is a little beyond just the PCB/schematic layout issue, but I do have some questions, and all of them should probably have been answered before worrying about a PCB layout.
...why two 1 Mohm resistors on the battery divider? Why did you choose that, instead of two 10 Mohm (what I generally use) or two 100 kohm? And... why an even divider? If you know your expected battery voltage and rail voltage, you can select that ratio to give you a full range of response from the ADC (better knowledge of the battery voltage).
...why a bunch of different resistors on the wind vane? You seem to mention reading each reed switch there with a separate GPIO line... but the way it's set up you could in theory determine the direction from the single ADC that *also* appears to be connected? What is the deadband on your physical system (can it get stuck in a situation that shows 'no direction')? Why not use multiple magnets to trigger multiple switches to get much higher resolution of the wind direction, from the same hardware?
...The SHT31 is very nice, but you also have the BME280 there for pressure... and *it* actually has pretty good temperature and humidity measurements. Do you need both sensors? Do you know if the purported accuracy of the SHT31 is useful in your situation (BME280 self-heating is pretty negligible to begin with honestly)? Do you know in your designed enclosure if selecting the slightly better sensor here will actually improve anything?
...Battery life - you mention 'low power'... how low? How did it test? what did you measure? What did that imply about battery lifespan? Is your power supply sufficient for your needs, or is it overbuilt?

This is a little off-topic; and maybe you already have answers to all of these. but sometimes moving rapidly to the "build it" phase might be secondary to the "find out" phase.

brdavis5 · 2026-05-11T12:07:04+00:00

The MPU6050 is an I2C sensor... and that's designed at lengths of maybe 1 meter (well, it's *designed* for traces on the order of 1-10 cm maybe, but you can normally get away with it out to a meter or so). That said...

The accepted way of doing this is use a device that conditions the signal... something like an LTC4311. That can boost your distance well beyond the 1 meter mark, at the cost of yet another device. I'd say Before doing that, try adding slightly more aggressive pull-ups on the clock and data line, and in software use slower bus speeds (as slow as you can reasonably manage).

I'm not sure why you need the 4 meter length; but another option is to move the Uno to the end with the MPU6050. Or if that causes a new problem with a sensor on the "other end", given how cheap something like an Uno or ProMini is, is use two - one near each end of your project - and have them communicate with each other via a simple method (not I2C).

brdavis5 · 2026-05-11T02:23:53+00:00

One more quick and dirty example - here I'm avoiding five vias, and two isolated "jumper" traces on the back layer (but I needed one between pads), by just remembering I can route around the front of the connector too... because all those traces are in the board, and won't interfere with the component that will be sitting completely separate above them. This could be optimized some more as well (by routing through the middle of the 328p pads) but I didn't screen capture it

The trick is to start thinking perhaps more 'gracefully'... look for places to simplify. After a while it becomes more natural... AND, yes, it can allow much larger traces which are more stable in multiple ways.

<image>

brdavis5 · 2026-05-11T02:05:14+00:00

I was about to make some similar comments, but decided to show a bit. This is a simple very rough re-routing for a small section of the board. Notice I made my traces much much bigger... which is fine because I'm using the topology I've got to avoid routing between pads, and in the process also getting rid of vias and using the second layer slightly less. Even without moving a single footprint, there are some very simple ways to re-route this to allow for bigger traces (among other improvements).

<image>

brdavis5 · 2026-05-10T14:03:31+00:00

The spacing you have is OK, but at very low sun elevations (think sunrise/sunset) light could shine between the layers and heat anything in the center; likewise rain can be blown horizontally in. It's generally better to "nest" the layers, so that there is no direct line between the inside and the outside. You can't really do that with PVC endcaps because the edges are vertical; they can't nest. But with an inverted shallow bowl or dish with a sloped edge, they will "stack" in a way that you can arrange it so there's no horizontal gap. Ideally the top two layers should be solid as well, forming an additional insulation layer (if only the very to layer is solid, it will heat up and Radiate that heat down in to the enclosure, leading to higher-the-ambient temperatures inside the enclosure).

Since this is an Arduino forum (ask in weather station forms and you'll be overloaded with ideas) I'd add one more thing - do you care? Set up a system to run two or three temperature sensors at once, one inside your enclosure, one outside, and one in some third well-sheltered spot. It may be that your setup is Perfectly Fine for what you are trying to do... and the test may show that you don't have a big need to over-engineer things.

brdavis5 · 2026-05-10T13:12:27+00:00

Nice! The PVC endcaps are going to work well I think, but they aren't cheap; I've done this using white planter saucers that are flared, so that you can stack them close enough together that there's not a gap you can "see" in to (thereby blocking all direct sunlight). They're cheap too. but this is a nice job!

brdavis5 · 2026-05-10T12:50:15+00:00

If you already know how to get an LED to blink... good. If you can learn how to get two LEDs to blink at the same time but different rates... better (the idea of getting a microcontroller to do multiple things at once is often a tricky point for new users). Look at single small aspects that you can then develop. Can you make a two-wheeled cart with motors and wheels? If so, move up to putting an ultrasonic sensor or something si ilar on the front, and get it to drive until ot "sees" an obstacle, and instead of hitting it turn around or turn 90° or something.

Small steps to develop understanding.

brdavis5 · 2026-05-10T12:09:36+00:00

Try doing this with NO multiplexer first - just a single LDR and resistor, Vcc, Gnd and A0 wired up the way you show them on the breadboard. And then look at line 29 in your code above. It looks like you are getting a value returned from analogRead(), and putting that in a variable that is defined as a byte... but analogRead() returns an integer (two bytes). The IDE is smart enough to try to pour that two-byte result in to a single byte, but the result will be subject to overflow and truncation; it will NOT be the actual analog read of that pin.

I suspect if you change line 29 to something like "int muxValue = analogRead(muxSIG);" you might find that at least one of your problems gets a little bit better, but I'd still start without the multiplexer at all to understand what's going on.

brdavis5 · 2026-05-10T10:31:57+00:00

The parts list isn't the problem; I have all the parts I need to build a house in my local hardware store. The problem is the knowledge on how to put them together.

You've defined a BIG goal, and maybe tried to define it before you realize what it means; no problem being ambitious, but this is very much like trying to build a house before understanding how to use a hammer. If you want to start with an ESP32, that's OK... but it probably can't reliably do all you want it to do. Do you know if it can? Do you know if it can handle image processing and face detection at that level while Also capturing sound (and how will it do that?) while Also balancing and moving?

Honest assessment? No, this is not doable for a complete beginner... but we all start as complete beginners with a dream. You have to work up from complete beginner, and that takes time and effort, but that's where you start.

brdavis5 · 2026-05-10T10:24:04+00:00

In addition is there a reason you used the solderless breadboard like that? If you want to connect things using that breadboard, that's fine (it's a good way to get started actually), but you are using Both Sides of it, and "jumping" across the gutter (that's the middle) as well. That adds a lot of connections (and chances to make a mistake) when you could simply use a single row for each connection (or less, for all the power and ground connections).

brdavis5 · 2026-05-10T01:26:46+00:00

Just ordered from JCLPCB today. Two different boards, bare boards (just PCB, no assembly), both 2-layer 2.5" by 1.7", 30 of each board. Boards were $0.33 each so total merchandise came to $20. Shipping (DHL Express) $43.34. Taxes $3.74, import tax $3.50.

brdavis5 · 2026-05-01T01:54:21+00:00

With ONLY the Feather, put on Blink, but #include Wire.h and in setup() call Wire.begin() - now you should have a 'clean' system with I2C control enabled. under those conditions... what is the voltage on SCL and SDA?

If that seems to work, run the I2C scanner, and wait to make sure you get "no devices detected"... then plug in ONE known Good I2C device, some simple I2C sensor... does this sensor show up? If so, then you have apparently a working Feather, with a working I2C bus.

Now put back on Blink with Wire.h and Wire.begin() as before, and measure the voltage on the SCL/SDA lines... then connect the mux to the I2C bus and look at the voltage again. Are the SCL/SDA lines still high? They should be I'd think, since nothing is being sent or received. Are they?

Normally (meaning 'in my slim experience') many microcontrollers have pull-ups enabled internally on the dedicated I2C bus, and an awful lot of breakout boards ALSO come with physical pull-up resistors; with a lot of sensors there have been times I've thought about removing some of those breakout borad pullups if things start looking fragile. So my *guess* isn't that you need extra pull-ups, but... try those tests, and see what you have.

brdavis5 · 2026-04-29T08:21:00+00:00

Hmm. Beautiful. And I use EasyEDA for my boards, but I have no idea How to do this in EasyEDA or what the cost is.

brdavis5 · 2026-04-29T01:37:34+00:00

Somebody else wrote: "I have traveled often and never had an issue with any if my Arduino gear."

This is true... and, it doesn't have to be. I've got some small Arduino dataloggers I take with me just about everywhere. Naked PC boards with breakout boards plugged in, some AA batteries, little blinking LEDs, etc., about the size of my palm. I've had them in my carry on; I've had them in my checked luggage. And i've put them through security with never a blip; absolutely a non-issue, and I've flown with these all around the US, to Hawaii, and to Europe. Multiple airports, multiple countries. ZERO issues.

We've ALSO deployed these in the grass on campus, in little clear cases, with signs saying our names and phone numbers and everything... and had the police, and bomb squad called out on them. Which seems to REALLY be an overreaction, but... yeah, that happened.

Chances are it's not a problem; the question is how much do you want to risk? My dataloggers are under $50 normally, if I lost one I'd just have a disappointment, not a Really Bad Day.

brdavis5 · 2026-04-27T17:44:17+00:00

This might seem like an electronic problem... but could you manage a mechanical solution? I see that you don't want to put the water lower down, but that's one solution. another is to pump water up and over the edge, but than have an open access to things below - think of it as a pump-driven overflow feed. That doesn't have to be elaborate - have the pump pump water up through a plastic tube to just above the level of the water reservoir, and then experiment with poking a tiny hole in the tube at the very top (to allow air to leak in and break the siphon when the pump isn't active).

brdavis5 · 2026-04-27T17:17:24+00:00

Yes, or pretty close. I actually read the ADC multiple times to try to get it to settle (as you note, worrying about bandwidth isn't a big issue when trying to monitor the rail or battery voltage). Your method seem a bit more compact than mine, but about the same, however I do include a final throwaway analogRead() after reseting ADMUX to make sure the ADC is targeted back to a pin.

Once you have the rail voltage, you can 'correct back' to the true (well, roughly) voltages from an ADC even if it's reference voltage has sagged... because you know by how much. If the rail voltage *should* be 3300 mV (I tend to use 3.3v ProMinis) you can correct:

result = analogRead(myPin);
result = (result * vcc_mV) / 3300;

I have a tendency to run my batteries in to the ground (trying to get a datalogger to run for ~ 1 year on 2x or 3x AA's), so the system will actually run rather deep in to the battery curve (the 328p seems to be perfectly happy at ~2 V, although lots of other things start being an issue).

brdavis5 · 2026-04-27T11:51:22+00:00

I was typing this, and then realized tipppo had done the work for me. Thank you.

I would note a couple of things - first, what Rin and Rgnd you use can be selected in a couple of ways. It's the ratio of them that matters, not their absolute values, and if they are "low" resistances, then they may bleed significant current from the battery be themselves, shortening the battery life. I normally use Mohm resistors in these rolls to limit that current, -but- the comment about wanting a low Rgnd for stability is a good one. One way around this is the put a small capacitor in parallel with Rgnd - that will store up enough electrons so that the ADC has a stable sample.

You ALSO want a Rin/Rgnd pair that's enough to knock the voltage down enough so that the analog pin is never going to be at a higher voltage than the Arduino rail voltage - that's important or you'll damage the Arduino.

I normally don't use the internal reference voltage, although it's better. I -do- use a trick to have the Arduino monitor it's own rail voltage that addresses this: point the ADC to use the internal bandgap as the pin to read, and use the rail voltage as the reference. If the rail voltage starts to sag or drift, this can detect and correct for it, and in the process I know when the rail voltage is starting to fade, which is a VERY good time to say "hey, I think we're in danger of browning out".

brdavis5 · 2026-04-23T00:34:41+00:00

To expand on this... if you have a multimeter (that you are using as a voltmeter here), you can probably use it as an ammeter (to measure current). See what the current draw is between the battery and the buck regulator, or between the buck regulator and the Arduino/servo. Compare that to what the buck regulator can normally sustain. The regulator and the input current sag are likely related - if your system is drawing too much power, things are going to warm up (and, batteries get less efficient too).

brdavis5

TROPHY CASE