Hi
I need to connect multiple ESP32 with together, like mesh but wired.
Before buying any stuff I want to be sure it suits for me. So I have some questions:
* Can I use ENC28J60 with ESP32? https://www.aliexpress.com/item/1005001 ... web201603_
* What Mb/s I can archive with ENC28J60? How much connections per sec?
* For multiple ESP32 with ENC28J60, do I need Network switch for that?
Thanks
Multiple ESP32 through ethernet with ENC28J60 RJ45
Re: Multiple ESP32 through ethernet with ENC28J60 RJ45
Thats going to depend on many factors including how bad your driver is, how big the packets are, which pins you use for SPI etc, etc.What Mb/s I can archive with ENC28J60? How much connections per sec?
The ESP SPI driver has fairly high latency which would cut badly into bandwidth with smaller packets. I would imagine more than the ESP Ethernet but have not checked.
Why not use something like a LAN8710?
The ENC28J60 has a SPI interface and so will likely be much slower than the ESP RMII interface (& especially so if you do not use native SPI pins).
Think; Ethernet is 100MHz and so you are trying to feed 100MHz from a general purpose SPI channel. You are not going to get 100MHz from the SPI channel, & especially not using some dupont (as I suspect you will try)!
If you want close to 100MHz you will need a PCB board. This is nice and cheap https://www.olimex.com/Products/IoT/ESP ... e-hardware
There are lots of posts on ESP32 ethernet performance (typically meaning RMII) on forum so I will let you research that.
You will need a switch/hub to connect multiple ESP/ENC28J60 Ethernet devices, just like your home devices.
EDIT: PS the ENC28J60 has max SPI of 20MHz. You may not even achieve that because of ESP32 GPIO MUX details. You will achieve <<20Mbps Ethernet for the latency reasons given above. Perhaps 10-15Mbps with big frames.
& I also believe that IDF CAN should be fixed.
Re: Multiple ESP32 through ethernet with ENC28J60 RJ45
Thank You PeterR
Is w5500 or W5200 faster than ENC28J60? My problem with LAN8710 it needs lots of wires.
I want to send something like 10 times in second and packet of say something few, bytes, chars, floats. Asking and sending between other ESP32 Ethernet devices, with handshake if needed. UDP vs TCB, what seems to be better for me?
Is w5500 or W5200 faster than ENC28J60? My problem with LAN8710 it needs lots of wires.
I want to send something like 10 times in second and packet of say something few, bytes, chars, floats. Asking and sending between other ESP32 Ethernet devices, with handshake if needed. UDP vs TCB, what seems to be better for me?
Re: Multiple ESP32 through ethernet with ENC28J60 RJ45
10Hz few bytes is not a problem. Thats like 1KB (forget minimum packet size). Go with your original idea IF you have a driver/transport layer which works with the ESP32 IDF.
UDP or TCP? Well that depends (again).
If you want all the data (only lose data in unacceptable long term hung scenarios) then a connection based protocol like TCP. But you want a mesh with all processors sharing the data & to do this via TCP based transport would require a discovery mechanism e.g. mDNS or multicast etc.
If you want the data in 'real time' then UDP is best. Actually multicast if you want to share with all the other processors. You need a smart switch for multicast to work.
I would go multicast if you can. You might loose the odd packet (assuming good hardware) but if this is telemetry then that would seem best.
The UDP/TCP difference is similar to that between your bank account and a speedo. You want all your deposits recorded in your bank account but are prepared to wait for a minute or so for that to happen. With a speedo however you don't want to see the speed you were doing 1 minute ago. EDIT: TCP for deposits, UDP for withdraw transactions
You could do both of course.
PS I have used AJAX HTTP (TCP: connect, request, receive, close) to exchange data in a local system and use that data to update a vehicle speed dial @10Hz. Also MQTT QoS0. MQTT is less jerky (its a push model after all) but both are good. ESP AJAX typically runs at around 30-70mS BTW.
I have also used multicast on aviation loggers (e.g. iNET-X) and also connectionless 'real time' radio streams.
Both work well.
However I have used TCP on a poor quality link where the requirement was not to loose data and so one design requirement was to have a sensor side large memory buffer for use when the Ethernet extender was having a sulk. The receiving user interface team just did not get that point and their user graph contained gaps in the data as they ploted using local receive time base rather than source time base. My sensor hardware design proving rig (stimulate device, graph response characteristic) was perfect. Just every now and then the graph scroll would pause whilst waiting for my source to resend etc.
If the link is good either should work but multicast saves you having to discover mesh items.
UDP or TCP? Well that depends (again).
If you want all the data (only lose data in unacceptable long term hung scenarios) then a connection based protocol like TCP. But you want a mesh with all processors sharing the data & to do this via TCP based transport would require a discovery mechanism e.g. mDNS or multicast etc.
If you want the data in 'real time' then UDP is best. Actually multicast if you want to share with all the other processors. You need a smart switch for multicast to work.
I would go multicast if you can. You might loose the odd packet (assuming good hardware) but if this is telemetry then that would seem best.
The UDP/TCP difference is similar to that between your bank account and a speedo. You want all your deposits recorded in your bank account but are prepared to wait for a minute or so for that to happen. With a speedo however you don't want to see the speed you were doing 1 minute ago. EDIT: TCP for deposits, UDP for withdraw transactions
You could do both of course.
PS I have used AJAX HTTP (TCP: connect, request, receive, close) to exchange data in a local system and use that data to update a vehicle speed dial @10Hz. Also MQTT QoS0. MQTT is less jerky (its a push model after all) but both are good. ESP AJAX typically runs at around 30-70mS BTW.
I have also used multicast on aviation loggers (e.g. iNET-X) and also connectionless 'real time' radio streams.
Both work well.
However I have used TCP on a poor quality link where the requirement was not to loose data and so one design requirement was to have a sensor side large memory buffer for use when the Ethernet extender was having a sulk. The receiving user interface team just did not get that point and their user graph contained gaps in the data as they ploted using local receive time base rather than source time base. My sensor hardware design proving rig (stimulate device, graph response characteristic) was perfect. Just every now and then the graph scroll would pause whilst waiting for my source to resend etc.
If the link is good either should work but multicast saves you having to discover mesh items.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: username and 114 guests