Loading Profile...
BlinkMs loose unit addresses at random!
I have a chain of 14 BlinkMs that I've programmed to unit numbers 1 thru 14. However occassionally many of them will loose their unit numbers, quite often switching to a duplicate number. I'm 100% sure I'm never sending the set address command. How is this happening? I suspect there's a bug in the firmware somewhere thats allowing this to happen (perhaps when there are timing issues on the I2C bus). In any case, this is a major problem as the only way to fix this is to manually remove each BlinkM and reprogram it's address.
I’m frustrated
7
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The company has a solution in progress.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Can you describe your setup in more detail? What are you using to drive the BlinkMs? How long is the bus? How fast are you updating them?
I’m sorry to hear that you're having problems.
-
Inappropriate?The bus length is -long-, about 4 feet (they are being used as indicator lamps in a pipe organ console). However I've slowed down the clock/data speed to very slow (sorry I don't have exact timing). There are 4.7k pull-ups at the end of the bus. I had to write standalone bit-banging code to drive the bus as the standard rate on the Arduino board was way too fast. The only command I send to them is the change color command. I do have to update all 14 of them as quickly as possible regularly; I sequentially access each one, setting it's color, every second or so for all of them.
I did numerous tests to determine a max speed for the bit-banging code, and backed off to a safe speed that works reliably. The code uses the Microsecond delay call for timing, about 20us for each bit. I've run the code as slow as 1ms per bit with the same issue of random loosing of the programmed address.
I do get proper 'ack' feed back on each byte transmitted.
A possible scenario is that the glitch occurs when power is lost while sending data. The system may be powered off by the user at anytime, including while I'm sending to the BlinkMs. If I remember correctly, I think the problem happened mostly when I did power on/off tests. Sorry I can't be more specific as each time it happened (at least 5 times yesterday), I had to stop, remove the bad blinkm(s), reprogram the address, and reinstall; making for a rather frustrating day.
Hope that helps. -
Inappropriate?Btw, I did check the signals on the data and clock lines with a scope... they are clean with good rising and falling edges.
-
Inappropriate?Hi Granz,
Could you share your code with us? (privately if you like) We've had a few sporadic cases of BlinkMs losing their addresses but no good way to reliably produce the error case. It appeared to be I2C data rate related, in cases where the I2C master wasn't checking for an ACK from the I2C device. If you have some code that reliably reduces the problem, it would go a long way to helping us find the bug and squashing it.
Once the problem is found, we can do a swap out of your BlinkMs with updated ones. Or, if you have experience with AVRISP programmers, you could update the firmware yourself. -
Inappropriate?I'll try to get some code for you when I get back to the office on Tuesday.
-
Inappropriate?Hi Guys,
Has any progress been made with this?
I have a project coming up with 16 blinkM's.1 Comment
Add a comment
This solves the problem
-
We haven't heard from grantz and we haven't replicated the problem. If you encounter it, please let us know. -
Inappropriate?I've not heard anything from granz, perhaps he's not had any subsequent issues. If you're concerned about this issue, I'd recommend installing BlinkMs in such a fashion so that so that you can re-address them in needed.
And I have made up a post on how to do a 13-node BlinkM network in my BlinkM Cylon post. -
Inappropriate?I have experienced this problem too-- it is very annoying. I purchased a very large amount of BlinkMs because I thought they would be more reliable as a networked array of leds opposed to a wire to teach LED, but this makes it probably less reliable. I am using 14 BlinkMs on an ribbon cable similar to the Cylon project; one time while filming the project I tried updating an led to a different color and bam, it and the one next to it lost its address. :( The operating system also said that USB had been unplugged (it had not been) probably meaning the Arduino reset. If you'd like to see code, please let me know. (though it is very similar to the cylon project)
I’m frustrated
-
Inappropriate?Any Ideas? My research group is sending this project out to present it a few states away and in the UK. If possible, I'd rather not have spent $400 dollars on LEDs and have them botch up 6000 miles away. :(
As an update, one of the BlinkMs that lost its address seems to have died. It now blinks once when powered, and accepts no commands and plays no scripts afterwards. Many others BlinkMs in my shipment arrived like this as well, but I have not had the chance to test all of them.
Thank you. -
Inappropriate?zschallz (and anyone), if you have a failed BlinkM, contact us at blinkm at thingm.com and we'll arrange replacements for you.
As for the I2C address problem, I'd really like to find a way to reproduce this bug and squash it. If anyone has a setup that pretty reliably does it, I'd definitely like to see some pictures, diagrams, code, etc. of it. Or if you'd like to share the process you go through where this has happened before. For code snippets, email us at blinkm at thingm.com (since GetSatisfaction doesnt do code snippets very well) -
Inappropriate?When reporting to Todd It will be helpful to list the number of BlinkM's online and the type and size of the power supply used as well to help eliminate issues that might be related to power fluctuations or surges during use..
Will -
Inappropriate?I have the same problem : I use an arduino board, and a strip of ten blinkm. pull up resistor are on the 5v of the arduino and the blinkm are powered with a separated regulator (common GND).
the 4 same blinkm lost their adress when i repower few time everything.
So to detect what is going wrong i wrote a setup wich makes blink each blinkm on each canal of the i2c bus :
////
int i ;
for(int i = 1 ; i <= num_led;i++)
{
BlinkM_setRGB(0x00,0x0,0x0,0x0);
delay(5);
BlinkM_setRGB(i,0xFF,0xFF,0xFF);
delay(300);
Serial.print("canal : "); Serial.println(i);
}
////
After a reprogrammation and some reboots + sequence, i found that it is the same leds wich lost their adress and have most of the time taken an adresse of an other led between the losts leds . Whatever, they respond to canal 0
Maybe it is the corruption of a bit in the address. Is there some CRC made on the adresse in the attiny45 of the blinkm ?
Arnaud -
Inappropriate?Hi Arnaud,
Thank you, this is helpful. I've tried similar arrangements of BlinkMs but haven't seen problems yet. I'll try again, replicating your exact setup.
You say you have pull-up resistors, could you describe exactly how you have them wired up? Or attached a schematic or diagram image showing the connections?
Address 0 is the "broadcast" address in I2C, so every BlinkM should respond to commands sent to it.
Do the BlinkMs that have lost their address still play the default startup light script (white->red->green->blue->off->repeat)? -
Inappropriate?I have reprogrammed the default sequence with communiator and sequencer.
But the concerned led with the problem lost these sequences too. As far as i remember, concerned leds maintained the programmed sequence and the channel number when it stays plugged on 5v. When I unplug and replug power, let say 5 times, almost every concerned led lost their information.
My pull up resistors are on a shield up to the arduino board between 5v of arduino and respectively SDA and SCL. grounds are common between arduino voltage regulator and the dedicated one for leds (78T05N -> 5V 3A for 10 leds and 20 in the futur, with all the capacitors to maintain a perfect 5V even when the leds are blinking -> verified with oscilo).
Best thing i can do is send you the leds concerned asap to let you have a hand on it.
For information, I bought the leds at lextronic (France) 10 days ago.2 Comments Add a comment
This solves the problem
-
-> i am trying to identify if the problem had a link with the i2c bus by programming a starting sequence with sequencer and defining an address to concerned led and just putting 5v without connecting them to an i2C bus
Arnaud -
I can't quite parse what you said in your last comment. Could you rephrase it?
-
Inappropriate?Sorry for the very long delay getting back to this problem (was on other projects).
The bug has continued to happen, tho not as frequently. The system is installed at the customer's site. Every once in a while, I have to visit and reprogram a few of the blinkms that have lost their assigned addresses. Note, this system is powered on almost all the time, with very few power on/off cycles. I'm fairly sure the problem is happening when powering off and back on.
Anyway, I noticed an errata on some revs of these chips that says eeprom corruption can occur if the supply voltage drops too low. There are 3 'fuse' bits on the chip that setup minimum operating voltages (Brown-Out Detection). Turns out the blinkms do not have these fuses programmed (BOD disabled). The errata suggests setting a BOD threshold to avoid the eeprom bug.
I've now set all my blinkm's high fuse bits to 0xDC (4.1v - 4.5v Brownout detection). I will now have to wait to see if the problem re-occurs.
Hope this helps
-Dave
Feel free to contact me if you need more info (granz@newl.com)
-
Inappropriate?Btw, I found that I needed to set the hfuse value to 0xDD to allow a bit more power leeway. Seems unless I have a really good power supply, there's a bit of droop when several come on at the same time.
-
Inappropriate?Well, I'm back from the client with that blinkm string. I've set the BOD on all of them.. Now its just a matter of time to see if the problem goes away.
While had them hooked up to the programmer, I checked the eeprom contents. On the 3 that failed, location 0 of the eeprom (where the unit number is stored), was set to 0, 89, & 0 repectively. Seems consistent with the idea that eeprom corruption is in fact what's happening. The rest of eeprom seemed to be the correct values. -
Inappropriate?Hi David,
Thanks for doing that research. It matches what I've been thinking that perhaps it was a on-reset EEPROM corruption issue that perhaps the BOD could help with. Unfortunately, all the BlinkMs produced thus far have the BOD disabled (including the shipment we'll be receiving in a few weeks).
If anyone has this problem and they do not have access to a AVR-ISP programmer to reflash their BlinkMs, contact me at blinkm @ thingm.com and we'll arrange to get your BlinkMs reflashed at no charge. -
Inappropriate?No prob. Hope this is the problem. (fingers crossed)
The BOD set to 0xDD seems to be a good setting. The Blinkm won't work correctly when plugged into an arduino board if the BOD is set to 0xDC (4.5v). It keeps resetting. Perhaps even a 0xDE setting would be safer if you are going to pre-program them. -
Inappropriate?Btw, http://www.geocities.jp/arduino_dieci...
works great if you don't have a progammer, but do have an Arduino Diecimila
-
Inappropriate?Latest update: All 14 Blinkms are continuing to work perfectly. All have retained their programming :)
-
Inappropriate?David I owe you a beer or two:
I have a setup with 100 blinkms, and each time I boot it up, some of them pick a random address.
Could you provide some explanation (or links to) what BOD is and how to set it using avrdude? Also, how do you connect the blinkm to the programmer? I couldn't find a convenient way to connect miso and rst (you know, I have to repeat the whole procedure 100 times...)
thanks
I’m thankful
-
Inappropriate?Hi Matteo (and anyone else with this issue),
In the BlinkM-firmware-hex.zip download there is a Makefile with target "make eraseprogram" that sets the fuses, erases the chip, and reprograms the firmware. It should work out-of-the box for an AVR-ISPmkII programmer and avrdude in your path.
If the above doesn't make sense to anyone reading this and you want to fix this issue yourself (instead of emailing us at blinkm at thingm.com to arrange a swap), you need two things: an AVR programmer dongle and software program called "avrdude" to control the dongle. The most common dongle is called the "AVRISP2" and is available for about $34 from Digikey. There's also a $22 easy-to-solder kit called the USBtinyISP.
Probably the easiest way of getting the "avrdude" software up and running is to download the Arduino software for your system and use the "avrdude" that comes with it. It is a command-line program and lives at "arduino-0012/hardware/tools/avr/bin/avrdude" (or whichever version of Arduino you've downloaded, always get the latest)
Once you have both the programmer dongle and "avrdude", you can wire up the programmer to your BlinkM as shown in the BlinkM datasheet, download the BlinkM-firmware-hex.zip bundle linked above, unzip it, and run the following commands:
avrdude -P usb -c avrispmkII -p attiny45 -v -v -e -U lfuse:w:0xE2:m -U hfuse:w:0xDD:m -U efuse:w:0xFE:m
avrdude -P usb -c avrispmkII -p attiny45 -v -v -e -U flash:w:blinkmv1.hex -U eeprom:w:blinkmv1.eep
The first command erases the blinkm and sets the fuses. The second command programs the firmware and eeprom back to the defaults. -
Inappropriate?Thanks Tod :)
Two questions:
Do you *suggest* to reprogram the firmware? I have to repeat that procedure 100 times, I'd save quite a lot time by just setting the fuses
I'm thinking to "play it safe" and use 0xDE (BOD level 1.8v) instead of 0xDD (2.7): being 100 leds on a wire, I think it's more likely to have the voltage run low (is it?). Is this advisable? Any possible side effect?
Thanks -
Inappropriate?You should be able to just change the hfuse and that's it. I tend to do everything ("nuke it from orbit, it's the only way to be sure") :-)
To make adjust the BOD-level by just changing the lfuse, the avrdude line becomes:
avrdude -P usb -c avrispmkII -p attiny45 -v -U hfuse:w:0xDD:m
That sets the BOD to 2.7V. I think for BlinkM going any lower wouldn't be of much use since the lowest voltage the Red LED in BlinkM needs to turn on is around 2.5V (the Blue and Green need around 3.4V & 3.0V respectively) BlinkMs are designed to run at 5V (i.e. the colors are most balanced around that voltage)
The way the BOD works is you want it's detection level to be as high as possible so it triggers (and thus puts the chip in reset) as soon as the chip's power source gets too low. In theory, having no BOD enabled is fine, but as we're seeing with the current run of these ATtiny chips, we want to put the chip in reset as soon as possible to avoid the EEPROM getting scrambled. -
Inappropriate?Has this been fixed?
I don't have the equipment to reflash these, but I'd like to order some for a project. I'm wondering if these still come needing reprogramming or if it's safe to use them as-is? -
Inappropriate?I am also wondering this. Are BlinkM's configured like this by default now? And since the problem isn't technically a firmware change, was the firmware revision number at least increased so that I can check if my MaxM's have correct fuse settings without having to order/build an AVR programmer?
I suspect I'll probably have everything working on the bench and problems in production months later if I dont check this ahead of time. -
Inappropriate?Hi John,
This problem does not affect MaxMs for two reasons: a) the MaxMs all have the brown-out detector (BOD) enabled, b) my understanding is the EEPROM scrambling issue was only a problem on the chip in the BlinkM (ATtiny45) not the one in the MaxM (ATtiny44). -
Inappropriate?And Jason, apologies for not responding to your question from a while ago: this problem has been fixed in all currently shipping BlinkMs. If you think you have a BlinkM that still exhibits this problem, contact us at blinkm at thingm.com and we'll arrange a replacement for you.
EMPLOYEE
EMPLOYEE
