When I was getting into Xbee, it wasn't too clear to me what was the recommended interface for the PC size.
While there actually are expensive-ish dedicated PC adapters, the short story is that most folks actually use the same Xbee chips that you put on your arduino shields, and use an adapter that can be connected to USB.
For this you have two to chose from, and I'll explain them both (I got both to try them out, and each has its strong points and weaknesses). This is what they look like (the sparkfun one is red):
The sparkfun adapter costs a bit more, but it has the built in FTDI chip, so it comes with a mini USB connector and it ready to connect to your PC: no fuss. It also comes with a very handy set of LEDs: serial RX/TX, and RSSI (which shows if RF data was received). The big plus is also that it's already all soldered and ready to use. Oh, the module also easily supports longer Xbee Pro modules.
Its only shortfalls are the lack of AI LED (which comes in handy to show that the module has joined an active network) and no reset jumper, which can be required to blind flash modules or reset modules with ZB END device firmware (which goes to sleep by itself and can't be talked to with X-Ctu without a reset).
Those modules need to be soldered. It's not very hard, but it's time consuming and it's easy to put solder inside the xbee headers. One of my modules wasn't working right until I figured that the problem were the headers had a bit of solder and prevented a consistent good contact. The other shortfalls are the lack of serial RX/TX LEDs which are crutial for knowing that your blind flashing is working, and the default build doesn't accomodate Xbee Pro modules well (you have to bend the resistor and capacitor out of the way like in the picture above).
On the plus side, there is no FTDI chip on there, so they're cheap ($10) and you can use a 3rd party 5 pin adapter cable you may already have, or if you buy one now, you'll be able to reuse it later to flash some arduinos like the AT mega 328.
If you're planning on mostly plugging your Xbee into a breadboard, the Ladyada option is cheaper since you can solder header pins and use the adapter without ever paying for an FTDI cable (or more generally share one cable for multiple modules).
Sometimes you have a flash a non responsive Xbee module, it may be a ZB End device firmware that is in sleep all the time, or you just don't know the module speed and don't feel like finding out, you can flash the module with X-ctu and reset the module when it tells you to.
But to do this, you need a reset switch, which neither of those two modules has.
I ended up foldering a PC jumper on both modules as shown in the pictures, and that would be a worthwhile addition to both modules by default.
The procedure for blind flashing is explained here and there:
Set speed to 38400, API disabled
in modem conf, select right firmware
set baud rate in serial interacing option to 38400
set always update firmware and start write with module not plugged in
when error message on pushing reset appears, plug module in
After getting into arduino (and I'll blame Johnathan Oxner on this one), I had to get back into electronics as a result too.
It took a bit over $500 to get basic parts and tools all stocked up.
I'm re-learning the basics and finding projects to build (like a wireless Xbee controlled outdoors soil moisture sensor, or adding breath and SPO2 measuring to my arduino sleep monitoring board).
So far, well, electronics is what I remember it to be: hard and less satisfying than computers for me. Debugging is harder, getting parts adds delays that don't mostly exist with computers, and there is a lot to learn :)
Stay tuned for more.
Ok, maybe this is my first successful project (not counting flashing LEDs in sequence off an arduino). The Ladyada breadboard power supply sorely lacks a voltage display when in adjustable mode.
I found a device called 'LED 1s-6s Lipo Battery Voltage Indicator Checker Tester' on Ebay. Here are links that might work in a few weeks still :)
It is a better choice than the more expensive 1-8S tester with low battery alarm because it will work in 1S mode without flashing voltages. Now the trick it is powered by the voltage it's measuring, but the voltage cannot drop below 3V it won't work.
You can however measure down to 1V (or maybe even less) if you apply 3V or more on one other pin, but you don't want to apply that voltage to the other pins before the unit has initialized. If it 'boots' with only one voltage, it will nicely just display it and then you add voltage to pin 3 and it will measure pin 2 voltage down to low values without shutting off. You just don't want it to boot with voltage on pin 3 or it will alternate between showing voltages on pin 2 and 3, which is what you want for a lipo battery, but not for this application.
Maybe I could have done something complicated with a capacitor or a timer, but I just put a switch that turn off and only turn on to apply power to pin3 when I need to measure small voltages. It's a bit hackish, but it cost $5 for the digital voltage meter, which is hard to beat :)
End result pictures below:
The RCCCv2 board is an awesome little board, but unfortunately its switched output are not very usable as general purpose power swtiching. One is strobes, so it goes on and off no matter one, and the other one could switch any load, except that the GND line is switched, not the 5V line. As a result, if I plug my cameras into 5V, thir ground goes to the OSD board, the OSD board is connect to the autopilot and the serial communication grounds the circuit via the autopilot, which means my cameras would turn on regardless of whether their GND connection to the RCCC board is floating, or switched.
It's really too bad that the RCCCv2 will not switch the 5V line instead of the GND line.
My other issue was that I wanted to switch both 5V for the cameras and 12V for the VTX, so the best plan was to switch 2 volt lines with a dual relay. Doing this with the RCCC board was again a bit tricky because it would only switch a ground line that would go floating otherwise, so I had to use a pullup to 5V.
If I had to do this again, while I was not able to find any small RC controlled dual throw relays (the only one I found was huge and 3 times the size and weight), the Pololu 2803 RC Switch with Medium Low-Side MOSFET works for small loads, but if you need relays (and in my case I do because I needed a high side switch, and the mosfet was low side), the next best option is a Pololu 2804 RC Switch with relay. Sadly, the relay on it is big, but I can unsolder it and put a smaller one. I recommend the Pololu switches just because they're very configurable (you can change the setpoint, as well as change the direction they'll turn on/off for).
That said, for more than twice the money, a smaller and less configurable one is the PicoSwitch Radio Controlled Relay.
But anyway, I did have this small dual throw relay already, so I made it work with the RCCCv2 board to switch 5 and 12V.
Relay board testing:
Flipping the lights with my RC contoller
Now trying the whole things with my plane electronics, and checking current draw:
My little dual latching relay board is quite small, it replaces 2 bigger relays:
Better design where the relay is not energized when 5 and 12V power are switched on:
And here is the end result board, showing how it's wired with the RCCCv2 board:
I happened to pick up a solar powered floodlight at costco, and figured I'd use the solar panel charged batteries to power lights inside our shed.
6.7V input from the batteries, taken down to 5V with LM voltage regulator
The problem was that my motion activated lights actually used quite a bit of power when doing nothing, so their batteries would die after 1-3 months without them being used:
This nice bright light has an RF receiver that needs to be powered all the time, sucking power:
This light is even worse, it uses more than 500mA when fully bright, and uses an infrared LED to detect hand swipes. That burns 3mA, killing batteries in less than a month:
My meter shows more than 0.5A when full bright:
Small show and tell video:
This is the ghetto end result in the shed, but it works :)
In the end, I did have to replace the LM voltage regulator with a better one from pololu, 2.5A 5V with less than 1mA quiet use. This allowed the batteries not to be used up into a voltage regulator doing nothing :) Then, I also had to put the voltage/amp display on an off switch, as it was using another 15mA just to display those values. Now, everything is happy :)
The thinkwiki power connector page explains very nicely how Lenovo power supplies come in round and slimp (rectangular) tip, and can be 35, 45, 65, 90, 135, 170, and 230W. The way the laptop knows how much power it can draw, is by measuring a resistor between the center pin and ground. So far, most of my power supplies had been 90W, and all my thinkpads, including the T540p, were ok enough with that, even if maybe they were not always charging at full speed.
However, when I got my thinkpad P70, although it also uses around 25W in typical use, which means plenty of extra wattage on a 90W power supply to charge the battery, the P70 was unfortunately designed not to charge under any condition unless it recognizes a power supply that's at least 135W (it ships with a 170W power supply, and it's a huge monster brick). I'm pretty mad at lenovo for that because they could totally have designed the P70 to charge at a slower rate from a 90W power supply, or at least when the laptop is sleeping, but no, even when it's sleeping, it will just not charge at all.
Sadly, this means that the RAVPower 23000mAh Portable Charger Power Bank External Battery Pack I bougght, was able to power the laptop, but not charge it. I guess in this case, it's not a huge issue since energy would be wasted trying to charge the laptop battery instead of just powering it, but still, that was disappointing.
here, the pack is powering my laptop at 20V, 2.1A
The P70 will function off a 90W power supply by just not discharging its battery, and consuming around 1.5A at 20V (i.e. 30W), so that meant that not only I had to buy some bulky 135W power supplies (less bulky than 170W thankfully), but also that I was now unable to use my travel iGo 110W 12V DC power supply, which I use to charge in cars. For AC, I did buy a Lenovo ThinkPad 135W (Slim Tip) Replacement AC Adapter for lenovo ThinkPad T440p 20AN 20AW, Lenovo ThinkPad T540p 20BE 20BF: https://www.amazon.com/gp/product/B00HOMBO0M
But for car use, I was upset about the situation, so I read up and realized I only had to change the resistor in my barrel connector to slimtip adapter and that would likely allow my thinkpad to start charging from my 110W iGo power supply. The hard part was finding where the resistor was since I had to replace a small resistor with a bigger one (the other way around, I could have trivially added a resistor in series).
So, I started with the AC Charger Power Supply Adapter Converter Cable Cord For Lenovo ThinkPad : https://www.amazon.com/gp/product/B00T013J44 and had to find where the resistor was hidden. After cutting the cable in 2, I convfirmed it was on the slimtip side, so I had to take the plug apart until I found it.
After that, it was just a matter of adding a new resistor, and in the end, I added a resistor bridge, so that I could select no resistor, 550 Ohm (90W), 1kOhm (135W), or even 1.9kOhm (170W). For my laptop, though 135W was enough, and my iGo only delivers 110W anyway.
I added a amp/volt meter (RioRand 2in1 4.5-30V/10A Digital Voltage Detector DC Current Volt Amp Meter|http://www.amazon.com/gp/product/B00JE42W86]), so I can tell how much current is flowing and whether I might be exceeding the wattage of the power supply. When my laptop is running, and the battery charging, it's now using 5.6A (just about 110W)
So problem solved. I'm not super happy at Lenovo for having stupidly designed their Thinkpad P70 not to charge from a 90W power supply under any use case, even at reduced speed, or even with the laptop sleeping or off, but since I already had the laptop, I was stuck with it, so this little resistor hack did the trick. Hope this helps someone.
While those shoes are quite cool when they work, and getting them for $50 or less on amazon is quite cheap. Sadly the build is a bit cheap and the hardware could be improved. So I went ahead and did it.
This is what you find under the sole: everything is inside a resin and the built it lipo is too small (only 4H runtime). Two sets of 4 wires come out: one is to control the LEDs and the other one has 2 wires for the switch built in the shoe, and 2 wires for the USB power charging (which charges super slowly, about 4X slower than the speed the lipo can charge at):
The first thing to do is to open the side of the shoe to get to the switch, take it out, and turn it around so that it points away from your foot. Otherwise it's way too easy to trigger. I've also cut the yellow wire and added a small slider switch. This allows me to disable the push switch if I want the shoes to stay off, or not rotate between color patterns each time the switch gets bumped:
The lipo is totally built in and too small. Adding a second lipo in parallel is a bit difficult, I had to burn off the resin to access the lipo terminals:
it claimes 450mAh, but I think it's smaller
it's a bit difficult to solder wires on top of the lipo wires without shorting it
I then added a female connector to allow use of bigger lipos from a mobius I wasn't using
I had a few lipos to choose from, but the mobius one was the best fit for the hole in the shoe
I had to cut off a bit of plastic fit the battery
still a bit of a tight fit
My shoes now work a bit over 12H, do not turn on or off without my wanting them to, and they come with a real off switch. I did put a very solid sole insert on top though to protect the electronics and the new bigger lipo underneath. There is also a worst case scenario where it could catch fire :)
The end goal was adding neopixel strips on my shirt sleeves and pant legs:
Here is a 6mn clip showing the shoes and shirt if you'd like the details:
The problem with my shirt, though, is that the colors you see on the picture are actually due to broken traces, causing the colors you see. It's better than nothing, but not what I was trying to do, and no way to create streaming effects. This is of course where neopixels come in.
I'm not going to repeat the excellent Adafruit Neopixel Uberguide here, but I have a 3mn video clip showing a standard IR RGB LED controller, compared to a neopixel strip. It also shows how I use standard remote control servo cables to wire neopixels, and how to watch out for:
signal wire being in the center, so you must not feed 5V on the middle wire like you would with RC and servos
how if you have a neopixel strip that doesn't work right, you can only connect to the first LED, and you have to start cutting off LEDs from the strip one by one until you get to the first one that works
before you start cutting, make very sure you aren't connecting to the last LED (DO vs DI)
Why IR and Neopixels at the same time, is hard
So, the main point of this page is however to look into the issues of controlling Neopixels and receiving IR signals at the same time.
It's easy to listen for IR, and then change neopixels, leave them alone, and listen for IR again. It's hard (or near impossible on some chips) to actively update neopixel strips for animations and listen for IR commands at the same time.
Why? This video explains the issue:
What's going on is on low end arduino chips (328p, leonardo, or even AT mega and all other 16 bit AVRs), neopixels are controlled by stopping chip interrupts and sending a very precisely timed signal to the neopixels. If the timing is off just a little bit, the wrong colors get sent, or nothing works at all. This is why interrupts must be disabled
Now, there are actually many other addressable multicolor LED types. The nice ones are 4 wire and work via SPI, which allows the CPU to control the timing and the clock, removing this exact bit banging timing issue. The cheaper 3 wire ones have a set clock and require that the CPU sends a very precisely timed signal, usually done while disabling interrupts. See https://github.com/FastLED/FastLED/wiki/Overview
But since neopixel strips (aka WS2811/WS2812/WS2812B) is what I already had, I now had to deal with this precise timing issue. As you can guess, disabling interrupts causes issues with the IRRemote library because it has its on interrupt handler timer that also requires being run at a special timing, or it doesn't capture proper IR signals.
The end result is that you cannot disable interrupts and receive IR signals, and if you don't disable interrupts, the neopixel signal is unstable and the colors flicker (demonstrated int the video above).
So, unless you use some special hardware to drive neopixels strips on an AVR chip, concurrent IR + neopixels is just not going to work.
an arduino nano v3 running neopixel strips
my 328p arduiny chip (equivalent to arduino nano) and anti plug backwards toothpicks :)
because my 328p chip was unprogrammed, I had to figure out direct ISP programming pinout for it and I flashed a bootloader on it
Concurrent IR + Neopixels solution #1: be fast (Teensy 3.1)
a few chips for comparison (uno, leostick, nano v3, arduiny, and Teensy 3.1 in green)
Thanks to better FastLED hardware support, when I moved my code to a Teensy 3.1 32 bit ARM CPU, the CPU was fast enough that it had time to re-enable interrupts in the middle of updating neopixels. This in turns allowed the IR Remote interrupt handler to just barely run in between pixel updates, and capture IR codes. Success!
See this video for details:
The magic code that makes this work, is here: https://github.com/FastLED/FastLED/blob/master/platforms/arm/k20/clockless_arm_k20.h#L34 sei(); delayMicroseconds(WAIT_TIME); cli();
Thanks to this re-enabling of interrupts, things work.
So at this point, someone sensible would have declared victory. However, I felt bad wasting a Teensy 3.1 on something as simple as driving a single neopixel strip (it can drive 8 in parallel) and reading from an IR receiver, when it has around 32 I/O ports. This is why I checked if I could get this to work on ESP8266 chips which are even cheaper and have much fewer I/O pins (but add Wifi)
Concurrent IR + Neopixels solution #2: don't use the CPU for neopixels (ESP8266 (I2S) and ESP32 (RMT))
I had more 32bit chips, so I thought I would give them a try. I tried the ESP8266 and ESP32:
However in my tests, the IRremoteESP8266 library was maybe a little bit too slow and caused occasional visible neopixel glitching. This is where I found this interesting library: https://github.com/JoDaNl/esp8266_ws2812_i2s/ which manages to drive the neopixels without doing bit banging with interrupts disabled ((ab)-using the I2S hardware support). It's not a very fancy library in what it offers, but it works perfectly with interrupts enabled.
Same thing for ESP32. Actually ESP32 is even more difficult to get a perfect timing out of using bit-banging given that it's a dual core CPU running on top of an RTOS, and no matter how precise your code is, you just cannot guarantee that it'll run perfectly at the timing you need all the time. I did add ESP32 support to the Adafruit Neopixel library, but it only works most of the time, which isn't really good enough.
This where its built in RMT support comes in. It can generate 8 precise signal waves, which are perfect for neopixels, so this is the way to go to animate neopixels without disabling interrupts (making IR receiving trivial). IRremote was missing ESP32 receive support, but I added it recently, so it's all working.
Here's a video summary of ESP8266 and ESP32:
Software and Libraries
So, here's a summary of all the libraries I went through, 2 for IR, and 4 for Neopixels:
FastLED is a more complete library with better hardware support (both in pixels and CPUs): https://github.com/FastLED/FastLED . The big plus of this lib is that it support re-enabling interrupts on 32bit chips, allowing the IRremote ISR to run.
Instead of FastLED (which does work), on ESP8266 you can use https://github.com/JoDaNl/esp8266_ws2812_i2s/ . The support is bare, but uses an inventive (ab)use of the I2S subsystem (I2C for audio) to generate neopixel signals using an onboard co-processor unit without tying up the main CPU or requiring the disabling of interrupts.
On ESP32, FastLED isn't supported yet (I added support in Adafruit-Neopixel) but both require disabling interrupts at least temporarily and it's hard to do anything real time on a dual core ESP32 running on top of an RTOS. The good news however is that it has 8 RMT channels which are designed to handle precise signals like this without tying up the CPU. See this code that supports Neopixels with exact timing: https://github.com/MartyMacGyver/ESP32-Digital-RGB-LED-Drivers
This is a 25mn mashup of all the video clips, including a section on flashing the arduiny via ISP (AVR 328p):
I also have a video showing the evolution of lights on my shirt from v1 (single non controllable color) to v2 (tri color, but not pixel addressable), to neopixels with cool patterns (jump to 3:50 if you'd like that):
It used a 12V controllable dimmer: https://www.amazon.com/gp/product/B00MHKCTLE which can simply change the brightness of the LEDs, which are of a set color. I bought the LED strip in Akihabara Japan, but I'm guessing something similar can be found elsewhere.
they are a flat trip that doesn't really like being bent
all the LEDs are in series, so if the chain fails somewhere, nothing lights up beyond the point of failure (which is why I have extra wires soldered on to make redundant paths and get around breakage
I have had some sections of 3 LEDs where one color died
All of the controllers I tried have a dimming function, but it fails to work when I use the fade dimming patterns, which means they are full bright, suck battery and blind others. I've therefore had to add a 2nd voltage regulator where I can just dim the voltage sufficiently so that the current is then also capped by each color string and therefore the brightness is controlled (you cannot limit the global current fed to the LED controller because you don't know whether it's all fed into a single color, or shared amongst 3).
Of course the last thing is that all the LEDs for a color are in series in a single circuit, so you light up all the reds, or all the blues or greens, or none. You can't turn on one LED individuallly. This is where the next solution comes in.
ESP8266/Arduino Controlled Neopixels
To fix the issue of not being able to have custom multi color LED patterns, where each LED/pixel can be controlled separately, the solution is neopixels (aka WS2811/WS2812/WS2812B). Each LED/pixel is controllable separately, which is done by a computer, in this case the ESP8266 can run my own programs to control all the LEDs.
The ESP8266 is a 3.3V based microcontroller for low power use (good when battery powered) while the neopixels are 5V powered, but thankfully the neopixels can use 3.3V signalling from the ESP8266 while being 5V powered to light up properly. The one thing to keep in mind is that neopixels use some power even if they are not lit. In my case 200 neopixels, take about 120mA when they are off, and 4.5A when they are all lit in white on full brightness.
Neopixels are almost infinitely versatile, instead of having them in single line strips like on my shirt and pants, you can also make display matrices out of them: