BeagleBone RED

That's nice! I was going for  green or yellow (since I already had them) but I aborted when I saw the resistors. I may go ahead, since you got good results without replacing them.

By the way, how did you stop the program that flashes the user LEDs seemingly randomly? (I guess this must be obvious, but I couldn't find it : )

I was trying to use the LEDs for another purpose but I couldn't see in the usual places (rc3.d etc) where that default  resides.

shabaz wrote:

By the way, how did you stop the program that flashes the user LEDs seemingly randomly? (I guess this must be obvious, but I couldn't find it : )

Well it is, and isn't, obvious. It's not really a program that flashes the leds, it's the kernel.  There was a file called /etc/default/leds and some systemd nonesense, but killing those doesn't actually help.

Look in your device tree source files and you'll find the actual built-in defaults. So you can change the dtb to do something else and it'll stay that way until you upgrade.

See post 109 of http://www.element14.com/community/message/75911#75911/l/re-have-a-question-about-the-next-gen-beaglebone-ask-it-here for how I modded the device tree defaults

After the system's booted you can change the value of /sys/class/leds/beaglebone:green:usr[0-3]/trigger  and no, no idea why the name has green in there. I'd have just used use[0-3] and missed out the whole beaglebone:green: bit altogether

So to take the photo I just set them all to default-on with echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I didn't look in depth at the options yet, but one of them is gpio and I'm hoping that lets you effectively disable the led-class driver and control the led yourself, if not it'll either be back to trying to disable it in device tree or a recompile to make the driver a module

I may go ahead, since you got good results without replacing them.

the ones I used are only 15mcd and supposedly have a diffused lens, although it's hard to be sure when they are so small. It does seem to make a difference compared to the usually clear lensed blue ones though.

Lead free solder, tiny device, very close together certainly makes it tricky to swap them. I didn't quite have to reach for the hot air tools and tweezers, but close..

shabaz wrote:

By the way, how did you stop the program that flashes the user LEDs seemingly randomly? (I guess this must be obvious, but I couldn't find it : )

Well it is, and isn't, obvious. It's not really a program that flashes the leds, it's the kernel.  There was a file called /etc/default/leds and some systemd nonesense, but killing those doesn't actually help.

Look in your device tree source files and you'll find the actual built-in defaults. So you can change the dtb to do something else and it'll stay that way until you upgrade.

See post 109 of http://www.element14.com/community/message/75911#75911/l/re-have-a-question-about-the-next-gen-beaglebone-ask-it-here for how I modded the device tree defaults

After the system's booted you can change the value of /sys/class/leds/beaglebone:green:usr[0-3]/trigger  and no, no idea why the name has green in there. I'd have just used use[0-3] and missed out the whole beaglebone:green: bit altogether

So to take the photo I just set them all to default-on with echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I didn't look in depth at the options yet, but one of them is gpio and I'm hoping that lets you effectively disable the led-class driver and control the led yourself, if not it'll either be back to trying to disable it in device tree or a recompile to make the driver a module

I may go ahead, since you got good results without replacing them.

the ones I used are only 15mcd and supposedly have a diffused lens, although it's hard to be sure when they are so small. It does seem to make a difference compared to the usually clear lensed blue ones though.

Lead free solder, tiny device, very close together certainly makes it tricky to swap them. I didn't quite have to reach for the hot air tools and tweezers, but close..

Thanks, that's really helpful. I'd missed seeing that bunch of posts.

I've been working with the device tree again last night for another purpose, and I am amazed at the complexity. Makes sense for a cape ecosystem, but not so easy for those that want to directly use the pins. The aim was to get the modes changed on some pins, and I am currently trying to create a separate dtbo that will get loaded from the main dtb.

I have fairly thin solder (26swg) which is ok-ish on 0603 but I do need to go thinner.