I purchased 10 chain able LEDs and tried to make them work. I must admit that this was a complete disaster. I was running version 1.2.5 of the firmware and tried the script where you have to install all the LEDs in cahin to port D7.
I particularly payed attention not to mix up with IN and OUT on the LED boards.
When I started the Raspberry all LEDs where lit, most of them in white but some with less luminescence and slightly different color.
I run the script ‘grove_chainable_rgb_led.py’ and some things happened with the LEDs, although it was not as indicated inside the file…
I run the script a second time and nothing was happening anymore.
The only way to solve the problem was to completely switch off the Raspberry and make sure that there was no power supply anymore to the boards. I tried reboot but that did not solved the issue
I started all over again with exactly the same result
I tried to eliminate the lines from the script to find out what causes the problem. I could not fin the solution and I switched off the system more than 20 times. At a certain point I was able to have some control, but I needed a lot of time.sleep in between each command. I only used the ‘grove.pi.storeColor(R,G,B)’ command and the ‘grovepi.chainableRgbLed_pattern’ command, but it was not stable and predictable at all.
The worst thing was that I discovered that also other sensors no longer worked like the temperature and humidity sensors. As a result I checked on the firmware revision level and it read out (0.0.0), so something was definitely modified inside the firmware. I had to reinstall the 1.2.5 firmware several times. This is not the purpose of the ROM on the board.
Finally I gave up and decided to cry for help…
Can someone please explain me how these LEDs should function and provide me with some kind of stable solution?
Hey Freddy,
Can you try a few things out. First start with 1 LED and try to get it to work on v1.2.5 . If that works keep increasing the LED’s until you reach the point where it stops working. If it does not work at all with v1.2.5, downgrade to v1.2.2 and then try to repeat the tests above.
I tried with one LED and v 1.2.5 and it failed immediately
I then downgraded to v 1.2.2 and tried it and it looks like it is working for me.
However, I run the complete demo script that you provide with 10 LEDs and it only worked once.
After that the system was not controllable.
I then had to shut down the complete system to have a running system again.
I then tried with 4 LEDs because that is what I will need and I limit myself to address them individually and at a first glance it looks that it is functioning.
I wonder how one of the last commands in your script functions since it looks like it is addressing i2c while the LED’s are connected to a digital port.
The command loos like:
grovepi.write_i2c_block(0x04,[95,pin,7,1])
I also hope that the system is not producing too many analogRead errors.
I also had a couple of digital IOErros.
I hope that my hardware is functioning OK…
Finally. Is there a grovepi command to reset the board completely?
Kind regards and thanks for your patience with me,
There is definitely something wrong with either the chainable LEDs or with my GrovePi board.
I am trying to use the LEDs together with switches and sensors on the board.
I will try to give you a summary of my findings (always with the sensors connected):
The chainable LEDs do not work when connected to digital port 3 or 8
When LEDs connected to for instance port 4 and you have a push button (with 10 K pull-down resistor) on port 5, all the LEDs will burn white as long as you push the button.
So far the port lower in this example 3 is not influenced
When a relay is put in port 5 instead of the push button, the LEDs will always be turned white.
Putting a DHT sensor next to it will ruin everything and I had very strange results in doing so
In my application I use 4 switches, one DHT sensor, one output relay and the LED array, so all ports are used
I also use a moisture sensor and light sensor on respectively analog port 2 and 0
On the i2c lines I use the LCD on line 3 and the barometer on line 1
It starts to work relatively well, but I have to consider a lot of reading errors both on the analog ports and the digital ports.
For the digital ports I use one switch which is most of the time True (1) and there I have sometimes a wrong reading. I now check the status 3 times to make sure…
I had readings of 255 instead of 1 and 0 (on all digital switches) but I can capture the 255 in my program.
I must admit that my programming is very amateurish but in most cases it works.
I hope that somebody can give me some hope that I will be able in the near future to solve the LED problem.
Is there a reset command in Python for the GrovePi board, because when something goes wrong with the LEDs, I can only solve it by completely turning of the system?
Hey Freddy,
Sorry for taking this long to reply back. I am going to try out the both the v1.2.2 and v1.2.5 firmware for the RGB Led. The RGB LED code was submitted from a user on the forums and was pretty complex so we might have broken something in the new firmware. But, I only have 1 RGB led so it wont be possible for me to chain them and test them together. But I’ll test out one of them and let you know how it goes.
Hey Freddy,
I somehow ended up destroying the RGB led over the weekend trying to test it with the GrovePi but yeah, I can indeed confirm that there is a problem with the RGB color. I was still investigating the problem when this happened. I am going to get a replacement LED and will try soldering and replacing it and trying it out. Sorry for the inconvenience, I’ll try to get this working as soon as possible.
Hey Freddy,
I was unsuccessful in repairing the sensor but a new one is on the way from Seeed. I’ll post an update as soon as I get it and test it out.
I want to assure you that we will get this problem solved but it might take some time.
Sorry for the troubles.
Hey Freddy,
We have received the LED’s. We’ll give it a shot this week and will let you know how it goes. Can you give us a few more details about the reading errors that you are getting.
As mentioned before I have a lot of reading errors from both the analog or digital ports.
Digital ports reads a faulty state once a while, so I have written a subroutine to check the state 4 times in consecutive row to be sure about the state.
Also it does not always reads 1 or 0 but gives detects another number.
The analogue ports randomly generate errors that I trap.
For your information, I will include the script I am using.
I also will include a small report on the errors I receive in one Month.
I measure some things every minute. In November I had 2143 of those errors. If I do not use the 4 times loop for port detection the system is not usable.
For your information, I tried to enter delays at multiple points but none of them where of any use.