Start a new topic
Not Taken

Camera monitor feature

I think nextion must be able to show camera view. if nextion supports ( rearview )camera function like a monitor, we will be very apreciate. Thanks.

2 people like this idea

I am now reviewing all of the Feature Requests, this will take some time, patience please.

UART to slow to implement this effectively.  433 pixels per second.

Massive safety issue - not taken

1 person likes this
A hardware like a vga in may be installed or developed instead of uart communication. İ think this feature will take long time to use by a camera monitor
I too would love this idea as I'm developing for an automotive application.  But I also understand it probably could not be implemented in software alone... different hardware would be required.


I do have to say I fail to understand where the "massive safety issue" lies.

All that's being requested (and as I said above I understand it's not a simple request technically) is for the device to be able to show video from an external input... just like 1000 other displays already on the market.


You can't see a safety issue? 

He requested the equivalent functionality of a rearview camera.  To me, that's like on a car, a vehicle - something that needs dependability.  at 433 pixels per second throughput, a 5" Nextion will require 887 seconds to process one frame, that's 14 minutes 47 seconds.  Imagine a review in a vehicle that gave 4 or 5 snapshots per hour.

Without new hardware it is not possible, so on the existing Nextion hardware it's definitely a no go.

If it was new hardware, it would be a different series - perhaps the future Intelligent series, but I have no timeline.

Well I think it's a matter of perspective and no that wasn't a camera joke... at least not intentionally!  ;^)

I drive a 26-year-old car which of course was built before backup cameras were available.  And my Nextion project is indeed for the car.  If I implemented a backup camera and it failed, the car would be no less safe than it is right now.  So I would only stand to gain if this functionality were available, and compared to the current situation, would lose nothing if it failed.


The Nextion firmware currently just doesn't have any mean of streaming picture data.  Gerhard Kropf created the Proof-of-Concept to send picture data over serial using the line command.  As the Nextion firmware takes text commands, each pixel has to be drawn using line x,y,w,h,color  So it can be done, but this averages about 25 characters per second, and at 115200 baud (Nextion's top baudrate) it gives approximately 433 pixels per second.

I have been playing with building on that concept with the enhanced model nextion using an OV7670 cam and using the Enhanced digital IO pins to see if it can be improved upon.  One main key to getting better performance is to ensure the cam is set to output 565 color so that the pixel color does not require any additional time on conversions.  Tracking current pixel x,y positions in the HMI can get a bit more speed using syXX variables - which from their behaviour suggest these may make use of the STM32 registers - they certainly bypass any need for a lookup in the component tables as is what happens when you use the Variable components.

It isn't as simple as using the 8 IO pins to transfer a single byte at a time.  This would require the Timer variable which at 50ms minimum would result in 19.5 pixels per second (20 is degraded with the other work the Nextion has to perform in interpreting the text based code).  So using one IO pin to trigger the pixel pulse bound to a hotspot again increases things on the Nextion side of when to read the pins and start calculating the pixel color, but your mcu also needs to be informed of when it is okay to send the next pulse - not doing so will soon overload the Nextion and you'll have a corrupted image and possible stack overflow.  So another IO pin set after the calculations are complete leaves 6 pins to send bit data on and you have established flow control.  This means a pixel color is transmitted in 3 pulses.

Other considerations are taking a smaller frame say 160x120 (via some advanced configurations sent to the Ov7670) to reduce the frame pixel count and increasing the line width height to create a sort of zoomed image (some pixelization occurs but you have an image representation on the display)  This greatly decreases the amount of time to get a frame, but the throughput still isn't that high.

So the time needed to interpret Nextion side code yields around 533 to 566 pixels per second.  Your mcu will also need to capture the data coming in from the cam to buffer it, the cam just isn't going to hold it's frame data for 30 seconds while the mcu and the Nextion work it out.  So on the IO pin concept, you can get an image just a bit quicker then sending it over serial, but not to any great significance.

It might be useful for creating a time-lapse, but real-time imaging is not realistic.

[Edited] - a time-lapse would also assume you could retrieve the image from the screen, which you can not, lapse in thought there - synapsis didn't fire.

Yeah I wasn't really expecting it to be done in software, for the reasons you mention.

What I envisioned would be a hardware design change, where the input to the LCD itself would be switchable from the current driver (connected to the Nextion processor) to a video-decoder/driver chip.  That would be done under software control, so by sending the Nextion a command over serial, the feed to the LCD could be switched.

A "picture-in-picture" effect with the video displayed in a window within the Nextion HMI environment would be really cool, but would require even more hardware and probably a much more powerful processor.


As you can see I have been playing with trying to find a way to make it work. so I would certainly make use of it if it was there.  But I imagine it will have to be considered for the Intelligent series.

I wanted to bump this with a +1 as I am interested in this feature as well - but for a different purpose.  I understand the demands of trying to stream image data over serial to this device, but for my needs, this would be fine.  

Here is what I envision.  I built a weather app and would like to have a radar image available to view.  The idea is that every hour or so, the device would pull down a snapshot of radar for my area and stream it to the Nextion memory (maybe the SD card if they open it up to loading files).  It could do this in the background.  The user would click a button / go to another page to view the radar image. If it takes minute to stream the data, no big deal as it would happen in the background, and the viewer would simply show them the most recent one on the SD card.  

I suppose this means 2 feature requests - save and view images from the SD card, and ability to stream the data over serial to save a bitmap (?).


I have bought many displays 5 "7" Enhanced, but a problem that displays aren't able to read pictures with microSD.

really for 2 years you couldn't make it?  possibilities of your controller - big, and it can make it.

Please share an example (code) as to transmit the picture from the camera through GPIO.

There have passed 2 years, really absolutely it is impossible to read the picture with microSD?


I think to use the auxiliary controller (Arduino or stm32), it reads the picture from the camera and will write her on microSD. And the Nextion read the picture from microSD, and to show it on the display. (for this purpose the controller should be connected in parallel to microSD)

  or how it is possible to transmit through direct connection of SPI the picture from the microcontroller about the Nextion (pins microSD)?

  or how it can be done through GPIO?