Forums

Bluetooth or Other Remote Control Link

Started by rickman February 11, 2015
A friend has asked me for help with an idea he has which requires a 
simple RF link to control a 12 volt circuit.  One end of the link would 
need an MCU to collect the inputs and make a decision about the state of 
the 12 volt circuit.  The RF link is used to control the 12 volt 
circuit.  The MCU end would be battery powered and so needs to be low 
energy.  It is only on with a very low duty cycle, less than a dozen 
times a day for a short while each time.  There may be a need for a 
bidirectional link to verify the serial number of the remote unit, I'm 
not sure.  The range is single digit feet, but there may be metal in the 
way, similar to a unit under a car hood for example.

I was originally thinking of using Bluetooth, BLE specifically.  But I 
have had some awkwardness with the connection in various uses.  One 
advantage is that qualified modules are available which get around the 
FCC certification I believe.  I found the NRF51822 Eval Kit which seems 
to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I 
would assume.

If the remote unit does not need to be identified, I would think there 
are much simpler solutions.  I expect the type of xmit and receive 
modules used in weather stations might be adequate.

Any recommendations for units to consider for a prototype?

-- 

Rick
> >I was originally thinking of using Bluetooth, BLE specifically. But I >have had some awkwardness with the connection in various uses. One >advantage is that qualified modules are available which get around the >FCC certification I believe. I found the NRF51822 Eval Kit which seems >to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I >would assume. > >Any recommendations for units to consider for a prototype? >
Rick Take a look at the CY8CKIT-042-BLE Bluetooth® Low Energy (BLE) Pioneer Kit from Cypress http://www.cypress.com/?rid=102636 Also comes with Windows/iOS/Android support examples --------------------------------------- Posted through http://www.EmbeddedRelated.com
rickman <gnuarm@gmail.com> writes:
> The range is single digit feet, but there may be metal in the way, > similar to a unit under a car hood for example.
I'm dubious about bluetooth working reliably in an environment like that, but you could try.
> I expect the type of xmit and receive modules used in weather stations > might be adequate. Any recommendations for units to consider for a > prototype?
Car alarm remotes? If you're just triggering a relay or something, you should be ok with a very low bit rate compared with BLE. There's all kinds of other RF stuff on Sparkfun: https://www.sparkfun.com/categories/16
Den onsdag den 11. februar 2015 kl. 17.40.32 UTC+1 skrev rickman:
> A friend has asked me for help with an idea he has which requires a > simple RF link to control a 12 volt circuit. One end of the link would > need an MCU to collect the inputs and make a decision about the state of > the 12 volt circuit. The RF link is used to control the 12 volt > circuit. The MCU end would be battery powered and so needs to be low > energy. It is only on with a very low duty cycle, less than a dozen > times a day for a short while each time. There may be a need for a > bidirectional link to verify the serial number of the remote unit, I'm > not sure. The range is single digit feet, but there may be metal in the > way, similar to a unit under a car hood for example. > > I was originally thinking of using Bluetooth, BLE specifically. But I > have had some awkwardness with the connection in various uses. One > advantage is that qualified modules are available which get around the > FCC certification I believe. I found the NRF51822 Eval Kit which seems > to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I > would assume. > > If the remote unit does not need to be identified, I would think there > are much simpler solutions. I expect the type of xmit and receive > modules used in weather stations might be adequate. > > Any recommendations for units to consider for a prototype? > > -- > > Rick
http://rfduino.com/ -Lasse
On 11.2.15 18:40, rickman wrote:
> A friend has asked me for help with an idea he has which requires a > simple RF link to control a 12 volt circuit. One end of the link would > need an MCU to collect the inputs and make a decision about the state of > the 12 volt circuit. The RF link is used to control the 12 volt > circuit. The MCU end would be battery powered and so needs to be low > energy. It is only on with a very low duty cycle, less than a dozen > times a day for a short while each time. There may be a need for a > bidirectional link to verify the serial number of the remote unit, I'm > not sure. The range is single digit feet, but there may be metal in the > way, similar to a unit under a car hood for example. > > I was originally thinking of using Bluetooth, BLE specifically. But I > have had some awkwardness with the connection in various uses. One > advantage is that qualified modules are available which get around the > FCC certification I believe. I found the NRF51822 Eval Kit which seems > to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I > would assume. > > If the remote unit does not need to be identified, I would think there > are much simpler solutions. I expect the type of xmit and receive > modules used in weather stations might be adequate. > > Any recommendations for units to consider for a prototype? >
A garage opener? -- -TV
On Wed, 11 Feb 2015 11:40:27 -0500, rickman wrote:

> A friend has asked me for help with an idea he has which requires a > simple RF link to control a 12 volt circuit. One end of the link would > need an MCU to collect the inputs and make a decision about the state of > the 12 volt circuit. The RF link is used to control the 12 volt > circuit. The MCU end would be battery powered and so needs to be low > energy. It is only on with a very low duty cycle, less than a dozen > times a day for a short while each time. There may be a need for a > bidirectional link to verify the serial number of the remote unit, I'm > not sure. The range is single digit feet, but there may be metal in the > way, similar to a unit under a car hood for example. > > I was originally thinking of using Bluetooth, BLE specifically. But I > have had some awkwardness with the connection in various uses. One > advantage is that qualified modules are available which get around the > FCC certification I believe. I found the NRF51822 Eval Kit which seems > to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I > would assume. > > If the remote unit does not need to be identified, I would think there > are much simpler solutions. I expect the type of xmit and receive > modules used in weather stations might be adequate. > > Any recommendations for units to consider for a prototype?
Is ZigBee still a viable contender for this sort of stuff? If it's really under hood, it sounds like (a) a difficult EMI environment, and (b) a "whyinhell not just use wired" environment. But I'm sure he has constraints you haven't mentioned. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On 2/11/2015 7:09 PM, Tim Wescott wrote:
> On Wed, 11 Feb 2015 11:40:27 -0500, rickman wrote: > >> A friend has asked me for help with an idea he has which requires a >> simple RF link to control a 12 volt circuit. One end of the link would >> need an MCU to collect the inputs and make a decision about the state of >> the 12 volt circuit. The RF link is used to control the 12 volt >> circuit. The MCU end would be battery powered and so needs to be low >> energy. It is only on with a very low duty cycle, less than a dozen >> times a day for a short while each time. There may be a need for a >> bidirectional link to verify the serial number of the remote unit, I'm >> not sure. The range is single digit feet, but there may be metal in the >> way, similar to a unit under a car hood for example. >> >> I was originally thinking of using Bluetooth, BLE specifically. But I >> have had some awkwardness with the connection in various uses. One >> advantage is that qualified modules are available which get around the >> FCC certification I believe. I found the NRF51822 Eval Kit which seems >> to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I >> would assume. >> >> If the remote unit does not need to be identified, I would think there >> are much simpler solutions. I expect the type of xmit and receive >> modules used in weather stations might be adequate. >> >> Any recommendations for units to consider for a prototype? > > Is ZigBee still a viable contender for this sort of stuff? > > If it's really under hood, it sounds like (a) a difficult EMI environment, > and (b) a "whyinhell not just use wired" environment. But I'm sure he has > constraints you haven't mentioned.
I don't automatically question all requirements. If they ask for wireless, I'll give them wireless. I didn't say this would go in a car. I said there might be some level of shielding from metal similar to being under the hood, lots of metal, but not shielded like a PC case. The distance is short, so a bit of attenuation from a loose case shouldn't be a problem. I don't know much about ZigBee. I believe it is a lower data rate than Bluetooth which would be fine. The one end needs to be low power and I think Zigbee fits that. I'll do a little digging. But I think that is what BLE is in response to, so there may not be much difference. One nice thing about Bluetooth is there are a million ways to prototype and canned modules with certs are available. -- Rick
On 2/11/2015 3:51 PM, Tauno Voipio wrote:
> On 11.2.15 18:40, rickman wrote: >> A friend has asked me for help with an idea he has which requires a >> simple RF link to control a 12 volt circuit. One end of the link would >> need an MCU to collect the inputs and make a decision about the state of >> the 12 volt circuit. The RF link is used to control the 12 volt >> circuit. The MCU end would be battery powered and so needs to be low >> energy. It is only on with a very low duty cycle, less than a dozen >> times a day for a short while each time. There may be a need for a >> bidirectional link to verify the serial number of the remote unit, I'm >> not sure. The range is single digit feet, but there may be metal in the >> way, similar to a unit under a car hood for example. >> >> I was originally thinking of using Bluetooth, BLE specifically. But I >> have had some awkwardness with the connection in various uses. One >> advantage is that qualified modules are available which get around the >> FCC certification I believe. I found the NRF51822 Eval Kit which seems >> to be a SOC with both Bluetooth and an ARM CM0, not bad but no certs I >> would assume. >> >> If the remote unit does not need to be identified, I would think there >> are much simpler solutions. I expect the type of xmit and receive >> modules used in weather stations might be adequate. >> >> Any recommendations for units to consider for a prototype? >> > > A garage opener?
Maybe, or a remote engine starter. Are these things on a frequency that is not licensed? I seem to recall that garage door openers are on a frequency that is shared with emergency services. Maybe not a problem at a close range. -- Rick
On Wed, 11 Feb 2015 22:07:46 -0500, rickman wrote:

> On 2/11/2015 7:09 PM, Tim Wescott wrote: >> On Wed, 11 Feb 2015 11:40:27 -0500, rickman wrote: >> >>> A friend has asked me for help with an idea he has which requires a >>> simple RF link to control a 12 volt circuit. One end of the link >>> would need an MCU to collect the inputs and make a decision about the >>> state of the 12 volt circuit. The RF link is used to control the 12 >>> volt circuit. The MCU end would be battery powered and so needs to be >>> low energy. It is only on with a very low duty cycle, less than a >>> dozen times a day for a short while each time. There may be a need >>> for a bidirectional link to verify the serial number of the remote >>> unit, I'm not sure. The range is single digit feet, but there may be >>> metal in the way, similar to a unit under a car hood for example. >>> >>> I was originally thinking of using Bluetooth, BLE specifically. But I >>> have had some awkwardness with the connection in various uses. One >>> advantage is that qualified modules are available which get around the >>> FCC certification I believe. I found the NRF51822 Eval Kit which >>> seems to be a SOC with both Bluetooth and an ARM CM0, not bad but no >>> certs I would assume. >>> >>> If the remote unit does not need to be identified, I would think there >>> are much simpler solutions. I expect the type of xmit and receive >>> modules used in weather stations might be adequate. >>> >>> Any recommendations for units to consider for a prototype? >> >> Is ZigBee still a viable contender for this sort of stuff? >> >> If it's really under hood, it sounds like (a) a difficult EMI >> environment, >> and (b) a "whyinhell not just use wired" environment. But I'm sure he >> has constraints you haven't mentioned. > > I don't automatically question all requirements.
I don't automatically question _all_ requirements. But I don't see any point in taking a bunch of someone's money to go down a blind ally, either. You know who you're dealing with.
> If they ask for > wireless, I'll give them wireless. I didn't say this would go in a car. > I said there might be some level of shielding from metal similar to > being under the hood, lots of metal, but not shielded like a PC case. > The distance is short, so a bit of attenuation from a loose case > shouldn't be a problem. > > I don't know much about ZigBee. I believe it is a lower data rate than > Bluetooth which would be fine. The one end needs to be low power and I > think Zigbee fits that. I'll do a little digging. But I think that is > what BLE is in response to, so there may not be much difference. > > One nice thing about Bluetooth is there are a million ways to prototype > and canned modules with certs are available.
I know that there are _some_ canned ZigBee modules, but I don't know how much. I was really just throwing the name out to give you something to research -- I know that ZigBee was hot several years ago, but I don't know if it's faded from the market or not. If this BLE thing has taken over the ZigBee ecological niche, then it's the way to go. -- www.wescottdesign.com
On 2/12/2015 10:55 AM, Tim Wescott wrote:
> On Wed, 11 Feb 2015 22:07:46 -0500, rickman wrote: > >> On 2/11/2015 7:09 PM, Tim Wescott wrote: >>> On Wed, 11 Feb 2015 11:40:27 -0500, rickman wrote: >>> >>>> A friend has asked me for help with an idea he has which requires a >>>> simple RF link to control a 12 volt circuit. One end of the link >>>> would need an MCU to collect the inputs and make a decision about the >>>> state of the 12 volt circuit. The RF link is used to control the 12 >>>> volt circuit. The MCU end would be battery powered and so needs to be >>>> low energy. It is only on with a very low duty cycle, less than a >>>> dozen times a day for a short while each time. There may be a need >>>> for a bidirectional link to verify the serial number of the remote >>>> unit, I'm not sure. The range is single digit feet, but there may be >>>> metal in the way, similar to a unit under a car hood for example. >>>> >>>> I was originally thinking of using Bluetooth, BLE specifically. But I >>>> have had some awkwardness with the connection in various uses. One >>>> advantage is that qualified modules are available which get around the >>>> FCC certification I believe. I found the NRF51822 Eval Kit which >>>> seems to be a SOC with both Bluetooth and an ARM CM0, not bad but no >>>> certs I would assume. >>>> >>>> If the remote unit does not need to be identified, I would think there >>>> are much simpler solutions. I expect the type of xmit and receive >>>> modules used in weather stations might be adequate. >>>> >>>> Any recommendations for units to consider for a prototype? >>> >>> Is ZigBee still a viable contender for this sort of stuff? >>> >>> If it's really under hood, it sounds like (a) a difficult EMI >>> environment, >>> and (b) a "whyinhell not just use wired" environment. But I'm sure he >>> has constraints you haven't mentioned. >> >> I don't automatically question all requirements. > > I don't automatically question _all_ requirements. But I don't see any > point in taking a bunch of someone's money to go down a blind ally, > either. > > You know who you're dealing with. > >> If they ask for >> wireless, I'll give them wireless. I didn't say this would go in a car. >> I said there might be some level of shielding from metal similar to >> being under the hood, lots of metal, but not shielded like a PC case. >> The distance is short, so a bit of attenuation from a loose case >> shouldn't be a problem. >> >> I don't know much about ZigBee. I believe it is a lower data rate than >> Bluetooth which would be fine. The one end needs to be low power and I >> think Zigbee fits that. I'll do a little digging. But I think that is >> what BLE is in response to, so there may not be much difference. >> >> One nice thing about Bluetooth is there are a million ways to prototype >> and canned modules with certs are available. > > I know that there are _some_ canned ZigBee modules, but I don't know how > much. > > I was really just throwing the name out to give you something to research > -- I know that ZigBee was hot several years ago, but I don't know if it's > faded from the market or not. If this BLE thing has taken over the ZigBee > ecological niche, then it's the way to go.
Actually I am thinking it might be better in most respects to use something more like a car fob remote circuit if that can be found in precertified modules. I expect it can't since car fobs are very high volume and I expect every one is a custom design. I'll look up the frequency so at least I have an idea what the regs are. Maybe no certs are needed other than the usual EMI stuff like PCs. -- Rick