The Combine Forum banner

41 - 60 of 212 Posts

·
Registered
Joined
·
131 Posts
Brian, I was just going to toss in the pressure for kicks. Ours reads off the pump side of the valve manifold, and it is always a good check while running. Plus could use it for verification down the road as mentioned above.
 

·
Registered
Joined
·
5,824 Posts
I think sensing pressure from the farthest away nozzle is an interesting thing too.

Have you decided how often per second you want to do flow calculations?

One other feature of spray controllers is after shutting all the booms off, and then turning on again, they wait a few seconds before doing rate control again. This is to help with headlands as the speed usually decreases while turning, but then in a couple seconds you are back up to speed and heading down the pass, minimal rate disturbance that way.
 

·
Registered
Joined
·
131 Posts
I agree that knowing the pressure difference could be useful, relatively easy to add that in as we go.

If I read your AOG_Rate correctly, your timed loop is 50ms? I was going to see what happens with that. I updated the code, just have to get a sprayer back here today to play with. Oh, and I broke AOG(Probably something you didn't want to hear). I will post on the AOG thread in a bit.

In terms of waiting after everything coming on, that could be a simple state change check in the timed loop from the last time the loop was executed.

https://github.com/warrenseely/Liquid_Rate_Control
 

·
Registered
Joined
·
131 Posts
In terms of variables requested from AOG:

Speed, relay, and target rate for sure.

I would propose sending a setup value for the meter calibration tag for ease of user integration, but not a huge deal. Once you set it, I woldn't think chances of using multiple flowmeters with different #s are high.

Sending to AOG: actual rate(Liters/min), pressure(bar), maybe total liters(will need a reset for that though...)

Are we doing a calibration routine? Most of that info would probably be handled in AOG I think based on what Brian has wrote.

Did I miss anything?
 

·
Registered
Joined
·
131 Posts
Had some time to work on the rate control. Tapped into the sprayer pressure and flow signals, and attempted some code. Also ran an oscillascope on the flow signal and wow. Much messier than I was expecting! See attached pic. Center is with the flow at "0", the taller spikes are the meter pulses....and they only reach about 200mv reliably. Amplitude scale on left side is -500mv to +500mv.

Arduino needs roughly 4v for an input to consider it "high" so some voltage amplification will be necessary. Probably some filtering as well......
 

Attachments

·
Registered
Joined
·
375 Posts
Had some time to work on the rate control. Tapped into the sprayer pressure and flow signals, and attempted some code. Also ran an oscillascope on the flow signal and wow. Much messier than I was expecting! See attached pic. Center is with the flow at "0", the taller spikes are the meter pulses....and they only reach about 200mv reliably. Amplitude scale on left side is -500mv to +500mv.

Arduino needs roughly 4v for an input to consider it "high" so some voltage amplification will be necessary. Probably some filtering as well......
Was the flow meter still connected to it's normal circuit? If not, are you missing a pull-up resistor?
 

·
Registered
Joined
·
131 Posts
Yeah flowmeter was connected to its usual circuit, and I "tee'd" into that. I was expecting a much cleaner signal so its entirely possible that that was the issue. Was hoping to run parallel with AOG until the code is completely working but that may not be an option. I can give it a whirl tomorrow with the flow sensor only going into my code and see if that and/or a pullup resistor fixes it.
Only had enough time to tap and grab some readings before my sister showed up with a blown wheel bearing -_-
 

·
Registered
Joined
·
3,827 Posts
Discussion Starter #48
I used a hall effect paddle flow sensor from seeed studios and the signal was quite clean and I could get good measurements up to quite a fast rate. My New Holland sprayer uses a sensor with a metallic paddle that's either sensed with a hall sensor or more likely an inductive proximity sensor. Either way, I'd expect a fairly clean pulse signal out of it.

On my NH sensor, every year I replace the paddle wheel and axle since they wear out rather quickly. I think they charge me almost $200 for the little paddle and fiberglass axle. Makes me wonder if I could get a 3D printed metal paddle cheaper...
 

·
Registered
Joined
·
1,207 Posts
If you design it, I will print it. No charge :) Oops, missed the metal part. Yet to see a 3d printer doing metal.
 

·
Registered
Joined
·
375 Posts
Yeah flowmeter was connected to its usual circuit, and I "tee'd" into that. I was expecting a much cleaner signal so its entirely possible that that was the issue. Was hoping to run parallel with AOG until the code is completely working but that may not be an option. I can give it a whirl tomorrow with the flow sensor only going into my code and see if that and/or a pullup resistor fixes it.
Only had enough time to tap and grab some readings before my sister showed up with a blown wheel bearing -_-
My other thought is maybe the o-scope was "zoomed" out to far?
 

·
Registered
Joined
·
422 Posts
My other thought is maybe the o-scope was "zoomed" out to far?
That's possible (i.e. x-axis of scope). Another problem is that the digital IO pin connected to sensor has too high of impedance. The IO pins of the AVR have very high impedance if you don't add any extra circuity. That means they draw hardly any current from the line connected to them. With such low current, noise can become a big problem, especially if you have a long wire going to the sensor. That is why in industrial settings they often don't use voltage for sensors but "4-20 mA current loops". Having a current in that range makes the sensor much less susceptible to noise (e.g. magnetic fields inducing voltage in the cable).

You should probably have an external pull-up or pull-down resistor in the circuit somewhere. It will depend on the type of sensor you are using. Usually the datasheet for the sensor will have details. There are some reverse engineering tricks you can do to figure out how the sensor works. There are also internal pull-up resistors in the AVR. Those a high resistance though and not suitable if your signal is noisy or the cable to the sensor is long.

I think in "real" designs, you would have a buffer between the sensor and the microcontroller, e.g.

SN7407 Hex Buffers/Drivers With Open-Collector High-Voltage Outputs | TI.com

If not a buffer, they would at least have external circuity to limit voltage and current in order to protect the microcontroller.
 

·
Registered
Joined
·
422 Posts
Here is a simple example of how to interface a hall-effect sensor with a 5V microcontroller:

AH276 hall effect sensor with microcontroller

This reminds me of an excellent book for people getting into this stuff: "Practical Electronics for Inventors", Paul Scherz. It is filled with all sorts of useful information. A lot of stuff is covered but the book explains it all without assuming you have a degree in electrical engineering or something. There is a section in the book that is dedicated to exactly this topic: interfacing sensors with microcontrollers. There is even a nice summary inside the cover I think.

Another commonly recommended book is "The Art of Electronics". I would not recommend that one for farmers who are trying to invent things. It is a good book but it is written for undergraduate engineering students. If you are not comfortable with differential equations, it is not for you. ;-)
 

·
Registered
Joined
·
131 Posts
Got the signal cleared up! Had a bad connection and had to add a 90k Ohm pullup resistor. The good news is I can run in parallel with the existing controller so that will help with calibrating.
 

·
Registered
Joined
·
131 Posts
Here is something for Torriem (and anyone else)to think about.

After getting my signal cleaned up on the sprayer, I was able to get some readings with the arduino. However, it would read ONLY after a reset, and ONLY for about 10 seconds as the displayed flow number gradually decreased from 168? down to 0. As it approached 0 it would decrement slower, once it reached 0 it would not display again until a reset of the arduino was performed.

I set up a motor with a feedback wave(like Brian's TractorSim setup) so I could get a good signal and test without being in the rain. Tried tinkering with the PPMReader library code, and what I eventually concluded is that something is either getting so large its overflowing, or something else is approaching 0 and dominating the "liters per minute" that the library returns. If I call the PPMReader.reset() function within every 12 seconds, I can get a relatively stable number. ~12 seconds is when the LPM --> 0. Calling reset function at 1 second intervals gives a return within 0.06 100% of the time; as the frequency of the resets increases, the repeatability decreases. Likewise inverse. Pick your preferred accuracy and scale? I need to try adjusting the signal frequency and see what happens yet.

Anyway, wondering if someone else has any input on this. I ammended the code so only the Liters/min is being sent out, (ignore all the commented code, that is future!). Running the output to serial monitor gives same result as AOG. Code is in link below. Library files are included.

https://github.com/warrenseely/Liquid_Rate_Control

WIRING:
digital pin 3 is a constant output for running my motor(hbridge enable) and is wrote HIGH in the setup() function
" " 2 is the signal input and is tied to an interrupt.
 

·
Registered
Joined
·
3,827 Posts
Discussion Starter #56 (Edited)
Do you know how many pulses per rotation your flow meter is giving you? I think the one I was working with was only 2.

Instead of outputting LPM, can you just output the raw ppm value? The first thing in debugging this is to see if the raw values are sane. Also, is the total counter counting (and not overflowing)? I guess you have to set the "record" member variable to do that. But it would help in debugging I think.

A reset really only should be necessary if you want to zero out the total pulse count.

EDIT: so I think I found a bug in PPMReader (no surprise). I extracted PPMReader from another project, and I seemed to have missed at least one thing. In PPMReader::pPMReader(), I think we need to set last_time to 0. Although calling reset() does that also... but for correctness the constructor should initialize that to 0 also.

Further EDIT: I think I must have missed something in on_trigger()... I'm trying to reconstruct my logic here. I went back and double checked my full project (which uses a modification of PPMReader), and the code is the same, and it worked before as is, but I can't seem to see anywhere where the last_times ring buffer is updated with new times once it's fully loaded. Hmm. Seems strange to me. I'll do some thinking.

Okay so can you try this. Basically add the line "last_times[last_time] = now" in get_ave() such that it looks like this:
Code:
        ppm = (uint16_t)( TICKS_PER_CALC *
                /* convert microseconds to minutes */
                1000000 * 60 /
                /* divided by microseconds passed */
               (now - last_times[last_time]) );
        last_times[last_time] = now;
        last_time = (last_time + 1 ) % TICKS_PER_CALC;
I think that missing line is why you had to reset so much. I have no idea why my code worked at all before in my own project. Maybe it didn't and that's why I had so much grief! Might have to dig out the rig and give it a try again this winter.

If that fixes it, I'll change it on github.
 

·
Registered
Joined
·
5,824 Posts
I think the PPM reader is a serious overkill doing way more then needed.

I would concur in the reading of the pulses first. Make a very simple code block that just reads pulses, and once a timed frame spit them out the serial monitor and reset your counter.

make sure you make your isr variable type as volatile:
volatile unsigned int pulseCount = 0; //use unsigned long if it will count higher then 65535

Also, i would go back to your much simpler isr routine that just increments pulseCount every time the pulse happens. ISR's should never be more then a line or two.

Since the timed loop triggers every 50 msec or 20 hz, multiply the pulseCount by 20 to get ppm, then reset the pulseCount. Or set your loop timing to 5 hz, or even 1 hz to slow the world down.

Serial print the value out the monitor. Once that works, keep adding stuff as required.
 

·
Registered
Joined
·
3,827 Posts
Discussion Starter #58 (Edited)
Reading your comment more closely, Brian, what "timed loop" are you talking about that triggers every 50 msec? Are you talking about loop() itself?
 

·
Registered
Joined
·
3,827 Posts
Discussion Starter #60
I think I edited my post while you were replying. Can you tell me more about the time "timed loop" thing?
 
41 - 60 of 212 Posts
Top