Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
What kind of chip?
- Thread starter AlexDring
- Start date
MacGyverS2000
Electrical
You're looking for an RF receiver/transmitter chip. Quite a few companies offer possibilities. Microchip offers their KEELOQ family, which includes code-hopping capabilities, etc.
If this is a one-off deal, that's OK, but if this is going to be a sellable product, you'll need FCC testing for both receiver and transmitter. It's not cheap, and if you've never done antenna desing before (particularly PCB-based antenna design), you're in for a steep learning curve.
If this is a one-off deal, that's OK, but if this is going to be a sellable product, you'll need FCC testing for both receiver and transmitter. It's not cheap, and if you've never done antenna desing before (particularly PCB-based antenna design), you're in for a steep learning curve.
- Thread starter
- #3
So if I plan on selling it, I have to get FCC's blessing? Is that so I dont interfear with other tranmissions? I am not too keen on electronics as you can tell. Does code hopping mean switching the code so it cant be used agaisnt me?
I am assuming by your statement that if I use a RF chips, that I will have to come up with an antenna also. Arent there atteneas already out there. I have seen them on some products a little black wire or whatever.
What is the range of RF chips? Is there anything else I can use, depending on range? Is the range dependent on power source?
I am assuming infra red doesnt go around corners or walls. My satellite remote can go anywhere in the house to be used. I noticed a little symbol that says something like UHF (ultra high something). Ever hear of that?
Anyway thanks for your time, hope you dont mind me picking your brain.
I am assuming by your statement that if I use a RF chips, that I will have to come up with an antenna also. Arent there atteneas already out there. I have seen them on some products a little black wire or whatever.
What is the range of RF chips? Is there anything else I can use, depending on range? Is the range dependent on power source?
I am assuming infra red doesnt go around corners or walls. My satellite remote can go anywhere in the house to be used. I noticed a little symbol that says something like UHF (ultra high something). Ever hear of that?
Anyway thanks for your time, hope you dont mind me picking your brain.
MacGyverS2000
Electrical
Go to the FCC's website and download Part 15 of their rules and regs... that's the section dealing wiht low-power transmitters/receivers. By getting an item tested (you get a company/item ID # when it passes) you are proving to the FCC that your product fits several rules, such as total/average transmit power, transmit time, etc.
Using the chips is only half of the battle. You could design anantenna system that works so well (by accident), you crank out too much power. The receiver can use a wire/whip antenna, but you have to understand the compromises in using one over another design, as well as how to design it (it's not just a simple piece of wire cut to any length)... any receiving element can inadvertantly become a transmitting element, therefore you need to test it for such.
For a handheld remote, you can't use a wire for the antenna, you have to use a PCB patch antenna, and that's where the fun starts. You can find design guidelines for how to create them, but you're not likely to find a pre-made solution, and lots of testing time will have to be invested to get it to work.
Range depends on power, but again, that's regulated by FCC rules. UHF stands for Ultra-High Frequency, which is a band of RF. It can go through walls, IR cannot.
If I remember correctly, my last reading of the rules states up to two prototypes can be made/used and may not be sold. Because of your questions about UHF and IR, my guess is you're not highly electronics literate... that being the case, I would suggest having someone else work on this portion of the project for you, or give it up altogether. There are too many unknowns in this type of project for you to learn in a reasonable period of time. Maybe in 6 months to a year with a lot of reading you could begin some basic designs, but it doesn't sound like you're at that point yet.
Good luck!
Using the chips is only half of the battle. You could design anantenna system that works so well (by accident), you crank out too much power. The receiver can use a wire/whip antenna, but you have to understand the compromises in using one over another design, as well as how to design it (it's not just a simple piece of wire cut to any length)... any receiving element can inadvertantly become a transmitting element, therefore you need to test it for such.
For a handheld remote, you can't use a wire for the antenna, you have to use a PCB patch antenna, and that's where the fun starts. You can find design guidelines for how to create them, but you're not likely to find a pre-made solution, and lots of testing time will have to be invested to get it to work.
Range depends on power, but again, that's regulated by FCC rules. UHF stands for Ultra-High Frequency, which is a band of RF. It can go through walls, IR cannot.
If I remember correctly, my last reading of the rules states up to two prototypes can be made/used and may not be sold. Because of your questions about UHF and IR, my guess is you're not highly electronics literate... that being the case, I would suggest having someone else work on this portion of the project for you, or give it up altogether. There are too many unknowns in this type of project for you to learn in a reasonable period of time. Maybe in 6 months to a year with a lot of reading you could begin some basic designs, but it doesn't sound like you're at that point yet.
Good luck!
- Thread starter
- #5
Having worked a lot with battery powered wireless, the main issue is this - your battery powered receiver in your keychain. The receiver has to run continuously and draw current since it doesn't know when a message might arrive. You will end up with a keychain the size of a cellphone that needs recharging every several days.
The next problem is range. A simple wireless system might have a line-of-site range of 1 mile. But the range through walls, obstructions, etc might be reduced only to 500 feet or less. If you're not in range, you have no security.
You would do better to put a cell transmitter in your car that puts out a paging message or text message to your cell phone number to indicate an alarm. However, I believe such car security systems/services (which use cellular reporting) already exist.
The next problem is range. A simple wireless system might have a line-of-site range of 1 mile. But the range through walls, obstructions, etc might be reduced only to 500 feet or less. If you're not in range, you have no security.
You would do better to put a cell transmitter in your car that puts out a paging message or text message to your cell phone number to indicate an alarm. However, I believe such car security systems/services (which use cellular reporting) already exist.
I agree with all the above, it sure ain't an easy problem.
Honestly, your best bet is to try to find some existing product that does something very similar to what you want. Then look at how they did it, try to reverse engineer it, and then try to adapt or improve on the design.
If there is nothing similar already out there, chances are it is either not possible, or going to be extremely difficult, or cost more than the customer will be willing to pay for your eventual product.
These days customer expectations are extremely high. No bigger than a pin head, battery lasts for years, costs less than cents to mass produce in China, and so on.
Good luck, I have been designing customer products for many years, and I am glad to be retired.
Honestly, your best bet is to try to find some existing product that does something very similar to what you want. Then look at how they did it, try to reverse engineer it, and then try to adapt or improve on the design.
If there is nothing similar already out there, chances are it is either not possible, or going to be extremely difficult, or cost more than the customer will be willing to pay for your eventual product.
These days customer expectations are extremely high. No bigger than a pin head, battery lasts for years, costs less than cents to mass produce in China, and so on.
Good luck, I have been designing customer products for many years, and I am glad to be retired.
There are a lot of companies that make key fob transmitter/receiver sets. They are available as a commercial product intended to be used as a component part for another system such as the one you are designing (whatever that is). Many of these purchased solutions are pre-engineered/pretested modules. Some are probably already FCC approved. So you don't have to reinvent the wheel to make your end product. I'd start with google to find manufacturers...
Comcokid-
Just thinking out of the box for a minute here.
There is no reason that your receiver HAS to be on
all the time. For example, a small CMOS timer can
be used to turn on the receiver for enough time to
stablize it and see if the transmitter is sending.
Then have the timer turn it off for awhile.
In the example of the car alarm, I think that one
could, fairly easily rig up a circuit (OK, OK, I'd
use an 8 pin PIC, so I'm biased). To turn on the
receiver, wait for stablization (and a little more),
see if the transmitter is sending, and if so, then
do some code checking. Otherwise, let the receiver
and the PIC go to sleep for 4 or 5 seconds and
repeat. I'm sure that the duty cycle of this would
be lower than that of leaving the receiver on all the
time, although it might be negated if the inrush/startup
current of the receiver is greater than the average
current steady state. An investigation of this would
be in order.
For the transmitter side, I'd just have it continue
to send messages after triggered until the power went
away. And, you could put a large enough cap in the
transmitter to ensure that the transmission would last
long enough to be detected, even if the battery to the
car was cut! This would be a marketing point for
selling it. Most car alarms require the battery to
be there so they can beep the horn, flash the lights,
etc.
I'm not disagreeing with your comments, it's just
something that came to mind when I was reading the
thread!
Peace,
Cheers,
Rich S.
Just thinking out of the box for a minute here.
There is no reason that your receiver HAS to be on
all the time. For example, a small CMOS timer can
be used to turn on the receiver for enough time to
stablize it and see if the transmitter is sending.
Then have the timer turn it off for awhile.
In the example of the car alarm, I think that one
could, fairly easily rig up a circuit (OK, OK, I'd
use an 8 pin PIC, so I'm biased). To turn on the
receiver, wait for stablization (and a little more),
see if the transmitter is sending, and if so, then
do some code checking. Otherwise, let the receiver
and the PIC go to sleep for 4 or 5 seconds and
repeat. I'm sure that the duty cycle of this would
be lower than that of leaving the receiver on all the
time, although it might be negated if the inrush/startup
current of the receiver is greater than the average
current steady state. An investigation of this would
be in order.
For the transmitter side, I'd just have it continue
to send messages after triggered until the power went
away. And, you could put a large enough cap in the
transmitter to ensure that the transmission would last
long enough to be detected, even if the battery to the
car was cut! This would be a marketing point for
selling it. Most car alarms require the battery to
be there so they can beep the horn, flash the lights,
etc.
I'm not disagreeing with your comments, it's just
something that came to mind when I was reading the
thread!
Peace,
Cheers,
Rich S.
- Status
Similar threads
- Locked
- Question
- Question