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.
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
Teensy - connected to router via LAN
c099-F9p - connected to router via onboard WIFI (sent to 192.168.1.255:2244, 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.
edit:
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.
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
WIFI/Udp:
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.
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
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)
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.
I have almost the exact same setup that I am working on. The Teensy 4.1 is giving me trouble. Which .ino file did you use or recommend using. I have the power over ethernet splitter to run it with ethernet kit that is made for the Teensy after I get the right software loaded on it to run over the ethernet port. Any help would be appreciated. I am using a POE switch and then a ethernet cable to the ethernet to usb adapter with usb plugged into the Panasonic toughpad. The 5.8.2 version of Ag Open GPS is what I am using.
I am using the ace .ino from the “Ace repository” on github. Also the Ace version of AgIO that can be copy/pasted in to replace the regular version of AgIO in any release.
I assume you have to generate the AgIO version with visual studio to make a .exe from the files available on github. Also using the AceSteer on the nano after creating a .hex file for it correct?
Also is there a machine section control “Ace” .ino? I didn’t see it on github and I didn’t see one for the gps. Any help is appreciated. Thanks!
