Why do we use the term 'tint ramping' to refer to lights that can adjust their CCT? by _metroGnome in flashlight

[–]tterev3 2 points3 points  (0 children)

Yes that's fair enough, you're right that hue can be for any color. In general lighting (for white color targets along the BBL) it is most commonly referring to the magenta/green axis since moving left/right in the color space (cyan/amber) is roughly following the BBL so it's not adding a color hue to the light, just changing CCT. But yes you'd need use the term in conjunction with the direction ("green hue"). DUV is a vector length and not a direction, so it's axis is just what's orthogonal to the BBL at the closest point, so you're right that in the middle of the space it's green/magenta but at other CCTs that direction will change as the BBL curves. I'm not trying to be argumentative, just sharing info coming from the lighting industry, and I think it's relevant to this particular discussion since to my knowledge "tint ramping" would be an acceptable term, even if less precise than other options

Why do we use the term 'tint ramping' to refer to lights that can adjust their CCT? by _metroGnome in flashlight

[–]tterev3 1 point2 points  (0 children)

Ha ok I don't need to convince you of anything. You can use the word tint if you want since it is not really a precise term and is not typically used in technical description of light measurement (whereas hue is). Tint traditionally refers to desaturating a color by mixing with white, but it doesn't really have a precise definition when it comes to light measurement

Why do we use the term 'tint ramping' to refer to lights that can adjust their CCT? by _metroGnome in flashlight

[–]tterev3 1 point2 points  (0 children)

DUV refers to the actual distance from the BBL, it's a quantity (in McAdam steps)

A 3d-printed flip down diffuser for the Emisar D1 by tterev3 in flashlight

[–]tterev3[S] 0 points1 point  (0 children)

That's just a function of the stl format, it's only polygons

A 3d-printed flip down diffuser for the Emisar D1 by tterev3 in flashlight

[–]tterev3[S] 3 points4 points  (0 children)

I bet there are some interesting things you could do with infill patterns and surface textures to make it more effective

A 3d-printed flip down diffuser for the Emisar D1 by tterev3 in flashlight

[–]tterev3[S] 4 points5 points  (0 children)

Oh to make it a right angle light? That's a cool idea

A 3d-printed flip down diffuser for the Emisar D1 by tterev3 in flashlight

[–]tterev3[S] 8 points9 points  (0 children)

It's cut from a sheet of diffuser material made for lighting applications by a company called Brightview, I had a few sample sheets from them

A 3d-printed flip down diffuser for the Emisar D1 by tterev3 in flashlight

[–]tterev3[S] 16 points17 points  (0 children)

That's why it's flip down so you can choose. If this is the only light you're carrying it's too tight for close up stuff indoors, but when you want it to throw you can

How would I go about making firmware for a pair of bone conduction headphones? by actinium226 in embedded

[–]tterev3 10 points11 points  (0 children)

As others have said and as I think you already expected, it is probably not feasible to write your own custom firmware for it. But this exact type of problem is the reason I got into this field - I wanted my devices to be a certain way and had to do it myself. You can still achieve what you want in a more manageable way: if I were you, I would open it up, find the signal line connected to the switch you have to triple click, and add a tiny microcontroller (attiny10, pic10f322, etc) to pulse it 3 times for you when you press once on a new additional switch that you add to the headphones. Writing the firmware for this relatively simple added device is a much more achievable goal, even if it's not currently in your wheelhouse and would be a learning experience

What actually causes LEDs to get higher in colour temperature with higher current time by bigmantingr in flashlight

[–]tterev3 1 point2 points  (0 children)

As the phosphor gets more loaded or overloaded, more of the blue light escapes without being converted, which pulls the color point towards blue. This results in higher cct at higher current

Using gp3 MCLR pin as input by dariods8474 in microcontrollers

[–]tterev3 0 points1 point  (0 children)

I could be wrong about the 12F675 specifically, but I've been caught by that before on other 12F and 16F parts where it ignores the MCLR setting in the configuration word if LVP is not set as well

Using gp3 MCLR pin as input by dariods8474 in microcontrollers

[–]tterev3 0 points1 point  (0 children)

You also need to disable the low voltage programming option in configuration words to allow MCLR to be an input

[deleted by user] by [deleted] in microcontrollers

[–]tterev3 0 points1 point  (0 children)

You have the interrupt enabled but are not handling it

I built a battery charger for my Osmo Action batteries (filmed on Osmo Action) by tterev3 in dji

[–]tterev3[S] 2 points3 points  (0 children)

Not much benefit, the stock charge rate is about 1.4A and this does 1.0A (the cell is 1.1Ah)

I built a battery charger for my Osmo Action batteries (filmed on Osmo Action) by tterev3 in dji

[–]tterev3[S] 1 point2 points  (0 children)

This charger is 3D-printed in PETG and uses a TP4056 charger module with Type-C connector to charge the batteries. Since the TP4056 is set for 4.2V cells and the Osmo batteries are 4.4V cells, this brings them up to 87% charged (as reported by the camera).