(Variable) Rate control

Feature requests
21

Ok, you might have to explain it a little more. It is probably easier as torriem says to use a plug-in system for different features. I am open to anything that improves AgOpenGPS :slight_smile:

22

I saw your video. So a separate RateController app talks back and forth with AOG using PGNs over UDP. Here is an example of what the PGNs could look like:

  1. PGN from AOG
    0 header 0
    1 header 1
    2 workedAreaTotal Hi
    3 workedAreaTotal Lo
    4 ToolWorkingWidth Hi - only sections that are on
    5 ToolWorkingWidth Lo
    6 Speed Hi
    7 Speed Lo
    8 mdSectionControlByteLo
    9 mdSectionControlByteHi

  2. PGN from AOG
    0 header 0
    1 header 1
    2 manBtnStateIsAuto Hi whether manual section button is in auto state
    3 manBtnStateIsAuto Lo
    4 manBtnStateIsOff Hi
    5 manBtnStateIsOff Lo

  • infer manBtnState On if not Auto and not Off
  1. PGN to AOG
    0 header 0
    1 header 1
    2 autoBtnSetState 0 - no change, 1 - On, 2 - Off
    3 manBtnSetOn Hi (16-9)
    4 manBtnSetOn Lo (8-1)
    5 manBtnSetAuto Hi
    6 manBtnSetAuto Lo
    7 manBtnSetOff Hi
    8 manBtnSetOff Lo

Is this what you had in mind?

23

Here is a rate control plug-in:
https://github.com/SK21/AOG/tree/master/RateController100

It is a separate app that runs together with AOG. The only changes on the nano were to swap ports 8888 and 9999. The nano sends to the controller on 8888. The controller sends to AOG on 9999. No changes are needed to the ports on AOG. I added the 3 PGNs to AOG to allow it to send and receive the data. Any other plug-in for rate control, remote switches, etc. could use these PGNs.

1 Like
24

YEs that is it exactly lol. Now you aren’t tied to the gui of AOG. But technically its not a plugin - i suppose important to make that distinction, it is a separate app completely getting info by udp

2 Likes
25

So how do you send data the other way? I tried making RateApp send on same socket as AOG but of course you can’t do that, binding the same ip/port to 2 different sockets.

Also the rateApp framework i wrote (its on github) uses loopback for AOG to communicate back and forth to talk to RateApp. But what seems impossible is to do both.

I can have AOG send to RateApp on 18888 and rate App send to module on 8888. Then module send back to RateApp on 19999 and rateApp send to AOG on 9999. But as soon as you take out the RateApp, comm is broken for those not using it. You can’t have AOG and RateApp both send to 8888 since they both use the same socket IP/port and will not bind.

So, do we have the secondary app, RateApp only listen to 18888 and send back to AOG on 19999 via loopback on 127,0,0,1 and then have RateApp send to its own module on a completely different pair like 8885 send and 9995 listen and build the module specific to listen only to RateApp? RateApp of course would get all the pgn info like sections on-off speed etc via loopback.

26

In my app its nano → 8888 → rate controller → 9999 → AOG and AOG → 8888 → rate controller → 9999 → nano. If you take out the rate controller the link is broken. You would just have to change back to nano → 9999 → AOG for those not using the rate controller. But if your not using the rate controller you wouldn’t need the nano on the rate pcb, unless you are combining it with the auto-steer pcb.

I find that the separate rate controller app is not as stable as the one built-in to AOG. Sometimes the connection is lost. I’ll look at your framework, maybe it is more stable. Still finding a few bugs in the rate controller.

27

The rateApp source code doesn’t compile.

28

Well maybe it needs some love, I tried to make it a solution with some more directories.

My version doesn’t use the network udp but the loopback instead. This doesn’t rely on the network at all.

Was thinking some more about this, have AOG talk to modules as normal when not using the rate app. But if the rate app is used, aog only talks to rateApp via loopback local and not the network. 127xxx and not 192xxxx. Rate App receives and sends the udp to the network passing forward and backward to AOG.

The other challenge of course is every setup has to work for everyone be it having udp or only using usb

29

Bus protocol😉

30

Just a guess, can you do TCP for one and UDP for the other?

31

Or sending autosteer data to 9999, section control to 9998, machine control to 9997, rate to 9996?

32

A socket with IP and port doesn’t care whether its TCP of UDP, so that kinda sucks

Richard, the problem is both applications need to send and recieve from the same port on the same computer.

33
34

Understand for sure… don’t know it’s possible to have multiple sockets for udp in aog? So that you can send multiple packets on multiple ports in that loopback circuit.

35

TCP is way too complicated to connect for this app considering how it is used.

36

You can have 127.0.01 and the networked IP adress so that is 2. But you can’t have them bound to sockets in multiple apps.

37

Crappy

1 Like
38

If using RateApp it could just pass thru udp via loopback and not use 8888 9999 for AOG (turn them off)

If using AOG only, turn off loopback, use udp on network as normal. Modules would never know the diff or require different code.

You could also use usb only for rateApp since using loopback doesn’t require a network

EScQLezUcAEoajo

39

If you had multiple arduinos, say 2 pcb boards with 8 relays each, (or any other app/arduino combination) they could all communicate through the RateApp?

40

if they were udp, yes.

First board would listen to the lo byte, second board to hi byte for section control of all 16 on 2 boards. Not a problem with ip/port since they are all different “computers”

However you can’t hook up multiple usb boards directly unless rate app provided 2 usb ports, then even usb would work. That is the big advantage of RateApp - you can do whatever you want. Not limited to Rate Applications as well, obviously