Loading Profile...
I2C address setting problem - won't 'stick'!
I'm setting up a chain of BlinjM's. What is the recommended way to assign the unique I2C addresses? I've tried using the test code and the "a" command, but the address don't seem to stay loaded. Maybe something with power sequencing?
4
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Hi Tim,
The 'A' command sets the I2C address, while the 'a' command gets the I2C address. Did you mean capital-A? If so, do you have a repeatable test case that causes this issue? We've had reports of a few other people having this problem but I can't replicate it in the lab.1 Comment
Add a comment
This answers the question
-
This is the most I can tell you:
I have one Arduino board connected to up to six (so far) BlinkM’s in parallel. The BlinkM’s are powered through the +5 connector, not the direct connection on the Arduino board (the cable to the chain of BlinkM’s goes to two different connectors on the Arduino.
I have the 0011 Alpha software downloaded, along with the tools and drivers.
I am programming the I2C addresses by plugging one BlinkM in, and running the BlinkMTester sketch. I get the address using ‘a’, set it using ‘A’, verify it using ‘a’, then verify the LEDs work by trying a few lamp combinations with the ‘c’ command.
I have programmed six BlinkM’s for the address range of 16 to 21 this way.
I then run my sketch (which I can send you seperately) which should sequence the LED’s. Once it worked, but when I power cycled, all the BlinkM’s had returned to address 16. sometimes they have returned to address 97.
Suggestions? -
Inappropriate?I just tried the same process with the Cylon example sketch, and with twoBlinkM's plugged in, programmed to addresses 16 and 20 (dec). It worked, until I power cycled and reloaded the arduino; then the BlinkM formerly at address 20 changed to 97.
Also, the fade speed of that BlinkM was changed to 0, keeping it from lighting at all. I have seen this before when the address changes.
HLP??!! -
Inappropriate?I think I have narrowed down this issue to hot swapping the BlinkMs.
-
Inappropriate?As far as I know an address of 97 means that the BlinkM isn't wired in properly. I was having this issue today and it was frustrating. BUT! It was my mistake, I had reversed the SDA and SCL lines, maybe there is a dodgy connection there?
I’m unsure if this helps you
-
Inappropriate?I was having the same problem. The BlinkM's kept changing their address to 97. Then taking Tim's advice, I stopped hot swapping the BlinkM's. Now I have two BlinkM's addressed 1 and 2 on my I2C bus. Do not hot swap the BlinkM's. Unplug your power supply before removing BlinkM's from your I2C bus. Thanks Tim.
I’m happy
-
Inappropriate?I am having this problem too with on device connected to Arduino. Using the test code and setting the address to say, "A1", and the "a" command returns 1. I power down the Arduino, power it up, and the address is now 97.
help??? -
Inappropriate?I've done some more testing with inconsistant results. I was able to set one of the blinkm's address by turning off the running script, fading to all LED's off and then setting the address. I tried it on a second and it didn't work. (reset to address 97) Perhaps its related to power. Even still, it should never change unless instructed to do so explicitly.
For anyone trying to sequence, this is a VERY important feature. I am planning to use 50 blinkm's in an application and if the address keeps changing, the blinkm's are useless to me. -
Inappropriate?Just tried this again but did not remove power to the Arduino or the blinkm. I set the address to 9, closed the serial monitor, opened the serial monitor, ran the "a" command, and received back address 97.
-
Inappropriate?Address 97 is what the Arduino Wire library reports when either there is no response or if you are addressing the general call/broadcast address 0. (97 is ASCII 'a', the first byte of the "get address" command)
Could you give a detailed step-by-step description of exactly how you are hooking up your BlinkMs, exactly what Arduino/Processing sketches you are using, or what BlinkM commands you are sending and to what addresses? I'd like to be able to replicate this problem. -
Inappropriate?I have one blinkm plugged directly to Arduino just like in your demo video. Ardurino has the test code loaded with the address set line removed. Tried Arduino is powered by usb and ext.
Test 1
1. Connect blinkm.
2. plug in usb cable
3. start serial monitor
4. send A09
5. send "a", returns 9
6. stop serial monitor, pull usb plug, remove power
7. connect power, plug in usb, start serial monitor
8. send "a" returns 97
Test 2
1. Connect blinkm.
2. plug in usb cable
3. start serial monitor
4. send A09
5. send "a", returns 9
6. stop serial monitor, Leave power ON
7. start serial monitor
8. send "a" returns 97
I have 8 blinkm's, they all did this.
A test code issue? Since I'm new to Arduino, good time to try my own code and see what happens...
Thanks for your help -
Inappropriate?Hi Bill,
When you start the Arduino Serial Monitor, does the BlinkMTester sketch immediately print out either "no response" or "addr mismatch"? Also, can you still command the BlinkM with things like the 'o' and 'c' commands?
If so, then I think there is a bug in the BlinkM_funcs.h library for BlinkM_getAddress() that makes it not always return the correct value. I'm working on an update to the example code that will be released shortly, and I'll see about debugging that function. Also, which version of the Arduino software are you using and what kind of Arduino board do you have? -
Inappropriate?Also, if you have access to an AVR-ISP programmer and a breadboard, you can try reprogramming a few of your BlinkMs with the BlinkM firmware to see if that helps. Alternatively, if you'd like to send me a few of your BlinkMs so I can do some testing and potentially replace them if they are bad, email me at blinkm @ thingm.com.
-
Inappropriate?Todbot,
Yes, I get an adddress mismatch when startting the serial monitor. I can set the address to 9 and command the blinkm with 'o' anc 'c' commands just fine. -
Inappropriate?Oh, I have Arduino Diecimila and 0011 software.
Thanks for your help. -
Inappropriate?Hi,
I got the same issue there with the same configuration. Any idea on the issue, and how I can fix it ? This is quite urgent as I have a demo tomorrow :(
Jm -
Inappropriate?I'm having a similar problem with a single MaxM running on top of an Arduino Decimilla using the 0012 build of the Processing environment. I think I'm using the latest version of the blinkm library too.
I'm having problems using BlinkMTester to successfully do the "a" and "A" commands plus other commands.
With BLINKM_ARDUINO_POWERED set to 0, I can successfully use the "a" command to change the address. Can also successfully run "o" and other commands.
But when I have BLINKM_ARDUINO_POWERED set to 1, the "a" command has no effect and the address is left at 0xff (-1) even though the call to the "a" command is successful (but obviously not working.)
I’m unsure if this helps
-
Inappropriate?Ok, I found a very good workaround. In fact the blinkM doesn't loose it's I2C id. The issue is more related to the Arduino power up sequence. One good way is to hack the SetAddress code to re-initialize each blinkM standing on the bus after reboot. The setAddress is using as target 0x00 (all BlinkM), you only have to create a setAddress resetting target address 0xNN and set to 0xNN and call it at the beginning of your powerup sequence for each expected LED (you can send a loop to reset it !), it will reset the connection between the Arduino and the led and will make it work.
Mail me, if you need more, or patches. I believe this is more an Arduino SDK bug, but it works great ! -
Inappropriate?Krowney, a MaxM with the Blaster LED board on top won't work reliably plugged directly on top of an Arduino. This is because the Blaster board draws too much current for the MaxM to work. A more robust solution is something like this: http://flickr.com/photos/todbot/30216...1 Comment Add a comment
This answers the question
-
Tod-
Thanks for the quick response. Unfortunately, this does not work. For the problem I'm facing, the arduino powered solution works. Its the standalone setup that fails. I even tried to do the wiring setup that you sent me via the flickr picture, but there was no progress.
So its clear: I2C communication definitely works when the Arduino board powers the MaxM. The problem only arises when the MaxM is running in standalone mode (i.e. it's own power from a 1.2A 12v wall wart with the jumper switched to "ext" and BLINKM_ARDUINO_POWERED is 0)
Any ideas?
Thanks for the help so far.
Kevin -
Inappropriate?Vejmarie, I'm not sure I understand the changes you've made. Calling "Set Address" to a specific I2C address will have no effect: if you know the address, there's no need to reset it, and if the BlinkM is not at that address it won't respond.
I'm curious to see your code though, you may've come across an issue we need to address. Send us email at blinkm @ thingm.com (we have no access to email addresses on GetSatisfaction)
In general, there are two types of timing considerations when dealing with BlinkM: power-up and setting saved values (i.e. writing EEPROM). For the first case, if powering the BlinkM directly from an Arduino by plugging it into analog pins 2,3,4,5, you should way several tens of milliseconds for the power to stabilized. The most recent version of BlinkM_funcs.h does this for you in "BlinkM_beginWithPower()". In the second case, whenever you write a "saved" value in BlinkM (I2C address, startup params, light script lines), you should wait approximately 10 milliseconds for the EEPROM in BlinkM to get written. Again, the most recent version of BlinkM_funcs.h includes these delays so you shouldn't have to. -
Inappropriate?I believe Vejmarie's solution worked because the BlinkM does an i2c reset whenever it resets its address. Thus if you target blinkm at address 16 with a command to set its address to 16, it will diligently perform this procedure then reset its i2c communications. The problem here seems to be that writes to the blinkms from the arduino were working but reads/responses from the blinkm to the arduino were failing after arduino was power cycled.
I don't know if this is still a problem, but my MaxM's and arduino are in the mail, so I am eager to read about any potential pitfalls before I get going.
I was going to attempt a design where the arduino has control of each connected MaxM's reset pin, so that I can program the addresses of all connected blinkm's in circuit - in case something goes wrong I will have a programatic abilitiy to reset the entire system to a known state rather than having to fiddle with unplugging a ton of blinkms every time I have to mess with their i2c addresses.
Has anyone attempted to control the blinkm's reset with an arduino digital pin?
EMPLOYEE
