Wi-Fi has a delay. It’s better to use w5500.
1 Like
Can be solved by using Bluetooth xbee on f9p for incoming ntrip (example from lefebure app on phone)
No need 2 uart. Better if slave F9P direct connect to master F9P
Delayed yes and? 50-100millisec… it is dont problame…
Sorry i work only ESP32 with Wifi, UDP. And only single board. Dual is unnecessary…
I found the thread about using wifi.
The issue seems to be the wifi stack / protocol groups packets which can cause delays or out of order packets. The AOG application sees the grouped packets as one position update.
It seemed to be related to using a wifi router. One user was able to overcome the issue by making the ESP32 the AP and some changes to the code to avoid grouping packets.
Thanks Gruni. I learn something new about AOG and satellite navigation almost everyday on this forum. 
I add \r\n packet separator. Defragment UDP packet.
void autoSteerPacketPerser(AsyncUDPPacket udpPacket) {
if (udpPacket.length() < 5)
return;
buffer = udpPacket.data();
for (int i = 0; i < udpPacket.length(); i++) {
data[bufferIndex] = buffer[i];
bufferIndex++;
}
for (int i = 0; i < bufferIndex - 1; i++) {
if (data[i] == 13 && data[i + 1] == 10) {
parsePacket(data, i, udpPacket);
for (int x = 0; x < bufferIndex - i - 1; x++) {
data[x] = data[i + 2 + x];
}
bufferIndex -= i + 2;
i = -1;
}
}
}
The seedstudio footprint looks also good.
But i think to plug into the lora xbee, that is unused in most cases, will be a good option, as it works with existing design.
I ordered an esp32 super mini. Should arrive around 10th December. Let’s see how performant the ceramic antenna is, and if it is small enough to fit in xbee.
So 3 options
Pcb xbee to seedstudio
Pcb xbee to esp32 super mini
Socket on main pcb for seedstudio
The firmware is already there. Im using it on my panda gps bno esp32+w5500 boards
1 Like
That helps at the session layer. However, the WiFi data link and physical layers are where the issues of collisions, retransmits, packet grouping and ordering happen. I think this is where the issues with WiFi and AOG that FarmerBrianT and others highlight occur.
Yes. The problame is UDP.
Unreliable, everything must be checked.
You still need at least 2 uarts, the diagram even shows it. You need the position data from the one and the relative position data from the other. Then you also have the radio to worry about as currently the teensy will forward correction from the radio at a lower baud rate to the gps at 460800. If you are running single F9P and want to keep up with the current boards you need RCV with the IMU which also requires a UART. The ESP32 does have 3 serial ports but the one is for programming, you could still use this but you would run into problems trying to flash the board while plugged in. You could also use software serial as well to add a serial port.
Dual only needs 1 uart. Send NTRIP data and receive GPS position.
Bno RCV not better.
Try calibrate the bno…
Yes that is right. and these collisions do not only occur with wifi. And someone can fix that. I do it in my copy.
1 Like
Mostly, tablet and board are connected directly tho (I think it’s pretty rare that switches are used), so not sure how packets will ever arrive out of order? Does anyone have a packet trace that supports this? Kinda curious as to how this happens.
Ethernet switch is a must for section control or pcbv2+panda system, as 2/3 cables need to go to tablet, cheaper then router.
1 Like
The thread I linked to was about WiFi not wired Ethernet.
1 Like
Here’s the latest brain storming idea.
This is the standard PCB width, in three lengths (1/2 full length, 160mm & full length 220mm)
There are enclosures in 160 & 220mm lengths
Supports dual micro in short length with one micro on bottom (requires soldering bot micro headers yourself to avoid 2-sided assembly by jlcpcb), also 2nd micro on top in medium length, and dual Standard/micro combo & bynav/um982 in full length.
Includes the idea/option of using a esp32 Xiao for wifi AP (ext ant).
1 Like
Looks very nice. I like the placement of the micro’s on the front, clever idea.
I was just thinking if it would be a good idea to add some sort of connector to the board for faceplate LED’s. I know those PCB faceplates seem to be gaining in popularity and it would make it very easy to have connectors already there. Could even get the faceplates assembled with the connectors and the backwards SMD leds already assembled so all you need to do is plug in a cable.
You mean just a pin header somewhere close to the faceplate? Which signals?
There’s room for 6 right angle smd LEDs under the top micro, we found some RGB and bicolor that are the same size as single color ones so that’s already quite a bit of blinky blinky.
One idea for front panel GPS RGB:
Solid red no data
Red blinking data but no RTK
Grn blinking float
Grn solid full rtk lock
Blue flash rtcm data
Any spare pins for bluetooth adapter? Might be handy to interface any cool little boxes (like an LCD screen on the steering wheel 
)