Raspberry Pi GPIO Part 2: Relays

The relays arrived.  They are neat.

These are uxcell HK19F relays, which came in a pack of 10x for $6.89 and free shipping from Amazon.  Just make sure you pick a seller that is in your local country unless you want to wait a month because there are so many Chinese sellers on amazon now.  They're DPDT which means Dual Pole Dual Terminal, so there are two individually switched inputs that each go to two different outputs.  One is normally open, and one is normally closed.  If you saw my previous blog post about the hotwheels radar gun, I need this to simulate the trigger which bridges one pair of wires when the trigger is pulled and bridges the other pair (to show top speed) when the trigger is released.

Here I will give you poorly constructed explanation of what I perceive to be going on.  I've also traced the diagram since it's really hard to see.
When the coil is not engergized Input 1 is bridged to Output 1A and Input 2 is bridged to Output 2A
When the coil is energized Input 1 is bridged to Output 1B and Input 2 is bridged to output 2B
It's possible that I have normally open/normally closed swapped because I did not verify, but am assuming that the image shows the relay in the "unpowered" state.

Increasing the 3.3v GPIO output to run a 5V relay coil

So unfortunately the output of the GPIO pins is 3.3v and very low current, so we're going to need to amplify it somehow.  We're going to use a transistor to do this.  You've probably heard about how transistors revolutionized technology and made computers smaller than buildings and radios smaller than refrigerators by replacing vacuum tubes.  Me too, but I had no idea how they worked.

This is a transistor.  It's main function is to act like a switch that's toggled by a very low amount of power (sort of like how a relay works).  However a transistor and be activated by a lower amount of power than a relay, but cannot handle as much current as a relay.  In some cases you can use a MOSFET which is sort of like a beefy transistor with a heatsink which can kind of do both jobs reasonably well.

The Emitter pin (bottom) goes to ground.

The Collector pin (top) is what your circuit should ground into.

The Base pin (middle) is what you give a tiny bit of power to and it opens the flow from Collector to Emitter.  Think of a transistor as a valve and by applying power to the Base pin you're opening the flow of electrons from Collector to Emitter.

These rules Assume you are using an NPN transistor.  A PNP transistor is totally different, it does something like positive power supply to Collector, Emitter to your circuit, and power can flow when base is grounded.

Ok, so +5V supply red wire, goes to one side of the coil on the relay.  The other contact on the relay coil goes to the collector pin on the transistor.  The emitter pin on the transistor goes to ground via the black wire.  The grey wire is a 3.3v GPIO output from the pi going to the base pin on the transistor.  Use a resistor where gpio enters the transistor, not shown.  You dont want to pull more than 16mA from the pi or you can damage it. 330 ohm worked for me and dropped draw from 40mA to 7mA.  When a small 3.3v current is applied to the base pin, the transistor allows the 5 volts to pass through the coil on the relay which toggles which outputs are connected to the inputs.

Here's a closer look:

The Brown wire is going from a 3.3v output (rail, not GPIO) on the pi to input2 I talked about above (remember the relay is flipped over now so input2 is on the left now).  I have output2B going to the positive lead of an LED, and the other lead going to ground.  The LED is on the normally open output but the reason it's lit up is because the program is already running in this picture.  I ran a simple python script that toggles the GPIO output on and off every second (which I covered in the GPIO part 1 post).  If I connected a second LED to output2A then the LEDs would alternate as the relay is cycled and would never be on at the same time.  There's just really one thing that's missing here...


This is a diode.  A diode only lets power flow one way.  Apparently when driving a relay with a transistor you're supposed to put a diode across the coil IN REVERSE.  Basically the positive lead on the diode needs to go to the negative side of the relay coil and the negative lead on the diode needs to go to the positive side of the relay coil.  The reason for this is that you are creating a magnetic field in the coil to open it, and when you stop powering the field that coil can output power as the magnetic field collapses and damage your transistor (sort of like how a motor spins when you power it but then outputs some power when spun).  Allegedly this is the reason why, and I might not even be getting that right, so you might want to look up the reason yourself.  Anyways I recommend you put a diode in backwards because every example I've seen says to.  It will be obvious if you have it "wrong" (not backwards, and yes this is super counter-intuitive) because your relay will never cycle and your transistor might burn out (as there is no resistance in the diode so it just lets you bypass the coil and dump all that power from the +5v rail to the ground straight through your diode (which will get hot from that much current) when you introduce a current on the gate pin).

So there you go.  Relays are kind of fun because you can hear them cycle as they're mechanical.  As my relay turned on and off it sounded like the turn signal of a car (which coincidentally operate off of... relays!).

So we're taking about 15mA at 3.3v from GPIO and using a transistor to enable a 5 volt circuit.
That 5 volt circuit opens and closes circuits on the relay.
That relay can handle 1 Amp at 125VAC or 2 Amps at 30VDC.

Go big or go home

Now I don't believe there is a reason you can't "stack" relays, and this is probably actually a thing and there is probably actually a name for it.  So in theory you could use this not very big relay to toggle a 12v circuit that powers the coil of a huge ass relay, effectively toggling hundreds of amps with your wee little GPIO output.

Raspberry Pi GPIO functional examples (Read/Write)

"The knowledge, it fills me. It is neat."
          -Gir, Invader Zim

One of the things I've been putting learning is how to read voltage on GPIO pins, as well as output a voltage to turn devices on.  Using an LED that can handle up to 3.5 volts or so, and a motion sensor module that outputs a 3.3v signal, I figured out the basics.  There are three things I'm going to go over, and those are sensing voltage, outputting voltage, and sensing continuity using GPIO pins.

For most of this section I'm using HC-SR501 motion sensors from Amazon (Most are sold from China but A seller named "Nevada Robotics" ships them prime).

This sensor is great because you can power it with 5 volts (what the pi outputs) and it in turn outputs a signal of 3.3 volts (what the ideal/max voltage is to sense with GPIO is).  When it outputs a 3.3v signal, it really just outputs a voltage of 3.3v at a low current.  If you want to run a 3.3v device off of it you will need to use a transistor, and even a relay if it's a higher draw device.  Your motion sensor and pi need to be grounded together if they are not running of of the same power source.  These motion sensors have two screws on the back, one that will control how long the output signal lasts on motion (which I turned all the way down), and another that will control how sensitive the device is (which I turned all the way up).  I forget which is which but the data sheet is easy to find with some moderate google-fu.  Also keep in mind that the documentation on this sensor said it's somewhat unreliable for the first 60 seconds while it starts up, but it seemed fine to me!

Also you can refer to the GPIO pinout on this page so that you know what pins I'm using.

Sensing a signal (voltage)

Here's a little breadboard.

Top red/black pair: Power to the breadboard

Bottom red/black pair: powering the motion sensor

Brown: signal from motion sensor

Yellow: to pi's GPIO 4 pin

LED: Also lights up when motion is sensed to help with debugging

Here is some code that you can run.  You define GPIOPIN=4 so that it knows you are working with GPIO4.  Since we are using GPIO.setmode(GPIO.BCM) it's going by the pin numbers on the Broadcom chip channels, or something.  The other option is something like GPIO.BOARD if you wanted to reference the pins by placement number.  I went with GPIO.BCM since you have to look at the diagram to see which pins can do GPIO anyways.

So DetectMotion() will return a 1 or 0 when called; 1 means there is currently motion and 0 means there is not.  Motion meaning it's sensing 3.3v on the GPIO4 pin, because I'm using a motion sensor.  You could have this sense anything that outputs 3.3v, or a higher voltage if you use appropriate resistors.

Then we have a infinite while loop that is constantly calling DetectMotion and if it ever comes back with a 1, prints out "Motion was detected!".  It will only do this once no matter how long the motion/signal lasts for because it's got a while loop that just passes (does nothing) until there is no motion/signal and it exits the loop.

The whole thing is wrapped in a "try" so that when it gets an exception (KeyboardInterrupt) it can run GPIO.cleanup() which removes the configurations from your GPIO pins so you don't get nasty errors that they are in use the next time you run the script.

And this is what you should see!  Every time the LED lights up it should say "Motion was detected!".

Outputting a signal (voltage)

Here is an even simpler breadboard.  Grey is going from GPIO27 on the pi to the positive lead on an LED which has the other lead grounded.  Again your LED usually needs to somehow be grounded to the pi but in this case I'm using the same 5v power source so it does not.  Also use a resistor to limit draw from GPIO to 16mA or less.

Here's an example of some code that will make the LED blink by alternating 3.3v and 0v out each second on GPIO pin 27.

Of  course the output in the console is very anti-climactic.  I should have put in an echo that said "turning light on" when setting the pin to 1 and "turning light off" when setting the pin to 0.  Now your output doesn't necessarily need to go to an LED, it can go to a transistor to drive a relay.  I'm still learning about transistors myself but have ordered some releays that will get here in a few days.  When they do, I'll write something up on how to drive them via a pi.

Having an input signal trigger an output signal

You're then able to use an input signal to trigger an event in python code that will turn on or off your output signal.  So lets make it so that when our motion sensor sends the pi a 3.3v signal, it will blink the LED quickly.  We'll set up the breadboard as so:

The lower Positive/Negative pair are powering the motion sensor.
The brown wire is the signal coming from the motion sensor.
The yellow wire is going to the PI's GPIO4 pin.
The grey/purple wire is coming from the PI's GPIO27 pin to the positive end of a grounded LED.


Here is some code that listens for a signal on GPIO4 and will output one on GPIO27.  Notice that I had to pick new names for the pins since there are more than one.  Instead of GPIOPIN, I'm using GPIOinput and GPIOoutput.  You will need to also update any references from GPIOPIN in your code if applicable.  You only need to do GPIO.setmode(GPIO.BCM) one time for any GPIO pins you reference.

You can see how the GPIOinput and GPIOoutput pins are setup on seperate lines, then I toggle the output to 1 for 1 second, then toggle it to 0.  I did this for two reasons, first when you set up the the output it seems to start as 1 so you need to disable it, and secondly having the light come on for 1 second helps you know that the script is actually starting properly.

The definitions (functions) should look really familiar from the examples above.  The whole thing runs forever in that while 1 loop, where whenever motion is sensed, the pi will keep calling the "ToggleOutput()" function until it stops.  The "ToggleOutput()" function blinks the LED and this time actually prints "blink" every time the LED is going to blink.  With a .1 second sleep, you should see the light flash about 5 times a second (but only when there is motion.


And there you have it!  When the sensor sees motion, it sends the 3.3v signal to the pi.  that triggers the pi to tell you that there was motion and start repeatedly calling the ToggleOutput() function that blinks the LED as long as the motion continues.  At the end of the runtime there was a longer set of blinks because it was longer continuous motion.  Neat!

Sensing continuity

Sensing continuity is fairly straight forward.  You basically create a signal on a GPIO pin and sense when it drops (from being grounded).  So what I did is use GPIO18 and a GROUND pin to go to a switch.  When the circuit is open, the input will show True.  When the circuit is closed, the input will show False.  The difference in this from sensing an input is that we are using PUD_UP to supply a small voltage to the pin we are listening to which will make the pin show False until it is grounded.

Now just connect wires to GPIO18 and GND.  Then connect those wires to a switch, or just strip them and you can touch them together to simulate a switch.  The reason for the .1 second sleep is that I saw a little bit of jitter on state changes.  That's probably because I was just doing a bad job at making a solid contact.

Here's what you will see as you touch the wires together and pull them apart (or toggle a switch if you are using one).  I'm using this to sense my garage door through a magnetic reed switch, and my script will text me with a timestamp whenever the door becomes open or closed.  The while/pass portion makes it so that you only have your event happen once time on each state change.  I had the option to use a normally open or normally closed switch.  Well I used a normally closed switch for my garage door, so if the wiring ever fails it will tell me the door is open and I'll be forced to go check "why my garage door opened at 3am" (sort of a failsafe).  If you use a normally open switch, and your wiring fails, it will just never alert you when your door opens.

Well hopefully this helps!  It's been a lot of fun learning this and you can imagine all the projects that this opens your pi up to.

Adventures in Radar with the Raspberry Pi (Part 2)

This is a continuation on a previous post, which you are advised to read first.

"It came!  It finally came!" -Sid from Toy Story.  Also myself.

Alright, lets rip this shit open!

Well this is embarrassing... I did not mean literally!  I had a lot of trouble with drilling out the screw caps, which was compounded by the fact that the cheap plastic was also very brittle and kept "grabbing" the bits.  I could have done this really cleanly with a drill press but since I was drilling freehand the bits kept pulling and stripping screws.  Since the whole process was going to disastrously anyways, I ended up just tearing it apart.


Pay no attention to the huge dent in my waveguide from the drill bit!  Hopefully it won't affect anything too much...

So we have the RF TX/RX module with a waveguide soldered to it.  Then there is a little PCB with the screen and buttons on it.  Finally there is the end of the battery holder with a dual pole dual terminal switch for the trigger.


Here's a picture of the back of that battery holder/switch assembly.  There are two sets of wires, Brown and Blue.  It looks like when you pull the trigger, the blue wires are bridged to take a reading, and when you let go, the brown wires are bridged to report the highest captured value.  I've already ripped off the black and red positive and negative terminals from the battery connector.


Here's a closeup of the board and the radio module.  There are only three wires going to the radio module, red, black and white.  Black is ground, white is "SIG" (our Doppler shift signal), and red is "VOSC" which I can only venture to guess is "voltage oscillated".  This is important because I vaguely remember that some devices are "pulsed" as opposed to a continuous wave.  I'd be worried that taking out this board would then change the way the radar module operates.


I powered up the device with some alligator clips and waved by hand in front of the waveguide and it registered 512 miles per hour.  That did not seem right.  Then I remembered that red switch on the left controls "Scale", so that you can radar a hotwheels car and figure out how fast it would be going if it were the size of a real car (it just turns on a 64x multiplier for speed).


This seems more reasonable.  Obviously you have to push and hold the button (simulating a trigger pull) to get real-time readings, and highest speed is reported when you let go.


Alright, time to solder some breadboard leads onto the wires that used to go to batteries.  If you solder but don't have a set of "Helping hands", get one.


Seeing as how everything seems to work, I then soldered a breadboard wire onto the SIG connection to try to tap into the signal coming out of the radar module.  This picture courtesy of the magnifying glass on my "helping hands" that I was repping above.  Unfortunately the GPIO input of the PI did not register anything.  I hooked up a volt meter which will only give a rough idea because I'm checking the voltage of sine wave (I guess) and only picked up about .04 volts.  Bummer, I'll need to figure out how to get that up to something reasonable to get the pi to read it.  Feeling defeated I gave up for the day.

BRO OF THE WEEK AWARD

goes to "Zerodegreec" for his contribution in reply #7 of this post on the arduino forums seen here:

This is super exciting because this "test point" he's referring to leads to the signal from the radar unit AFTER it's been amplified.  I took a reading on it and it seems to output over a volt which is 20x more power than I was seeing from the SIG wire out of the radar module.  I don't know if there is a way to directly convert the reading of a voltage of a frequency, but "more" is good enough for me to get my hopes up!  Also notice in this picture that a brown wire was added to go to the ground of the ATmega644 that was connected to the test point; I did not need to do this because the pi and radar module are being powered by the same 5v power source (the USB battery) with a common ground.


I soldered a breadboard wire to the "test point" on my board.  It's on there but barely.

There, much better!  The hot glue that came on this thing is obnoxiously effective so I added some of my own.

Since 5v into the pi's GPIO will release the magic smoke (I'm feeding this board 5v), I tried first with a 1k resister, the same size that I was using to drop the 5v signal to about 3.3v on the old radar module.  I connected the the lead on the other end of my resister to the pi, pulled the trigger, waved my hand in front of it and hoped for the best!


Neat!  Except for that last reading which must be an anomaly.


This is a capture of me walking towards the module.  According to wikipedia, the average human walks at 3.1 mph.  The average human however isn't usually carrying a laptop and walking like an idiot while being overly conscious about trying to walk a normal speed.  What I noticed is that when nothing is really moving there are virtually no readings, and this is awesome.  The previous radar module I tested had tons of background chatter, so much so that I told my script to only output readings over 3 mph.  Lets try something a little faster...



I figured a flap made of foil tape on a bike tire rotating in the path of the RF would give me some kind of reading.  With the bike upside down I turned the pedal for a bit and pulled/released the trigger button so I could compare the top speed the radar captured with the top speed my script captured:


Seems pretty close to me!  The samples are really poor as it's a small target but the LCD reported 25 and my pi reported 27.07.  I'm wondering if the fractions of miles per hour are the Doppler shift of the wheel vibrating or something.  It's time to find something with a little more consistency.


I pointed the waveguide at the fan in different angles until I found one that the value didn't fluxuate much at all.  Some angles I was getting up to 40mph (with very poor consistency) which makes sense because the amount of Doppler shift is going to be affected by your angle of reading due to the cosine effect.  I started getting a really solid reading that was showing 12 miles per hour on the LCD screen.



Look at that!  Those are some solid readings!  I tried a few different tweaks and it seems like the best results were sampling the signal and waiting for it to decrease in voltage twice, and finding the time between them.  Then I averaged three such readings to get a more consistent speed.  I might not even need to calibrate as this radar module is 10.525Ghz just like the last one, and thus the same equation of 31.36Hz per MPH still seems to apply.  I'll probably still need something to remove the occasional anomaly though I only saw that when I had my hand within a few inches.


My current code.  When you call the "getspeed()" function, this is what happens in a nutshell:
1.  Wait for the GPIO voltage to be falling (signal wave dropping)
2.  Set the variable "start" to the current time
3.  Watch for the wave to drop two more times
4.  Subtract the start time from the current time to get the "duration"
5.  Divide the number of cycles (samples) by the "duration" to get the frequency in Hz (or waves/sec)
6.  Divide the frequency (in hertz) by 31.36 to get "speed" (miles per hour)
7.  Return said speed

So in the while loop I'm just adding the result of the getspeed() function three times and dividing by three to get an average.  I also have another IF statement below to take a picture if a certain speed is exceeded (not pictured).

What's next?
Now I need to put everything else together.  My plan is to get a DPDT (dual pole dual terminal) relay for the trigger assembly.  This will basically give me a relay that when I power the coil, it will take a radar reading, then when I stop powering the coil it will revert to the "highest" state (remember the trigger has two pairs of wires going to it).  That will allow me to have the LCD screen output the highest captured value after a sample, so that I can compare it to the highest value returned by the pi to see if they match.

How will I toggle the relay?  I've been experimenting with some HC-SR501 Passive Infrared Motion Sensors.  They have a 3.3v output that I should be able to run straight into GPIO and sense when they are triggered.  here is one that I was using to light up an LED when there is motion:


So my idea is that the pi will be alerted to motion when the PIR is triggered and sends a 3.3v signal to the pi via GPIO.  Then the script, having sensed the motion, will start listening for signals from the radar module while simultaneously outputting 3.3v to a different GPIO pin going to a mosfet that will turn on the power to the radar module.  After capturing a few seconds of signal from the radar module the pi will use the highest one using the "max()" function, and I can compare that against what the LCD shows as the highest value captured.  The range of the PIR is only about 7 meters so I might want to have the radar measure targets as they leave AFTER the PIR motion sensor detects them passing by.

Well that's all for now!  Hopefully you are smarter now!

Adventures in Radar with the Raspberry Pi

Please be aware there is a part 2 of this post here

So I'm always thinking of that killer product I could invent that would make me millions of dollars.  I will also continue to think of it because I haven't thought of it yet.  The next best thing in my mind is to take something that exists and see if you can build it cheaper or better, or just try to build it for fun.

Well why not try to build an inexpensive speed camera?  You know, those things that take your picture if you speed which are easily contested in court!

Here's what I'll need:

A computer of some kind.  I'm using a Raspberry pi 2.

A power source.  I'm using an Anker PowerCore 20100.  This will run a pi for days.

A radar module to measure speed.  HB100 Doppler Speed Sensor
https://www.tindie.com/products/limpkin/hb100-doppler-speed-sensor-arduino-compatible/

A camera.  Arducam 5 Megapixels 1080p Sensor OV5647

The Hideous contraption that I came up with.

Measuring speed:
This doppler module is pretty cool.  It transmits a 10.525Ghz radio wave, which is X-Band Radar, and senses the doppler shift of the return signal.  This gives you an idea of how fast an object is moving.  This concept is not much unlike how a truck horn or police siren sounds funny as it drives past you.


The HB100 module (Left) and the pre-attached backpack that runs it (Right).

Notice the four little squares by the corners.  Those are the patch antennas to direct RF (sort of) ourwards.  One pair connected by a solder trace is connected to the transmitter and the other pair is connected to the receiver.

You give this module 5v (VCC) and ground (GND).  Then in return it gives you FOUT and VOUT.
FOUT: Frequency output proportional to the dopler shift.
VOUT: Voltage promotional to the amount of RF being returned.

TELL ME HOW TO GET IT WORKING ON MY PI IMMEDIATELY -what I would say
So for the Me's out there, here you go:



Look at the Radar module:
Black is Ground going to GND
White is +5v going to VCC
Grey is the frequency signal, going to FOUT



Look at the Pi's GPIO pins:
Black is Ground going to GND
White is +5v going to the 5v supply pin on the Pi
Orange is frequency signal, going to GPIO 18
Wait where did we get orange?


Bruh...  You need to lower that 5v frequency signal to about 3.3 volts otherwise you might let the magic smoke out of your pi (which is very hard to put back in).  I used a 1k resistor.  How did I know what size to use?  Some online calculator told me so and it seems to work.

Reading frequency on a pi:
We're going to use python, because it's the easiest language to be accidentally successful with.  After much google-fu I came across this stackoverflow post in which this guy saved the day.  So using his advice to "Just calculate an average frequency of a set of input cycles.":

Note that I set a GPIO.wait right before the loop to make sure that you aren't starting the loop in the middle of a wave, as we're only taking two samples and it could throw things off.

Now just use a while loop that keeps doing something with the getspeed() definition, something like:

while 1:
     if getspeed() > 5:
          print getspeed()

Run your script with sudo so that it's able to access the GPIO pins (sudo python <yourscript>.py).  Now just wave your hand at it really fast like an idiot.  I quickly set a threshhold of 5mph to even display otherwise you see tons of 0-2 mph chatter.  The antenna isn't very directional so make sure you're not near anything moving (even through a wall).

Note that this screenshot is from a slightly different version of the function above, when I was also having it outputting samples per second.

Tweaking it:
You can set NUM_CYCLES to different values.  I used 2 because small faster objects like a tennis ball only return a small amount of doppler and the speed wont register if you need a sample size of 10+. The trade off to having it that low is sometimes you get random high values returned.  You can take many small samples and average them, or take several and return the maximum one doing something like this:
speed1=getspeed()
speed2=getspeed()
speed3=getspeed()
topspeed=max(speed1,speed2,speed3)

So what is the module good at?
It seems to be pretty good at sensing speeds consistently of slower objects like a person walking, jogging, etc.  It can also sense through walls.  Seriously, it clocked me walking from the other side of a solid core exterior door.

So what is the module bad at?
It has limited range (no horn, waveguide, etc.).  It's also not very accurate at higher speeds, which I assume is because of the frequency response range of the amplifier or the radar module itself.  I failed to notice when selecting a sensor that the data sheet keeps talking about sensing human movement.  I'll keep experimenting and see if I can sort this out with this module somehow.

Anyways, lets continue!  Image capturing:
So when sensing something that's moving past a threshhold speed, lets take a photo.  In my speed capturing loop I have an IF statement that calls the following if a certain condition is met:

So the python script takes the "reportspeed" and rounds it with 1 decimal then turns it into a string.  Then it makes a shell command out of it.  I then call ./snapshot.sh <speed in mph> and wait 5 seconds (capturing an image an annotating takes about 2-3).  This is because os.system is a 'fire and forget. and I don't want it to try to take another photo while the camera is in use.

Here is snapshot.sh:

Before you go any further, install imgmagick.
sudo apt-get update
sudo apt-get install imagemagick

This script, snapshot.sh, gets called with speed as an arguement.  It grabs the current date and time.  Then it calls the camera to take a picture.  The fastest way I found to take an image is above, with a 1 second "timeout" for the camera to get ready and set white balance etc.  You also set the dimensions if you don't want a huge jpg.  You also get the filename of the time in day_month_year_hour_minute_second.jpg format.

convert is the imgmagick command where all the ...magic happens.  You pick a font, pointsize, and text with pixel dimensions from top left where you want the annocation to be.  Notice the filename in the beginning of the command and after.  That's where the original/converted files are specified.  I used the same one so upon annotating the original is overwritten.

So does it all work?
Kind of.  I've got everything working except reliable speed reporting with faster objects.  This test should have really returned about 25mph.  It seems to be accurate for slower things like a human walking/jogging/running but the results can be jittery so you may want to average a few samples.


What's next?
I'm going to see if I can figure out a way to get more reliable readings.  I've done pretty exhaustive testing with the current method I'm using so maybe I can try a dedicated frequency to ...something board.

I also saw a tear down of a mattel hot wheels radar gun that looked promising.  I've ordered one on ebay and I'm going to see how that works as it seems to have a simple frequency out like my module does (but also a wave guide).

I also got my hands on a Bushnell Velocity Speed Gun.  I figured I would take it apart and locate the frequency wire:


Welp, I'm totally lost now.  I will need to buy my buddy (who owns an oscilloscope and logic analyzer) a lot of beer to help me figure this one out.  There are some interfaces on the board containing the LCD, so I'm thinking maybe there will be a way to interface the pi there.  I can at least use this radar gun to calibrate my pi with the hotwheels radar gun electronics.  Since they are different frequencies (the Bushnell is ~24ghz K band and the hotwheels is 10.525ghz X band) I don't have to worry about one jamming the other.

Other potential problems and potential solutions that go beyond electronics:
1. Battery life on a deployment with radar always running
2. Many cars don't have front plate
3. Some cars have radar detectors
Solution to all:  Put this on the side of a road with a PIR motion sensor.  Once it senses motion, wait a few seconds and tag the asses of cars as they drive by.  You save battery because the radar is activated by proximity of a car, you tag and photo the back of a car which (usually) has a license plate, and a radar detector won't pick up the radar until it's powered, so you can clock a vehicle before they detect you and have time to respond.

I can't imaging that you could use something like this to enforce traffic laws because photo evidence generated by it would never hold up in court.  You could always just put a big hash tag sign on your lawn that says #<yourcityhere>speedbot and shame speeders with a picture on twitter!  For bonus points you can reference your local PD in the tweet!  Another thing I was thinking about is that you could deploy this in problem areas, collect data, and graph it to see trends like if you have a lot of speeders during a certain time of the day.

Final thought:
Well this post pretty much sums up about a weeks worth of on and off tinkering.  I'll probably experiment further then I get the hotwheels radar gun and tear it apart, and of course document that here.  I hope that you have found this interesting and or helpful!