LEDs via Radio Frequency

August 9, 2004 10:36 AM

Electronics filter: Need to build something that'll light up different LEDs via radio frequency. Must be compact and battery powered. My electronics-fu is pretty good, but I'm not sure it's this good... [mi]

One of the biggest problems with motorcycles is that talking via the radio doesn't work well on sportbikes (way too much wind noise and vibration, even with a throat mic) so there's no way to pass necessary information along a group of bikers unless everyone's in sight of the person in front of and behind them and can make out hand signals. If one rider finds a hazard around a blind corner, there's no way to let the riders behind him know ... and if something happens to a rider at the back of the line, there's no way to pass word forward.

My solution to this is a small device with a group of LED lights and buttons for each light. When a button is pressed, it lights up (via radio) the equivalent light on all of the other devices within range. For instance, if an alert rider spots a deer in the woods and slaps the "deer" button, the "deer" light starts blinking on everyone else's console and the whole group will know to slow down and/or take evasive action. If a rider near the back of the line has a get-off, the person who wrecked or who discovers it can alert everyone else to stop and/or turn around and come back to the crash site. Need gas? Hit the button to alert the leader to plan a stop. A device like this would make group rides safer for everyone, and ideally it would be cheaper to make and easier to mount

I understand the basics of microelectronics. I know the basics of how resistors and capacitors and transistors and different types of chips work. I've etched my own circuit boards and own multiple breadboards of various sizes. Unfortunately, I don't know how to 1) design new and creative circuits I haven't seen before (I'm very much a skript kiddie equivalent with electronics), and 2) I don't know how to find the resources that I need (for instance, a chip that will take either pulsed signals or different tones from a radio receiver and output a signal to another chip to light up a certain light). Once I find the resources I think I can hack the thing together.

Currently, my biggest issues are:
1) How to transmit a radio signal, and what kind of signal to use -- coded pulses, maybe? I'd like to be able to have a selectable frequency (I.E. A switch of options 1-10, like on an old 900mhz phone) ... What kind of frequency should I be on -- ideal range is about 2 miles?
2) How do I receive the radio signal and translate it back into a particular lit LED?

Any experienced techies with solder-burned fingers mind giving a newbie a hand? If you know enough to help me design it and are willing to answer a lot of questions... that'd be awesome. Otherwise, does anyone have a link to a comprehensive and specific resource that would help me identify and solve the problems I'm having designing this particular device? Since I have basic electronics books and whatnot, basic resources that describe "this is a circuit... see the circuit conduct electricity!" probably wouldn't help too much.

posted by SpecialK to science & nature (16 comments total)

My electronics knowledge is about the same as you've described, so here are a few answers from the "script kiddie" perspective:

1. You're basically looking the same type of circuits used for radio-controlled cars, aircraft, garage-door openers, and alarm systems--there must be some circuit diagrams out there for this, but I haven't found any yet on Google.

2. I've gotten quite a bit of mileage from the 4-volume "Encyclopedia of Electronic Circuits", and there are a bunch of similar books. The Electronics section at a library or bookstore might yield something you can use.

3. You might want to look at modifying some FRS radios for the purpose. They already have a great range (1-3 miles typical for the $10 models) and they offer voice communication too. All you'd need to add for the LEDs would be some kind of audio encoder/decoders. You could go the cheap-but-difficult route and use 555-based oscillators and 567-based decoders (both cheap ICs) or use some of the dedicated DTMF encoder/decoders- then you'd have 16 channels, although with no security.

4. Is text messaging on cell phones out of the question? (Be gentle, I've never ridden a motorcycle.)
posted by mmoncur at 11:34 AM on August 9, 2004

mmoncur -

Thanks! That's more info than I had before. I didn't think of what circuits would be similar; just that I'd never seen something like that before. Sixteen channels would be perfect; that's about how many signals I'd think we'd need. Security is a "who cares" thing; I'd prefer that the devices all be interoperable without security. (I'm envisioning a line of 8 3-way switches with lights above and below that mean different things, or in a more complicated form, 16 push buttons and a "clear" button... the device would have an optional clamp on the bottom and/or top so that it could mount on a sportbike windscreen, ideally in the peripheral vision of the driver.)

As far as text messaging goes ... when riding a sport motorcycle, especially in twisties, it requires five fingers on each hand, plus two feet, plus a good sense of balance and a good inner ear so that you can estimate your remaining traction, to keep the bike oily-side down. (Left hand is clutch and signalling, right hand is throttle and front brake, right foot is rear brake, and left foot is gear selector.) You also absolutely *need* to keep your eyes on the road at all times, because your body will shift the motorcycle to track where your eyes are looking. (Most single-bike crashes happen due to target fixation.) You can take your hand off of the left grip for long enough to push a button if it's large enough to hit quickly with a gloved finger, but I wouldn't want to try anything else.
posted by SpecialK at 12:22 PM on August 9, 2004

Oh, and a lot of the areas that we ride in (back country highways, esp. coastal and paved forest routes) are out of cell range.
posted by SpecialK at 12:23 PM on August 9, 2004

Well that's darned easy. You need some microcontrollers, like the Parallax Basic Stamp, some switches, some LEDs, and a radio transceiver for each unit. Take a look at this to get an idea of the transceivers, and this for a microcontroller. These units would serve your purpose very well, but there are tons of other options out there, and potentially for less money. Go get a copy of Nuts And Volts magazine.

You would basically program the I/O lines on the MCU to accept input from your pushbutton switches, send a serial signal to all listening units telling them which LED to light. The LEDs could be made to blink, or stay solid, or anything in between. All pretty straightforward actually.

BTW - I teach Electronic and Kinetic arts at The Crucible in Oakland - thecrucible.org, and you can find more of my life at kineticworld.com
posted by ctp at 12:50 PM on August 9, 2004

Woot! Thanks, CTP... that gives me a place to start.

What do you use to program in PBASIC to get the programs onto the microcontroller?

I'd like to keep my costs somewhere around $50 per unit (asking around at a recent motorcycle meet got me that price, what people said they'd be willing to pay), so I don't think I can use the parts you listed -- but the jargon (knowing what things are called) will get me started looking at cheaper options.
posted by SpecialK at 12:59 PM on August 9, 2004

Thinking about it this way (digitally, rather than analog) has shown two other small complications.

First, I realize that I only need to be able to transmit a 16-bit "state" burst from each controller. However, this is a many-to-many relationship. One button gets pushed on one bike, it needs to show up on as many others are in range and tuned to the same signal. This presents two challenges:
-Would each device need to have an independent and individual identifier so that its signal can be separated from the rest? You have to be able to determine when the 'alert' state ends.
-How do you prevent double-talk... two transmitters transmitting different signals at the same time? Obviously it wouldn't be appropriate to lock out all other signals while one unit is transmitting, but you definitely want to be able to have the front rider signal "COP!" when the ridemaster (who might be riding sweep or leading the B group) is signalling for everyone to pull off for gas at the next station.

My thought was to use a timing chip and have DIP switches on the back of the unit that drive a series of resistors or another microcontroller to give each unit it's own ID, which could then be used to seed or offset the timing chip. That would partially solve both the timing and identification issues, but I don't know how that would affect the programming of the microcontroller.

It may be easy to you, but I've never had to do something like this. ;)
posted by SpecialK at 1:15 PM on August 9, 2004

Using FRS walkie-talkies is a great idea. For your data transfer protocol, I suggest reusing another well-established standard: DTMF, also known as "touch tones". This system encodes 16 different values (of which the telephone uses only 12) into an audio signal. Since it's a standard, you can buy encoder and decoder chips; here's a page demonstrating a couple of circuits that use them.
posted by Mars Saxman at 1:21 PM on August 9, 2004

Mars' link, fixed.
posted by bshort at 1:47 PM on August 9, 2004

Thanks! Awesome link. That may be the way to go, since I could also put a headphone jack on it for audible alert tones. Out of curiousity, bshort and/or Mars, do you know if that guy ever built the cheap RF transponder that he was talking about? He apparently doesn't link from the tutorials on his home page.
posted by SpecialK at 2:37 PM on August 9, 2004

Using DMTF signalling with FRS radios:

To signal an alert press a button on the originating station. The switch electronically latches a circuit on the recieving station that sends out a DMTF tone for a 1/10th of a second every 10 seconds.

On the recieving end any station that hears a tone within the last 15 seconds lights the appropriate warning light.

Deactivation is then done by the originating station unlatching the alert OR the ride master could send a signal that unlatches an alert or unlatches all alerts. One way (8 tones for alerts on/8 tones for alerts off) gives you maximum flexability. The other (15 tones for alerts on/1 tone for all alerts off) give maximum alert levels. Combinations (6 tones alerts on/6 tones alerts off/1 tone all alerts off/1 tones for an alert that can only be turned off by turning all alerts off). You could even set it up so that only the originating station can clear the alert. Or reserve certian alerts to the ride master by making his box the only on able to send the approriate tone.

If you want to get fancy any number of alerts could be accomodated if you used multple tones to set an alert.

The advantage of requiring a periodic signal is any fool playing DMTF tones over your selected frequency will only cause a momentary alert. FRS also allows for multiple channels so you could handle several rider groups at the same time or avoid known noisy spectrum.

If you crank you recieve interval up to 20, set your send interval to 6 and introduce some randomization to the send interval you would be fairly immune to signal clashing.

Keep in mind this kind of spectrum is pretty noisy. You have to have a system that is robust enough to handle cell phones, door openners, microwaves, remote control cars, FRS radios, poor quality two way radios. etc. etc. depending on what frequency you pick. Turn the squech down on a CB radio and drive around some time for some idea of all the noise.
posted by Mitheral at 3:00 PM on August 9, 2004

Would each device need to have an independent and individual identifier

Only if any unit was supposed to not transmit or receive certain signals. If everyone with a unit has equal rights to transmit, then no, simple wide broadcast will work fine.

How do you prevent double-talk... two transmitters transmitting different signals at the same time?

Looks like that was kinda covered already before I got this typed. With the microcontrollers (as with many other ways) you can just make sure each unit sends it's outgoing data a few times, and at random intervals. We're talking about all of this taking place in the span of less than a second or two.

As far as the DTMF idea goes, it's a great one, but I'm not sure you are going to save any money because the ancillary parts, and R&D time will add up very fast. You still need some sort of central control to key the radio when it needs to send a signal, and to convert the decoded DTMF to light up the right LED. You are also vulnerable to anyone on your chosen channel, and even worse someone on your channel using DTMF...good thing there are lots of other channels. It's certainly an idea worth checking out though.

BTW - there are plenty of lower cost MCUs and other wireless products out there. I am playing with the Athena MCU from Kronos Robotics at the moment. They can be had for $7 to start, and programmed in BASIC. You can go with bare PICs for a buck or two if you can program in C or assembly.
posted by ctp at 5:46 PM on August 9, 2004

Ooh, I can do C. That would bring the cost down considerably. I like the idea of going with serial, honestly... the DMTF would work fine, I'm sure.

I'd like to keep my sell price below $50/unit for the prototype units. If I can sell enough of them to show proof of concept, I could probably start an interesting business making them... something I've always wanted to do.
posted by SpecialK at 6:48 PM on August 9, 2004

Something to check out -- the rfPICs . I'm a fan of the PIC, and these give you the transciever built in. The canonical use is remote controlled locks and starters for cars, so they work great in the automotive enviroment.

But this gives you a controller hooked to a radio. That's 90% of the battle. Making a PIC blink an LED is the microcontroller's version of "Hello World."
posted by eriko at 7:25 PM on August 9, 2004

You can get even simpler than that if you use some of the modules that are designed for things like remote car unlockers. They sound just about perfect for this application: the transmitter is a fob with 1-8 buttons on it, and the receiver has 1-8 TTL outputs. Internally they have mask-ROMmed microprocessors and send the data as a short digital burst. Holtek seems to be the biggest manufacturer of the individual chips, but I think you can get prepackaged modules with the coils and other RF stuff already designed-on.

Let's see. Along with Parallax you might want to look at:

• Linx Technologies makes a lot of RF modules. You'd probably have to buy them through Digi-Key or Mouser.
• Abacom RF modules
• OKW Electronics has a bunch of remote-control modules
• "Carl's Electronic Kits" sells a transmitter/receiver pair with a keyfob and relay outputs (respectively). Looks kinda like one of the OKW modules on their board, maybe.
• Lemos International distributes Radiometrix' modules.

posted by hattifattener at 10:26 PM on August 9, 2004

The Linx stuff is a great idea. Each unit would need both a Tx and Rx, but it would be easy to get them set up really fast. I've used their stuff before and it's nice.

On the subject of trying to make them to sell for $50 - surrender Dorothy! :) Things of this sort can be manufactured in quantity (generally in Asia) to maybe meet your price point, and let you make some money - but with off the shelf consumer priced parts - nope. Your best bet is to make a set of them as a proof of concept, and look for an experienced and/or trustworthy angel to go into business with.

BTW - am I the only one that wonders, if these went into wide production, if some people might buy one and sit next to the road and push the "cop" button everytime a bike went by just to see them hit the brakes?
posted by ctp at 11:52 PM on August 9, 2004

I've actually been thinking about just that issue, ctp, and that was the impeutus for the possiblity of setting a "group ID" dip switch somwhere on the unit, like you would for garage door openers.

Using a PIC, it might be possible to integrate that feature.

My only concern with the units that have the RF already built onto them is range. Would they meet the 2 mile + range requirement?
posted by SpecialK at 1:17 PM on August 10, 2004