You are not logged in.
Hi all,
I'm new here, so hello to everyone!
It seems I'm having a problem with NanoDLP or I guess more with the config.txt on my Raspberry Pi3+ for my particular display.
The Display I'm using is this one from Aliexpress:
and these are the specs:
with the HDMI to MIPI converter.
Using the tvservice command I get the following results:
pi@raspberrypi:~ $ tvservice -s
state 0x12000a [HDMI DMT (4) RGB full 4:3], 640x480 @ 60.00Hz, progressive
pi@raspberrypi:~ $ tvservice -m DMT
Group DMT has 2 modes:
(prefer) mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 87: 2560x1600 @ 50Hz unknown AR, clock:222MHz progressive
pi@raspberrypi:~ $ tvservice -m CEA
Group CEA has 2 modes:
mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
The interesting thing is that if I use my current config.txt setup with a 'Raspbian Stretch with desktop' the display works (Pixel Desktop shows up and I can use the graphical user interface with no problems at all). But when I install the NanoDLP image and use the same config.txt the display is not working so well anymore.
Using the Dynamic Calibration grid pattern leads to this:
Sometimes for a very short time the image is correct (I guess because I wasn't able to find a description/ image that showed the correct image ):
My current config.txt looks like this:
gpu_mem=128
hdmi_force_hotplug=1
hdmi_pixel_freq_limit=300000000
hdmi_drive=2
disable_overscan=1
hdmi_timings=2560 0 123 10 30 1600 0 12 4 4 0 0 0 50 0 222183000 0
max_framebuffer_width=2560
max_framebuffer_height=1600
display_rotate=0
framebuffer_width=2560
framebuffer_height=1600
config_hdmi_boost = 0
dtparam=i2c_arm=on
dtparam=audio=on
dtparam=spi=on
enable_uart=1
dtoverlay=pi3-disable-bt
disable_camera_led=1
hdmi_pixel_encoding=2
start_x=1
dtparam=i2c1=on
I would be great if anyone could help me with this...
Uli
Offline
Very strange. Try install nanodlp on 'Raspbian Stretch with desktop' see if it works correctly or not.
Offline
Ok, I installed "Raspbian Stretch with desktop" and installed NanoDLP with:
wget linkto nanodlp.tar.gz --no-check-certificate -O - | tar -C /home/pi -xz --warning=no-timestamp
cd /home/pi/printer
sudo ./setup.sh
But still the same problem prevails, showing the 'Dynamic Calibration grid pattern' shows for a very short time the correct image and then its replaced with the screwed up one.
Before I installed NanoDLP, the Pixel desktop ran flawlessly after installing NanoDLP the desktop is disabled now when I start the Raspberry Pi (I guess as expected??)
Using 'Preview Layers of Plate' shows for a very short time the correct layer and then it vanishes. Clicking on the next layer button shows nothing further.
For me it looks a bit like the sync signal gets lost but the HDMI to MPI converters status LED signals a good connection/ signal...
Not sure what to do now, have already played/ changed a lot in the hdmi_timings setup but no value combination I came up with did solve the problem. I'm still puzzled why the PIXEL desktop runs fine with the current config.txt file and NanoDLP has problems with it. NanoDLP must do something different or the Pixel Desktop does something after the GPU was configured with the values in the config.txt file.
Last edited by uli96 (2018-08-03 08:47:28)
Offline
Could you disable nanodlp using systemd and see if pixel working fine or not?
Maybe modifications on config.txt by nanodlp causing this issue.
Offline
Ok, I disabled NanoDLP with:
sudo systemctl disable nanodlp.service
and restarted the RPi
Desktop comes up and everything works fine, started LibreOffice Calc with lots of small lines/ Tables looks perfect.
Enabled NanoDLP:
sudo systemctl enable nanodlp.service
and restarted, same problem as before.
Last edited by uli96 (2018-08-04 04:43:44)
Offline
Please, share a debug file.
Offline
Tried getting a debug-file (Setup page/tools tab/ debug button) but if I click on button 'Debug Info' nothing happens...
How can I get the debug file (I guess nothing happened so no need to create a debug file...)?
Last edited by uli96 (2018-08-05 13:57:19)
Offline
UPDATE:
I contacted the company that designed the HDMI to DSI board and asked them for the config.txt file for my JDI TFTMD089030 LCD Screen. The same screen is advertised in their fact sheet as being tested with that same adapter with a Raspberry Pi.
They sent the config file to me and I tested again, and it worked....for a while (a few minutes of activating and deactivating the dynamic calibration) and then it didn't work anymore.
So I'm pretty sure now that I really have the correct configuration in config.txt for this display but still it doesn't work reliably with NanoDLP.
Here is the config.txt from CONFU INDUSTRIES CO., LTD in case someone wants to use it:
force_trubo=1
gpu_freq=300
core_freq=400
# HDMI Basic configuration
hdmi_pixel_freq_limit=400000000
hdmi_timings=2560 0 123 10 50 1600 0 12 4 4 0 0 0 50 0 222183000 0
hdmi_drive=2
disable_overscan=1
max_framebuffer_width=2560
max_framebuffer_height=2560
# Portrait or Landscape Setting
#Portrait-1 (Flexible cable is bottom side.)
display_rotate=0
framebuffer_width=2560
framebuffer_height=1600
# Landscape-1 (Flexible cable is right side.)
#display_rotate=1
#framebuffer_width=1920
#framebuffer_height=1200
# Portrait-2 (Flexible cable is upper side.)
#display_rotate=2
#framebuffer_width=1200
#framebuffer_height=1920
# Landscape-2 (Flexible cable is left side.)
#display_rotate=3
#framebuffer_width=1920
#framebuffer_height=1200
# Enable audio (loads snd_bcm2835)
dtparam=audio=off
Offline
if I am not mistaken
max_framebuffer_width=2560
max_framebuffer_height=2560
should not be the same
Offline
Yep, I saw that one too, but it doesn't change a thing if I change the max frame buffer height to 1600
What I just found out , is that if I leave the dynamic calibration image or a layer switched on for a while, the whole LCD seems to work after a while, without further hiccups. It seems only after a restart that the screen has problems to display (sync??) correctly. Once it has synced it seems to work fine.
Haven't figured out how long it takes, will investigate more tomorrow.
Offline
It takes almost exactly 10 minutes, after that the display works. Tested this with two displays and two HDMI to DSI converters.
This is really odd.
I suspected that this might be a temperature related problem but two displays start to work after 10 minutes of failing to display the correct image - no way!
Must be software related (Software on the converter??)
Last edited by uli96 (2018-08-09 13:24:53)
Offline
Well that is embarrassing, I was able to get a debug file, it just downloaded so fast I didn't notice (stupid I know).
So here it is:
Offline
I am having exactly the same problem with the same LCD.
Did you find a solution?
Offline
This worked!
hdmi_force_hotplug=1
disable_overscan=1
framebuffer_depth=24
gpu_mem=192
framebuffer_ignore_alpha=1
#start_x=1
hdmi_cvt=2560 1600 48
hdmi_group=2
hdmi_mode=87
hdmi_pixel_freq_limit=400000000
hvs_priority=0x32ff
max_framebuffer_width=2560
max_framebuffer_height=1600
framebuffer_width=2560
framebuffer_height=1600
config_hdmi_boost=4
Offline
My 'solution' was to start up the printer, leave the display on for 10 minutes and then never shutdown the PasPi again.
I'll try the setup that worked for you and report back!
Offline
Hi , ı have the same problem did you solve the problem? Thanks
Offline
I bought the same LCD for testing.
The board was causing me a lot of trouble, I could not get it to work, even under Windows.
I think I got a broken hardware.
So I bought the following board and it worked right away with my Raspberry Pi 2B
Offline
hi , I think I also damage the board but when I connect it to my windows pc it says screen is detected but no image on the screen.Do you have the same problem?I am trying to find the problematic component . is it lcd screen or driver board . Lcd screen was working then stop showing any image. But driver board turns to green light when I connect t windows pc.
Offline
I had exactly the same behavior. I could exclude the display, since I have a second display to try out.
Therefore, I got the specified board and with this it worked immediately.
Offline
Okay thank you I will give it a try and buy specifided board.I hope it will work .
Offline
Looks like I'm in the same boat. Same display, but a different controller. I am ordering the other alternative board (with an LCD as a backup), but I'd like to continue this discussion with some things that I have found.
The settings listed above for the config.txt file will work, to a degree. During boot, the screen displays everything just fine. It's not until you actually try to display something in NanoDLP that it starts to fall apart. When everything is set up for 2560x1600 (75um X/Y resolution), the image fails after a second or two, regardless of whether it's the calibration image, or a slice preview of a model. If you drop the resolution in NanoDLP (not in the config.txt file) to 1920x1080, the picture comes up perfectly, albeit small.
Does this help point to something? Is there an issue at this resolution that has yet to be caught? Is it really just crappy hardware?
Offline
Well, the board and LCD that was recommended in a previous post yields the same results, so that was a little disappointing.
I played around with the NanoDLP resolution settings (the settings in config.txt work perfectly outside of NanoDLP) and managed to get the calibration image to display without any flicker or artifact at 2440x1600 (native is supposed to be 2560x1600). While I can live with that for the time being, it's a little irritating that I cannot take full advantage of the resolution of the screen.
Offline
I only can share my config.txt
#=====================================================
gpu_mem=256
#force_turbo=1
boot_delay=1
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
#hvs_priority=0x32ff
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=-150
#overscan_right=-150
#overscan_top=16
#overscan_bottom=16
#-- Console framebuffer depth in pits per pixel (default=16)
#framebuffer_depth=24
#framebuffer_ignore_alpha=1
# uncomment to force a console size. By default it will be display's size minus
# overscan.
max_framebuffer_width=2560
max_framebuffer_height=1600
framebuffer_width=2560
framebuffer_height=1600
#-- EITHER hdmi_timings
hdmi_timings=2560 0 123 10 50 1600 0 12 4 4 0 0 0 50 0 222183000 0
#-- OR hdmi_cvt=width height framerate aspect margins interlace rb
#hdmi_cvt=2560 1600 24
hdmi_pixel_freq_limit=400000000
hdmi_ignore_edid=0xa5000080
#hdmi_ignore_cec_init=1
hdmi_blanking=0
# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=87
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
# Enable audio (loads snd_bcm2835)
dtparam=audio=off
#-- Portrait or Landscape Setting
#display_hdmi_rotate=2
display_hdmi_rotate=0x10000
#start_x=0
#=============================================
Offline
Question... I struggled with getting my screen to work for a long time.
Realizing that the raspberry pi's build in firmware does a lot of controlling when it comes to the HDMI output. I upgraded to the latest version of Dabian on the PI then went back to my NanoDLP image and at last my problem went away. I have a post about my ordeal on the forum.
Have you updated your firmware? Have another Pi to try?
Mo
Offline
Hello
I had the same problem but after using the right config.txt info from the factory i had perfect screen on rasbian desktop but still out of sink in nanodlp so i change the machine display settings in 2559 X 1599 and all works fine now
Maybe nanodlp software count 0 to 2560 and 0 to 1600 that makes 1 to many and scrambles the display?
Hope this helps
Offline