(Variable) Rate control

Feature requests
41

Here is some code that may be useful:

            recvSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            recvSocket.ExclusiveAddressUse = false;
            recvSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);

            sendSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            sendSocket.ExclusiveAddressUse = false;
            sendSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);

It allows you to connect two ips to the same port. I have udp in a seperate class. Use multiple instances of the class to connect.

I tried to use 127.0.0.1 to connect to AOG with all network connections disabled, but it didn’t work. Can you connect RateApp to AOG without a network connection?

42

So would you have not the same pgn’s in AOG and RateApp? or send multiple versions from 2 applications to modules?

RateApp works to talk to AOG without a network in loopback. This is how you would have to do it for people without udp but would still want to use RateApp with usb.

Back to that “has to work for everyone” problem.

Even if you use ExclusiveAddressUse only one port is still allowed to talk to the network.

43

Here is an example pgn diagram.
PGNs

Maybe the UDP through RateApp is better. As long as it doesn’t limit other plug-ins / companion apps.

44

So how do would you do this without the rate app active and modules like autosteer and section control

45

Your suggestion of two days ago about switching between loop-back and udp is the best solution since two ips can’t use the same port. This would be in the case of using USB. UDP to other modules also work through the rate app.
If a network is present then the rate app, autosteer, sectional control, etc. can work as normal with AOG. The only change would be for the rate arduino. It would swap ports 8888 and 9999. It send to the rate app on 8888. The rate app sends to AOG on 9999. This wouldn’t allow USB though.
Another case could be a if a companion app that does land leveling or etc. It wouldn’t need the rate app but it would need autosteer. Does this new companion app need to do pass-through udp as well?
For two or more companion apps can they all communicate with AOG over loopback? Any one of the companion apps would then provide pass-through UDP for other modules?

I am getting a headache :smile:

46

Here’s another shot at it.

https://github.com/SK21/AOG/tree/master/AOGcomm

The instructions:

  1. start AOGserver

    • this represents AgOpenGPS

  2. start AOG Companion App

    • this is an app on the same pc as AgOpenGPS
    • up to 5 can be started
    • each needs a seperate send and receive port

  3. start AOGmodule

    • this represents an arduino module (autosteer, rate, etc.)
    • start on another pc on the same network

How the comm works:

  1. Arduino modules connect udp or usb to AOG with no changes.

  2. Companion apps connect to AOG over loopback. Up to 5 companion apps can connect, each with a seperate receive port.

  3. PGNs are in 3 groups:

    • 31000 to 31999 are for AOG
    • 32000 to 32999 are for arduino modules
    • 33000 to 33999 are for companion apps

  4. Arduino modules and companion apps all send to AOG. If the PGN is not for AOG it is resent by AOG.

  5. Companion apps can communicate with AOG, other companion apps and modules. Modules can communicate with AOG, other modules and companion apps. AOG can communicate with the modules and companion apps.

The main thing is AOG resends the PGNs to modules or companion apps.

47

Well i think i got the thing working with nothing changing anywhere, no matter if you use AOG and InterApp in either udp or serial. UDP never leaves AOG if InterApp running so even if you have a machine control board, autosteer board, and a rate board, they all would listen on 8888 and send back on 9999. InterApp handles spitting out the pgn’s normally done by AOG - like a repeater.

If using only serial, you could have usb1 to autosteer, usb2 to machine control, and the InterApp runing out thru usb3. AOG talks to interApp via loopback udp completely unknown to the user.

As usual all the forms and user interface/error checking is the other 90% of the code

48

I thought about that repeater part as well. AOG can repeat any pgns that aren’t meant for it. To communicate with the companion apps AOG would send on multiple ports (8888,8889, etc). Each companion app can bind to one of the ports to receive the data. I think could be all built into a class in AOG.

49

so is AOG with Rate able to run an electric drive for say a planter without flow meter. Essentially basing its output speed entirely off of gps speed and a calibration number? :thinking:

1 Like
50

Possibly, is there an rpm sensor for the planter? It would be like a virtual chain drive. The faster the speed, the faster the electric drive.

1 Like
51

no sensor now . It is just a ground drive via chain and sprocket currently. It is a Case IH cyclo so would only need motors, 1 for each drum. Doesn’t seem speed sensor would be hard?

52

This subject interests me to modulate the sowing but I cannot find any assembly diagram to understand the operation. Is there one?

53

It may be possible without rpm sensors. The calculation might be pwmValue=Speed X meter cal. This would vary the speed of the motor. You would need a motor controller for each drum and a meter cal value for each motor controller. The size of motor and controller would have to be determined. To calibrate it you could use a form like this:
Capture

You would enter an estimated Meter Cal, start the motors and run for a length of time. Then weigh the output and calculate the rate and the new meter cal.

Maybe someone else has already done this and would have some ideas.

1 Like
54

just like flexicoil/NH does with the air seeder tanks. weight the product from xxx turns and get a per tick weight. speed/distance/rate all calc’d from that

55

I guess the difference is the speed would of the machine in mph/kmh not the rpm of the meter roller shaft. It should still work the same

56

Yeah it doesnt seem like you would need anything but gps speed. Would you have to use a stepper motor or could a DC motor be run at a constant speed via PWM. Or is that what rpm sensor would be for, check to see how fast motor is actually turning :slightly_smiling_face:

57

A rpm sensor is what Bourgault, Flexicoil, etc. use. They measure the rpm of the meter roller. If the DC motor repeatable turns at the same rpm for a given pwm value I think it could work without a rpm sensor.

It would kind of be doing the same job as the monitor from Bourgault, Flexicoil. Could even replace it with enough coding, another pcb, time, etc. :slightly_smiling_face:

1 Like
58

but it won’t turn the same speed because of different loads. the sensor/pwm is a pid loop in flexi, i’ve watched it with a scope. I wanted to intercept the pulses coming from the magnet and increase/decrease the pulses for variable rate.

59

Yes you’re probably right. In some of that lumpy fertilizer it may not even turn.

60

I’m presuming this GitHub - Coffeetrac/AG_ASD_Host: ASD Host Controller for AGOpenGPS and Cerea will need altered to work with rate and v4?
Haven’t had time to dig into any code yet, as spring work started!!