do you think it can be added?
Edit, I’ve managed to add it, modified AgIO 
1 Like
If you want to post the changes here I’ll add it.
case 0xE6: //230 VR
{
SendModule2Port(data, data.Length);
SendModule1Port(data, data.Length);
break;
}
This is what I found you added, anything else?
No, anything else 
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
