I saw the sticky on this, but thought I’d point out that my particular one has blue and green swapped (not red as mentioned in the sticky). I wasn’t sure if you needed that for a data point for the patch 
Pete
Green should always be correct I think in all cases. Only red and ue can be swapped is this what you are seeing?
Green and Blue are swapped on one of mine (I haven’t tested the other). Red is correct.
I tested my second one. It is also B/G swapped with Red fine.
My leds also have green en blue swapped, red is fine.
I guess I had an incorrect assumption.
Yep one my LEDs is green blue swapped too. Red works as intended.
Both my LED’s are blue Green swapped too.
Yep both my units have Blue and Green swapped with repect to the AddBlue and AddGreen comands. Does anyone know why this is, is it just a bug?
As with others AddRed works just fine.
Same here (blue & green swapped).
To get around this, I added a #define in the up-and-coming WiFi scanner so that those of us in this boat could have the proper indications.
And again, Blue <> Green swapped
Martyn
There is a fix in the beta if anyone has tried it?
The beta is not recommended for new uses. This was part of the hydra release.
Gus, it doesn’t appear to be fixed. I just ran the following and it lit up green, blue, red. 
led.AddBlue();
Thread.Sleep(1000);
led.RemoveBlue();
led.AddGreen();
Thread.Sleep(1000);
led.RemoveGreen();
led.AddRed();
Thread.Sleep(1000);
led.RemoveRed();
there should be a led.SwapColor() to patch this problem
Hmmm… That doesn’t seem like a real fix. Could the driver not do that w/o the user having to call it explicitly? I tried the following
Debug.Print("Program Started");
led.SwapGreenBlueValues();
Thread.Sleep(1000);
led.AddBlue();
Thread.Sleep(1000);
led.RemoveBlue();
led.AddGreen();
Thread.Sleep(1000);
led.RemoveGreen();
led.AddRed();
Thread.Sleep(1000);
led.RemoveRed();
Thread.Sleep(1000);
It’s hard to tell if it worked or not… Since I added that line, I now get the following error every time I try to run. I’ve tried restarting the Hydra & VS many times. However, the LED did seem to continue differently the first time I ran it. It didn’t seem to be fixed. What appeared to happen was that the blue LED came on when SwapBlueGreenValues() was called and then stayed on while the green then lit up and then the red and then the blue stayed on after the cycle was complete. I’m going to do a full PC reboot the next and see if anything happens differently.
The problem is in the firmware on the multicolor led. This is a workaround for now.
Will check on the exception.
Hi there,
Are you sure this was uploaded to the CodePlex…?
because i have the source for the MulticolorLed.cs from the latest build and i DO not see the swap command at all…
and the issue with the GREEN and BLUE is still there…
i’m able to modify the source and get it fix… but like you said it’s a work around…
GUS, is there a way to get the firmware version of the Multicolor chip? this would help with the patching by adding an if statement…
here is my Fix: basically swapped the G with B in all three SendCommand in the MulticolorLed.cs
// Fully changes the mode, timespans and colors
private void SendCommand(Color color1, TimeSpan blinkTime1, Color color2, TimeSpan blinkTime2, Mode mode)
{
long time1 = blinkTime1.Ticks / 1000;
long time2 = blinkTime2.Ticks / 1000;
// send the parameters with mode off to avoid side effects of previous mode
WriteParams((byte)(DaisyLinkOffset + Registers.Configuration), (byte)Mode.Off, 0x00, color1.R, color1.G, color1.B, color2.R, color2.G, color2.B,
(byte)(time1 >> 0), (byte)(time1 >> 8), (byte)(time1 >> 16), (byte)(time1 >> 24),
(byte)(time2 >> 0), (byte)(time2 >> 8), (byte)(time2 >> 16), (byte)(time2 >> 24));
// now activate the correct mode
WriteParams((byte)(DaisyLinkOffset + Registers.Configuration), (byte)mode, 0x1);
}
// Writes color1 and changes the mode
private void SendCommand(Color color, Mode mode)
{
// send the parameters with mode off to avoid side effects of previous mode
WriteParams((byte)(DaisyLinkOffset + Registers.Configuration), (byte)Mode.Off, 0x0, color.R, color.B, color.G);
// now activate the correct mode
WriteParams((byte)(DaisyLinkOffset + Registers.Configuration), (byte)mode, 0x1);
}
// Writes color1 without changing the mode, unless the mode is off in which case it becomes constant
private void SendCommand(Color color)
{
Mode currentMode = (Mode)Read((byte)(DaisyLinkOffset + Registers.Configuration));
if (currentMode == Mode.Off)
{
WriteParams((byte)(DaisyLinkOffset + Registers.Configuration), (byte)Mode.Constant, 0x1, color.R, color.B, color.G);
}
else
{
WriteParams((byte)(DaisyLinkOffset + Registers.Color1), color.R, color.B, color.G);
}
}
now if i can only get the version of the chip firmware so i don’t have to worry about changing the code for furture version of the LED.
thanks.
This brings up a good question… Is it going to be possible to deploy firmware updates to DaisyLink modules via the Gadgeteer? Especially considering that every DaisyLink module potentially could use a different microprocessor.
After rebooting the PC, I’m not having any better luck. With the MulticolorLed module plugged in I cannot even get a blank template Gadgeteer project to run. Here’s the error again showing the line that’s trying to execute when the error occurs. If I then remove the module from the designer then it deploys to the Hydra w/o errors.
Also, I’m having the problem as noted in the other thread with the USB modules not appearing in the toolbox. That doesn’t seem to be a problem since I’m only using the USB Client DP module for power but perhaps the two are related.
Jayjay this is not on codeplex yet. We are still making changes.
I found the problem. I made a mistake and ended up swapping to colors twice in the Add and Remove calls. I’m sorry guys
The Turn calls should work fine. This will be fixed really soon.