Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use TEST_STREAM_DELAY #77

Closed
Itox001 opened this issue Nov 24, 2022 · 3 comments
Closed

How to use TEST_STREAM_DELAY #77

Itox001 opened this issue Nov 24, 2022 · 3 comments
Assignees

Comments

@Itox001
Copy link

Itox001 commented Nov 24, 2022

Hey, first thanks for all the hard work that went into this. I was browsing through the code when I stumbled upon this macro and I am interested in calibrating the stream delay. From what I could infer, it moves from a small X value to the middle of the bed, takes a snap, and then moves to the other side of the bed. Then we should find the pic in the tmp folder and see if its blurry, and adjust the stream delay compensation higher or lower to make it not blurry.

My problem is that when I tried to do this, I noticed that I got different values if I pre-move X to its starting point, or if I start the test from the far side. With a vale of 0.9 (which seems pretty high, I was taking successful timelapses with the default 0.05), I can take non blurry pics in the middle position, but if the head has to move from the other side of the bed to the starting point, then I get blurry pics again.

So, since the value seems too high, and there is different behavior depending on where the head starts, I take that either I am using the test wrong or the code is a bit buggy. Any word on this?

Thanks!

@FrYakaTKoP FrYakaTKoP self-assigned this Dec 18, 2022
@FrYakaTKoP
Copy link
Member

sorry for the late response!

Yeah you got it almost right the idea is to tune stream delay and park time to get a repeatable steady image in the middle of the bed. Sure looking at how blurry your image is a solution too 😅

If your stream delay changes mid print, sounds like you either need to increase parktime a tiny bit (warning increases printtime and blobbing/oozing). Also if the delay is all over the place this may indicate there is a lot of variation of frame capturing delay. Are you using a external camera (e.g droidcam or other ip based one)? Normally a USB/CSI based camera should more or less give similar snapshot delays all the time

@FrYakaTKoP
Copy link
Member

close because OP question should be answered and issue is stalled

@Itox001
Copy link
Author

Itox001 commented Mar 4, 2023

Sorry for the late response, somehow missed the notification. My time lapses actually come out fine, I was just looking around and found this calibration macro in the code and decided to give it a shot to see if I could enhance it further.

My issues occur solely during the TEST_STREAM_DELAY macro, that is where I get the funkyness and non repeatability that I described in my comment, the actual print time lapses come out fine with the default 0.05. Therefore, I thought that something was off with the test macro, or that I was misunderstanding how it worked.

But feel free to keep this issue closed, I have stopped tinkering with this calibration and just been happy with the time lapses themselves :) thanks for that! I have a strange issue were some frames come out corrupted, but that is rather on the streamer/camera side since I can see it as well on the camera preview once in a while.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants