I am running the ESP32 as an access point. It’s set up to wait for a connection, and when it gets a connection, it sends data continuously from an ADC (while True loop) with a 1ms sleep to throttle it.
Overall, it runs quite well.
On the connection client side, I have an app written in VS/C# that connects to it, and when it gets connection, starts to receive the data being sent. It seems to be pretty robust, but…the esp32/Micropython OS is throwing a weird message that I cannot find any reference to.
This is what is in the Thonny debug window:
dhcps: send_nak>>udp_sendto result 0
When this happens, it breaks the connection at the client side, which I manage with a try/catch statement. In the real application I cannot have this occurring – I really need the application to push data so long as it’s powered on.
What does this mean, what is the cause of it? If I knew, I could handle it in the code with perhaps a try/except.
I have written c# apps for esp pic’s … Web and Bluetooth
Without know the code you used
which class are you using … webclient ?
Hows many times does your c# app recieve data
is try and catch in a loop
maybe server code connection
192.168.43.1 GET / HTTP/1.1 Host: 192.168.43.223 Connection: keep-alive
Have you tried written your server code in c
Hope it helps
You did not say with certainty you know what the message means. So how can we guess by suggesting a fix on the client side? Besides, it’s an access point, not an HTTP server.
Hello Grog. I’ve never encountered that error message before… Can you share your exact code? So, I can take a look.
Thanks for your time!
I have discovered the issue – I was going to post the answer soon but wanted to make sure it was fixed. There was actually problems on both sides. It appears the error is in the while(True) loop, on the “conn.send(values)”
I did not have this encased in a try/catch, and it was breaking there, discovered after catch, and printing out the error arguments. on the client side, in the c# received, my receive buffer was a bit undersized, and was apparently pushing back some low-layer message to the AP that it was overflowing. once I adjusted the buffer from 512 to 1024 it’s working OK.
I also had to add a bit of code the client-side catch on the try: clientstream read, so it did not bail out after hitting catch; rather, it has to hit catch 3 times consecutively before it’s actually a “bad read”. The strange thing here, is, the packets are coming in UDP, even if this is the case, there’s some low-level handshaking going on when these errors occur.
good to know!
the only other thing I am trying to figure out is this. It’s a ESP-WROOM-32 device on the ESP32-DEVKITC-32U board. I assume it’s default running at the highest speed (80MHz?). I’m sending 3 ADC values as a list. I’ve done the read and sending the raw converter values:
data1 = int(input1.read())
data2 = int(input2.read())
data3 = int(input3.read())
myList = data1,data2,data3
conn.send(str(myList)+’\n’) (the terminator to delineate at the receive side)
But the highest rate I can achieve is about 400 samples/sec – the samples are int16 as the size is 0 to 4095. But that rate seems to be slow, yes?
At worst case, that’s much less than mBits/sec for sure. How is it possible to get it running faster?
I apologize for taking so long to get back to you, but I’ve been with very limited Internet for the last couple of days. I’m finally catching up and I’ll try to give you a faster response next time.
To be honest I haven’t tried and I don’t have any real data on the maximum samples/sec to achieve with ESP32 on MicroPython.
Can you try changing the frequency?
import machine machine.freq() # get the current frequency of the CPU machine.freq(160000000) # set the CPU frequency to 160 MHz print(machine.freq())
Can you change it? Does it make a difference?
Can you also try this?
I think what “ckuehnel” suggested in the Forum might help change the rate
yes, have run it at 240MHz. Makes no difference!
As someone pointed out in another forum (micropython) the esp32 is limited by it’s core and I believe this. In the link you sent on the adc reads, yes, an easy test to perform using the tick timer and I had done this a while back. The adc speed is not the issue.
The WiFi, in AP mode and sending UDP bytes should be able to attain at least 1Mbps, according to Expressif documentation. So I have changed my code to send a bytearray, fixed at 16 bytes. it’s really not much better than what I was doing before, sending a string with limiters and a newline, at 24 bytes. Now I can achieve slightly faster rates, maybe 10%. I know the hardware (wifi) and application running on the client side are limiting the performance in any way. I tested it on a different mode and it could easily handle a 10Mbps feed.
So 16 x 8 x 380 bytes/sec = 48.6kbps. Wow. That’s it. At this point, I do not believe it’s the device that it’s advertised to be. Not nearly 1Mbps in UDP.
So the device is more like a novelty so far as WiFi goes, because these transfer rates it’s not possible to do much that’s meaningful for faster acquisition. I’ve used other devices like zigBee that can and do perform significantly better. The obvious advantage of the ESP32 is the compact and integrated structure, leaving the management of peripherals and firmware intricacies to the OS. So don’t get me wrong, it’s a decent little device, just not right for more serious WiFi rates!
Perhaps an expert on the ESP32 can chime in an provide some feedback. I would really like to know how I can get anywhere near that 1Mbps rate!