Screen displays corrupted images on Mac

[opless]

Someone else has had a similar issue here:

https://youtu.be/4z5OOW1jL94

I’m also using an M1 Mac.

I’m also reverse engineering the vendor .net binaries to attempt to figure out what is going wrong.

Though I’m struggling a little with the obfuscation. 😂

it’s not something as simple as endian issues!

[opless]

Looks like it's something weird with the serial comms or the operating system.

Closing because it's not fixable here.

[mathoudebine]

Sorry to hear that, FYI the display you should expect is this one: https://www.youtube.com/watch?v=Y1m4KK881Aw
I had greater success in decompiling the chinese binary than the english one, it was not obfuscated. You will find the link of it in the README

[opless]

I've had a look at all three, and yes, the one you mention is MUCH easier to work with.

It's a shame there's no way to get hold of the creators and have a look at their firmware source.

I'm considering knocking something up in golang, to see if it's just the serial port drivers are broken on the M1 or if it's just pyserial that's not working.

[alanrenouf]

Im also getting this issue on my Mac, dont get it on windows. the port shows up as "/dev/tty.usbmodemUSB35INCHIPSV21" @opless did you find a workaround ?

[opless]

It's very much to do with the USB serial implementation, as far as I can tell.

I had some better luck sending data to it via golang, as the serial port initialisation is different.

I pretty much put the project aside after things getting busy with the day job and having less brain in the evening. It's certainly something weird with the M1 serial usb drivers though!

[mathoudebine]

Hi, i'm reopening this issue for people with Mac that have the same problem. Feel free to discuss here. What you can also try is changing the COM port settings here:

turing-smart-screen-python/main.py

Line 184 in deb0a60

lcd_comm = serial.Serial(COM_PORT, 115200, timeout=1, rtscts=1)

If i remember correctly, the display also works with baudrates slower than 115200

[alanrenouf]

Tried slower baudrates and not getting any luck

[Ebag333]

#15

I think I've fixed it by serializing the updates to the screen (using a queue, so it'll run through each one cleanly before executing the next).

With the default code base I could get it to step on itself, once I started adding a bunch more things to update it just got worse and worse. You could help by increasing the delay after an update was done, but slowing down the updates isn't really a solution as it makes everything slow.

With this PR it runs at a very high rate and has no issues with keeping up, not getting serial errors anymore.

[alanrenouf]

I still get the corrupt image using the overhaul branch on my mac, I like the other changes to make the code more modular. Nice!

[gerph]

From my own investigation:

In my testing in my own library, I found that the delay between the bitmap data being output and the next command being issued needs to be quite long - about 0.02 seconds. Shorter than this and you get corruption on the display. The current delay in the code on the master branch is about 0.01 seconds, which means that the other slack is being taken up by the code sitting between the time.sleep(0.01) and the next SendReg writing a command. On faster machines that code will be executed faster, and result in the corruption (I believe).

In my library I changed the behaviour so that instead of explicitly sleeping at the end of the update of a bitmap, we remember when the last output happened and if we try to write a command before the required inter-bitmap-delay has expired, we sleep there instead. This means that we get useful work done between the two operations, and if you did enough work you'd never need to sleep at all before the next command was written.

My library changes that did this were here, if they're useful to you:

gerph/turing-smart-screen-python-mit@8ba5901

It looks like the changes in PR #15, mentioned above, move the logic for the delay out of the communications library. I cannot tell how this keeps the bitmap transfers and the subsequent command updates apart enough to avoid the corruption.