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
Bluetooth or Other Remote Control Link
Started by ●February 11, 2015
Reply by ●February 12, 20152015-02-12
Reply by ●February 12, 20152015-02-12
> >>> I don't know much about ZigBee. I believe it is a lower data rate than Bluetooth which would be fine.ZigBee is based on 802.15.4. Standard rate is 256Kb/s. Custom rate upto 1Mb/s. Should be more than enough for your app.> >>> The one end needs to be low power and I think Zigbee fits that. I'll do a little digging.Yes, you can time multiplex the link to save power, as long as you don't have to follow some standards.> >>> One nice thing about Bluetooth is there are a million ways to prototype and canned modules with certs are available.Only necessary if you are talking between modules between company A and company B.> >> I know that there are _some_ canned ZigBee modules, but I don't know how much.802.15.4 chips are around $3 o $4 each.> >> 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, it's WiFi taking over, if power consumption is not an issue.> 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.Yes, it's a lot simpler if you don't have to worry about logo certification. If you are responsible for both sides of the link, who cares about logos?
Reply by ●February 12, 20152015-02-12
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
Reply by ●February 13, 20152015-02-13
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
Reply by ●February 14, 20152015-02-14
On Thursday, February 12, 2015 at 10:32:30 PM UTC-5, 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. > > -- > > RickIf you are just looking for a quick prototype with point-to-point communication I would use a couple of XBee2 (ZigBee) modules. These are certified and very simple to apply. Lots of examples and documentation (including my website www.wiblocks.com). A couple of great books -- Building Wireless Sensor Networks: with ZigBee, XBee, Arduino, and Processing ISBN-13: 978-0596807733 ISBN-10: 0596807732 Making Things Talk Practical Methods for Connecting Physical Objects ISBN: 978-0-596-51051-0 ISBN 10: 0-596-51051-9 (* jcl *)
Reply by ●February 14, 20152015-02-14
Of course there is also XBEE. I recommend this book to learn about it "The Hands-on XBEE Lab Manual: Experiments that Teach you XBEE Wirelesss Communications " by Jon Titus http://www.amazon.com/Hands--XBEE-Lab-Manual-Communications/dp/0123914043/ref=sr_1_1?ie=UTF8&qid=1423932593&sr=8-1&keywords=The+Hands-on+XBEE+Lab+Manual%3A+Experiments+that+Teach+you+XBEE+Wirelesss+Communications --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●February 14, 20152015-02-14
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
Reply by ●February 15, 20152015-02-15
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
Reply by ●February 16, 20152015-02-16
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
Reply by ●February 28, 20152015-02-28
Check this Xbee alternative solution based on Sub-G band. USART port. This module is available as "Ready-to-use," focuses on ease of integration even for non RF specialists, thus limit technological risks, while reducing the development time and cost. The following is the link for details: http://www.appconwireless.com/PRODUCTS/showproduct.php?lang=en&id=7
