Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #36477 > unrolled thread

Bluetooth or Other Remote Control Link

Back to article view | Back to comp.lang.forth

Contents

  Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-11 11:40 -0500
    Re: Bluetooth or Other Remote Control Link visualforth@rocketmail.com - 2015-02-11 09:46 -0800
    Re: Bluetooth or Other Remote Control Link Paul Rubin <no.email@nospam.invalid> - 2015-02-11 11:21 -0800
    Re: Bluetooth or Other Remote Control Link Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-02-11 22:51 +0200
      Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-11 22:12 -0500
    Re: Bluetooth or Other Remote Control Link Tim Wescott <seemywebsite@myfooter.really> - 2015-02-11 18:09 -0600
      Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-11 22:07 -0500
        Re: Bluetooth or Other Remote Control Link Tim Wescott <tim@seemywebsite.com> - 2015-02-12 09:55 -0600
          Re: Bluetooth or Other Remote Control Link Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-02-12 08:44 -0800
          Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-12 15:04 -0500
            Re: Bluetooth or Other Remote Control Link visualforth@rocketmail.com - 2015-02-12 12:39 -0800
              Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-12 17:16 -0500
            Re: Bluetooth or Other Remote Control Link Tim Wescott <seemywebsite@myfooter.really> - 2015-02-12 17:37 -0600
              Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-12 22:32 -0500
                Re: Bluetooth or Other Remote Control Link Tim Wescott <tim@seemywebsite.com> - 2015-02-13 11:18 -0600
    Re: Bluetooth or Other Remote Control Link visualforth@rocketmail.com - 2015-02-13 11:22 -0800
    Re: Bluetooth or Other Remote Control Link Frnak McKenney <frnak@far.from.the.madding.crowd.com> - 2015-02-14 11:50 -0600
      Re: Bluetooth or Other Remote Control Link rickman <gnuarm@gmail.com> - 2015-02-15 21:49 -0500
    Re: Bluetooth or Other Remote Control Link o pere o <me@somewhere.net> - 2015-02-16 09:29 +0100

#36477 — Bluetooth or Other Remote Control Link

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

[toc] | [next] | [standalone]

#36478

On Wednesday, February 11, 2015 at 11:40:30 AM UTC-5, 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?
> 
> -- 
> 
> Rick

Rick, Look at http://www.kiblerelectronics.com/bob/products/rafl/rafl.html and http://www.kiblerelectronics.com/myf/myf.shtml and ask Bob. He may be able to help you!

Cheers,
Dirk.

[toc] | [prev] | [next] | [standalone]

#36483

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

[toc] | [prev] | [next] | [standalone]

#36484

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

[toc] | [prev] | [next] | [standalone]

#36490

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

[toc] | [prev] | [next] | [standalone]

#36488

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

[toc] | [prev] | [next] | [standalone]

#36489

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

[toc] | [prev] | [next] | [standalone]

#36499

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

[toc] | [prev] | [next] | [standalone]

#36503

joi, 12 februarie 2015, 17:55:21 UTC+2, Tim Wescott a scris:
> 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

BLE is just bluetooth with a lower energy profile. So, it is still point-to-point protocol.
Zigbee is a mesh protocol, it is very sofisticated. It's so sofisticated that it hardly made its way in the wireless communication world. People turned to simpler mesh protocols.
So, point-to-point and mesh (wireless network) are different classes.
For the intended application, zigbee is way too complicated.

[toc] | [prev] | [next] | [standalone]

#36510

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

[toc] | [prev] | [next] | [standalone]

#36514

On Thursday, February 12, 2015 at 3:05:05 PM UTC-5, rickman wrote:
> 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

Rick, why aren't you looking at 
http://www.kiblerelectronics.com/bob/products/rafl/rafl.html and http://www.kiblerelectronics.com/myf/myf.shtml and ask Bob. 
This stuff is operating by his Forth, and he supports Forth for Radio Frequency Link Controllers.

[toc] | [prev] | [next] | [standalone]

#36521

On 2/12/2015 3:39 PM, visualforth@rocketmail.com wrote:
> On Thursday, February 12, 2015 at 3:05:05 PM UTC-5, rickman wrote:
>> 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
>
> Rick, why aren't you looking at
> http://www.kiblerelectronics.com/bob/products/rafl/rafl.html and http://www.kiblerelectronics.com/myf/myf.shtml and ask Bob.
> This stuff is operating by his Forth, and he supports Forth for Radio Frequency Link Controllers.

I did look at it, but I can't find a lot of important info.  For example 
he doesn't even say what frequency it transmits at.  I'll send him an 
email to see if I can get more information.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36523

On Thu, 12 Feb 2015 15:04:56 -0500, rickman wrote:

> 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.

You may be right about the simpler transmitter.  I'm almost certain that 
you need more certification if you're an intentional emitter vs. 
unintentional (like a PC), but I don't know how much.

I suspect that much of the required certification isn't with the FCC, but 
with the BlueTooth consortium or ZigBee or whoever, who want to make sure 
you're playing nice with their intellectual property before they give the 
nod on using their logo on your product.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#36527

On 2/12/2015 6:37 PM, Tim Wescott wrote:
> On Thu, 12 Feb 2015 15:04:56 -0500, rickman wrote:
>
>> 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.
>
> You may be right about the simpler transmitter.  I'm almost certain that
> you need more certification if you're an intentional emitter vs.
> unintentional (like a PC), but I don't know how much.
>
> I suspect that much of the required certification isn't with the FCC, but
> with the BlueTooth consortium or ZigBee or whoever, who want to make sure
> you're playing nice with their intellectual property before they give the
> nod on using their logo on your product.

I think in this case we don't need no stinkin' logo.  I think I'm just 
going to punt and go with the Bluetooth.  I wasn't asked to design a 
marketable system, I am being asked about a proof of concept.  I'll just 
put something together with an Arduino or whatever that works on the lab 
bench and then we'll see what they really want.  The main reason for 
going with something like Bluetooth is to avoid any certs issue by using 
pre-certified modules.  For this proof of concept it is just to get 
there with the minimum effort.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36542

On Thu, 12 Feb 2015 22:32:18 -0500, rickman wrote:

> On 2/12/2015 6:37 PM, Tim Wescott wrote:
>> On Thu, 12 Feb 2015 15:04:56 -0500, rickman wrote:
>>
>>> 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.
>>
>> You may be right about the simpler transmitter.  I'm almost certain
>> that you need more certification if you're an intentional emitter vs.
>> unintentional (like a PC), but I don't know how much.
>>
>> I suspect that much of the required certification isn't with the FCC,
>> but with the BlueTooth consortium or ZigBee or whoever, who want to
>> make sure you're playing nice with their intellectual property before
>> they give the nod on using their logo on your product.
> 
> I think in this case we don't need no stinkin' logo.  I think I'm just
> going to punt and go with the Bluetooth.  I wasn't asked to design a
> marketable system, I am being asked about a proof of concept.  I'll just
> put something together with an Arduino or whatever that works on the lab
> bench and then we'll see what they really want.  The main reason for
> going with something like Bluetooth is to avoid any certs issue by using
> pre-certified modules.  For this proof of concept it is just to get
> there with the minimum effort.

This is an observation more than anything else:

If you do a one-off, running in a license-free band, per regs but without 
formal testing or certification, the FCC is not going to be interested 
enough in you to even verify that you exist.  So you could go ahead and 
make your 400-ish MHz data link (there's some specific band in there; I 
can't remember) and have a ball.

But for a one-off it's probably less work to go with BT modules even so.



-- 
www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#36549

On Wednesday, February 11, 2015 at 11:40:30 AM UTC-5, 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?
> 
> -- 
> 
> Rick

Hi Rick,
Accidentally I discovered this webpage:
https://www.sparkfun.com/search/products?term=RF%20Link

They are offering simple RF Links for less than 10$ a pair of transmitter and receiver, 25$ for a Bluetooth modem. 

[toc] | [prev] | [next] | [standalone]

#36566

On Wed, 11 Feb 2015 11:40:27 -0500, rickman <gnuarm@gmail.com> 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?

Would something like this satisfy your requirements? Or do you really
need the complexity of WiFi or BlueTooth?

  <http://www.seeedstudio.com/depot/315Mhz-remote-relay-switch-kits-2-channels-p-150.html>

It's basically a paired transmitter and receiver pair for $20,
unidirectional.


Frank McKenney
-- 
  The thing which keeps life romantic and full of fiery possibilities
  is the existence of these great plain limitations which force all
  of use to meet the things we do not like or do not expect.
     -- G.K. Chesterton: On the Institution of the Family (1905)
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

[toc] | [prev] | [next] | [standalone]

#36591

On 2/14/2015 12:50 PM, Frnak McKenney wrote:
> On Wed, 11 Feb 2015 11:40:27 -0500, rickman <gnuarm@gmail.com> 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?
>
> Would something like this satisfy your requirements? Or do you really
> need the complexity of WiFi or BlueTooth?
>
>    <http://www.seeedstudio.com/depot/315Mhz-remote-relay-switch-kits-2-channels-p-150.html>
>
> It's basically a paired transmitter and receiver pair for $20,
> unidirectional.

Thanks, this is interesting.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#36594

On 02/11/2015 05:40 PM, 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?
>

You could look up one of the Xbee RF Modules. You could probably be 
happy with the basic 802.15.4 modules, without the need for ZigBee support.

Pere

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web