Bugzilla – Bug 7568
Purple light when Receiver is paused
Last modified: 2009-09-08 09:11:30 UTC
Examining some of the retail units, I noticed that the color of the LED is a lavender to light purple when on (paused) and connected, instead of a dim white. When the receiver is playing a track, it is a nice bright white. 1 sample unit has been sent to Felix for him to examine.
I did some comparison between a SBR with 'good' LED and the one showing a purplish dark white. I disassembled the unit and it's not the plastic button nor the light pipe making it purplish. To me it looks like the red part of the tricolor LED has a slightly larger area causing the purplish dark white. I even think you see the effect on bright white too. Playing with the TricolorLED plugin I can make the 'bad' LED nice white by reducing the red part, but that would also change the color on 'good' LEDs. The values for dark white are currently, red: 0x20, green: 0x20, blue: 0x20. If I reduce red to 0x10 the purplish goes away. I have no idea right now how to solve this in firmware as there is no feedback about the resulting color. I guess we need to find a way to verify if the LED is ok before mounting it.
Rico will be testing the units electrically to see if they are using the same amount of current on R, G & B. Any news on this, Rico?
Created attachment 3165 [details] visual of purpleness The receiver James handed to me to look at is on the bottom in this picture - 16:11:0A. It looks white in the picture but looks slightly pinkish to me. The top receiver is a PQP2 (I believe - 16:01:1D) receiver which came back undeliverable and looks gray to me but more purple in the picture. the current coming into D15 for each: Q2(g) Q3(r) Q4(b) 16:01:1D 4.44mA 4.36mA 4.35mA 16:11:0A 4.425mA 4.37mA 4.38mA Should these small differences have such an impact on the color?
The image you posted looks like the Ray was playing content? The error is reported as Ray being in a Paused state. Come to my desk, and I'll give you another unit (or two) to test.
Yes, I did not make sure Ray was paused, good thing I took the picture then. So there were no meaningful differences on the amps going in but it looks like there is a difference of about a quarter volt dc going in from Q2 as compared to the pqp2 receiver whose paused color looks closer to what we are expecting to see. All four receivers James gave me were the same shade purple on pause, as well as three others I found and surveyed. The schematic has red associated with Q2 and green with Q3 but when Q2 was disconnected the green DHCP acquisition state came up blank, also when Q3 was disconnected the initial red bootup state was not visible. Q2 Q3 Q4 16:11:0A 5.24 Vdc 6.00 Vdc 5.13 Vdc 16:12:59 5.17 Vdc 5.94 Vdc 5.11 Vdc 16:14:EA 5.15 Vdc 5.88 Vdc 5.03 Vdc 16:0D:61 5.21 Vdc 5.90 Vdc 5.08 Vdc 16:01:1D 4.98 Vdc 5.92 Vdc 5.08 Vdc So the assumption is that all production receivers are behaving with the purple light on paused state..? mflint saw it change from purple to white and back: http://forums.slimdevices.com/showthread.php?t=44779 It might be a good idea to see if we can get him to send that one back to us if he can reproduce that and he's sure it wasn't changing because he started playing music or something. Otherwise somebody needs to provide me with one that behaves as expected.
I've finally successfully transplanted a tricolor LED part from an older board onto a previously purplish appearing receiver. The paused color is now cool white, so the issue is with the part itself, not any of the rest of the circuit.
I spoke to Rico and he's going to work with diane to see if we can get binned parts that are more predictable for future builds.
- 080320-001913 - Jive r2097 / Ray r22 Duet connects and plays properly. However, the Ray is a Bright Purple when playing and a Dark Purple when paused/off. Forwarding unit to Rico for investigation.
I've been fiddling with the Tricolor LED plugin, trying to get finer control of the intensities to each color. I started by editing the color_list.html and setup_index.html to add in options less than 0x10, but any time I try to select one the color just goes off. I've also tried adding 0x18 halfway but when I select it the same brightness as 0x10 comes out. After finding me staring at the plugin code Caleb suggested I use Wireshark to see whether SqueezeCenter is passing along the modified values to the client as expected which appears to be the case (0038-003f): 0000 00 04 20 16 11 29 00 90 27 44 cd a5 08 00 45 00 .. ..).. 'D....E. 0010 00 38 da bf 40 00 80 06 0a bd 0a 00 00 de 0a 00 .8..@... ........ 0020 00 66 0d 9b 51 57 0a c5 62 e5 98 f0 f1 8f 50 18 .f..QW.. b.....P. 0030 fd 89 59 d4 00 00 00 0e 6c 65 64 63 00 18 10 10 ..Y..... ledc.... 0040 00 00 00 ff 0a 00 ...... Can anyone shed some light as to why the last half a byte for each color is ignored?
It's an oversight in current SBR firmware. The lower nibble gets cut of. Sorry about that. Fixed in rev 4138.
So far this procedure works well for calibrating several units I've been testing: Using sensors I have individually calibrated to our golden target, set each of RGB individually to maximum intensity and record the respective outputs, maybe get an average of the last 5-10 records. ff0000: Rmax .. .. 00ff00: .. Gmax .. 0000ff: .. .. Bmax The lowest of these 3 values will be used to calculate the intensity matching factor. (= 255/(lowest(Rmax,Gmax,Bmax)) Then this factor will be used to calculate each offset. Roffset= 255 - (255^2)/(Rmax*Intensity) Goffset= 255 - (255^2)/(Gmax*Intensity) Boffset= 255 - (255^2)/(Bmax*Intensity) These resultant values are flashed to nvram as permanent offsets to use when calculating colors. so if we want to define dark white to be 0x404040 and the correction offset is 0x70003c, then we should get 0x234030 to see the expected dark white color (drop remainder) The advantage is that the intensities are relative to the current player under test, and any inconsistencies in the fixture or sensor should be minimized as long as the test fixture is not disturbed between readings.
Sound ok to me, but I have difficulties following your example. Correction factor saved in snvram is: 0x70003c We want dark white, which is defined as: 0x404040 But that needs to be corrected to actually be: 0x234030 So, how do I get from 0x404040 to 0x234030 applying 0x70003c? I guess it's something obvious, but I can't see it. :(
Right, sorry. For some reason I'm stuck on calculating the offset value but obviously the complement is more useful for doing math. If the correction value is large like in this case almost half the red value needs to be corrected, we don't want to simply do a subtraction otherwise we lose effective range so the correction should be applied proportionally. The intensities' response are very linear so this should be OK. If we have offset 0x70003c, then our intended maximum value is the complement 0x8fffc3. 0x404040 is approximately 25% of the range 0xffffff. So to get 0x234030 we take 25% of 0x8fffc3 and drop any remainder. Instead of R,G&B offset values the maximum (complement) values are: Rmax= (255^2)/(Rsensed*Intensity) Gmax= (255^2)/(Gsensed*Intensity) Bmax= (255^2)/(Bsensed*Intensity)
Which firmware / SC Build will have these fixes in them so we can test?
Do you mean the fix that does not cut off the lower nibble (Comment #10) or the complete factory test procedure to set the correction factor and write it to snvram? The changes for the former are checked in, so it will be in the next SBR firmware and for the later we need to agree on a sequence how it will be used in the factory. I suggest the following: 1. Unit is put into factory test mode (using fac.pl) 2. Led is turned off (using fac.pl) 3. Color measurement is calibarated 4. Led is set to red (using fac.pl) 5. Red is measured 6. Repeat 4 and 5 for other colors 7. Correction factor is calculated 8. Correction factor is set (temporarily in fw using fac.pl) 9. Repeat 4 and 5 for all colors to verify (fw applies correction factor) 10. If ok, correction factor is written to snvram (together with MAC and UUID) 11. Reset (using fac.pl)
There are still factory/procedure issues, but as far as the firmware is concerned this is fixed.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.