Building another (better) PiCam security camera

I blogged briefly about building a security camera back in a previous post. It worked so well I decided to build another, but with a few improvements based on past experience…

I used this WiFi adapter (from Aazon): TRENDnet Wireless N 150 Mbps Mini USB 2.0 Adapter, TEW-649UB.  It’s supported out-of-the box by th OS, PLUS, you can easily pop open the housing and their a standard (tiny) wifi antenna connector on the circuit board. This let by connect a full, external antenna I had from dismantling and old router or something.

I followed this original Instuctable up to step 6:
Instead of Motion, I use VLC to stream the video.
I created two scripts in my /home/pi directory…
start-vlc.sh:
#! /bin/sh
sudo raspivid -o – -t 0 -n -w 800 -h 480 -fps 6 | cvlc -vvv stream:///dev/stdin –sout ‘#rtp{sdp=rtsp://:8160/}’ :demux=h264 :h264-fps=6 2>&1 | tee /var/log/vlc.log &
 
restart-vlc.sh:
#! /bin/sh
echo “$(date) – stopping vlc” >> /var/log/vlcstart.log
sudo ps -ef | grep -e ‘vlc \-I’ | grep -v grep | awk ‘{print $2}’ | xargs -i kill {} 2&>/dev/null || echo “vlc-streamer already stopped”
sleep 3
sudo raspivid -o – -t 0 -n -w 800 -h 480 -fps 6| cvlc -vvv stream:///dev/stdin –sout ‘#rtp{sdp=rtsp://:8160/}’ :demux=h264 :h264-fps=6 > /var/log/vlc.log 2>&1 &
 
I changed the run permissions on both files:
chmod 755 start-vlc.sh
chmod 755 restart-vlc.sh
Both scripts start the VLC streamer streaming H.264 800×400 video over RTSP at about 6 frames per second. That can all be changed, for example, you could use a different encoding..there are many examples for using different options on the internets. RTDP is fast, but be aware that one downside is that it is over UDP only, so doesn’t work if you want to stream outside your firewall.  I found I can easily go faster on the frames per second – just make sure to change both the “-fps n” and “:h264-fps=n” parameters to match. When I tried larger frame sizes though (liek 1024×768), I kept seeing it start to rebuffer. It would continue to do that, each time takin glonger and longer until it became unworkable…not sure exactly what was going on there, but 800×480 doesn’t do it, so I went with that.
I created a script in named vlc-streamer in /etc/init.d for starting and stopping the streamer as a service:
#! /bin/sh
# /etc/init.d/vlc-streamer
 
# Carry out specific functions when asked to by the system
case “$1” in
  start)
    echo “Starting vlc”
    # run application you want to start
    echo “$(date) – starting vlc” >> /var/log/vlcstart.log
    sudo -u pi /home/pi/start-vlc.sh &> /var/log/vlc.log
    ;;
  stop)
    echo “Stopping vlc”
    # kill application you want to stop
    echo “$(date) – stopping vlc” >> /var/log/vlcstart.log
    sudo ps -ef | grep -e ‘vlc \-I’ | grep -v grep | awk ‘{print $2}’ | xargs kill -9
    ;;
 
  restart)
    echo “Stopping vlc”
    echo “$(date) – stopping vlc” >> /var/log/vlcstart.log
    sudo ps -ef | grep -e ‘vlc \-I’ | grep -v grep | awk ‘{print $2}’ | xargs -i kill {} 2&>/dev/null || echo “vlc-streamer already stopped”
sleep 3
    echo “Starting vlc”
    echo “$(date) – starting vlc” >> /var/log/vlcstart.log
    sudo -u pi /home/pi/start-vlc.sh &> /var/log/vlc.log
    ;;
  *)
    echo “Usage: /etc/init.d/vlc {start|stop}”
    exit 1
    ;;
esac
exit 0

And finally, I added the startup to /etc/rc.local so that the service will start up automatically when the system starts:

# Start camera streaming
service vlc-streamer start
I set up the camera in iSpy using a custom profile. Configure it as an FFMPEG (H264) camera with an rtsp:// url pointing to your camera’s IP address and using the UDP protocol:
Image
Another deviation from the article – On my second camera, I wanted a real, durable, weatherproof enclosure – not the fake plastic kind of thing they use in the article. I used this Evertech B00LU2NPVS enclosure, again from Amazon which, for for $45 bucks, gave me a full IP66 weatherproof enclosure, plus built-in IR leds and a fan. I just glued the camera to the rubber diaphragm and the circuit board to the included mounting plate with some silicone caulk.
Note that this housing is actually QUITE large compared to the crummy little consumer WiFi camera enclosures. In fact, it was really kind of unnecessarily big for the PiCam – almost 18″ long. I ended up cutting about 4 or 5 inches off the tail end with a hacksaw, which actually worked pretty well. Because of that, I had to drill a new access hole in the bottom for the power cord. I also drilled a small hole in the back to mount the WiFi antenna connector I had scavenged.

A note about power: The IR led array and fan take 12v. The housing comes with a convenient DC “bullet” plug that connects to the IR assembly, and there is another pair of wires that come off the IR assembly to supply your camera, but they supply the same 12V. I connected these to a buck an adjustable buck regulator – a really convenient and efficient regulator that costs about 5 bucks on Amazon and can take a variety of input voltage and output whatever you adjust it to…in my case 5V. I then fed the 5V in to the USB power connector on the Pi by cutting up a USB cable and splicing it in.

 

02/16/2016 Update:

To improve stability a bit more, I tweaked the restart scripts (already reflected in the code, above). I also changed the output redirection, so it doesn’t spit stuff out to the console and redirects it to vlc.log properly.

Next, I created a script to check that the WiFi is connected, and force an attempt to reconnect if not. Then I set that up to run every five minutes via cron.

check-wifi.sh:
#! /bin/sh
count=$(ping -c 4 192.168.2.1 | grep ‘received’ | awk -F’,’ ‘{ print $2 }’ | awk ‘{ print $1 }’)
if [ $count -eq 0 ]; then
# 100% failed
echo “Restarting wifi”
sudo /sbin/ifdown wlan0
sleep 10
sudo /sbin/ifup –force wlan0
else
echo “Wifi looks good!”
fi
 
/etc/crontab:
#! /bin/sh
# Monitor remote host every 30 minutes using monitorHost
5 * * * * root /home/pi/check-wifi.sh

 

Finally, created a monitor in iSpy, so that if the connection is lost and reconnect failes, iSpy will launch a script to automatically try to restart the service.

First, I set up my pc so you can ssh to the PiCam without entering a password. After installing cygwin and making sure the cygwin\bin directory is in my default system PATH, I set up an encrypted keypair using this example on StackOverflow: http://stackoverflow.com/questions/16928004/how-to-enter-ssh-password-using-bash

Then I created a batch file to call the service restart command remotely and registerrd it as the “Reconnect Failed” Action in iSpy:

restartPiCam2CLV.bat:
rem try 5 times
set /A count = 5 
:DoWhile
 if %count% == 0 goto EndDoWhile
  set /A count = %count% -1
  ssh pi@192.168.x.yyy sudo service vlc-streamer restart
  if %errorlevel% == 0 goto EndDoWhile
  if %count% GTR 0 goto DoWhile
:EndDoWhile
exit \B
Image1

Failed connection Action

If the connection goes away and the automatic reconnect fails, iSpy will invoke the script.
Advertisements
Posted in Technical, Uncategorized | Leave a comment

Easy, Cheap Connector for ESP-01

One thing that’s been pretty annoying playing with the ESp-01 variant of the ESP8266 modules is the pinout form factor. The 2×4 pin configuration does not plug into a prototyping breadboard conveniently, and also doesn’t lend itself to connectors you might use in a more permanent solution very well – I was ganging two pieces of Arduino headers, using several female-ended jumper wire or gluing together multiple female ends to make a 2×8 connector…and that kind of thing.

While browsing parts at Fry’s, a really simple solution occurred to me. I got some plain old .1″ pin  spacing ribbon cable headers and a piece of ribbon cable. You could also use the prototyping ribbon cables that have male pins at the end for plugging into breadboards. (sorry for the blurry pics)

IMG_20151204_080211499

 

These work great, and cost mabe 50 cents each to make (max). Note they only had 20-pin connectors, so I only use the 8 on one side and they only had 9-conductor cable, so a got a length of that an peeled of one conductor 🙂

IMG_20151204_080244917

Posted in Technical | 1 Comment

Lessons Learned with ESP-201

I recently ordered several more ESP8266 modules, and of that set, I decided to get a couple of ESP-201’s. These were appealing because they’re still fairly bare-bones (and therefore extremely cheap – about $4US each), lacking an on-bard regulator or serial chip, but they also bring out a lot more IO lines to pin pads, and seemed more convenient for plugging into a prototyping breadboard.

UPDATE : Note that, as noted on another blog, “Compared to ESP-12 this module has 6 more pins broken out – D0, D1, D2, D3, CLK, CMD (GPIO6-GPIO11). But only two of them (D2, D3) can be used as regular GPIOs after slight hardware modification.” Yuck! Looking forward to the ESP32!

I encountered a couple of issues that took a fair amount of googling to figure out, so I figured I’d pass them on.

First, as others have pointed out, the pin labels are on the underside, which is really annoying.  like most ESP8266’s, you have to pull CH_EN high, and to flash it, you have to pull GPIO0 low. You ALSO have to pull GPIO15 LOW, though, which is different from other ESP variants. Once I pulled 15 low, GPIO2 high, and GPIO0 low, I was able to flash the module.

However…I was flashing a NodeMCU image onto them, intending to keep it consistent with the other modules I’ve been playing with for my Light Suit V2 project. But it turns out, the ESP-201 is specifically designed to work with the SDK and it does NOT work with NodeMCU flash images. You pretty much much need to use the SDK or, as I do, use the Arduino plugin to handle the compiling and flashing for you.

CORRECTION: ESP-201 WORKS FINE with NodeMCU, you just have to have the pin levels
right a boot to get it into a mode where you can load .lua files and run on boot – specifically, pull CH_EN high, as you normally do, and pull their pin “IO15” (really pin 13 on the chip, I guess?) LOW. To flash, pull GPIO0 low, as usual. This wound up working and now I’m much happier 🙂
ESP201_Frontesp-201_pinout

The Arduino plugin makes coding with ESP’s really easy since it builds and flashes your code to the module in one easy step without requiring you to go learn complex code build chain crap. Once I switched to that environment, the usual process of pulling GPIO0 high, followed by programming, worked well.  I haven’t really done much with it yet, but I presume it will work pretty much like any other variant using the Arduino toolset.

Posted in Uncategorized | Leave a comment

Can’t upload new LUA files once ESP8266 init.lua starts

I’ve been having this frustrating problem with my NodeMCU projects on the cheaper ESP8266 devices: Once you get into a loop in your code, or worse yet, if you have an error that causes a reboot loop, there’s no way to upload a new .lus file short of re-flashing – a major pain!

Well, I finally found a nice solution on Big Dan’s blog. Thanks to Big Dan, a simple code addition for startup of you app in init.lua gives you time to interrupt it using a simple “snippet” assigned to a button in NodeMCU.

Add some code like this to your init.lua:

function startup()
    if abort == true then
        print('startup aborted')
        return
        end
    print('in startup')
    dofile('test.lua')
    end

abort = false
tmr.alarm(0,5000,0,startup)

Then edit the code behind a “snippet” button to execute “abort=true”. Then you just have to click that snippet button before 5 seconds expire at startup time to abort starting your code.  Many thanks, Big Dan!

Posted in Uncategorized | Leave a comment

Light Dimming Using Ardiuno with Inverters

Since there’s not a lot of information about it out there in one place, I thought I’d share some insight into a problem I’ve been grappling with – dimming 110V LED lights run off an inverter using Arduino-driven triacs.

Recently, I’ve been experimenting with dimming strings of LED lights using an Arduino and similar devices. My goal is to kick my Light Suit up a notch by going from simple on-off flashing patterns to dimming intensities, ultimately driven by sound spectrum intensities – so that the strings throb in sync with music sources.

There is a trick to dimming 110V AC strings – since you’re typically using triacs to control hihg-voltage AC power, you have to worry about “Zero Crossing”. The problem is that, once you turn a triac on, it stays on until the voltage falls to the “zero crossing” point – the point at which the voltage is at (actually near) zero, even if you turn off the controlling voltage. So, to dim 110V strings, you actually have to do some timing – where you wait a small amount of time into the phase of the AC sine wave before turning the triac on. That way, you only voltage during a portion of the since wave – reducing the overall power. There’s a good article on the technique here: http://playground.arduino.cc/Main/ACPhaseControl. That is basically the setup I’m using.

A problem I’ve been encountering though, is that I’m running these strings off of a 12V-powered inverter. That was the easy way to take commercial string of LED lights attached to the suit and still be mobile. The problem I’m running into is that, at least in the case of small, inexpensive inverters, they use a modified sine wave, not a true sine wave. Google it for more details, but this is basically a notched square wave which emulates a sine wave in terms of total power delivered. But since the beginning and end of each phase of a modified square wave are at zero voltage, if you try to turn the triac ON at the beginning or end of the phase, it doesn’t happen, since the voltage is at zero.

Image1

You have to turn in on at some point during the “notch”, which is a narrower window than you have with a full sine wave.

Image2

What was happening for me was that, at low or high dim values, the lights would start flickering erratically or not coming on at all. Limiting the triac firing to the window of the actually square “modified sine” wave helps tremendously. It’s also worth noting that my two inverters behave differently – one flickers quite a bit even when I limit the firing window. I’m guessing it must be a “dirty” square wave or something, but can’t really be sure without a oscilloscope (this is one of those occasions where I really consider plunking down some $$ for one).

Also, I’m not sure why, but I still get some flickering when I drive the triacs from an Arduino Uno. When I use a chipKIT uC32 (an 80Mhz pic-32 “Arduino clone”), it works smoothly. I have know idea what’s going on here, but I’m kind of guessing that the speed with which the Arduino responds to a hardware interrupt can very a bit based on how busy the processor is or something.

Posted in Uncategorized | Leave a comment

ESP8266 Update

OK, since my first post on the ESP8266 and some replies I posted there as I made progress getting it to work, I’ve now had a chance to play with it a bit more.

One thing about the inexpensive ‘bare-bones’ variants – the advice everyone gives about NOT powering them from your serial adapter is definitely valid. I got significantly more flakiness with them, especially when trying to flash. Sometime it would take several tries to flash correctly. At times, the power draw even seems to have messed up USB hub, causing my mouse to go dead, for instance. The flashing flakiness applies both to flashing the full firmware and to simply trying to flash .LUA files to them.

So far, I’ve done almost all my experimenting using LUA and ESPlorer. This is mainly due to the convenience and to eliminate potential weirdness the Arduino build for ESP8266 might introduce. I’m not saying there is any – I just want to have a controlled comparison before digging deeper.

I do think there could be some issues trying to use certain Arduino libraries with the ESP, though. NodeMCU appears to be essentially a single-threaded, event-driven language, like Node.js. Since some Arduino libraries likely rely on interrupts for timing (SoftwareSerial, for example), you could end up messing up timing within the core firmware that controls the WiFi stack. So far, I have no evidence of this, it is mainly conjecture.

My little test project is to read the temperature from a TMP102 sensor from Sparkfun (my version has been retired, but the new one is essentially the same) and publish it to my OpenHAB server via MQTT over WiFi. The TMP102 uses an I2C connection with some specific addressing. Fortunately, both MQTT and I2C libraries are compiled into the latest NodeMCU firmware – I really just had to write a little MQTT code and pilfer some I2C communication code from Christee@nodemcu.com, which I found in the BMP085 module under the LUA firmware project: https://github.com/nodemcu/nodemcu-firmware, and wire the SDA and SCL pins to GPIO14 and 12, respectively. My complete set of code is here: https://github.com/acoulson2000/ESP8266-TMP102. One more thing – apparently LUA is integer-based (lame) and this messed up my conversions to Centigrade. I had to download and flash a floating-point-capable firmware image (nodemcu_float_0.9.6-dev_20150406.bin) from https://github.com/nodemcu/nodemcu-firmware/releases.

In any case, I mentioned in my last previous post on ESP8266 boards that both bare-bones boards I got have on-board 3.3V regulators. While this is true, they appear to be too wimpy to prove reliable when flashing or adding peripherals. Out-of-the box, I experienced a lot of flashing flakiness with the ESP-07 and ESP-12 cheapo boards, and little to none with the ESPToy. Using an external 3.3V source improved things immensely, though. At first, I just tapped the 3.3V source off an Arduino Uno connected to a USB port for power, and piped this stright to the 3.3V pin on the ESP-07 daughterboard – the little hole was just the right size to except a jumper pin 🙂  This made the device MUCH more stable.

Having had success with that, I decided to see about upgrading the chip to something that could provide more current. The seller himself indicated that it was not wise rely on the LDO (Low Drop-out regulator – similar to this one) on the ESP-07 and that its presence was actually a mistake (I think he just sources the things bulk from China, but he knows something about what he’s reselling). He recommended an LM1117MP-3.3 (linked here from DigiKey), so I ordered a couple, intending to swap out the chip. They’re both surface-mount, so this requires some soldering skills, but I was up for it. Unfortunately, I did not look compare the specs of both carefully. While they are both surface-mount chips, the 7333 is a SOT-223-3 which has smaller pins than the LM1117-33, which is a SOT-223-4. It has wider pin spacing AND the pins are not in the same order.

LM1117-22 Grafted onto ESP-07

LM1117-22 Grafted onto ESP07

So, I removed the original chip, the soldered the new one one, but spun around and with a jumper on the ground pin to connect to the original ground pad. I also put a little tape underneath it to prevent inadvertent contact with any of the boards though-hole exposed metal.

CaptureMan, after that, that thing works beautifully! I haven’t had a flash problem yet. I flashed two different firmwares and I even went into the ESPlorer Settings tab and cranked it up to Turbo mode. It still flashed program files flawlessley.

That was a lot of trouble to go to, when the ESPToy works right out of the box, but I think it proves out that an ESP-07 combined with some minimal components for a total price of about $5 is totally viable.

Here are shots of pretty much exactly the same sensor, the left one using the ESPToy powered and communicating to the PC directly over a USB cable, the right one connected to the PC via a USB-UART serial adapter. The Arduino is there purely as an easy way to get a 5V power supply while prototyping – I’ll switch to an AC adapter for the real deployment.

ESPToy with TMP102 Sensor

ESPToy with TMP102 Sensor

ESP-07 with Minimal Motherboard and TMP102 Sensor

ESP-07 with Minimal Motherboard and TMP102 Sensor

Next up…more esperimenting with the Arduino port for ESP8266!

 

 

Posted in Uncategorized | Leave a comment

Bluetooth HC-05 and Connection Status Detection

I have a project I’m anticipating where I want a bluetooth module connected to an Arduino.  I’m going to have the bluetooth module connected to an Arduino under my car seat. I’ll have the bluetooth pair with my phone automatically, then an app on my phone will send a short string through the bluetooth module to the Arduino, which will then set the position of my power seat to my preference. The same will work for my wife (naturally, mine will take precedence if we’re both nearby 😉 Ideally, I’d like to have the Arduino in sleep mode and have a signal from the bluetooth module wake it up via a hardware interrupt.

So, I found these cheap HC-05 and HC-06 Bluetooth-to-serial modules out there, which is nearly perfect. One problem – I bought one, and it wound up being an HC-06. Turns out, the State pin, which is tied to GPIO09 on the HC-06 ‘daughterboard’, and is supposed to go high when the bluetooth pairs, doesn’t work on the HC-06. I’m blogging this in case anyone else is looking to detect the state of the pairing on an HC-0X module.

Some research indicated the firmware is different on the HC-06 and that feature just isn’t even supported. Supposedly, it is supported on the HC-05. OK, no biggie – they’re, like, $5 ordered from China, mounted on a nice little break-out board. So, I order a couple of HC-05 and a couple weeks later they show up. I plug one in, pair it AND….still no go! Hmmm..in the meantime I’ve been reading about a lot of AT commands you can send these suckers (you configure them using an “AT” command set, sort of like my first modem – a 300 baud modem, I’ll have you know). I won’t document how to get into the console here – that’s document extensively all over the place.

Anyway, I’m thinking…hmm…maybe there’s one that enables that function? I found the AT command set for the HC-05 is thoroughly documented here, and sure enough, the “AT+POLAR” command does just that! The engrish docs read a little counter-intuitively – you actually need to send “AT+POLAR=0,0” to set the board up to turn the onboard LED high and raise GPIO9 (board pin 32) HIGH when paired. But once I tried that setting, it worked like a charm! Oh, and by the way, the opposite (AT+POLAR=1,1) results in the on-board LED flashing slowly when paired and GPIO9 just always stays low.

Hope this helps anyone else looking to do the same.

Posted in Uncategorized | Leave a comment

Experimenting with the ESP8266

Recently co-hacker Jay pointed this out to me: http://rayshobby.net/esptoy/ It’s basically a little board that has an even smaller daughter board (an “ESP-12”..more on this shortly) soldered right onto it, plus a USB-serial converter, a 3v regulator, an RGB LED and a button, and it boots up running a little LUA-based firmware that let’s you load little LUA sketches on it. He’s actually running the NodeMCU code on it. A very cool little board that let’s you get little Wifi ‘node’ up and going with minimal effort at the very low cost of $17! He also references a project that led him to put together first the ESPToy 1.0, then the current 1.2. The 1.0 basically combined an ESP8266 with an Arduino, but in 1.2, he did away with the Arduino part entirely.

I was intrigued that the author had basically loaded his own firmware onto the ESP8266 (the ‘ESP-12’ module) little device and started digging into it a bit more. So, it turns out the ESP8266 line of modules have their own embedded 32bit processors, the wifi protocol stack and hardware, and some on-board flash.  They expose GPIO pins and a serial port. Most amazing of all – you can get “bare-bones” ESP modules for less than $5! So, I decided to dig deeper. The LUA runtime is OK, but there aren’t a lot of libraries out there for talking to other things using it. For instance, I’m currently kicking around the idea of an arduino-powered, web-connected universal IR remote – I’d like the greater versatility of Arduion programming, rather than LUA…and the idea little $5 Wifi-connected arduino-like devices is crazy!

So, it seems like there is at least one project out there to program these suckers using the Arduino IDE and code. I’m going to blog my experience here..

ESP Module VariationsFirst step – I ordered a couple of different ESP devices. I should point out that there are a bunch of ESP modules (ESP-01 through ESP-12 at this point).
They’re basically all the same chipset in various configurations exposing different pins and with different (or non-present) on-board antennas.

Then there are many device that have an ESP variation mounted on them an break the pins out to more convenient configurations, add voltage regulator and buttons, etc, and are still very cheap (<$5).

ESP-07 MotherboardESP-12 With Additional ComponentsI got an ESP-07 on a more-or-less bare motherboard and an ESP-12 on a board that has an regulator, RGB LED, LED’s on several GPIO’s, and apparently a photo sensor. The ESP-07 package included an external Wifi antenna that can be snapped on to provide better range than the on-bard ceramic antenna. The ESP-12 package also came with a USB-serial converter that is necessary to connect to these things. I already had one, but figured a spare wouldn’t hurt. Neither of these had any documentation with them.

I
 also ordered a couple of the ESPToy’s just for the hell of it too 🙂

Bare Motherboard with REgulator I should also point out that first one DOES have a 3v regulator on the back side – even the seller didn’t seem to realize this, but its clearly depicted in the bare version he also sells 🙂

Anyway, having the regulate on-bard is big plus, since it will make actually using them with simple 5V (e.g., USB) supplies easy. (Update: I message the eBay seller to tell him it did have a regulator and he indicated the next version will not, since the chip used on this one is pretty low power. ESP-07 drawing a lot of power is a topic I’ve seen more than once…for instance, they say not to try to use the 3V supply from the FTDI serial adapter like the one in the ESP-12 package, above).

So… here goes..

Everything came at the same time. I plugged an ESPToy in first, since it was the easiest – just plug in a mini-USB cable and it powers up. It fires up the first time with a simple demos that goes into Wifi host mode and serves up a simple HTML page that lets you set the RGB values of the LED. It worked fine..ok, time to go drill into the ‘bare’ modules some..

So, at first, I had trouble getting either to do much. Neither would report or respond to anything over the serial port or show up on Wifi. It seems like there is a lot of variation in terms of what the default firmware is intended to do, but supposedly you should be able to get to a command prompt and do AT commands more or less right off the bat. I tried different baud rates – apparently older firmwares may be 115200 or 57600, while the latest is supposedly 9600 – all to no avail. I was focusing mainly on ESP-12 board and, finally, GPIO JumperI started wondering about the jumper. To flash new firmwares on these suckers, you have to hold GPIO0 (zero) high when you power the board on – this puts it in firmware flash mode. Maybe the jumper is for doing that? Yes! I took the jumper off (and also verified my conjecture with the multimeter) powered it on and right away, a new Wifi network, “AI-THINKER-9B5AC7”, showed up. It took some googling to find the Wifi password, which is “ai-thinker”. I also now get a whole bunch of output over serial as it starts up (my version is operating at 115200 buad) it shows it’s listening on 192.168.4.1. Hitting that url with my browser now produces a “We have a GET request” message on the serial port.

I still get get no response from AT commands, though. My theory is there is a non-standard firmware on this device that leaves AT mode to run the little HTTP demo app. In bit, I’m going to try flashing it with a newer firmware. At this point I also still haven’t gotten any response at all from the ESP-07.

 

Posted in Uncategorized | 3 Comments

Homemade Security Camera based on Raspberry Pi

This is a great project!  http://www.instructables.com/id/Raspberry-Pi-as-low-cost-HD-surveillance-camera/?ALLSTEPS

I’ve burned through some commercial consumer-grade wifi cameras – they tend to not last very long…possibly a function of the weather and our Texas heat. I’ve even repaired them a couple times; replacing the IR LED array or even the wifi daughterboad. This will be much more easily serviced and debugged, though – really cool.

I went a little further by adding an IR LED array that I happened to have lying around (from previous repairs projects). It is similar to this one – http://www.dx.com/p/31632 – although I can’t guarantee this is the same one – I got it a long time. A wide variety of these arrays are available – check the dimensions carefully to make sure it will fit in your enclosure. The one I had fit perfectly in the cylindrical camera body specified in the parts list, above (not the square one shown in the pics, BTW). I mounted the camera board right behind it and cut a short length of black plastic tube that fit in the center of the array to prevent back-scatter of light when the LEDs are on.

These arrays generally come with a built-in light sensor, so they only come on at night. They tend to ​run on 12V, so I use a 12V AC adapter, and a ripped the guts out of a $10 cigarette lighter USB adapter from Walmart (cheaper are available) and hard-wired it in much like described here: http://www.instructables.com/id/Solder-USB-power-c…

Image1

Be sure and get one that cranks out at least 1 Amp – I did have issues getting enough power to the RPi to power it and the Wifi dongle.

Image1

Posted in Uncategorized | 1 Comment

Fast Updates (frame rates) of Color Effect G35 Grids

It’s the time of the year to start playing around with Christmas Light hardware and software. Lately, I’m focusing more on simpler (i.e, less light strings) displays and more on incorporating my “mini mega light tree“.

As described in previous posts (Driving GE G-35 Light String with Digilent Uno32GE G35 ColorEffects Christmas Tree), this consists of a tree made from multiple GE G35 ColorEffects LED light strings. I adapted my light sequencing program to drive the addressable bulbs, using a Digilent ChipKit Uno32 ‘Arduino-compatible’ microcontoller as a protocol converter more or less. The PC software sends serial commands to the Uno32, and it in turn sends commands to the G35 strings via digital out pins. The software essentially treats the tree as a pixel grid which it can load bitmap to; transforms (scrolls and fades) can then be applied to the grid.

One problem that has plagued me, though, is that refreshes get bogged down when sending lots of commands to multiple strings. The effect is pretty severe when trying to do things like fade the whole tree, load an entire bitmap, or scroll a bitmap with lots of different-colored pixels around the tree (bitmaps with just a few pixel variations aren’t so bad, since I only have to update those pixels that change, not every single pixel). This year, I decided to take a stab at improving it.

Until now, I thought that my problem was shoveling a lot of data across the serial line, while also doing the work of sending the custom protocol out to various strings – possibly due to serial handling producing a lot of interrupts. Some other blog entries had misled me (or I misinterpreted them 🙂 to believe that controlling multiple strings at once with high refresh rates should be possible with Arduino-class hardware. Turns out this isn’t exactly true…or at least isn’t simple. There’s an interesting thread on the topic here.

Thinking maybe I just needed to reduce the serial data burden, I started down the path of offloading more of the work to the  microcontroller in order to reduce the data going over the USB serial line. It turns out this is NOT the reason it get’s bogged down. Even when no info is sent via serial (like during the all-string-fades I currently have during setup() execution) the delay between the update of each string increases as I increase the number of strings. One string is very fast, with no significant delay…five is noticeably bogged down. This led me to calculate how much time it takes to send a single color/intensity to every bulb on five strings based on the µSec delays built into protocol functions in the sketch. Turns out it takes over 1/20th of a second to update an entire string! Throw in some overhead for logic and serial handling and it’s nearly a quarter of a second to update five strings! I really should have calculated this sooner (or should have read that thread mentioned above :-).

It’s clear that to get faster updates, more horsepower won’t necessarily help -I need parallel string addressing. Even with more horsepower, I’d still spend too much time blocked, waiting on delay functions.  I think in that forum jwhite describes provides an implementation and provides code where he uses some kind of “ring buffer” and can theoretically update 6 strings simultaneously – I think by constantly looping through a timing cycle and writing the bits representing the ‘current’ color into six pins at once during each cycle? – effectively implementing a true raster rendering? The C code is actually over my head, so I’m kind of speculating here.

Since my C skills are probably too weak to take something like that on, it occurred to me that I could get the parallelism I want using multithreading. By driving each string from a separate thread, less time could be spent by the main thread being blocked by delay functions in the protocol implementation.  As a result, I just ordered a NetDuino Plus. I’m hopeful that this will allow me to take advantage of the multhreading support in the .Net Micro framework, not to mention giving me an easy way to port a lot of the display logic to run on the microcontroller instead of the PC. It even includes ethernet support and an SD card, so I’m thinking I should be able to put all the bitmaps in the SD and move from USB tethering to a simple network-based protocol over Ethernet. Watch here for an update 🙂

UPDATE: (11/27/2013) Dang, just realized the Thread.sleep() only has millisecond precision (and even then it’s not exact) – and although there are techniques for getting microsecond timing accuracy, they appear to be not very accurate, plus they just use loops which would probably not free up the cpu when sleeping. Going to have to think on this one some more…

Posted in Uncategorized | 6 Comments