for it to work (Like Ostrich suggested back in May), even when plugged into Port_1 and retrieving the value from only Port_1.
Adding the Port_2 declaration seems to be the part that activates the light. Why is this? As this doesn’t seem right to me, especially when it stops me using that port, effectively reducing the number of sensors I have to play with.
Also is there any way of activating it just as a lamp and defining the colour?
Just to put this out there: could it possibly be that a batch of BrickPi boards weren’t flashed properly, and thus have out-of-date or corrupted firmware? As it would explain why D.I. can’t reproduce the problem, while some of us are struggling.
if you’re willing and have the equipment already by all means, I’d try if I had an Arduino Uno or AVR programmer, as in theory if done right it’d either fix things or stay the same.
Did anyone have any luck with reflashing the BrickPi firmware? I can see how this might be why we’re unable to recreate the problem, and I’m really curious to know if there’s been anyone that’s reflashed and seen success.
I do not have Brickpi from dexterindustries.
I builded mine from scratch with two arduino uno based on atmega328P-au.
I tried with both firmware ( 1.7 and 2.0 ) and same result, color sensor do not work.
I had modified the CS_READ_DATA() function in BrickPiCS.cpp ( like said earlier ) and after that reflashed it.
Then it works !
I too have tried reflashing now and got the same result, corrupt firmware doesn’t seem to be the cause. But if the error is in a C++ file shouldn’t that mean that D.I. should have the same issue? But they’re reporting that it works fully.
What on earth could be causing this error for just a subset of people?
@flopsoft67: does that .cpp file need recompiling for the fix to work or not?
I’m looking into trying that myself, or perhaps experimenting with a more robust fix that doesn’t involve another library.
You have to modify the file and recompile the firmware like classical sketch with arduino IDE and that’s all.
if you don’t use an Arduino that’s not helpful. I used an AVR programmer to reflash. i thought i might have to run make or something
what i meant by a more robust solution is just finding out why the DI code doesn’t work and fixing it using only what is already used within brickpi’s firmware. unless you mean you added that library help it when an operation wasn’t firing quick enough or something. but i don’t see how ‘timing’ could cause the sensor to only work correctly when it’s declared on two ports, seems like an addressing issue to me.
I REALLY need this sensor to work as it should for my project as I’m only using standard sensors form the 2.0 set, so i can’t use port 5, and I need all four ports so i can’t be assigning the colour sensor two ports.
I have just (20th November 2014) received two BrickPi and they have the same problem with the Lego NXT Color Sensor.
With the Python color sensor test example the sensor is dead (no leds, reports Black) unless I add the bodge workaround as suggested on this thread (then it lights up and reads colors).
I’ve been talking to John from D.I. by email and he’s sent me a new board he’s tested himself and taken pictures of working. I’ve not gotten around to testing it yet so I’ll post here when I have. If the new one does work, I’ll be sending him mine so they can have a look at where the fault lies.
