UDP only - Where is AOG heading

Well wifi ntrip master can be connected to AOG? It has option to forward wifi network that its conneted so section control esp32 connected to wifi ntrip master, phone as main wifi for esp32 and tablet or some combination of that. Theres always bluetooth.

But probably not so simple :smiley:

Is there good wireless setup explained or possible?

Really nice, i want to Do the same… Can the UDP Code and PCB be shared. Would be a nice unit! :slight_smile:

Yes that is my understanding. All CAN chipsets have pretty advanced filtering capabilities in the silicon. The MCU only sees the packets it is interested in. Of course there is a protocol for claiming addresses that might need to be followed for j1939 and isobus, but I’m not sure if tractor components follow that, or if they just hard wire the ids. I think the tractor ECUs probably just hardwire the ids and don’t bother with address claiming, but implements plugged into the isobus probably do need to follow the address claiming procedure.

And yes there should be no problem with collisions on CAN because the CAN chipset and the transceivers should take care of that. I’ve never had any problems placing messages on the bus without regard for timing or existing traffic.

CAN is certainly more robust physically and electrically than ethernet is, but ethernet is certainly well supported by the hardware AOG uses (tablets, teensy, etc). I’ve read before that automakers are planning to move to ethernet and more specifically internet protocol down the road, perhaps using some kind of physically robust signalling system on the wires.

1 Like

So many legends here from the beginning… let me clarify some.

I fully agree that neither USB nor RJ45 is a suitable connector for farming or any other automotive use.

When talking about the plugs, just look to the origine of those plugs: RJ45 comes from telefone cords plugged once in their lifetime and thrown away when broken. Hirose, a high-quality Japanese manufacturer, states 200 plugging cycles for its TM21 series. It’s a lot for RJ45. On the other hand, USB is made for plugging. USB-C specifies 5000 cycles minimum - 25 times more than RJ45. But as I said, both aren’t really suitable (or you’ve some cables in spare). In industrial environments outside cabinets, the answer is M12-D. That’s quite ok for farming, especially if the sheath is made of PUR. These cables work for both Ethernet and USB. But those cables are expensive and in case of USB hard to find (e. g. Murr). Or do yourself.

When USB don’t reconnect, it’s bad software. Windows itself is quite weired and AgIO does no reconnection yet. I’m using use mice for 20 years now - never thought of switching to an Ethernet one…

When USB has trouble when driving the motor, it’s always bad hardware and/or wiring. Ethernet is a workaround, but doesn’t correct the root cause. If the USB motor driver is wired correctly, there is no issue at all.

USB delivers power. It’s even made for hot-plugging. Under power. For more than 5000 times. IMU, Arduinos and Ardusimple have it out of the box. Any further arguments needed for USB here?

RS485 (not RS232!) and CAN are suitable candidates as well. Advantage RS485: USB adapter ships for $.99 & very easy on every µC; with TI chips, time and data with a single twisted pair is possible. Disadvantage: Time slots must be defined by hand or better use simple proven-in-use protocols like Modbus.

Time management is the big advantage of CAN as @woody_matt already explained. And CAN is developed for automotive (by the manufacturer of the BNO08x by the way)! Any two twisted wires will do the job. But with CAN, you need another two wires for power.

Both, CAN and RS485 don’t need or even benefit from any isolation and they are immune to miswiring. A very professional approach, especially when taking into consideration, that WAS data and keypad data is available on argricultural CAN systems.

Automotive Ethernet will enter more and more cars, but as TWE with specialized ICs. Hard to get and expensive these days. Two twisted wires as well and also power - very nice. Maybe it is combined with TSN - then we can lower the jitter to nanoseconds. But that’s future and nothing to look for in the next few years.

The idea of having a AgOpenGPS being able to SEE is amazing. But with the right hardware, please. Picture processing has to be done in FPGAs like shown here or here. The outcome is a few bytes per second, so every low-latency transmission is suitable.

So my perfect system has an iMX core (Teensy) with the AOG runtime running on it, communicates to the CAN busses and has WiFi to any mobile device for the GUI. GMS sticks, IMUs, F9P can connect via USB or CAN. Let’s make it happen!

By the way: Network-over-USB including UDP works with Windows 10 out-of-the-box, too.


Just setting up the network. I figured the boards just get plugged in and inos uploaded and they are good.

Checkout this thread.

I did my best to explain how the wireless network works in OGX.


Can it also include hardware requirements?

1 Like

Great no wires no connectors broken or pullouts.
Best future wireless.

Phones in near future will not have any ports thats a fate shared with tablets as thay get thiner like finding a tablet cheap with ethernet port is becoming imposible soon no usb no charge port.

1 Like

Ok nice on wireless solutions, no cable clutter and clean install. But security? Malicious people are jammer with their ESP series.

In middle of nowhere in field ?

You are right too :slight_smile:

The problem with wireless (specifically 802.11) is that sometimes wireless devices queue up a bunch of packets and send them all at once, and there’s no guarantee of order. I remember discussion of early problems with regard to UDP over wireless here on the forum. Specifically I remember reports of problems trying to stream NMEA from the receiver over wireless to AOG.

There’s no guarantee of packet order on Ethernet either, but in practice they come through sequentially, and packets are sent one at a time, so no bunching or queuing.

We are working on what now. We will get it out soon. Rest assured it is fairly easy. Less than 15 steps and just some clicks. We will get a video out soon.

1 Like

I think this is a bit of a misconception, I can send 50hz NMEA over UDP wirelessly as fast I can send it through a wire. As you mentioned there is no guarantee of order of UDP but that is the same either through wifi or Ethernet connections. Internet protocols like UDP and TCP, also have huge packet sizes. Even if you had 20 different modules talking on the same network wifi was built with the capacity to run devices calling for hundreds of megabytes of data a second.(802.11n bandwidth ~250Mbps) The couple thousand bytes running around the network is easily handled without any packet queuing. A Gigabit Ethernet Network is obviously going to have a lot more capacity and that is where I can see queuing being an issue when max bandwidth is approached but I don’t think that would be the case in this use.

A possibility for packet queuing in early testing may have been connecting to home networks for testing where there is a lot of other network traffic from other devices on the network.

1 Like

I agree wireless bandwidth isn’t a problem, nor is latency.

And UDP being the primary focus of communication in AOG means wireless could work as transparently as ethernet.

1 Like

I think when using the ESP as an AP, it doesn’t group together packets, when you tell it to send it sends the data but most consumer routers will group the data into larger packets and that causes the issue Brian is talking about.


I do find using the esp32 as an access point intriguing if it works well. But, the whole point is, there is no easy path to wireless CAN or wireless RS232 or 485.

At least heading in the right direction of flexibility makes it a lot easier to prevent the death by a million options that leave you at a standstill.

The beauty is right now we have an awesome system that works for 99% that is both serial and udp. AOG itself is completely connectionless - meaning it only sends and receives data to the IO king known as AgIO. Technically we don’t have to be locked into any scheme - but it does make sense to use the most flexible.

Hope this makes sense.

IP67 high performance ethernet connector:




Help out a netwoking beginner here:

What are you connecting with serial, and what is it?

Is it RS232 connecions?

The serial connection with AgOpen is the USB connection
RS232 is another kind of serial connection but very little used here.


This exactly what I hope to be able to use one day for in row cultivation.