ESP All-in-one with WT32-Eth01 (pcb+sw)

The aim of this board is to apply the right amount of power/price and open the door to new connections (mainly wifi, Bluetooth). The software is aimed to be modular, taking advantage of OOP, and could be use in any other project -ACE or alike….
With teensy boards we have a huge amount of raw power, more that what we would never use in the current AOG architecture, that means that we invest more resources (money and usually time in my case in Europe) to get such powerful micro, T41 also has its limitations, like wifi or Bluetooth, soldering ethernet pins…
The project is in testing stage, waiting for parts.

  • electronics design has been created - link
  • SW design created - link

Any comment or suggestion is more than welcome.
Here some pictures:

5 Likes

Welcome to the forum! Great work! Have you considered using the UM982 instead of the F9P. The UM982 is a dual GPS receiver at nearly half the cost of a single F9P. I have a thread on the UM982 going.

Forum member @MrPoke is doing some interesting work on the ESP32 for AOG.

He also found a neat UM982 board.

Thanks,
Yes, I have seen these options, in fact the f9p micro has been selected due to two main reasons, first the f9p has been fully tested and second this footprint is compatible with this um982 board. UM982 Micro Form Factor Dual Channel RTK GNSS receiver

Nice work!

OOP :heart_eyes: is greet. Good idea in motor driver.

I have not seen that UM982 board option. It looks like another clever UM982 option. I like this line in the description “Compatible with AgOpenGPS Teensy Modules”.

I started the UM982 thread to see if we can gain more static and real world UM982 testing. The ultimate goal is to drive down the price of GPS navigation for farmers. The cost of 2 F9P’s is a big one.

1 Like

There was an issue in the WAS reading pin (long story short, swapping the pins 35 and 12 fixed it) now the pcb & code in the links should have it corrected. If you find anything to improve, please do not hesitate to let me know :wink:

Why ethernet? Why no wifi?
Is an external ADC really necessary?
PWM motor driver makes a lot of noise. It is worth shading.
Is it necessary to put a GPS module on the PCB? I think a cable connection is a better solution. This is how you can choose other manufacturers. (Navspark, UN, Rtklib etc)
I think it is better for the connection if each peripheral has a separate connector.

As already discussed there are a lot of good reasons for Ethernet over wifi. And with the problems with wifi I doubt that you could get compatability with ACE. As for having modules on the board it makes assembly much simpler and cleaner. And with the motor drivers I don’t think anyone has had issues with EMR interference so I don’t think shielding is worth it.

1 Like

If something doesn’t produce an error, surely it’s good?
Has anyone measured it with the EMR oscilloscope?
The wifi is not the problem. It just reveals the error.

Say that to gamers :wink:

2 Likes

Both options (eth/wifi) are available in this design. Ethernet has probed itself as reliable in all envlronments so far, with this pcb we could play with the best of each technology.
For ADC, this board uses the internal 12 b analog read (ADC1) of the ESP32, that is more than enough resolutions for the WAS; having said that, due to legacy hw the software is ready to use any internal or the clasic ADS1115 (14-16 b) external one.
The whole point of a pcb is to have all the components well organised, without many cables for the installation, so is a clean install (or clean removal/ change of vehicle), and that pupose is bst addressed by an All-In-One design. It works very well as it it, at least for my user case (and the ones I am close to). If anyone has a different need and I can help I would be happy to contibute if the need is clear and could add value to the rest of the community.

2 Likes

Well said. Also I think I speak for everyone when I suggest a ground pour on your PCB, it is super easy to add and let’s things like the cytron sink tons of current to GND along with helping with EMI.

Sorry, I can see it SensorInternalReader.h and use Kalman Filter. :+1:

This is very familiar to me :slight_smile: https://github.com/MrPoke21/AgOpenGPS_Boards/blob/4f4c4523e9a1275c9f9f1315db7655cdf2cfc243/ESP32/Autosteer/zPackets.ino#L239

        case 100: // NTRIP
          {
            uint16_t size = packet.length();
            uint8_t NTRIPData[size - 4];
            for (int i = 4; i < size; i++) NTRIPData[i - 4] = data[i];

            position.gnss.sendNtrip(NTRIPData, size - 4);
            break;
          }
      }
    }else{
      Serial.println("Unknown packet!!!");
    }

This is no longer relevant, the client must be modified.
I cleaned up the network code a bit. Defragment, and CRC check is nicer.

I think the motor controller should be placed next to the motor.

Thanks Guy1000 for the advice. Noise and Emi may be improved indeed (I had in mind that level of fine-tuning for future versions, if the PCB got traction within the community); as for sinking a heavier load, I believe traces are already much wider than the usual trace for the expected current in each net.

Anyway an specific example to start further adjusting would be very welcome, or any kind of help/advance from the most experienced colleagues around here. I shared all documents in editable version in case anybody feels interested in the project to contribute back to the group.

Does your esp32 code work with regular AOG or just your branch?

Voice of experience tells us (in many fittings in many users) that it works as it is -in aii PCBs, in all different versions.

I would love to see the factual reasons and measurements (whether magnetic noise, electric disturbances… Or any other) to increase significantly the complexity of the system layout, at least some figures to be able to compare in both positions, to provide a better argument that experience. I guess that would tell us if that change proposal is worth to explore.

1 Like

Not now. But I’m trying to solve it.
But this is a difficult task.

https://github.com/MrPoke21/AgOpenGPS

Is that by changing your code to work with AOG or trying to change AOG?

A lot of noise is made. Which do not appear in operation. Because Brian handled these errors in the client.
I tested the internal ADC and the Kalman filter. Value 1 is unfiltered. Value2 filters.
I added a capacitor to the input.