Panda - GGA over UDP

Finally did get the extra UDP port 2244 working, so PANDA could get GGA off the network at very high speed. This also allows any GPS unit to be hot swapped into PANDA just by plugging in an Ethernet cable.

Been testing a Trimble BD970 with native 10/100 MB/s port. Also F9P using HF Eport-E20 that has the ability to match the Ublox max Uart speed of 921600 baud. The Eport setup file also sets up RTCM3 to come in on UDP 2233, and can be configured by uploading a .xml file.

Here is a video already shared on the Telegram group, showing the working system. Really have been loving PANDA, very stable steering on rough ground. Has finally made me stop pulling up the tuning screen, and enjoy the scenery.

But the fun part is the next experiment, POE. Power over Ethernet. This provides the most flexibility for installation. All cables can provide data and power for electronics, cameras and sensors (not the steer motor power).

The first attempt will be POE GPS unit, that should be easy to make and test due to an adapter like this.


Nice Job,

I’m trying to get your firmware with the ublox C099F9P Application board running. (has onboard Wifi)

It’s now working on the table, but the teensy is sending GGA, VTG and Panda Messages (a lot of traffic):

In my opinion is should be only Panda transmitted, isn’t it?

If I connect the receiver by serial cable (standard), teensy is sending Panda only:

Its on UDP it can handle it!

But still something is up.

What port/ports are you sending GGA too?
Is “send GGA to UDP” in agio turned off?

Currently with the modified teensy .ino GGA should only be available on 2244.

If you are powering the ublox by usb, have you turned off nmea?

How are you reading the ethernet over USB?

I have no method to pass VTG in the .ino from 2244 currently. So it must be coming on usb. USB other than optionally for power is not needed.

Could you snap a picture of your connections?

An update, section control with UDP over POE works. GGA and Panda messages have no problems navigating a crowded home router passing both TCP and UDP traffic.

The parts for 14 sections of control cost $50cdn. I do see the need to develop a board that can ribbon cable or directly solder to the premade output card, with 330ohm resistors on the nanos outputs.

I was only able to get 14/16 sections working. But just remembered I did not try the tx/rx pins. If more sections are needed a teensy 4.1 could give about 48 sections, or run multiple nanos.

Ethernet cables are easily made and replaced in the field, POE is designed to be effective to 100m/328ft. So getting the section control relays near the meter box is no issue. But keeps them fully isolated from the implement.

I gave up on 802.3af, too great a chance of smoke having cable powered all the time. 802.3at is much safer and prevents accidental smoke release.

Here is a video of active POE section control, and a little art from DALLE-2


Setup is:

Teensy - connected to router via LAN
c099-F9p - connected to router via onboard WIFI (sent to, receive 2233)
AgIO - connected to router via WLAN
AgIO - connected via LAN/Internet to Ntrip Caster

No USB connections at all!

I found out that the c099-F9P Application board will start sending GGA and VTG messages to AgIO after receiving the first Ntrip message. If Ntrip is deactivated again, and the board is restarted, there are no messages (GGA and VTG) sent.

So your .ino should work properly!

It must be an normal response from c099 which is sent to the active Udp socket port 9999. May be it can be configured in u-center.


Finally I got my Setup with c099 and Panda working:

i modified your. ino so that ntrip is also sent to port 2244, so that c099 response with GGA and VTG.

edit2: Typo

I think the c099 settings are done via USB in a terminal program, old school. I started working on setting it up to connect to my phone wirelessly but gave up because required too much reading.

I didn’t spent too much time on the bluetooth/wifi aspect of my C099 as I knew I wanted to use USB - but I noted when I set the ODIN to either of them, it knocked the other two methods out. Serial/USB, bluetooth or wifi - pick one.

Maybe something I was doing wrong, but it seemed a shortcoming to me.

I’m using bluetooth over the last two years: (nmea for Agopengps and ntrip for c099, caster is connected via tablets sim card):

started with mbed-firmware as delivered:
→ there were every start some problems to connecting the gps in Ago. (connect - disconnect - connect and then mostly works.)

so i decided to go with odin-w2-firmware:
→ bluetooth working very well, no connection problems

in the meantime I had to swap back once (caused of a configuration conflict) to mbed-firmware (c099mbed3_v2.0.0)
→ bluetooth working very well, no connection problems

It’s a nightmare. Each Step/Try another problem.
I found out that the udp packets which are sent are sometimes fragmented, so that previous AgOpenGps modules are crashed.
Some investigation for doubled nmea messages …

Panda serial hardwired:
I tried a panda setup which I used for my last field seeding. Teensy was connected via serial to c099 board, Bluetooth was diabled by oe3 - open Jumper, oe4 - Jumper closed (enables ntrip via serial from Ardurino Header)

No need to pass rtcm3 on 2244, it already works on 2233.

The only change from the original .ino was picking up the ublox nmea on 2244 vs hardwiring the uart. That way the same .ino works with “all in one” and over udp without issue.

The “all in ones” are cool but a GNSS upgrade is inevitable, this small change allows a door left wide open to upgrade accuracy or performance at any time without having to remake a whole new board each time. Any NMEA source will do.

Also allows fully modular unit. Leaving the ads1115 and Bno085 calibrated and on the machine. So that any other tablet with a copy of the vehicle file can instantly use the tractor without any WAS recalibration, Bno zeroing once setup.

MBED…… my eyes hurt from the last time I tried to use one, did not enjoy it. Its old online complier is getting shut down, I am not sad.

That is how it works for c099 via WIFI . I have no serial connection at all.

What hardware are you useing for connecting the F9P to Ethernet? Is it the USR-TCP232-T2 as described in
Would a ENC28J60 Ethernet Shield do the job? I have one but I am unsure how to proceed…

Depending on what you want?

But as this is in Panda section I believe it includes a Teensy.
So UDP could go from teensy. (using an Ethernet Kit PJRC Store)
This link suit usb, but show connection between f9p and teensy.
Autosteer Single GPS+IMU+Panda - #44 by Vili

My plan was to create a distributed system where I use a Tennsy 4.1 to combind GGA over UDP with IMU over UDP into a panda sentence. I though that was what this thread was discussing, have I missunderstood what you are trying to achive here? Maybe I am trying to over complicate things but I like the idea of the distributed system :slight_smile:

They teensy 4.1 would be connected to the rest of the system via ethernet…

Then I did not tell you correct info.
Use the USR one in the first link and connect as described in the thread.
But you should not use the second link , because that shield is for the Nano.
EDIT: if you already have one USR then try it, but it is not as fast as the one Potatofarmer is using (in the start of this thread)

1 Like

Thanks! I do not have a USR yet. Going to order stuff this weekend.
Found the Eport-E20-PIN (Amazon) on Amazon. Would the USR be fast enogh or is the Eport needed for a reliable system?

For single the big draw of the E port is 921600 speed that matches the max speed of the F9p.

Not sure about other ports, and most run at 460800 max, so they did not interest me too much.

Once happy with singles equipment, have a dual ttl adapters to give dual a go.

Ive made changes to the ports going forward.
Gps 1 2211, Gps 2 2222, rtcm3 2233

The panda board runs at 115200 and works.
But it also has dedicated lines that can wait forever for data.

I want the GGA to come in as fast as possible, so it can be processed fast as possible and take the least amount of time using network resources or waiting in buffer.

Yes the goal is a distributed system, reducing electrical noise, increasing ease of install. Also all the cables are field rebuildable ethernet cables.

1 Like