AtmoWin - improvement discussion (1 Viewer)

[kenwonders]

Ah right though it was also affecting the fading in / out, edge detection is correct that way as the lower value increases the level of image data measured from the side so if you set it to 12 for instance it will detect only near the screen border and not further in
Hyperion has it as well only there you have a bit more options for vertical / horizontal with spacing and is % based, where if you were to increase the depth there it will increase the block size from the below screenshot whereas with AtmoWin lower depth value = more data which is weird

With the older AtmoWin builds this worked at least so might be setup related or specific hardware / led count.

Thanks for the help Rick, I do appreciate it. The issue is that if you check out the graduation pop up, it shows a green bar fading from the edge of the screen into the centre. This should mean a white presence (against black) in the 'faded' area should be a shade of grey (as it has only X% influence), however for me, a white object turns the whole pixel 'white' despite it only taking up a percentage of the area defined. You can see this on 'dumy' mode too.

 

[Rick164]

Thanks, will check with your config and try to figure out what is causing that

 

[Rick164]

Something odd when running it with Windows 10, it will not calculate the channel assignments with new configs unless I run it as admin so seems UAC is interfering with it.

 

[Kotik]

Visually the COM port for AtmoDuino V1 / V2 stays at the correct one however I made the mistake of not starting at index 0 when reading it back (hench the off by 1) , new version attached and let me know how it goes

New version is working as expected.

Thanks for the fix.

May i ask whats the difference between AtmoDuino v1 and v2? I have been using v1 for a long time now and it seems to work just fine but out of curiosity would like to see if anyone knows what is different between the two versions.

 

[Rick164]

Believe it's mostly for performance but @azzuro knows this better , with the new sketch by @kenwonders there's now an version which covers V1/V2 and AmbiBox all in one so that way you can freely switch back and forth:

https://github.com/ambilight-4-mediaportal/AtmoDuino/blob/master/RGB/AmbiDuinoBox.ino

 

[kenwonders]

There's no difference in the data sent apart from the header, which doesn't mean much unless your arduino is already dropping a lot of serial data.

 

[azzuro]

Hello guys.
The atmoduino v2 is the one from nevcariel (lav splitter dev)
Excepting it use its own coding files. I don't know the difference.

 

[Kotik]

The way i understand it is that they are exactly the same with one difference, using different coding for RGB.

 

[kenwonders]

Nope, as I said above the main frame data is the same. Check out my script, the only thing different between v1 and v2 is the 4 byte header up front. The last of those being calculated based on number of LEDs like so:

0xD7, 0xEE, 0x23, NUM_LEDS - 1 //atmoduinov2
0xFF, 0x00, 0x00, NUM_LEDS * 3 //ambibox atmoduino can overflow but the truncation is what ambibox appears to do too
0xFF, 0x00, 0x00, NUM_LEDS //atmowin atmoduino

after the header, frames are loaded in order of LEDs, 1 byte for each colour in RGB order (unless you configure Ambibox with a different RGB order)[DOUBLEPOST=1465759240][/DOUBLEPOST]oh you mean inside atmowin..... sorry

 

[Kotik]

I just now found out something interesting, i am using latest AtmoWin version from here (16x9 edition) and while testing some random things i noticed that for me LED no. 170 (last one in my case) never turns on

1st i thought that my last led is dead but then i entered AtmoWin config menu and faked my leds number by actually adding 1 extra led into the config, so on the com ports config of AtmoWin i faked the number and set it to 171, after that my last led does turn on.

U can easily test it if u set AtmoWin to a Static Color and visually check ur leds.

Can anyone confirm?