I am writing a sprinkler controller, and want to keep the update speed up. I have been using 9600 baud, but notice that when I upload the HMI file that the Nextion Editor forces the baud rate to 115000 baud. Will the serial connection run reliably at this rate? Or should I stay at 9600 baud?
More information is needed what nextion, what are you doing on the display that needs so much information sent to it , is there a better way to do it. I am using a nextion to control and display the information from two solar power inverters they work at 2400 baud and send back 30 blocks of data. The display has animation running showing the power going from solar panels , battery and generator so a lot going on. I started out using a separate micro controller between the display and inverters which used 9600 baud to the nextion with very little delay but after reading the nextion’s instruction set I did away with the separate micro and now the nextion is doing it all. I am happy to help you if I can.
My enhanced 4.3" nextions work fine at bauds=921600
I am using a NX3224T024 not sending all that much data but the person that wrote the original code that I started with (bruxy70) stated that he had problems when he reduced the update interval < 5 seconds. So I was wondering if a faster baud rate would work better. I reality if probably doesn’t matter for my use.
But I will try the 115200 and a 1 second interval.
Thanks for the feedback / response.
All my Nextion projects use 115200 serial between MCU and Nextion, and have had no problem in the last few years, irrespective if it’s an Arduino Nano, UNO, or a Teensy LC, or Teensy 3.2 variant.
I wouldn’t trust the Nextion Editor with judging serial reliability.
When I set the Editor to upload at 921k, it ends up at ‘whatever’ rate, usually around 115200.
As far as programming goes, check your PC’s Com Port settings, as the default (IIRC) is 9600Bd.
The T and K displays have an “official” maximum upload rate of 115200, but 250000 works sometimes, too. The P displays allow a reliable upload at 921600 baud when connected with short wires to a CP2102 USB-TTLserial adapter.
I have been using 115200
Why would you need a fast data transfer for a sprinkler controller? The higher the baud rate, the shorter distance you can run your cable, and more opportunities for errors. It seems that 9600 would be suitable for any application that does not require frequent feedback data. Frequent would mean a response in milliseconds. It doesn’t seem like a sprinkler would need feedback faster than once every few seconds.
The distance is the length of the wires that come with the display module (about 8"), from the ESP8266 to the Nextion display. The speed is for improving the update when changing the time settings and pressing of buttons with the display. At least that is what I was thinking. A new pull request for ESPHome is recommending to use 115200 baud rate if using hardware uart, 9600 with software uart.
You could calculate the time of data transfer for each baud rate, given the amount of data being sent. It won’t take long to send a few bytes.
At 9600 you could send 10 words in around 1ms. Isn’t that fast enough?
Of course you can use any rate you want, but it’s nice to know what you need.
You are correct, I am retired and I could drive into town at 35 mph (speed limit 50 mph), I have time. But it sure upsets everyone else.
The other reason: The new pull request for ESPHome will allow for transfer of a new TFT to the display over the serial connection. The higher speed will make the wifi transfer (reading of the file) speed the limiting factor.
I think of a sprinkler controller as a series of timers with relays, which is a very simple application. I don’t know what a pull request from ESPHome is, or how it relates to sprinkler controller, but it is possibly far more complicated than what I had in mind. A typical sprinkler controller wouldn’t need a refresh rate of greater than once per 5 seconds.
The PR is a Pull Request in GitHub that changes the software (in this case ESPHome) that sends and receives information from the Nextion display. In my case it allow me to change the desired run time for 4 different zones, start and stop the individual zones, counts down the time remaining for each zone, interlocks the zones so only one runs at a time (I am on a well) and allow control from Google calendar for setting days of the week, start times and run times as well for each zone. It also allows control from a web page or locally at the controls.
The fast way to use the nextion is in Protocol Reparse mode send it a block of data representing the state of controls which your store in the controlling micro , when you change something on the nextion it sends a block of data to the micro which stores it in an array its very fast even at 2400 baud.
I agree if I was just controlling my sprinklers, but it is tied to my Home automation system. That also controls my door locks, cameras, fans, lights, tvs, thermostat, power from the solar panels, weather info and monitor temperature / humidity in various location around the house. I can monitor / change things from the web on the a computer or cell phone. I also set up conditions and automations.
This is clearly far more complicated than a sprinkler controller, which could be done with timers and relays.
But the nextion is not doing this its a display so only the state of the display controls needs to be sent and only when there is a change.
One other feature that the higher baud rate may help wit that I didn’t know about when I asked the question is that the software update will soon allow me to upload a new tft file to the display remotely from the display without removing it. The higher speed will speed will speed up the process. Thanks for all of the input.
Communication speed and upload speed are not the same. When you start an upload, you PC tells Nextion at your communication speed (f.ex. 9600) that it wants to upload a new file and it also tells Nextion at what baud rate that upload happens. Nextion then switches to that baud rate, acknowledges, and after the upload is done, switches back to the baudrate from before.