• Driving a 80W LED lamp...

    Jakob Andrén • 07/21/2015 at 20:23 • 0 comments

    So this is what the internal "bulb" looks like:

    It has 148 Neopixels and 12 3W power LEDS, which consumes about 40W each when set on full power! Luckily it will newer be on on full for more than a second or two in a row so I only have to manage those effects as peaks.

    The power LEDs are driven by two FET transistors (at ground) directly on the battery 12V voltage, configured in series of three with two in parallel on each FET and then controlled by a PWM signal from the Teensy.

    The 148 Neopixels proved a lot more tricky, first they will have a calculated peak current of 9A at 5V and they do not like the 12V from the battery. So I had to find a regulator which could buck the voltage down and sustain that current! Well I found one impressive regulator NE12S10A which delivers up to 10A of current at 0.59 -5.1V @ 94% efficiency, perfect! Or... Turns out it is very inefficient at small loads, it draws 80 mA at IDLE and gets very hot also. And I want the cube to turn off the lights when standing still, and it should be able to do that for a long time.

    Solution? LM2574, an easy to build regulator for currents up to 0.5 A. I "programmed" (resistor bridge) it to deliver the 3.3V needed for the Teensy, ESP and MPU instead of using a linear regulator from the 5V source. And then connected the enable pin from the NE12S10A to the Teensy so that I dynamically may turn it on and of when needed. It powers up to 90% of full power in 3ms which is more than enough for me.

    All solved? Nope, the NeoPixels didn't turn on... Well missed the part about signal strength for the first Din. Oh well, it needs 70% of Vin which equals to 3.5 V, close but not enough. the recommended solution out there on forums seems to be logic level shifters, but I didn't have one on hand and wanted it to work. It struck me that I could lower the Vin as well, 3.3V is 70% of 4.7 V, so I tried that and it worked like a charm! Actually I changed the voltage dynamically with a potentiometer and could see that there was no real difference in the light, so I settled on 4.5 V as Vin, same power and stable signal!

    Summary:
    3.3V max 0.5A, micros
    4.5V max 10A Neopixels, only on when needed

    This is what it looks like mounted inside the bulb, pretty stuffed.

  • ESPduino or Neopixels memory leak?

    Jakob Andrén • 07/19/2015 at 23:21 • 1 comment

    So after several days trying diffrenet approaches for communication beetween server and ESP8266 we finally got the last bit working on the project (have some back logging to do here at hackaday.io), MQTT over a ESP8266 to a Teensy 3.1. The resulting speed is quite remarkable:

    Small edit: is anyone able to see the video?

    But it didn't work when I tried to combine it with my earlier MPU6050 and Neopixel code... Im now down to a mix of only ESPduino example code for a MQTT client (https://github.com/tuanpmt/espduino) and the Neopixel library from Adafruit. And from what I can see I have a memory problem and I had liked to get your input on that. So some examples:

    First serial output from a fully functional run, only about 20 pixels here, last is the data received which changes the output colour:

    �KNӒ��ے�mode : sta(18:fe:34:a0:f1:eb)
add if0
�=����)��b�ARDUINO: setup mqtt client
ARDUINO: setup mqtt lwt
ARDUINO: setup wifi
ARDUINO: system started
scandone
add 0
aid 5
pm open phy2,type:2 0 0
cnt 

connected with #SSID#, channel 7
dhcp client start...
ip:192.168.1.103,mask:255.255.255.0,gw:192.168.1.1
WIFI CONNECTED
Connected
Received: topic=cube
data=01028028000150015020

    And a faulty run that isn't able to connect to the MQTT server, get this or just nothing after "Arduino: system started" when rising the number of pixels. I guess that the ESP get the same gibberish and thats whats messes it up:

    Ӓ��ے�mode : sta(18:fe:34:a0:f1:eb)
add if0
����=����b�ARDUINO: setup mqtt client
ARDUINO: setup mqtt lwt
ARDUINO: setup wifi
ARDUINO: system started
scandone
add 0
aid 5
 open ph,type:2 
cnt 
connectewith [Incorrect SSID]channel 
dhcp clnt start.
ip:192.168.103,mask:5.255.250,gw:1928.1.1
ARDUINO: Invalid CRC

    So first thing that is visible is the missing characters in the serial communication, which what I could find is a sign of out of memory. But I run a Teensy 3.1 and both codes are supposed to work on Arduino Uno, I have done tests with the Neopixel library successfully on Uno, so it suprices me that it stops working after adding just about 80 pixels more. About 240 bytes of the 64 kbytes that the Teensy 3.1 has. The Teensy LC, which has 8 kbytes of RAM, also works if I reduce the number of LEDs down to 5.

    Does anyone have any ideas about a more exakt reason or solution to this?

    EDIT: It works together with FastLED, hmm. But FastLED is approx 5 times slower than the Adafruit library so I had prefered to have Adafruit up and running.

    #include <Adafruit_NeoPixel.h>
#include <espduino.h>
#include <mqtt.h>

#define NEO_PIN           6
#define NEO_NUM           20

ESP esp(&Serial2, &Serial, 15);  // CHpd port
MQTT mqtt(&esp);
boolean wifiConnected = false;

Adafruit_NeoPixel strip = Adafruit_NeoPixel(NEO_NUM, NEO_PIN, NEO_GRB + NEO_KHZ800);
uint32_t c = strip.Color(0,0,0); // Start with black


void setup() {
  strip.begin();
  strip.show();
  
  pinMode(16, OUTPUT);    // Turn on the Neopixel voltageregulator
  digitalWrite(16, HIGH);
  
  Serial2.begin(19200);
  Serial.begin(115200);
  //while(!Serial);

  esp.enable();
  delay(500);
  esp.reset();
  delay(500);
  while (!esp.ready());

  Serial.println(F("ARDUINO: setup mqtt client"));

  // Begin MQTT - settings in string, from example
  if (!mqtt.begin("DVES_duino", "admin", "Isb_C4OGD4c3", 120, 1)) {
    
    Serial.println(F("ARDUINO: fail to setup mqtt"));
    while (1);
    }


  Serial.println(F("ARDUINO: setup mqtt lwt"));
  mqtt.lwt("/lwt", "offline", 0, 0); //or mqtt.lwt("/lwt", "offline");

  /*setup mqtt events */
  mqtt.connectedCb.attach(&mqttConnected);
  mqtt.disconnectedCb.attach(&mqttDisconnected);
  mqtt.publishedCb.attach(&mqttPublished);
  mqtt.dataCb.attach(&mqttData);

  /*setup wifi*/
  Serial.println(F("ARDUINO: setup wifi"));
  esp.wifiCb.attach(&wifiCb);

  esp.wifiConnect("#SSID#", "###");

  Serial.println(F("ARDUINO: system started"));
}
//...
    Read more »

  • NeoPixel speed

    Jakob Andrén • 07/17/2015 at 10:29 • 0 comments

    So I want the absolute highest possible refresh rate on this project because that means I do not have to filter the results as much and therefor are able to let it have a funny pulse flashing behavior with quick moves.

    First a short note on the MPU6050 sensor, it transmitted the raw acc and gyro values in ~1700 us both on the UNO and Teensy, but I have reduced that time to ~300 us by rising the I2C rate from 100 kHz to 800 kHz with the help of the Teensy specific i2c_t3 library. It was actually possible to pull up the speed even more but the sensor is only specified for 400 kHz, and I prefer some stability and time savings wasn't as large after that point.

    So lets talk about the pixels now, with some unprofessionally measured speeds for the show() or equivalent method, like this:

        t = micros();
    pixels.show();
    Serial.println(micros()-t);
    MicroLibraryUpdate 150 LEDs
    Arduino UNO (16 MHz)Adafruit_NeoPixel446 us every 2nd 1472 us
    Arduino UNO (16 MHz)SimpleNeoPixelDemo960 us every 10th 1980 us
    Teensy LC (48 MHz)Adafruit_NeoPixel490 us every 2nd 1490 us
    Teensy 3.1 (96 MHz)FastLED4700 us
    Teensy 3.1 (96 MHz)Adafruit_NeoPixel856 us every 6/7th 1857 us

    So what really surprised me was the FastLED performance which was a lot worse than the others, despite what I read before trying it out. Do note that this doesn't include the efficient math routines that FastLED apparently has. In my case that doesn't matter, all my pixels have the same color and I only do a simple HSL conversion for finding the Hue in the accelerometer values, constant saturation, and gyro values for Luminance.

    Funny thing is that it seams the UNO actually is faster than the Teensys when it comes the raw updating of the LEDs. Count in the sensor readings, color conversion and I hope soon Twitter notifications and the Teensy will be worth it, or should I just have developed it around the ESP8266 with braked out pins? (I will say no on this because, Im now able to reset the ESP and when necessary without affecting the motion based lightning). Websockets and MQTT proved a lot more difficult to get working than I suspected, been trying out several now and all of them have had their quirks so far..

  • Hello light!

    Jakob Andrén • 07/13/2015 at 22:33 • 0 comments

    Well I got the LEDs inside, looks good so far. The biggest problem so far is the power consumptions which is pretty high. I am expeting as much as 9A at 5V when all are put on full white only from the WS2812B LEDs, count another ~6A at 12V for the Power LEDs for short bursts...