Is there a reason why a lot of processing code is on the arduino.
Would performance be improved by sending raw sensor data to the PC running AOG the running the calculations on the more powerful processor.
I assume generally the arduino is more than man for the job, but just a thought for discussion.
Basically the Arduino acts as a HAL (hardware Abstraction Layer), so there is more flexibility for the steering hardware (without the need to change AGO).
Besides being way easier to interact with hardware (read voltages, switches, control relays), the Arduino runs in a real-time manner, so it’s better for doing PID loops, generating pwm signals, etc. It has more consistent run times and special hardware for some of these tasks. A PC is influenced by what processes are running at the time, I/O load, etc. There’s more jitter when trying to do tight control loops.
That’s not to say a PC can’t do real-time hardware control and run PID loops. People do it all the time controlling CNC. But it requires special modes on the operating system (and a special kernel on Linux) to guarantee CPU time slices for the processes running, and the best it can achieve is known as “soft real time.”
If it isn’t, the Arduino compatible Teensy4.1 solves the problem with 600MHz dual core power with 32 and 64 bit FPU. 
With regard to the PC, in my case the popular CF-D1, even opening a settings window causes a significant pause in steer operation. Not what you’d want on the steer pwm output at high pwm values. 
Oh yeah, you had me at Teensy! 
I am a fan can you tell?
Which part of the arduino processing do you feel is not up to par?
Not sure why op @Roderick1st would want it moved.
But the Teensy is some serious bang for your buck. Multiple built in serial, can, i2c, ethernet and spi interfaces. An absurd amount of processing power and memory, all for $35 for the 4.1 vs the genuine nano 3.0 at $21. Teensy is fully compatible with AOG software, and the Arduino environment and 35X the HP for $14 extra.
So it can run the AOG steering, plus any other massive poorly programmed ill conceived dreams of mine simultaneously with processing, communication input/outputs to spare.
Also for CAN control you are one very small purchasable shield board from having AOG almost ready to steer.
I’m struggling with a slow down when activating the Mma but I suspect it’s a compatibility problem with using a nano every instead of standard nano. Standard nano on order.
I’ve yet to get a system up and running so can’t complain about anything to be honest.
I’ve been doing a lot of practise on C# to try and get up to steam on the system and I need to be able to share the gps data with my combine yield monitor which I’m also rewriting in C# as was written for android phone.
I suppose development in visual studio is a lot easier than arduino IDE. But I’m hacking away at an esp32 to bridge the nano to AOG via WiFi. The ESP should take over duties from C# app in the end.
On a side note Brian, you don’t fancy writing an option into AIO to broadcast NMEA messages out on another port for use with another app 
More like 300+ times the HP!! 
Well if you use udp, they are everywhere. That is the best solution
Except I’ve run into the problem of two apps on the same machine can’t both connect to port 9999.
Depends. 
I’m google fanatic… Like to search things.
“Actually, you can bind to the same port two different sockets.
This can be done via socket option SocketOptionName.ReuseAddress.”
So apparently both (all) apps have to be coded to reuseaddress…
Link of source: Why can't I have multiple listeners on a UDP port
Edit: rtklib has strsrv software, if recall right, it can “swallow” anything and output it to anything… Not quite so, but has been using it much for serial <-> sockets etc…
Allows udp/tcp server / client, ntrip, serial, file…
So put strsvr to listen 9999, put it to output data to what ever ports / protocals you want and then add one for aog and change aog setup to listen that…
I had read about that… I suppose an easier option would be to multi-IP the Nic and bond onto the different IP’s.
Tested. Not working.
If I change UDP port from agio to say 9997. It shouldn’t hear my dualgps setup that sends data 9999…
But… Wireshark of course shows src port 5544 dst port 9999… and agio and aog see that data…
So … ? is it hardcoded and the port change doesn’t change nothing?
And so, aog wont let go of 9999 and strsvr wont get it and can’t reroute…
OOOR I’m again wrong. But picture says same: dst port 9999, configured to 9997 and still gps goes and goes… And yes, restarted agopengs and agio… not computer.
AOG / AIO receive on 9999 they don’t send on it. Changing to 9997 Means your gps device must transmit out on 9997.
I’m not sure how AIO communicated with AOG.
my point exactly. port 9997, frshly started programs and gps goes thru to “wrong” port.
might just look source…
You recall perfectly, I have used this trick on strsrv for very non GPS related data. Its basically serial pass through.
I’m not sure the port numeric changes the port to be used.
The other option is send gps on serial and udp