Uploaded here.
Thx for providing the RC Code. In Europe its very common to use up to 7 section switches on sprayers. It would make sense to extend the numbers of possible section switches in your code up to 8 max, no PGN change is necessary. It would be very helpful!
We have an old Amazone UF1-series sprayer with 9 sections at 21m width. Iām not insisting on more than 8 but I would consider more than 9 quite common at least on a trailed or self-propelled sprayer. Individual nozels might not be used with AOG?
The code supports 16 sections. The pcb only has 8 relays, but more relays can be connected with the MCP23017 to a 8-channel relay module such as those found on Amazon.
1 Like
What I meant are the number of readin switches, in your code there are only 4 switches availiable.
Common hookup sprayers setups in our region:
5 sections at 15m width (also for 12m)
7 sections at 21m width
each section has itās own switch to control the belonging section manually.
In my case Iād like to readin 5 section switches and have to control 5 section relay outputs for the valves.
ARAG Control box like this:
If I use your current code I can only use 3 switches (left - middle - right) and have to assign
switch 1-left: section 1,2
switch 2-middle: section 3
switch 3-right: section 4,5
The sections will still be controlled individually in auto mode. In manual mode you are correct you have to combine sections. Do you usually use manual mode?
Usually one pass along the field bounderies, so there is no need to have an exact outline of my field and /or prevent wind drifts in outer section.
So would this work?
switch 1-left: section 1
switch 2-middle: section 2,3,4
switch 3-right: section 5
Iām late to the party and not very handy with the coding but I do completely understand the mechanics of how most rate controllers work.
For liquid itās fairly straight forward you are just reading flowmeter, speed and width to figure the oz/min or gal/minā¦ some systems read and use pressure as well. But from oz or gal/min speed and width you know rate per acre.
For dry all of the systems I have ever worked with used a variable rate beltā¦ if you are going to do the math in the arduino I would definitely send the rate, not a percent of rateā¦ because at that point you still need a bench mark of some sort.
To calc lbs/ac you need density of material lbs/cuft, cuft/revolution, width, and speedā¦
Again you need to send the info to the arduino or some type of belt speed numberā¦ I doubt a percentage would work well since 1% of 10gal/ac is hugely different than 1000 lb/ac
Percentage is used only between AoG and rateControl application, then in this las,t you define the real value of quantity/area that is sent to the Arduino
1 Like
Why not just dump a number?
When I setup several raven 440ās to do VR thatās exactly how it worked.
The envisio pro would read in a shapefile (industry standard) of numbers (btw the data is stored in the dbf file). Usually just a set of numbers output by the program of choice.
Once you put that into the enviso it would dump the number to the Raven 440 which held the density, width, speed, etc. information needed to actually know how to drive the belt.
So I guess thats why Im confused as to why you are wanting to change to percentage half way through.
What number and how big of a number do we send? Does the arduino receive this number? How many decimal points? Do we do all the calculations in AOG? Do we open another window in AOG to input and calculate all the rates? Or do we open another program to do the calculations. That is what we are really looking at, where are the calculations done? It is all bits and bytes when transferring from AOG. Whether it be big numbers or precents of numbers. A number such as 100000 takes a big sentence to transfer that number. It may take less to send a string. But you still have to convert it.
So here is the issue Rate file ā material being applied.
Here are the known factors
- Speed
- Width
- For wet.
a. Gallons per RPM of flow meter.
b. Gallons to apply - For dry
a. Material Density
b. Cubic ft per revolution of belt
c. Gate Opening
(It could also be done with a steady belt speed and moving the gate, but that can be cumbersome)
Now to the questions. Where to calculate?
We need the above information regardless, so do we dump that to the arduino and let it do math or calculate on the computer. To me it doesnāt matter because the result is the same and the math is fairly simple, except instead of just sending a calculation doing it on the computer, to calculate on the arduino you must send all of the relevant information every time in case someone changes information (density, width, etc).
In Opengrade they set it up to send a value (1-199) above 100 one direction, below another. VR could be done the same, where 1 is wide open and 199 is almost closedā¦ this would give steps that could be calculatedā¦ ie for 200 lb of potash on this machine the valve needs to be 75% open which corresponds to a value the arduino is toldā¦ and to return the arduino will tell the computer the rpms of the belt.
Now having said that you can also dump all of the info to the arduino, the biggest value you should encounter should be 9999.9 which would be a lime valueā¦ typical lime is only 3000 lbs/ac.
As far as significant digits, I could argue that for gallons 0.1 is plenty and for dry 1 is plentyā¦ typically the controller āliesā and tells you its spot on, but in reality its usually Ā±5% due to mechanics.
I am going to start working on the calculations on paper to get everything out in the open that I can think of.
Iāve seen values from 0, or 1 for on and off to values of 35000. So, I read a map, and get a random value. There are no units in the file. 230 units of _______. Or 35000 units of ______. Is 1 on or off. Lots of assumptions must be made.
The goal was to read what ever value was in the file and record that value for that spot. When the tool is over that spot it sends a ratio of the maximum value. A feature to add would be to send the max value out when loading.
It was always assumed that the AOG is only for locating the defined rate and send that information out for further processing by a specific rate processor. This could be for wet, dry, water, or whatever someone decides to write as a secondary program.
2 Likes
All that data isnāt sent to the arduino. It is sent to any secondary program that anyone wants to make/use. If all the calculations were done in AOG then there is only one way to do rate. It is locked in to AOG. If someone wants to do rate a different way AOG would have to be changed every time.
The only things sent to the arduino are units per minute required, a calibration number and PID settings.
2 Likes
Ok, if it gets sent to another program just send the value and maybe the max valueā¦ no unitsā¦ this is how the epro would do with the raven 440.
Actually aog could do the same and be fairly straight forwardā¦ all raven controllers (440, 660) will take a value from serial ( ie 200) and do their thingā¦ and they can be had for fairly cheap (cheap vr) and if Iām not mistaken, some could do section control as wellā¦
In essence that is what your striving forā¦ aog to read the vr file and dump a number to something else (arduino, other program) where you setup your controller and input widths densitys etc.
So with the current version, it would send 5 different percentages for every spot. Perhaps we can send five different sentences with an id and then the value.
Header, ID, value, check sum.
Anyone know if during a single AOG loop we can send all the IDs one right after another. Or do we need to send 1, finish loop, 2, finish loop etc. Iām old school and still canāt believe any of this happens as fast as it does.
It would be good to match up the pgn to a commercial system. But do we know what the pgn for a system like Raven is?
If 2 byes are used the actual rate could be over 65,000. It would work for high rates with no decimal. For lower rates one decimal place would be needed. How will the app know to divide by 10 to get the one decimal precision?
If 3 bytes are used the actual rate could be over 1.6 million to one decimal place. This would add an extra 5 bytes to the pgn. If each product rate is sent individually it would add an extra 30 bytes in total.
Percent is still the smallest pgn, but is it the best way?
Here is what raven doesā¦
Looks like itās simple string interface to send and recieve.
I know deere does something similar with grading software, Iāll look into what serial protocol they use to get rates from an external source if any.
More sources hereā¦ raven is pretty good about being open about protocols.
1 Like