Das Problem ist, das Du nicht weisst, was Vixen da genau schickt. Du schreibst einfach die ankommenden Daten auf das entsprechende Pin. Die Funktion digitalWrite() ist so programmiert, das sie bei einem Wert von "0" den Ausgang auf LOW schaltet und bei allen anderen Werten ungleich Null auf HIGH. Damit sollte es eigentlich klappen. Der Code sieht für 5 LEDs auch erstmal OK aus. Jetzt geht es halt darum herauszufinden, wie das Daten-Protokoll von Vixen aussieht. Das ist aus meiner Sicht die wahrscheinlichste Fehlerquelle. Es reicht ja, wenn zusätzlich zu den Channel-Daten noch irgendwas anderes mitgeschickt wird. Ein zusätzliches Byte bringt automatisch die Sequenz durcheinander.
Hast Du evtl. Zugriff auf ein LCD-Shield, oder irgendwas mit dem man die seriell gelesenen Daten ausgeben könnte?
Welches Plugin für die Ausgabe in Vixen verwendest Du? "Generic Serial protocol"?
Einen interessanten Beitrag habe ich im Vixen-Forum gefunden:
Hi guys, I've been working to integrate Vixen to Arduino for the past few week (using 2.1.1.0 and Arduino ATmega 1280)
I have the common configuration working easily - multiple channels, software PWM = lots of blinky lights, but I know this is where this integration is going wrong. One lost bit or byte and the whole display would be corrupted.
So I though I'd use the tools given.
- Limit serial channel brightness values to 196 steps, reserving 197 - 255 for control codes (or header / footer for now) (step up the values on the Arduino end)
- Thus I limited the Max Illumination to 196 (aka 3/4 brightness) - ugly but I can live with that.
- I then defined the header to use a single byte (255) and footer to use a single byte (254)
- Sketched up some code in the Arduino to look for these control codes before allowing the 'channel buffer' to be filled, and then expecting the 'footer' code when the buffer was full (and if it wasn't Huston we have a problem)
- Sounded right, I then proceeded to spend several hours debugging on the Arduino -- grrrr
- Gave up on the Arduino and began to monitor the com port (sysinternals portmon) - and this was when I discovered that somewhere in the generic serial plug-in it has been decided that the header and footer can only use 'printable ascii' codes (tracked down to Encoding.ASCII.GetBytes piece of code) - if the codes are even accepted, they come out at the other end as '?' or code 063
- Thus currently we cant 'reserve' any high or low ascii codes to use in the header / footer (aka cant use 0 – 32, or 127 – 255)
Anyone know how we can amend the source to cater for this?
Be good to be able to translate the 256 steps of illumination to 196 in the plug-in, and use the remaining bytes as channel markers.
Or maybe this is already accomplished in another serial based output plugin - I just need to translate the protocol into Arduino Code.
On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'
Been following ctmals videos about how to build a plugin + searching through the MSDN website , just need to change Encoding.ASCII to Encoding.UTF8 and we should be away laughing
Spannend ist dabei folgendes:
On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'
Das könnte ein Problem sein, bei Deinen Sequenzen.
Dazu kommt wohl, das nicht alle Werte zwischen 0 und 255 vom "Generic serial plugin" korrekt übertragen werden.
Der Poster verwendet ein Tool "sysinternals portmon", um den seriellen Port zu überwachen, evtl. solltest Du das auch mal machen. Wichtig ist halt, das Du herausbekommst was genau gesendet wird.
Mario.