Poll - board design

It is open source. :smiley:

Do you have an example of PANDA on a nano? I wouldn’t mind checking it out

This would be hard, the nano only have 1 hardware uart.
At least 2 are needed, GPS in and out.

I forgot about that, guess I haven’t used a nano in a while. That would really make it impossible to run anymore than a single serial device at high baud rates. I guess PANDA would work with a single F9P though, but I am not sure how dual works as it might need both serial ports to work. You would also lose the ability for RVC and the serial forwarding with the radios.

I would look to run it on an ESP32 device that has WiFi. Also an UM982 only requires 1 serial port. Interestingly, I was playing around with some of MechanicTony’s ESP32 stuff and created a board with an ESP32, UM982 and BNO085. Then this project popped up in my feed. Makes for a pretty cost effective compact board that has builtin WiFi. I use WiFi in my tractor to avoid running more cables all over the place.

The programing approach is pretty neat. Everything is separate tasks run by the TaskScheduler library. The main loop has one thing in it, task execute. The Github was posted a few posts back in this thread.

1 Like

I agree, have found cmps14 was terrible. BNO was awesome comparing, but dual has been flawless from the start. Extremely direction sensitive and can lay pcb box anywhere and also use the whole system mobiley as in for implement/tool guidance from tractor to tractor!

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
renditionDownload

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. :grinning:

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…

https://www.hestore.hu/prod_getfile.php?id=15821

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.