Seeking low power wireless recommendation

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings -

 

I have an application that is battery powered. It may need to sit there, waiting for a wireless query, for several months. Wake up (that is, initial connection time) can be very slow, perhaps as long as several seconds. Operating distance needs to be no more than 50m. 

 

So, I am looking for something which has either a very low receive current or which has an effective "receive sleep" mode, waking periodically to check for a received signal. 

 

This device needs to work in one of the international ISM bands. Data rate does not have to be terribly fast.

 

I'd appreciate any recommendations.

 

Thanks,

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Oct 16, 2015 - 12:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I have an application that is battery powered

What kind of battery - coin cell? AA? lead-acid?

 

(more specifically, what capacity?)

 

I've been using a SAM R21 which should be getting about a year on a CR2023.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two C cells running a data logger. I am already battery limited (that is, endurance is less than desired). Average current at low sample rates is now 150uA to 700uA supply load current (not battery current) at 3.3V. I'd like to find a wireless solution that averages under 200uA receive/idle current.

 

Thanks

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A SAM R21 could easily do that.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmmm -

 

Would have to think pretty carefully about that. And, I will. I was expecting a board spin, but not a whole new micro (now using Mega328P). The learning curve for both a micro AND wireless seems a bit daunting. At least the programming tool (Studio) would stay pretty much same. Thats a plus. Having a faster clock speed would be a plus (means shorter write times to microSD card, which I THINK might mean lower power consumption). More flash AND sram would also be a big plus. 

 

So many factors to weigh, here. Really appreciate the suggestion.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, the R21 is just a D21 micro and AT86RF233 radio together in one package - so, if you already have a micro, you could just add an AT86RF233...

 

Or leave the Mega328P as the "master" doing what it already does, with a simple interface to the R21 as a "network co-processor"...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Apr 30, 2015 - 05:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.

 

I'll start by looking at the AT86RF233 and see what it does power-wise. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Well, you won't get 200 uA in continuous receive mode. You will easily get way below that in sleep mode, so with rare wakeup cycles you can get your average close to that number.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats what I expected from the spec sheet. Can live with that. 

 

Thanks

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Well, you won't get 200 uA in continuous receive mode. You will easily get way below that in sleep mode, so with rare wakeup cycles you can get your average close to that number.

Yes - that is was I was thinking of.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You can get an arbitrarily small power usage from the receiver, at the expense of strobing the base station query for on average half the sampling time of the rx wake period. The trick is to do two CCAs on the rx with a spacing guaranteed to pick up a continuous strobe from the tx.  With 8Hz wakeups and paired CCAs contikimac gets max 125 msec response time using an average 1.5% rx power (~400 ua avg).  A 10 second response would need around 5 ua average current.  The power balance shifts to the tx strobe under those circumstances.

Last Edited: Fri. May 1, 2015 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which chips are you referring to? The AT86RF233? And some specific protocol?

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, that would be a specific protocol.

 

dak664 mentioned ContikiMAChttp://dunkels.com/adam/dunkels1...

 

Yes, this kind of thing can be done on the AT86RF233 - it's the kind of thing I was doing to get the year from a CR2032.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, never heard of ContikiMAC. That article appears very thorough. I'll review it in detail.

 

Glad to hear that such a strategy produces that magnitude of results.

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I hadn't heard of it specifically - but it is the same principle!

 

The article explains it well.

 

smiley

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I've just read the article. The approach seems kind of nuts, I don't really see how that can scale to large dense networks.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it does rather assume that the channel is "quiet" except when the receiver actually needs to wake up

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. May 1, 2015 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which fits my case of interest.

 

In my case, the devices sit there in a RF quiet environment until somebody approaches with a box to query it. No "network" in the sense of multiple devices talking to each other, even if they happen to be within range. My case is basically a substitute for a serial cable.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is true that the receiver wakes when detecting any RF activity on the channel. Typically with 802.15.4 it stays awake until the start of the next strobe (in contikimac the strobes are the actual data packets) and sleeps if the PAN or address don't match. So worst case is wake, RF detection just past the start of a long packet, stay awake for ~6 msec until that packet is over, the intergap delay, and address mismatch on the next packet, then sleep.  Only one packet is ever delivered per time slot (a special case uses the frame pending bit to signal the receiver to stay awake to receive a burst of packets) so you are still guaranteed a 95% sleep time (at 8Hz channel check rate) .  The down side, it also means only 8 packets per second can be sent to any one node, but packets can be sent between other nodes in the same time slot, after the targeted rx receives the packet and sends the hardware ACK.

 

If the nodes are completely unsynchronized the RF activity averages half the channel check period so the entire mesh throughput would degrade to that (8 packets/sec).  But if the tx can estimate the wake time of the targeted rx it can delay RF strobing until that time ("phase synchronization").  If the clocks are stable enough and the packets occur often enough to catch the first or second strobe then the mesh thoughput can be as high as 100 packets/sec.

 

Some graphs showing the RF activity are here

http://github.com/contiki-os/con...

 

With good synchronization one packet per second can be sent using less than two strobes on average - i.e., the overhead on both tx and rx energy is less than the energy needed to send the message.  But yes, it breaks spectacularly when too many messages enter the mesh at the same time.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at Bluetooth 4/LE/Smart? Designed to run "for a few years" from a CR2032. Maximum range of around 200M, depending on TX power.

 

 

 

Four legs good, two legs bad, three legs stable.

Last Edited: Fri. May 1, 2015 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

"Designed to run" and actually runs are two different things. There is nothing inherently better about BT transceivers over 15.4 transceivers.

 

The power saving will come from the application and entire system low sleep current. If you send a frame every few seconds, then total power consumption is dominated by the sleep current and that's what has to be optimized first. I even seen people put MOSFETs to control power to the peripheral devices, like external flash memory. Just to shave off a few uA here and there, it all adds up in the end.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for fill on contiki and the general information. I'll take a look at BT/LE/SMART just to be informed. 

 

My application is still in the conceptual stage, trying to guess whether or not what I need is even possible. It appears to be possible, so I will proceed with "learning phase" with diligence. Being able to use a module that already has FCC/CE cert (as I assume would be possible with BT) is a big plus.

 

Appreciate everyones input. It all really helps.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
The power saving will come from the application and entire system low sleep current.

Absolutely!

 

Quote:
I even seen people put MOSFETs to control power to the peripheral devices

That's basically what they've done for the L21, isn't it...?

 

wink

 

(well - one of the things)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

awneil wrote:
That's basically what they've done for the L21, isn't it...?
Well, yes, for the internal devices. L21 can't help with external flash chip. And in many wireless systems that flash does absolutely nothing until OTA upgrade happens. And that might not happen even once in a product lifetime.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
No "network" in the sense of multiple devices talking to each other, even if they happen to be within range. My case is basically a substitute for a serial cable.
Would µracoli be a fit?

http://uracoli.blogspot.com/

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never heard of uracoli. Will check.

 

Checked the link. I found very little of substance. The significant statement seemed to be: "At the moment, the code is not opened but feel free to ask for advice/snippets". Instead, this seems more useful:

 

http://uracoli.nongnu.org/

 

Thanks for the tip.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. May 2, 2015 - 04:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

"Designed to run" and actually runs are two different things. There is nothing inherently better about BT transceivers over 15.4 transceivers.

 

The power saving will come from the application and entire system low sleep current. If you send a frame every few seconds, then total power consumption is dominated by the sleep current and that's what has to be optimized first. I even seen people put MOSFETs to control power to the peripheral devices, like external flash memory. Just to shave off a few uA here and there, it all adds up in the end.

True. I guess the point is that it is a protocol that will increasingly be available on mass-market smartphone/tablet devices and the protocol is designed such that peripheral devices can run from a CR2032. On the negative side of the balance sheet the Bluetooth SIG will hold you to ransom for qualification and listing fees...

 

 

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
I guess the point is that [Bluetooth] is a protocol that will increasingly be available on mass-market smartphone/tablet devices

That can be a significant advantage - as it means that you don't have to develop, manufacture, and distribute your own "reading device".

 

But you will have to develop the App - which is a whole can of worms in itself...

 

Also, to be able to work with such devices means your embedded part has to meet the "full" BT requirements - you can't just do some simplified protocol optimised specifically to your requirements.

 

Jim was worried about adding "a whole new micro" when I suggested SAM R21: https://www.avrfreaks.net/comment... - adding BT will certainly mean adding a new micro!!

 

surprise

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Likely most Bluetooth transceivers are a micro though some do not have access to that micro (peripheral role Bluetooth instead of central role).

Some Bluetooth will make the 50m range requirement; others may not without some thought (antenna(s), gain, etc.).

Atmel is new to Bluetooth 4 (Bluetooth Smart, Bluetooth Low Energy).

Atmel has AVR with sub-1GHz ISM radios.


https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-NANO-BLE/

http://www.atmel.com/products/wireless/wifi/smart-connect.aspx

http://www.atmel.com/products/wireless/smartrf/tranceiver_ics.aspx

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the insight. As I said above, this is still in the concept stage. 

 

Not thrilled about 2.4GHz in this application. Sub-GHz would seem more suitable.

 

I am not worried about protocol compatibility. I will supply the device that it will be paired with. I think.

 

Lots to keep track of while trying to sort things out. Your comments help!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

John_A_Brown wrote:

I guess the point is that [Bluetooth] is a protocol that will increasingly be available on mass-market smartphone/tablet devices

 

That can be a significant advantage - as it means that you don't have to develop, manufacture, and distribute your own "reading device".

 

But you will have to develop the App - which is a whole can of worms in itself...

 

Also, to be able to work with such devices means your embedded part has to meet the "full" BT requirements - you can't just do some simplified protocol optimised specifically to your requirements.

 

Jim was worried about adding "a whole new micro" when I suggested SAM R21: https://www.avrfreaks.net/comment/1534951#comment-1534951 - adding BT will certainly mean adding a new micro!!

 

surprise

 

 

I was thinking more along the lines of substituting one micro for another. My only experience of BTLE is using the Nordic nRF51822, which is certainly capable of reading a sensor or two, in addition to running the BTLE stack.

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Atmel is new to Bluetooth 4 (Bluetooth Smart, Bluetooth Low Energy).

So new that they don't even have any BT products yet?!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Greetings -

 

I have an application that is battery powered. It may need to sit there, waiting for a wireless query, for several months. Wake up (that is, initial connection time) can be very slow, perhaps as long as several seconds. Operating distance needs to be no more than 50m. 

 

So, I am looking for something which has either a very low receive current or which has an effective "receive sleep" mode, waking periodically to check for a received signal. 

 

This device needs to work in one of the international ISM bands. Data rate does not have to be terribly fast.

 

I'd appreciate any recommendations.

 

Thanks,

Jim

 

There are no efficient transeivers in that band.  Bluetooth is your best bet but it isn't ISM.  There are a number of modules that are about 35mW during operation and can be put to sleep if you just need to wake them once in a while that may work.  They can achieve about 300kbps.  The least expensive unit out there is a PAN1322.  The software interface is nothing short of horrible but you can eventually get it working.  If you need distance, I would to to the Laird BT740.  It has a beautiful software interface and the performance of the transeiver is exceptional.  It is a CLASS 1 and will get you 50M.   The PAN1322 MIGHT get you 50 meters but only for line of sight and only if there is nothing in the way.  Bluetooth 2.0,2.1, 2.1+EDR does not offer an unreliable network so it will just keep retransmitting a failed packet until it get through or it times out.

 

Bluetooth LE (4.0) is much more energy efficient but doesn't offer an SPP (last I looked).  Performance over 4.0 is horrible at a max of about 50 kpbs.

 

ISM is limited to WIFI and only for dualband routers.  ISM is also far more directional and will require 10 times as much power as BT.

 

Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Re above..

WiFi and Bluetooth are industrial alliances' trademarks. These are based on IEEE standards like 802.11, 802.15.4, etc. The IEEE standards define frequency bands in which these standards are to be used.

The "ISM" bands are unlicensed in most countries. Bluetooth (an IEEE standard) is used in 2.4GHz though other bands may some day be popularized. Bluetooth is in 2.4GHz for the same reason as 802.11/WiFi is - unlicensed in most countries.

 

The only universally international unlicensed band I know of is 2.4GHz. The 5.4 and 5.8GHz bands are unlicensed too, but have more complex regulations among countries.  802.11/WiFi is NOT the only radio service using 2.4GHz. In Japan, 4.9GHz is (was?) unlicensed for WiFi-like uses. In the US, 4.9GHz is licensed for public safety only.

 

I'll omit the bands above 5GHz and the few unpopular 1GHz and up bands - unlicensed.

Sub-1GHz, the 902-928MHz band is unlicensed and very popular in No. America and some other regions. In much of the EU and Asia it is a licensed band and used for cellular systems. In AUS, and elsewhere that band is 918-928MHz as I recall.

The 868MHz "band" is rather narrow and is unlicensed in some of the EU. In No. America a pair of at/near 868MHz duplex wider bands is licensed to cellular system operators.

The 433 and 315MHz "bands" are unlicensed in some of No. America, but in the US there are restrictions on transmitter duty cycle intended to better enable transmit-only devices like temperature sensors.

 

As to the  comment  on directionality: That comes from selection of antenna types. No matter the band.

 

 

Last Edited: Tue. May 5, 2015 - 05:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samgm2 wrote:
Bluetooth is your best bet but it isn't ISM

See stevech comments - "ISM" includes 2.4GHz

 

How is Bluetooth inherently "better" than anything IEEE 802.15.4-based - especially considering that one could you a specifically optimised, proprietary scheme over it?

 

Quote:
Bluetooth LE (4.0) is much more energy efficient but doesn't offer an SPP (last I looked)

You mean Serial Port Profile ?

 

Nordic certainly have examples of of "UART over BTLE"

 

Quote:
Performance over 4.0 is horrible at a max of about 50 kpbs

That sounds like it could certainly be adequate for the case at hand?

 

Quote:
ISM is limited to WIFI and only for dualband routers

Nonsense - See stevech comments!

Quote:
ISM is also far more directional and will require 10 times as much power as BT.

Nonsense - See stevech comments!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
the devices sit there in a RF quiet environment until somebody approaches with a box to query it

Does the "query" have to be initiated wirelessly, or could the "somebody" press a button, say?

 

As noted, the trouble with wireless "initiation" is that the radio needs to be ON (ie, consuming power) continually to detect it.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless mistaken, I think this is Jim's "up the top of the tree measuring its sway" project. Climbing to press a button might be a "little daunting". cheeky

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

samgm2 wrote:
Bluetooth LE (4.0) is much more energy efficient but doesn't offer an SPP (last I looked).
No SPP though there is UART-like with Android and iOS applications.

Adafruit Industries very recently announced a BLE UART module-on-board.


https://github.com/NordicSemiconductor?utf8=%E2%9C%93&query=uart

https://plus.google.com/+adafruit/posts/CCRh2WFtAu4

P.S. access to Google can be a problem : https://www.adafruit.com/products/2479

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Atmel is new to Bluetooth 4 (Bluetooth Smart, Bluetooth Low Energy).

awneil wrote:
So new that they don't even have any BT products yet?!

 

Just seen this: http://blog.atmel.com/2015/01/23...

 

So just into the "vapourware" phase...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...