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.
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 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.
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)