Thursday, October 17, 2019

RGB Fairy Lights with only 2 wires (part the first)

I am a huge fan of all things blinky and light up. I’m less interested in things I cannot control remotely by writing a plugin for XTension or by building a new controller for it. While looking for RGB “fairy” lights on Amazon (“fairy” lights here being defined as some strands of what looks like magnet wire with surface mount LED’s soldered between then and then sealed into a little blob of epoxy) I came across these RGB ones and was intrigued since they appeared to have only 2 wires. There was no control wire or separate PWM lines for the RGB channels. (Amazon Link) These are by “Yihong” but there may be others that are the same.

They came with an RF remote which is nicer than the IR ones that some similar things come with. Since you don’t have to point it at the controller box. Interestingly enough the remote also has an IR led and so could be used by either type of system. I have not tested to see if it is running on the standard 433mhz band or does something special. Given that it appears the same as the thousand other such remotes I’ve gotten over the years for other LED displays or just for remote arduino projects I would guess that it does.
In spite of the picture on the box showing different colors on the strand at the same time, you cannot control the LED’s individually, only as a whole strand.

This is the very tiny control box. The strand is powered from a USB plug and this box does the work of receiving the remote signals and adding whatever data is necessary to the power lines going down the strand. I have not broken the case open yet to see whats in there.

While there is tons of information out there about the “neopixel” type LED’s and the newer “dot star” that Adafruit sells and are amazingly wonderful there is very little information about anything similar to this. If anybody knows the type of chip or LED that they are made from I’d be interested to hear about it.

This you tube episode from Julian Ilett shows him reverse engineering a similar protocol. The system used by my lights looks to be very different however. So the first step to seeing what it’s doing is to get it on the scope. Since the wires are just enameled I scraped some of the insulation off them at the end of the strip. It occurs to me that I might have gotten a cleaner signal by tapping it at the front of the string instead. I’ll try that in step 2 and see if it makes it easier for the scope to trigger on it.

These LED’s are different than Julians as they don’t pulse all the way to off. The data pulses drop the voltage to the lights down to 1.5 volts, but not all the way to off. This potentially makes sense as it would let the little processor in the LED chip continue to operate as it’s being updated.

Here you can see the amazingly noisy USB power supply, either from the hub I was using to power this or from the controller device itself I don’t know, but it didn’t seem to bother them. You can also see the tiny blips of the control pulses coming in every 100ms or so. 

Zoomed in on those a bit you can start to see the data.

There are 2 lengths of pulses. Since the on portion of the pulse is always the same length the entire duration of the data packet changes based on how many 1’s there are in it.

The short pulses, which I will call a binary 0, are approximately 5us with the bus at 1.5v and then 10us back at 5v. The actual measurements I got from the scope was 6us and 12us but they varied enough that I assume they meant to use 5 and 10us. That may have to be adjusted later if the device is very picky about the timing. The 1 binary pulse is 10us at 1.5v and 10us at 5v.

Every data packet starts with 8 “0” or short timing bits. These do not appear to change no matter what the string is displaying so I will assume they are a preamble that helps the receiver lock into the data rate. In the screen shot above you can also see the end pulse which is twice the length of the “long” or binary 1 pulse, 20us at 1.5v. 

There are 32 bits in total, one byte for the preamble and 3 more bytes which obviously encode the RGB values that the LED should display. I did several captures from the various solid colors the three different intensity levels, leaving out the preamble byte: I’ve added the decimal value of the binary next to them:

RED:   FULL:  0010 0110(38)  0000 0000     0000 0000
       MED:   0100 1100(76)  0000 0000     0000 0000
       LOW:   1001 1000(152) 0000 0000     0000 0000

GREEN: FULL:  0000 0000      0010 0110(38)  0000 0000
       MED:   0000 0000      0100 1100(76)  0000 0000
       LOW:   0000 0000      1001 1000(152) 0000 0000

BLUE:  FULL:  0000 0000      0000 0000      0010 0110(38)
       MED:   0000 0000      0000 0000      0100 1100(76)
       LOW:   0000 0000      0000 0000      1001 1000(152)

Its quite obvious already that the 3 bytes are RGB values. You can also see that even when on at full they dont send just an FF. Perhaps the LEDs would overheat at full on. There is some visible PWM even when a solid color is set to full on. Or there is a limit in the controller device itself that is not capable of 255 individual levels. They are rotating that bit pattern across for dimming the LED. At this point Im thinking that the value is actually how long to wait into the PWM cycle before turning on that LED. That would make sense, it would let a larger number actually be a dimmer display. Just for fun sampled some of the other colors as well:

ORANGE: FULL:  0011 0001(49)  0101 0000(80)  0000 0000
        MED:   0110 0010(98)  1010 0000(160) 0000 0000
        LOW:   1100 0100(196) 0100 0100(68)  0000 0000

YELLOW: FULL:  0010 0110(38)  0100 1100(76)  0000 0000
        MED:   0100 1100(76)  1001 1000(152) 0000 0000
        LOW:   1001 1000(152) 0011 0000(48)  0000 0000

CYAN:   FULL:  0000 0000      1101 0010(210) 1101 0010(210)
        MED:   0000 0000      1010 0100(164) 1010 0100(164)
        LOW:   0000 0000      0100 1000(72)  0100 1000(72)

and now Im wishing I hadnt sampled those extra colors as they dont seem to follow the same start point of PWM. Or perhaps they are just compensating for irregularities in how much the LEDs output at any given level. They wont be the same certainly, generally red needs a much higher value than green and blue to look the same. 

In any case there is enough information here to get started trying to build an Arduino controller for the thing. I’m not entirely sure how to provide the 1.5v pulse level in hardware. Will it be enough to just run the stream power supply through a resistor? Will have to calculate the power draw of the LED’s and do the math to drop the voltage to that level. Or are the LED’s in sync with this pulse and so will be off when the data starts and therefore I’ll need a different value since the load would be less. Or will it be necessary to provide a 1.5v regulator and use a transistor or mosfet to bypass it when the strip should be given the full voltage. Some experimentation will be necessary. When I’ve had a chance to play with that I’ll post again.

Tuesday, May 7, 2019

WiFi Signal Strength as presence indicator, part 2

As a followup to yesterdays post about trying to filter the wifi RSSI of an ESP8266 board in order to sense movement I added a standard variance calculation on the last 2 minutes or samples or so. I added a threshold of 1 just for testing and have let it sit here for a while. The graph of that output looks like this:

When the variance goes above 1, or whatever preset threshold, I turn on the presence register which shows in green. You can see that it definitely does work to know when I’m coming and going, but at this sample rate, buffer size and threshold it also comes on randomly with non-people moving through the room wifi interference.

In order to register anything reasonable at all you have to have the device very close to the person you want to know if they are there. This may be of use for this particular application as I plan to have the device sitting on my desk to provide some display of info for me while sitting here. It might even be able to blank and wake up it’s own display based on that. That would be useful and fun. Unfortunately if I sit very still it eventually thinks I’ve gone away. It’s decided that while I’ve been typing this paragraph actually. Lost of tweaking of settings would be necessary to make it at all useful.

I’m not sure that it will ever be useful as a generic motion sensor. You just have to be too close to the device to get it to see enough variance in the signal. Still an interesting experiment and I will keep fiddling with it to see if something useful can be done with it. It’s also possible that with the newer ESP32’s or other devices you could get better resolution or even access to things like the path being used to send the info or other similar data that would let you do a much better job. But for something that wakes up when you walk up to it and then goes to sleep shortly after nobody is standing next to it this could potentially be used.

Calculating a variance is a standard statistical technique so that you can gauge if you’ve got enough data points to realistically represent what you’re looking for among other thing. The formula is:

S2 = ∑(xi - x̄)2 / (n-1)

Which translates to the Variance squared being equal to the sum of each value in the dataset minus the average of the dataset squared and then divided by the number of points in the dataset minus one. So the first thing you need is an average of the dataset.  It’s slightly complicated by the fact that my buffer array of read RSSI values may contain 0’s or values that are not a valid RSSI. As I place the values into the buffer I am making them all positive as I am not worrying about the actual db value, only the variance of the data. So the first thing you need to do is to call the scanRSSI function every second. To do this you need to compare millis() with the calculated next time you want to do something inside the loop. You can’t just compare simple unsigned longs as are returned from millis() as they will overflow back to 0 at some point which will break everything. So you can do the clever trick of casting it to a long and then subtracting it later which will yield the proper result of timing even during an overflow condition.

#define MAX_RSSI_ARRAY 128
bool currentPresence = false;
byte rssiArray[MAX_RSSI_ARRAY];
byte rssiIndex = 0; // the index into the array where we are now
unsigned long nextPresenceScan = ((long)(millis() + 5000)); // 5 second start

the code above sets up the buffer array as bytes, since the numbers will never be more than 255 there is no reason to waste memory by using 2 byte ints or anything else. We also need an index into the array so we know where to save the next value and the nextPresenceScan value which is where the trick comes in. Casting the value of millis() + 5000 as a long integer and then putting it into an unsigned long variable we get around the overflow problem as far as the comparisons later are concerned. Very clever and described in great detail on the Arduino website if you’re interested.

Next we need some code to run inside the loop() to check the time and call us when it’s time to run. Something like:

void loop( void){
 if (((long)(millis() - nextPresenceScan)) >= 0){
  nextPresenceScan = ((long)(millis() + 1000));

Same trick as before, sets up the nextPresenceScan and then calls the function to do the work.

void scanRSSI(){

 float currentRSSI = WiFi.RSSI();
 if (currentRSSI > 0){
  // sometimes the WiFi.RSSI() call can return a number greater than 0 to indicate
  // an error or that it simply couldn't get the info at this time. If that happens
  // just ignore it.

 // add the new value into our buffer at the current rssi buffer index
 // multiply by -1 to turn it into a positive number
 rssiArray[ rssiIndex++] = currentRSSI * -1;
 // if the index is now beyond the size of our buffer reset it back to
 // the beginning of the buffer for the next read
 if (rssiIndex >= MAX_RSSI_ARRAY){ rssiIndex = 0; }
 // first value we need for the variance calculation is the average
 float accumulator = 0;
 // since the buffer may not be filled with valid data yet 
 // we need to count how many non-zero values there are for the
 // average calculation rather than just divide it by the 
 int averageCounter = 0;
 float average = 0;
 for (int i=0; i<MAX_RSSI_ARRAY; i++){
  // ignore values of 0
  if (rssiArray[ i] > 0){
   if (rssiArray[ i] < mn){ mn = rssiArray[i];}
   accumulator += rssiArray[ i];
 // if we don't have at least 10 valid values in the array then just drop out
 // there is no point in calculating the rest unless we have enough values to 
 // look at
 if (averageCounter < 10){ return; }
 average = accumulator / averageCounter;

 // now loop again to calculate the SUM portion of the variance
 // reuse the accumulator 
 accumulator = 0;
 // loop through the buffer array again, this time subtracting the average and then
 // squaring the result adding it to the accumulator
 for (int i=0; i<MAX_RSSI_ARRAY; i++){
  if (rssiArray[ i] > 0){
   // dont want to waste the memory to include the floating point or C math
   // libraries, so just put the calculated value into a local variable and
   // multiply that by itself
   float work = (rssiArray[i] - average);
   accumulator += work * work;

 // here we divide by n-1 
 float variance = (accumulator / (averageCounter - 1));
 // the variance may be less than 0? if so take absolute value
 if (variance < 0.0){ variance *= -1; }
 // now do something clever with the variance data.


That is actually pretty horrible code. I also do realize that I’m never taking the square root of the variance as calculated. That doesn’t seem necessary at this point and the poor arduino is already working hard with all those floats. If I make the value even smaller it will be harder to watch whats happening. It’s also not memory compact as it needs a full buffer. I’m sure some other kind of rolling average could be used. To get anything useful you’ll have to adjust the threshold and the scanning frequency and probably a lot of other stuff too. An interesting starting point to something potentially useful.

The device in question here is sending it’s values back to XTension for graphing and potential use. The graph above was generated by that program. XTension: Home Automation for the Mac, is my day job.

Sunday, May 5, 2019

Using wifi signal strength as a motion or presence indication

It seems like it should be possible to use wifi RSSI as a presence or motion detector. I have seen some very fancy devices that made low level use of the reflection information to target motion or people in a room, but the graph below is from an ESP8266 just reporting it’s RSSI every 5 seconds.

The device is sitting on my desk just a couple of feet away, so the range might not be very good, but still there might be instances where this is useful. You can quite plainly see in the above graph that I was in the office on and off until just after 7, and then it is fairly smooth while I was attending the local Philharmonic concert to hear my wife sing Mahler’s 2nd, and then picks up in variability as soon as I started going in and out of here this morning.

A lot of hysteresis would be necessary since there are many things that can affect the signal strength. Since it would take some time to know that you were there for sure it might not be useful to turn on lights or make adjustments when you arrive, but it could definitely be used to figure out when you’ve gone. Adding a Wifi calculated presence detection to such IOT devices would be very helpful. It would not work very well for battery operated devices however since you would need to wake up the wifi radios far more often than for the regular functions of the device.

Part two of this thought has code examples and is here.

Wednesday, February 6, 2019

Fancy Crown Molding for New Bookshelves...

The living room in this house has been something we planned to remodel completely since before the day we moved in. All the standard white enamel cabinets and shelves that come with these houses were going to get thrown out and replaced with wonderful floor to ceiling book shelves and a library ladder and all sorts of wonderful things.

I haven’t written about this yet because even so many years later it’s still not quite finished. We’re getting closer though. I just wanted to share this piece of test molding I made, oh, a little more than a year ago now, that serves as the template for the rest of it as I slowly completed the work. More info will follow as it’s even closer to being done now.

I’ve always been a bit intimidated by fancy crown molding. I didn’t know how to design it or make it work or make it go around the things that were there. This project has forced me to come to terms with some of that.

Here is my test piece for the multi-part crown molding that will go around the top of the new bookshelves. I’m so happy with the way it turned out I can’t even tell you. It even looks great in the finished product that I’ll upload another article about shortly :)

It’s all commercially available molding from the local Home Depot or Lowes. I tend to buy molding from Lowes because they sell it in 6 and 8 foot sections where at Home Depot I need to know how much I need ahead of time and cut it from a 10 foot segment that will by no means in the known universe fit into my car. I could probably save a few bucks by figuring that all out. But it makes too much work ahead of time. I can just calculate how many 8 foot sections I need and add one more to fill in the gaps :)
.code { background:#f5f8fa; background-repeat:no-repeat; border: solid #5C7B90; border-width: 1px 1px 1px 20px; color: #000000; font: 13px 'Courier New', Courier, monospace; line-height: 16px; margin: 10px 0 10px 10px; max-height: 200px; min-height: 16px; overflow: auto; padding: 28px 10px 10px; width: 90%; } .code:hover { background-repeat:no-repeat; }