-
Notifications
You must be signed in to change notification settings - Fork 10
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
Image prints come out with lines #17
Comments
I tried on another computer with a different adapter, and there are still lines on the output. Image prints are fairly unusable because of this. In contrast, images from the official app basically come out perfect. |
@skorokithakis, could you please provide information about your device, model and library version? |
Sorry, I completely forgot: I have a PeriPage A6, I'm running v1.1 from PyPI. I'm running the script both on my desktop and my laptop, with the same results. |
@skorokithakis, it may be aliexpress description issue. This printer (and image size) looks like A6+ |
Ah, you are correct, @bitrate16. I've set it to Oddly, the lines only appear to be printed at the top of the image. |
I tried a different image and that one didn't have any lines, so this seems intermittent. Odd, though, hm. |
@skorokithakis Try setting concentration to 0 and make a test print. Maybe it is overheating |
I have the same issue. It seems to be caused by underflow as slower to print darker rows are less prone to produce white lines. Reducing concentration ends up producing more of them. Comparing logs between PC and phone app - phone sends data in 122 byte packets and my PC for some reason sends 47 bytes per packet. Also it looks like they changed the hardware. PCB in my A6+ has different MCU and Bluetooth controller. Maybe they cheaped out on stepper motor too. |
I agree with @rkolbaskin, it does seem like an underflow issue. I'll try reducing the delay to see if it helps. |
A delay of 0.005 still had two lines. A delay of 0.002 had no lines. |
@rkolbaskin If they've changed hardware/protocol/something else, you cold try to determine bytes per row used in printer by printing out continuous sequence of '0123456789abcdef'. Bytes per row then can be calculated based on number of characters in a row when using unsafe writeASCII Also, delay is very experimental value that may vary from Bluetooth adapter and printer hardware. In my case default delay produces expected images on low concentration. If printing with high, image can be stuck/cut/broken because i couldn't find any indicators for overheat/complete/other printing states and overheating is unpredictable |
Seems to be 48 for me (as in, it printed 48 characters in a line before wrapping). |
@skorokithakis that looks fine peripage-python/peripage/__init__.py Line 55 in b2d2a9b
|
Hm, it sounds like delay might need to be adjusted with the concentration, then, though I can see how that can be finicky. |
We can sniff bluetooth packets sent during printing through app and check if there are status telemetry. Especially when printing long pure black image. Later I will check if it is possible to print very long black image with app |
I printed a black banner with the script, with concentration 2, and it turned out fine. It looks like black images are ok, but gray is a challenge (because of underruns). |
@skorokithakis What do you mean by underruns? |
Sorry, underflow, buffer underruns. The same issue that @rkolbaskin described above. |
In fact this printer works the following way:
So there could not be white lines if printer didn't receive anything. If no row data received after step 2 or iteration on step 3, printer just waits for data and does nothing. Possible problem is - client sends rows too fast (too low delay) and printer can not properly print it and has to drop lines. Another untested possible thing - buffer is not aligned to packets and row header may be unaligned, so partially cut off. In this case printer receives partial header and consumes row data as header, so image gets corrupted |
But then why does the problem go away entirely if I set the delay to a very low value? I can test setting the delay to 0.1, I predict the problem will be even greater then. |
@skorokithakis increasing delay results in white line inserted after every row. |
Maybe they've really changed something in hardware. Try to request device info peripage-python/peripage/__init__.py Line 315 in b2d2a9b
peripage-python/peripage/__init__.py Line 290 in b2d2a9b
Or look in app if it is there |
@bitrate16 Hardware: "v3.38.21_AY", firmware: "V1.12_304dpi" |
What will happen with delay 1 or 10? If it feeds paper with constant speed, this should produce just white Also, i can later implemented deleted row mode to check what happens when each row is submitted with very large or varying delay. |
It only inserts one white row regardless of delay size. |
@rkolbaskin I can try to reverse app communication again to check if something has changes. You can you do the following test from app:
Later it can be analyzed with wireshark |
Current workaround: allow commandline config of delay to manually set it to 0.001. Possibly will cause problems for long images, like data loss |
I already tried removing I also already captured bluetooth logs and at the first glance they don't look any different from what your script does (except it sends more than 0xFF rows per print command). I might do another one for you later. |
Do row size of app match one in library? |
Here are print commands from the logs |
Just tried printing with official app from two rooms away. It ended up making white lines as well. |
Printing an image via this project results in the image having lots of horizontal lines, as if there were buffer underruns while printing. Printing via the app presents no such problem. Is it an issue with my Bluetooth adapter perhaps?
The text was updated successfully, but these errors were encountered: