The basic attributes of these modules are as follows:

Modules	Dimensions	Picture	Pinout	Antenna	GPIO	Notes
ESP-01	14.3mmx24.8mm			PCB Antenna	GPIO0/2/16	Multiple Variants Exist! Most common module. This version may be known as V090 or V091
ESP-02	14.2mmx14.7mm			U-FL connector	GPIO0/2/15	Multiple Variants Exist!
ESP-03	17.4mmx12.2mm			Ceramic Antenna	GPIO0/2/12/13/14/15/16	Most popular in esp8266.com poll
ESP-04	14.7mmx12.1mm			none	GPIO0/2/12/13/14/15/16
ESP-05	14.2mmx14.2mm			U-FL connector	NONE	Multiple Variants Exist!
ESP-06	14.2mmx14.7mm			None	GPIO0/2/12/13/14/15/16	Metal shield claims FCC
ESP-07	22mmx16mm			Ceramic Antenna & U-FL connector	GPIO0/2/4/5/12/13/14/15/16	Multiple Variants Exist! Metal shield claims FCC
ESP-08	17mmx16mm			None	GPIO0/2/12/13/14/15/16	Metal shield claims FCC
ESP-09	10mmx10mm			None	GPIO0/2/12/13/14/15	1MB Flash memory
ESP-10	14.2mmx10mm			None	None
ESP-11	19.3mmx13mm			Ceramic Antenna	GPIO0/1
ESP-12	24mmx16mm			PCB Antenna	ADC + GPIO0/2/4/5/12/13/14/15/16	Metal shield claims FCC
DWA8	17mmx27.1mm			PCB Antenna	ADC + GPIO0/2/12/13/14/15/16

ESP-01 Variants:

Tinhead of the esp8266.com community contributed info about an older variant using the ESP8266 rather than ESP8266EX (may also be referred to as v080):

ESP-02 Variants:

TuxFanGKR of the esp8266.com community reported that a pinout variant had made him let the magic smoke out! And a third variant (confusingly named ESP-02 version 2) has been spotted here. Pinout is of TuxFanGKR’s variant – photo of ‘version 2’.

ESP-05 Variants:

A fifth pin has been added to the ESP-05 module carrying reset, thanks to esp8266.com contributors gbit and Didier9 for this info:

ESP-07 Variants:

A variant of the ESP-07 has been reported with 2 extra connections (one of them ADC) by mvdlande on the esp8266.com forum:

References:
ESP8266EX Pinout
Hardware guide

Any corrections, omissions or improvements? Please leave a comment!
Thanks to comment below, pinout of module ESP-11 has been corrected.

The post ESP8266 modules hardware guide – gotta catch ’em all! appeared first on layer zero labs.

Our goal is to allow others to write applications to use data from our systems for their own purposes, as well as reusing our API and apps themselves. The API is documented using the fabulous Swagger specification – we used the swagger-node-express because we like node. Swagger provides great looking documentation of the API as well as full details of the responses and error codes, but wait – there’s more. It’s not documentation in the usual sense, it’s an interface to the API itself. Thus it provides a really easy way to test the API out and get real data back, complete with headers and response codes – everything you need to develop apps against it.

Our system uses the seriously hard-core Cassandra database – even though we can’t quite justify it based on our data-needs today! In fact when we asked a support question on the Cassandra IRC channel we were told that a mere two box cluster was ‘not a typical deployment’! But it fits our requirements in terms of storing time-series data – and we have great hopes that soon we’ll be needing racks of boxes across several continents. If it’s good enough for GitHub and CERN then it’s good enough for us.

Speaking of GitHub, all our code are belong to you – this means it’s released under the GPL v2 and you’re welcome (and obligated!) to use it, abuse it, improve it and then return those improvements back to the common pot.

As well as all of this, we’ve also written an app that uses our API to present a simple web form allowing for the download of data in csv format. You can try out our download app here – again we really do appreciate your feedback (it’s the best way to get better).

Node express allowed us to get this simple web-app up and running with the minimum of fuss and maximum of effect. We’re hoping to follow this up with a graphing app very soon – watch this space.

We’ll be showcasing the system and its associated API , apps and dashboard at the very wonderful Wuthering Bytes open hardware festival in Hebden Bridge – if you can possible be there – you must! As well as our talk/workshop there are dozens of great things happening from Sophie Wilson to space rocket launches and beyond!

The post Open aquaponics API, documented with Swagger and sample app appeared first on layer zero labs.

This sensor is probably the one I’m most proud of so far, all the elements came together really well despite having to hack the MinipH circuit in the literal sense!

The enclosure maketh the project

As soon as I had finished making this sensor, and put the lid on and stepped back, I was genuinely surprised and pleased with how much better the sensor suddenly seemed. Despite the fact that I knew exactly how much sweat and tears had been expended and all the clever details, even then, I was mostly impressed when the case went together!!

At first I was a bit disconcerted by this, I am constantly trying to see the ‘real substance’ of things, ideas and people, rather than just see the ‘surface’ details. And yet, even with a project of my own that I knew intimately, I was beguiled by the case.

So anyway, the case turned out to be the perfect size, the quality of the plastic (ABS) and surface finish is very good, the sides feel strong and mate well with each other. It’s made by Evatron, model PC001 and I ordered a black and white one, both with and without a battery compartment from CPC in the UK (£4.54 with free delivery).

I prefer the look of the white one, its not trying to be Apple white (they’ve probably patented that one) but it’s not beige either – I suppose ivory is a fair description. The battery compartment option tempted me but I decided in the end that it would never be moisture or splash-proof let alone waterproof with a door.

Construction details

One of the first and easiest decisions was to remove some of the little plastic mounts intended for internal pcbs, they just get in the way. I snipped most of them off with heavy duty wire cutters and then used a sharp chisel to cut the remains of the plastic flush to the surface. Then the hole can be made in the middle of an end, it needs to be 12mm to accomodate the BNC connector of the pH pH probe circuit. I find that it’s very difficult to drill holes accurately without a pillar drill, especially in this sort of situation where the hole needs to go in the middle of where the case splits. However, it is perfectly possible to mark out pretty accurately by careful measurement and ‘eyeing’ up the marks from several angles. So I just marked out the hole as carefully as I could, then drilled it roughly in the middle at 10mm. I then used a file to remove the rest of the material and return the hole to a centred circle. I tried to retain a flat on one side of the hole, to match the mounting pattern of the connector, but it’s not vital.

Now in order to fit the pH sensor circuit we need to hack it – this time with a fine hacksaw. I spend quite a few minutes examining the board layout files (yet another reason to love open source hardware!) and a load more time examining the physical circuit, and became convinced that there weren’t any traces or components that I’d be damaging. The physical construction of this type of circuit is important, but I reassured myself that I wouldn’t be breaking any guard traces, just clipping off a bit of ground plane.

Needless to say, despite my brave words I was more than a bit apprehensive to take a hacksaw to such a perfectly formed little board. Perhaps this is what novice surgeons feel the first few times they have to cut into somebody? Anyway the operation was a success, and the patient was able to make a full recovery, minus a corner.

The MinipH circuit is from Sparky’s Widgets – aka Ryan Edwards – another hacker hero of mine! (I think I’m going to have to make a page of them soon). He has some great info on his site that really helped me understand some of the more subtle aspects of pH measurement.

I decided to use the hardware I2C port rather than the software ports provided as part of JeeLib – I figured that perhaps the processing overhead might be a bit lower, but I haven’t tested that assumption. The demo sketch provided with the hardware worked great out of the box, and Naomi then wrapped it in a class and got the data sent over the radio.

The only other fiddly detail was getting the power consumption down, as the circuit consumes a few milliamps constantly. I tried a few different ways to power the circuit and eventually settled on using a digital out to raise vcc high when I need it. The draw of the circuit is well inside the limits for the IO pins, and it seems to work fine. This way I can sleep most of the time and only switch on the sensing circuit when required.

I did some testing and found that the pH circuit needs quite a bit of time to settle, and I ended up allowing five seconds for the circuit to ‘warm up’ before reading from it. Even then the results often carry on dribbling up (or down) for quite a while. So rather than a pattern of ‘wake up, measure, sleep’ that we’re currently using, in the future we’ll be implementing a scheme where the sensor wakes up, keeps the pH circuit powered up for some time whilst taking measurements, then sleeps. Of course the mcu/radio can be sleeping during most of the measurement time, but the sensor would remain powered up.

In an ideal world I’d like to do some more clever work in software to measure the speed of change and basically predict where the results will settle. This should give a fast reading despite the pH probe actually taking ages to settle. And also, let’s face it, getting pH accurate to one decimal place is great for most situations, and the extra place may be questionable anyway as I’m not sure the accuracy is quite equal to the resolution.

And finally, the battery is from Adafruit, as detailed in the overview page. With a sleep current of 7μA against a capacity of 1200mAh, we should be good for a couple of years I reckon, even if we spend a fair fraction of one percent of the time awake.

The microcontroller sketches that configure and then run the sensor are available over at github – we are developing a system based on Node-RED to receive the data that you can also download from github. I hope that you find our work useful, and build something yourself with it, just as we’ve built on the astounding work of so many others. Happy hacking!!

The post Wireless pH sensor appeared first on layer zero labs.

Posts on the Eve-alpha wiki led me to an image of the modifications I needed to make:  Now I have the radio connected to CE1 to enable it and GPIO 24 (#5 in WiringPi convention) as the IRQ line. Potentially this could allow us to be polled when messages arrive. (Actually I needed to change this later on – stay tuned!)

I found a raspberry pi driver that exposes the RFM12B as a device in /dev/ Fantastic!! It’s here. So we can download it and then edit the config with a
git clone https://github.com/gkaindl/rfm12b-linux.git
cd rfm12b-linux
nano rfm12b_config.h

The following values needed to be changed for my situation, one to enable use with the raspberry pi and the other seemed like a good idea, as I’ll be planning to interoperate with JeeLib code shortly:

#define RFM12B_BOARD 1
#define RFM12B_DEFAULT_JEE_ID 1

Then make moaned about not having the kernel sources. So I installed the 3.10-3-rpi kernel (was 3.6) and rebooted as detailed here.

EDIT – responding to issues raised on Github – boiled down method of installing a recent kernel complete with headers on bare 2014-01-07-wheezy-raspbian is:
sudo aptitude update && sudo aptitude upgrade -y
sudo aptitude install -y linux-image-rpi-rpfv linux-headers-rpi-rpfv
echo -e "kernel=vmlinuz-3.10-3-rpi\ninitramfs initrd.img-3.10-3-rpi followkernel" | sudo tee -a /boot/config.txt


EDIT – Raspberry Pi 2 ISN’T WORKING YET! see here. 

On reboot, uname -r should say something like

3.10-3-rpi

rather than

3.10.25+

Now the code will compile! Back in the rfm12b directory, we can proceed to load the spi module (if not blacklisted in /etc/modprobe.d/raspi-blacklist.conf) and the radio driver:

sudo modprobe spi-bcm2708
sudo insmod rfm12b.ko

If this works you probably want it loaded on boot automagically like this

sudo cp rfm12b.ko /lib/modules/3.10-3-rpi/
echo -e "rfm12b" | sudo tee -a /etc/modules
sudo depmod -a


On the JeeNode Micro, code from JeeLabs seemed a good place to start, but I also need a way to get code onto the Jeenode micro. Unlike many larger arduino compatible/inspired devices, it doesn’t provide a USB interface. Instructions at JeeLabs suggested I could use the Arduino IDE, and a diagram.

The latest beta of Arduino is more friendly with other hardware, so I downloaded that with a
wget http://downloads.arduino.cc/arduino-1.5.4-linux32.tgz
tar xzf arduino-1.5.4-linux32.tgz

Next the hardware description of the JeeNode board from Jean Claude’s repository is needed, so I downloaded and extracted that:
git clone https://github.com/jcw/ide-hardware.git
mv ide-hardware arduino-1.5.4/hardware/jeelabs.

Now when I start the arduino IDE I get an extra option in the board menu!!

Using my cheapy clone USBasp device (but ensuring that I didn’t connect the 5v to the JeeNode Micro) I managed to set the fuses:

avrdude -v -p t84 -c usbasp -U lfuse:w:0xc2:m -U hfuse:w:0xd7:m -U efuse:w:0xff:m

and then I could use the ‘Upload Using Programmer’ in the arduino IDE to program the JeeNode. I uploaded the rfm12b_echo_client example to the JeeNode and fixed it up so that the baud rate was one of the permitted ones for TinySerial (it only supports a few baud rates so setting it to other values supported by the regular serial library gives an error on compilation). I also added the lines from the JeeLabs site to turn the radio on just before the rfm_initialise command:

bitSet(DDRB, 0);
bitClear(PORTB, 0);

After a bit of faffing I was able to see the send LED pinging away every second, but nothing on the raspberry pi side where I was running rfm12b_jeenode and rfm12b_echo alternately. After many false starts I finally re-read the kernel driver instructions again and remembered that the interrupt line is specified as going to pin 22 on the pi’s GPIO, not the one I’d used following the Eve Alpha guide.

Once I soldered the wire to that line instead, the raspberry pi started echoing ‘hello’ from the radio! I moved all round the house and couldn’t get it to drop a packet, even from the kitchen to the bedroom (it’s not a big house, to be fair).

The post RFM12B linking a JeeNode Micro with a Raspberry Pi appeared first on layer zero labs.

For various reasons I’ve needed to retrace my steps a few times, so here I’ll document them all for my and your convenience. Starting point is a fresh download of Raspian (2014-01-07). End point will be auto-running a monitoring node with sms capability.

My latest trick is to create a 200MB ‘dummy’ partition at the end of the SD card using gparted before putting the card in the pi. Because the auto-resize script can’t deal with this arrangement I also expand the partition in gparted. This way the main, expanded filesystem will be a little bit smaller, to cope with the fact that sometimes SD cards are a few MB smaller than you would like. Now I can image and recover the main two partitions and if the dummy partition gets corrupted because it is truncated then it can just be deleted.

After first boot, ssh using username pi and password raspberry. Run sudo raspi-config to enter the easy config. Change password and set the timezone, then in advanced – change hostname, ensure that the graphics split is 16MB, enable SPI and reboot.

Ok, now after logging back in we do a quick install of some packages via aptitude (also adding in mosquitto for mqtt brokering and gammu for text messaging):
sudo aptitude update && sudo aptitude upgrade -y
sudo aptitude install bootlogd monit mosquitto gammu gammu-smsd

Now get the node stuff: (not sure if the npm updates are needed or not tbh!)
wget http://node-arm.herokuapp.com/node_latest_armhf.deb
sudo dpkg -i node_latest_armhf.deb
rm node_latest_armhf.deb
sudo npm install node-red -g
cd /usr/local/lib/node_modules/node-red
sudo npm install serialport stately wiring-pi
sudo npm update


Configure gammu (from this excellent page, thanks Mattias!) by identifying the port. Plug in your 3G dongle with a valid, activated sim card. Use dmesg | grep ttyUSB to find the USB port used for the modem. I found that I had three ports assigned and I tried them all to find that the last one assigned worked. Gammu has a config script helper you can activate with a sudo gammu-config – the only thing I needed to change was the port. Then your should get a sane response from sudo gammu --identify like this:

Device : /dev/ttyUSB2
Manufacturer : Huawei
Model : unknown (K3520)
Firmware : 11.314.12.02.00
IMEI : 15 digit no.
SIM IMSI : 15 digit no.

Now we need to edit the gammu daemon config file with sudo nano /etc/gammu-smsdrc to put the port and speed used by the modem in, e.g. /dev/ttyUSB2 and at19200. To test it you can start the daemon with sudo service gammu-smsd start and then echo "Hello Earth, Mars calling" > /var/spool/gammu/outbox/OUT###########.txt (replacing the #’s with your phone number) you should get a text!

And a killer autostart script from here (thanks Antoine Aflalo) and monit script from here (thanks Giovanni):

sudo nano /etc/init.d/node-red

#!/bin/sh
#/etc/init.d/node-red

### BEGIN INIT INFO
# Provides: node-red
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start or stop the node-red server
### END INIT INFO

NAME=node-red
DAEMON=/usr/local/bin/node
SCRIPT_DIR=’/usr/local/lib/node_modules/node-red/’
OPTIONS=”–max-old-space-size=192 red.js -v”
LOG=’/var/log/node-red.log’
USER=root:root
PIDFILE=/var/run/node-red.pid

. /lib/lsb/init-functions

start_daemon () {
start-stop-daemon –start –chdir $SCRIPT_DIR –background \
–chuid $USER \
$START_STOP_OPTIONS –make-pidfile –pidfile $PIDFILE \
–exec $DAEMON — $OPTIONS >> “${LOG}” 2>> “${LOG}” </dev/null
log_end_msg 0
}

case “$1” in
start)
log_daemon_msg “Starting daemon” “$NAME”
start_daemon

;;
stop)
log_daemon_msg “Stopping daemon” “$NAME”
start-stop-daemon –stop –quiet \
–chuid $USER \
–chdir $SCRIPT_DIR \
–exec $DAEMON –pidfile $PIDFILE –retry 30 \
–oknodo || log_end_msg $?
log_end_msg 0
;;
restart)
$0 stop
sleep 5
$0 start
;;
status)
status_of_proc “$DAEMON” “$NAME”
exit $?
;;

*)
echo “Usage: $0 {start|stop|restart}”
exit 1
esac
exit 0

And now we can do a:

sudo chmod 755 /etc/init.d/node-red && sudo update-rc.d node-red defaults

to install the startup script. On reboot, the node-red daemon should start, along with the mqtt & text message server.

To configure monit, edit /etc/monit/monitrc if desired to set the time intervals of the checks and to set the users who can do web monitoring. Add a line at the end to include an additional directory for service definitions:

include /etc/monit/monitrc.d/*

Finally create a file to configure the monitoring of node-red (again tweaked from Giovanni to cope with authentication enabled on the pi) with sudo nano /etc/monit/monitrc.d/node-red

check node-red with pidfile /var/run/node-red.pid
start program = “/etc/init.d/node-red start”
stop program = “/etc/init.d/node-red stop”

if failed url http://username:password@localhost:1880 timeout 10 seconds then restart
if 3 restarts within 5 cycles then timeout

If node-red dies, then monit will start it up again within 30 seconds. Monit can be monitored and controlled remotely quite easily on port 2812.

To send a text message via node red, just configure a file node to save a file to the /var/spool/gammu/outbox with the format OUT############.txt where the hashes are the number you want to send. Once the message is sent gammu will automagically move the file to the sent folder for you.

The post Setting up a Pi from bare Raspbian to work as a Node-Red controller appeared first on layer zero labs.

I started with the occidentalis distro from adafruit – and to install node.js itself I needed to use different package to match the pi

wget http://node-arm.herokuapp.com/node_latest_armhf.deb
sudo dpkg -i node_latest_armhf.deb

but apart from that things were fairly smooth, I farted around for ages trying to get a manual build of wiring-pi to be recognised, then just randomly tried a

npm install wiring-pi

to install the library directly, and that worked great!  I edited the node-RED settings.js file to add in the ability to use wiring-pi in the global context, and then restarted node-RED.

I wanted both mosquitto and node-RED to start automatically on boot, and rather than use rc.local I created a file in /etc/init.d like so:

sudo nano /etc/init.d/mqttstart
sudo chmod 755 /etc/init.d/mqttstart
sudo update-rc.d mqttstart defaults

the mqttstart script just consists of:

mosquitto -d
cd /home/pi/node-red
screen -dmS red sudo node red.js

So after all that setup; I loaded up node-RED and copied in the blink example and got that working!! but then changed the code around a bit, and looked into the pwm capabilities of the pi. Turns out it has one built-in pwm function and the wiring pi library provides soft-pwm on other pins.

So I changed the pin to pin 1 (wiring-pi convention) and hacked at the blink example function code to show the pwm functioning:

Here is my code, as per the example on the node-RED documentation, just copy the text into the clipboard, then select import from clipboard in the top right and paste it in:

[{"id":"ce4d5b27.31b2a8","type":"function","name":"fade LED up and down on input","func":"\n// select wpi pin 1 = pin 12 on header\nvar pin = 1;\n\n// initialise the wpi to use the global context\nvar wpi = context.global.wpi;\n\n// use the default WiringPi pin number scheme...\nwpi.setup();\n\n// set the mode to pwm output\nwpi.pinMode(pin, wpi.modes.PWM_OUTPUT);\n\n// do the fade up/down in brightness thing\n\nfor (var i=0; i<256; i++){\nwpi.pwmWrite(pin, i*4);\npausecomp(5);\n}\nfor (var i=256; i>-1; i--){\nwpi.pwmWrite(pin, i*4);\npausecomp(5);\n}\n// we don't \"need\" to return anything here but may help for debug\nreturn msg;\n\n// timing function hack kudos Pavel Bakhilau via Sean McManus\nfunction pausecomp(ms) {\nms += new Date().getTime();\nwhile (new Date() < ms){}\n} ","outputs":1,"x":505,"y":370,"wires":[["6c906a60.936f94"]]},{"id":"df3260b7.20cda","type":"inject","name":"tick","topic":"","payload":"","repeat":"1","crontab":"","once":false,"x":291,"y":344,"wires":[["ce4d5b27.31b2a8"]]},{"id":"6c906a60.936f94","type":"debug","name":"","active":true,"x":730,"y":385,"wires":[]}]

And now it works to light an led progressively.

Then I replaced the directly driven led with one driven by a TIP120 transistor – keeping a resistor (820Ω) in place to limit the current out of the pi. I haven’t got a convenient 12V load to test it with right now but here’s the same led but with a lot more current drive potential!

As a nice way to check my sanity, I set the light onto 100% and measured the current drawn from the pi – my cheap multimeter measured 2.31mA which is gratifying as my calculations here predicted 2.3mA! Way to go theoretical predictions!

The post raspberry pi running node-red, wiring-pi to pwm control a light appeared first on layer zero labs.

Firstly Node-RED depends on node.js, so I installed node.js via Chris Lea’s ppa – he seems like the right sort of person to package up the current stable version and keep it up to date. The instructions here: https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#ubuntu-mint worked fine except that I omitted the specific version string and apt-get automatically chose the more recent version. I got v0.10.18-1chl1~raring1 which is bang up to date. If I’d used the package manager without adding Chris’s repository then I would have got v0.6.19~dfsg1-5ubuntu1 which is almost certainly too old for node-RED.

Then to install Node-RED itself – the installation page here: http://nodered.org/docs/getting-started/installation.html is very well written so I won’t duplicate it here. Helpfully, the example of installing additional nodes is for twitter, so I went ahead and did a

 npm install ntwitter oauth

then I could just get going with

node red.js

and voila! my browser at localhost:1880 now displays a Node-RED screen.

Next up – install a mqtt broker – seems like mosquitto is a good one, but again the official repositories lag way behind the code, the ubuntu one is at 0.15 and the mosquitto provided one (http://mosquitto.org/download/) is at 1.2! I started it with a

mosquitto -d

and my test node:RED program is this one:

It’s super easy to configure the mqtt subscribers and publishers, I used an injection node as a trigger and firstly saw that messages were flowing into mqtt and out to the debug module. Then I rewired it, clicked deploy, and then my tweet was sent straightaway! (the injector fires at startup by default).

The post Tweeting with Node-RED via a mqtt broker appeared first on layer zero labs.

So much so, that my friend was asking me to help fix them instead of sending them off to a specialist service – costing £180!

After taking the wrong deck apart and struggling to find any problems (nice one Jimmy!) we realised that the other deck’s problems were due to a signal cable which had a nasty bulge in it covered by sticky blue tape. Under the tape the leads had been half-heartedly twisted together, and needless to say, were now well oxidised and making poor contact. The earth lead was also damaged and ‘repaired’ in a similar way.

The hardest part of the job was removing the bottom rubber plate which has loads of screws! There are a couple of different types, if you are doing this. make sure you don’t get them mixed up like we did (duh).

Once the rubber bottom piece is removed, next we had to remove the circular plate that provides strain relief and signal shielding. Best to remove the strain relief block first (it’s difficult to describe how this works, but a couple of minutes fiddling with it should make it obvious!!) and then the circular plate just unscrewed.

After that, it was just a case of de-soldering the old cable, cutting a new one to suit, few seconds work to solder it in and replacing the cable tie. Notice that there are two separate strain relief devices, this sort of build quality and attention to detail is part of why these things cost more today than when they were being made! Seriously, you can pay £1300-2000 for a box-fresh (old but unused) 1210 – that’s just for one deck, and most people want two! Having heard Jimmy bang on about their superlative qualities endlessly I finally got to appreciate them directly – it’s true that if you want to know how well something has been made, then try and repair it.

After that it was time to re-assemble and test – over to you, Jimmy,

A nice little job, took about half an hour, and a fair bit of that was taking apart and re-assembling the wrong deck! – saving our mutual friend (the deck’s owner) a tidy £180.

The post Fixing Technics 1210’s appeared first on layer zero labs.

Using it, I worked through my use case of an raspberry pi connected to a TIP120 to drive a 12V LED light.

diagram from http://ctheds.wordpress.com/2007/10/30/tip-120/

What value of resistor should I use? I’ve seen several different values on web examples, so looks like I need to actually understand something rather than just cut’n’paste!!

So, my load uses 12V and lets say 300mA of current (I don’t know the actual value yet, but it will be around there).

Looking at the datasheet we can see from top line on the graph in figure 2 that when the collector current (I_C) is 300mA then the voltage at the base (V_BE) will be about 1.3-1.4V. Lets say 1.4V because this way we are heading in the direction of handling more current, i.e. getting a bit of a fudge factor safety margin.

So knowing that the voltage across the base needs to be 1.4V, and the pi puts out 3.3V logic high, the resistor will have a voltage across it of 1.9V.

The bottom line on the graph tells us that at the collector current (I_C) of 300mA, the collector voltage is 0.5V. In other words, the transistor itself will ‘drop’ 0.5V across it, the rest of the supply voltage (12V) is presented across the load. So the lights will get a little bit less voltage (11.5V) than they are used to, but they should still work fine. If this voltage dropout is a problem I’ll have to use a relay or some other more exotic solution like an ultra-low dropout transistor

Also given in the corner of figure 2 on the datasheet is the current ratio at saturation, which is I_C=250I_B. So I_B=I_C/250, with our load of 300mA that gives a base current I_B of 1.2mA. To be safe, we’ll make sure that we actually drive the transistor a bit harder than that, so that we can get it into saturation quickly and fully, say at 2.5mA.

So the resistor needs to pass 2.5mA and it has 1.9V across it. Ohm’s law says V=IR and therefore R=V/I; 1.9/0.0025= 760Ω/.

Next value up is 820Ω, will allow 2.3mA to pass, close enough, and still well over our calculated saturation point. The next resistor value down in the standard series is 680Ω – which would allow 2.8mA to pass and would also be just fine. So I’ll use whichever one of those is handy. I will investigate using a 10k pull down resistor on the base to ensure that the transistor is switched off when the raspberry pi is in a high impedance state (perhaps during booting), not sure if that will be necessary or not.

The post Transistor calculations for a 12V 300mA light via raspberry pi gpio pin appeared first on layer zero labs.