{"action":"created","issue":{"url":"https://api.github.com/repos/psieg/Lightpack/issues/209","repository_url":"https://api.github.com/repos/psieg/Lightpack","labels_url":"https://api.github.com/repos/psieg/Lightpack/issues/209/labels{/name}","comments_url":"https://api.github.com/repos/psieg/Lightpack/issues/209/comments","events_url":"https://api.github.com/repos/psieg/Lightpack/issues/209/events","html_url":"https://github.com/psieg/Lightpack/issues/209","id":384872964,"node_id":"MDU6SXNzdWUzODQ4NzI5NjQ=","number":209,"title":"Smoothing for WS2811/WS2812","user":{"login":"TJ-91","id":26199554,"node_id":"MDQ6VXNlcjI2MTk5NTU0","avatar_url":"https://avatars2.githubusercontent.com/u/26199554?v=4","gravatar_id":"","url":"https://api.github.com/users/TJ-91","html_url":"https://github.com/TJ-91","followers_url":"https://api.github.com/users/TJ-91/followers","following_url":"https://api.github.com/users/TJ-91/following{/other_user}","gists_url":"https://api.github.com/users/TJ-91/gists{/gist_id}","starred_url":"https://api.github.com/users/TJ-91/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TJ-91/subscriptions","organizations_url":"https://api.github.com/users/TJ-91/orgs","repos_url":"https://api.github.com/users/TJ-91/repos","events_url":"https://api.github.com/users/TJ-91/events{/privacy}","received_events_url":"https://api.github.com/users/TJ-91/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2018-11-27T16:15:34Z","updated_at":"2018-11-30T16:33:57Z","closed_at":null,"author_association":"NONE","body":"So I've seen there are discussions about implementing smoothing for Adalight devices. I've also seen the attempt to provide smoothing in Prismatik.\r\n\r\nI have a setup with WS2812B LEDs and [use this program based on FastLED](https://github.com/Wifsimster/adalight_ws2812) on my Arduino clone. \r\n\r\nNow my thoughts were that implementing software based smoothing in Prismatik is kind of flawed since you'd have to send new color information in very short intervals. Which makes communication a bottleneck, I suppose. Instead I thought I'd do it on the Arduino itself.\r\n\r\nHere is my fork with my first attempt: https://github.com/TJ-91/adalight_ws2812\r\n\r\nUnfortunately it has some problems/drawbacks. I'll put this part at the end of my post and first describe the results:\r\n\r\nIt works very well if the prismatik frame time is set high enough (I'm currently using 180ms). This means there will be some delay. However the smooth transition means that there is a delay anyway. Also the smooth transition makes up for the fact that there are only 5-6 frames per second. To be honest, when I compare the result to a video of a Philips TV with ambilight it's not worse than that :) \r\nSo for movies I think it's fine but for desktop usage some more fps (less delay) couldn't hurt, I think. \r\n\r\nIf anyone can help me with the problems below that would be very welcome! It's working but I know I could make it much better.\r\n\r\n# Problems\r\nMy idea is to do smooth transitions while waiting on data from Prismatik. Obviously this induces some constraints. The maximum achievable fps has to be cut down since otherwise there would be no time for showing the intermediate colors between two colors.\r\nThis should only become an issue for high frame rates or very long LED strips.\r\n\r\nHowever there is another problem that I've encountered. I seemingly have to make sure that my color transition is fast enough to fit between two color frames that are received from Prismatik. If I take too long with the smooth color transition then it will show artefacts (completely wrong colors). \r\n\r\nI'm not quite sure how to solve this problem. The problem is not that I'm reading wrong values from a malformed color frame. The program should still be reading valid frames due to reading a valid Ada-header first. So there should be no wrong color information even if we start reading in the middle of one frame. In this case the second half of the current frame would be thrown away and the next frame would be processed normally. All of this assumes that a full serial buffer results in the behaviour that I think it does. \r\n\r\nI am not very familiar with serial interfaces (or any kind of low level communication for that matter). So maybe there is something to consider that I ignore out of ignorance.\r\n\r\nYou can see in my implementation that I tried to read all serial data in between the color transition and buffer the last frame. The thought was to start with the newest color information instead of waiting for the next frame after the transition is done. Also I thought that clearing the serial buffer could help with any strange glitches (it doesn't so I commented that part out).\r\nMy final goal was to go one step further and always take the most recent color information and throw the old one away even while in the middle of a color transition. \r\n\r\nMaybe I'll be able to achieve all of this by cleverly working around any timing issues. But I feel there has to be a better and more robust solution.\r\n\r\nIf you have any questions, please just ask.\r\n\r\nPS: I've thought about using another color space than RGB to calculate more accurate color transitions. In RGB the distance between two color vectors does not accurately represent the distance between the perceived colors. Also currently I'm adding/substracting a fixed number to each of the RGB values per step. This is very rudimentary. However this solution really seems to be good enough and I'm not sure if there is any need to improve it."},"comment":{"url":"https://api.github.com/repos/psieg/Lightpack/issues/comments/443260587","html_url":"https://github.com/psieg/Lightpack/issues/209#issuecomment-443260587","issue_url":"https://api.github.com/repos/psieg/Lightpack/issues/209","id":443260587,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MzI2MDU4Nw==","user":{"login":"TJ-91","id":26199554,"node_id":"MDQ6VXNlcjI2MTk5NTU0","avatar_url":"https://avatars2.githubusercontent.com/u/26199554?v=4","gravatar_id":"","url":"https://api.github.com/users/TJ-91","html_url":"https://github.com/TJ-91","followers_url":"https://api.github.com/users/TJ-91/followers","following_url":"https://api.github.com/users/TJ-91/following{/other_user}","gists_url":"https://api.github.com/users/TJ-91/gists{/gist_id}","starred_url":"https://api.github.com/users/TJ-91/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TJ-91/subscriptions","organizations_url":"https://api.github.com/users/TJ-91/orgs","repos_url":"https://api.github.com/users/TJ-91/repos","events_url":"https://api.github.com/users/TJ-91/events{/privacy}","received_events_url":"https://api.github.com/users/TJ-91/received_events","type":"User","site_admin":false},"created_at":"2018-11-30T16:33:57Z","updated_at":"2018-11-30T16:33:57Z","author_association":"NONE","body":"> so the LED libraries disable interrupts when latching to the LEDs. No interrupts = no serial data.\r\n\r\nAre you sure? I think that's what the `#define FASTLED_ALLOW_INTERRUPTS 0` is for. And I don't use it and it doesn't change anything.\r\n\r\n> corrupt the transmitted data \r\n\r\nIs it corrupted on a level that will create wrong serial buffer contents? My implementation **should** only read correct frames but if it's corrupted on this level it's hopeless. It would explain my problems at least.\r\n\r\n> You can always up the baud rate on the Nano, although that introduces its own set of problems.\r\n\r\nI can experiment with this to see where it leads.\r\n\r\n> testing for feature support, sending config information etc. - not every implementation will handle it.\r\n\r\nWell you may be right. I'll have to think about it. I think it's fine but you are ideologically right but I think simply naming it differently also doesn't magically solve everything. Also I don't think testing for features is necessary. Add a checkbox in advanced settings to enable the extended protocol features and then it comes down to \"know what you do\" :)\r\n"}}
{"actor":{"display_login":"TJ-91"}}