How to manage low power, low speed long range RF comms?

[Rerouter]

Hello, I'm working on some set and forget logging sensors that I would like to give RF comms to, so that driving by the area let them ping in and download there stored memory, say once per day, to once per week, with a payload of about 2KB per day, However i am struggling with which method to choose.

My constraints,

Its powered by a coin cell, I can go for a larger one, but still current and amp hours are limited, (my current device chews an average of 8uA while logging)
Range would ideally be between 85 - 220m, larger is better, but i Understand it generally chews more power,
The receiver will have a nice big supply, and can have amplification. and have an antenna height of about 2m above the ground.
The device will be about 10cm above the ground, clear of grass or other material, a pcb or stiff wire antenna is possible, but not a sma pivot.
And transfer speed is not much of a concern.

So far I have been pointed at the nRF905, however people testing them have given mixed results.
https://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf

Any thoughts or suggestions?

[ogden]

Range would ideally be between 85 - 220m, larger is better, but i Understand it generally chews more power,

Make sure your base station have good (hi gain) antenna and sensors include transmit power control. For instance if sensor receive/measure strong base station signal, it can transmit at low power. You will save battery and avoid saturation of base receiver LNA as well.

So far I have been pointed at the nRF905, however people testing them have given mixed results.

nRF905 is good choice, you need 868/915 MHz for > 200m NLOS application. Of course, there are many other similar transceivers, very popular is CC-series from TI.

What is worst case maximum sensors in base station range? For how long each sensor have reach to base station? - Drive-by can be at 100km/h on highway or it can be slow moving tractor in the field.

[Rerouter]

nRF905 is good choice, you need 868/915 MHz for > 200m NLOS application. Of course, there are many other similar transceivers, very popular is CC-series from TI.

What is worst case maximum sensors in base station range? For how long each sensor have reach to base station? - Drive-by can be at 100km/h on highway or it can be slow moving tractor in the field.

maximum sensors would be 80 per 100m radius, and sorry, more correctly would be drive up and wait. Its to remove the need to do field retrieval of data.

[ogden]

maximum sensors would be 80 per 100m radius, and sorry, more correctly would be drive up and wait. Its to remove the need to do field retrieval of data.

I recall you said 220m? What number of sensors could be in 400m range? Any possibility of non line of sight? Any walls between station and sensor? - Anyway you shall have good & reliable MAC layer, good planning of data transfer amounts and speeds (the higher speed the less sensitivity, thus range), and thorough real-world testing as well.

[Marco]

Just looking at the sensitivity _claims_ the nRF905 seems somewhat behind the time. Ultra-narrow band is king, this is the territory of the Sigfox/Lora chips from On Semi, Semtech and TI with 10-15$ module cost. Then there are the many HopeRF rebadges with god knows what ICs at claimed -120 dB sensitivity for peanuts ... but caveat emptor.

[ogden]

Just looking at the sensitivity _claims_ the nRF905 seems somewhat behind the time. Ultra-narrow band is king, this is the territory of the Sigfox/Lora chips from On Semi, Semtech and TI with 10-15$ module cost. Then there are the many HopeRF rebadges with god knows what ICs at claimed -120 dB sensitivity for peanuts ... but caveat emptor.

Ultra-narrowband is not solution for every RF sensor application, it's not king at all. It is good only for very low throughput, long range applications like meter reading. Particular application is not like that. SigFox does not meet requirements definitely. Proprietary LoRa at higher bitrate maybe. For 200m range there's no need for best ever sensitivity. There's throughput (data transmission speed) versus sensitivity tradeoffs as well. Further reading: https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem

When you have 200 sensors having 2KB data each to read, you would not be happy to use 100bps of UNB bandwidth to read them when arrive on site because it can take forever.

Just FYI - SigFox have daily data limit per sensor node:

- 140 messages in uplink with a payload up to 12 bytes
- 4 messages in downlink with a payload of 8 bytes

Obviously node cannot send it's daily quota in one transmission because there's duty cycle limits as well.

[cstratton]

Pinging the nodes to request data may be problematic, as that implies that the node has to wake itself and its radio up fairly frequently to check for pings.  That's plausible for a mains-powered smart meter, but not really for something running from a battery, even a battery several times larger than the one you want to use.

Most of the really, really low power sensor nodes transmit on their own schedule, to mains powered always-monitoring receivers.  If they receive, it's typically only after enough recent communication to synchronize clocks and establish a narrow time window when they should be awake and listening.

Can you have a mains powered aggregator/gateway that would collect somewhat randomly timed node transmissions at a site, and then do a drive-by-query of that at a higher bandwidth?

Can you add a solar panel to each node, and only try to collect data when it is sunny?

[Marco]

Sigfox even moreso than LoRa doesn't really seem to be relevant as a standard. The TI chips you alluded to are also nominally Sigfox after all. The AX5043 is as capable of higher bitrates as the CC1120. They both have 10 dB sensitivity on the nRF905 at 50 kbps, but unlike it they can also go much lower if necessary.

There are 432*200 seconds in a day, so even at 0.1 kbps a lot of nodes can send data to a single receiver.

[ogden]

Pinging the nodes to request data may be problematic

No it's not. Base station shall always/continuously transmit on control channel, calling for nodes and assigning data transmission time slots. Node wakes-up every minute or so for short period of time looking for base station signal. When base detected, it does inform station it's presence and waits for data transmission time slot assignment which shall follow shortly as soon as it is available. When assigned, it changes RF channel to data transmission to transmit data.

[edit] Other option obviously is some collision avoidance MAC protocol which also is feasible as low power here.

If node receiver is listening (15mA/3V) for let's say 5 ms each minute, it's average waiting consumption is 1.25 uA. You can do it even with CR2032 button-cell. Transmit budget depends on application, battery sizing as well. But to say that mains power needed - it's BS.

[ogden]

Sigfox even moreso than LoRa doesn't really seem to be relevant as a standard. The TI chips you alluded to are also nominally Sigfox after all.

No. Fact that CC-series chips can be used for SigFox does not make them SigFox nominally. [edit] AX5043 you mention is more "SigFox nominally" because of it's native PSK support. To get SigFox PSK modulation out of CC-series, you have to do quite a tricks considering it does not directly support PSK.

There are 432*200 seconds in a day, so even at 0.1 kbps a lot of nodes can send data to a single receiver.

You are advised to read initial post more carefully. Application is "driving by the area let them ping in and download there stored memory, say once per day, to once per week". Meaning base station could be out of sensor range for more than week. [edit] And you have 2KB per day of data per node to download.

[cstratton]

Pinging the nodes to request data may be problematic

No it's not. Base station shall always/continuously transmit on control channel,

Well, for starters, continuous transmission is typically not legal in the regulatory categories under which these systems typically operate. 

Instead, they must typically obey duty cycle limits.

Reduced transmit duty cycle, plus clock uncertainty, means longer receive windows.

Longer receive windows means more power consumption...

That might be a reason to consider something in the more permissive 2.4 GHz ISM band for a close-up application, rather than the sub-GHZ frequencies typically used for this kind of thing, especially at longer ranges.

[RoGeorge]

[ogden]

Reduced transmit duty cycle, plus clock uncertainty, means longer receive windows.

Longer receive windows means more power consumption...

Duty cycle is strong argument. Ok. Base does not send continuously. Then use CSMA/CD or similar - where base listens and node tries to transmit to get control comms to base. Again doable at low power and duty is not violated. [edit] Proposed 2.4GHz will have same problem (multiple nodes trying to get one base) to solve.

[Marco]

No. Fact that CC-series chips can be used for SigFox does not make them SigFox nominally.

Lets just agree to disagree on what nominally means then.

Any way, for my own amusement lets run down the likely suspects at 50 kbps :
AX5043 -111dB 50 kbps BER 0.1%
CC1120 -110dB 50 kbps BER 1%
nRF905 -100dB 50 kbps BER 0.1%
SI4463 -110dB 40 kbps BER 0.1%
SX12312 -105dB 38.4 kbps BER 0.1%
CMT2300A -109dB 50 kbps BER ?

So yeah, I'll have to admit for the higher bitrates it doesn't seem to matter much ... but the nRF905 is still a bit old in the tooth.

[ogden]

So yeah, I'll have to admit for the higher bitrates it doesn't seem to matter much ... but the nRF905 is still a bit old in the tooth.

You did prove your point. Agreed that nRF905 is old and there are better transceivers around. Let's rephrase: nRF905 could do the job for particular application. My preference for new designs is TI or Semtech offering. Thou Semtech transmitter stage have its "EMI compliance quirks", but with good RF engineering it works [edit] SiLabs looks good on a paper as well, but I have no experience with it.

p.s. Does anybody besides SigFox engineers knows how to transmit SigFox signal using CC-radios? - I mean some uC source code here.

[Marco]

Duty cycle is strong argument. Ok. Base does not send continuously. Then use CSMA/CD or similar - where base listens and node tries to transmit to get control comms to base. Again doable at low power and duty is not violated. [edit] Proposed 2.4GHz will have same problem (multiple nodes trying to get one base) to solve.

If possible I'd have the transmitter cycle through the ID's of the sensors continuously in it's pings, avoids the hidden node problem.

[cstratton]

Continuous relative to the accepted protocol, not continuous carrier CW.
For BLE, for instance, that would be continuously advertising which occurs frequently but not actually literally continuously.

BLE is in an ISM band where higher duty cycle in permitted than in the sub-GHZ bands typical for meter readings.

Also, while uncoordinated BLE beaconing may transmit from an ultra-low-power coin cell device, it is typically *received* by something with a several watt hour battery only expected to last a couple of days, ie, something that can afford substantial receive windows.

[ogden]

If possible I'd have the transmitter cycle through the ID's of the sensors continuously in it's pings, avoids the hidden node problem.

Please explain why CSMA/CD (or similar) have hidden node problem and how you can cycle through sensor ID's without sensors continuously listening.

[cstratton]

how you can cycle through sensor ID's without sensors continuously listening.

Well, if a node hears a query for a different node in the same pool, it could at least take that as a hint to start listening more than it usually does in the hope of hearing a request to its own ID.

Hearing another node in the same pool transmit a response could probably be a useful attention hint as well.

[ogden]

Also, while uncoordinated BLE beaconing may transmit from an ultra-low-power coin cell device, it is typically *received* by something with a several watt hour battery only expected to last a couple of days, ie, something that can afford substantial receive windows.

I believe that BLE could be used in particular application as well, thou sensor BOM and complexity will be higher compared to "common" ISM transceiver IC's. Thou I may be wrong. Comments here are welcome.

[ogden]

how you can cycle through sensor ID's without sensors continuously listening.

Well, if a node hears a query for a different node in the same pool, it could at least take that as a hint to start listening more than it usually does in the hope of hearing a request to its own ID.

Hearing another node in the same pool transmit a response could probably be a useful attention hint as well.

Recall base station duty cycle argument mentioned in this thread? - It shall not transmit all the time meaning sensor nodes shall have significant receive time window meaning battery drain penalty for sensor. No good.

[edit] Low power sensor shall periodically call for base, not opposite (if base cannot transmit "i'm here" continuously). In particular application "emptied" sensors can go to extended sleep for hours - to free channel and increase communication chances for others.

[Marco]

Please explain why CSMA/CD (or similar) have hidden node problem

Two sensor nodes on opposing side of the tractor, tractor hears both while sensors don't hear each other ... so they will try to interfere.

and how you can cycle through sensor ID's without sensors continuously listening.

I'd do pinging on one frequency and responses on another. Ping through the IDs continuously with just enough time in between for a node to respond, while receiving from a node just keep pinging the same ID continuously. So say node X wakes up and listens for pings, it hears the ping for Y ... it knows it can sleep at least for modulo(X-Y)*inter-ping-time before it listens again. It will probably still not be it's turn then, but it can make a conservative estimate using the same method again and again till it is.

[ogden]

Two sensor nodes on opposing side of the tractor, tractor hears both while sensors don't hear each other ... so they will try to interfere.

This is not a problem at all. You just have to invest more of your brains or google search into it. - If two sensors interfering to each other in transmission x, then in transmission x+1 they will not because they will use different (to each other) random transmission time slot next time. Ethernet over coax and not only, prove that it works.

[Marco]

This is not a problem at all.

There are workarounds for the problem, of varying effectiveness and complexity. Lets say you do it naively and just cut up 10 seconds into 30 time slots to send 2kB, if 100 new nodes pile into that at once, it's going to take a while and a lot of collisions to work through. You can use small timeslots for shouting pong and then have the node wait for an ACK to get assigned a non competitive large transmission time slot for the data I guess.

PS. ethernet over coax doesn't have hidden nodes, WLAN does.

[ogden]

Lets say you do it naively and just cut up 10 seconds into 30 time slots to send 2kB

Right - don't do it naively. Naive assumption is that Two sensor nodes on opposing side of the tractor will interfere each other and this is problem that cannot be solved.

PS. ethernet over coax doesn't have hidden nodes, WLAN does.

Then do it as ethernet over coax does/did it.

[Rerouter]

Wow!, That is a lot of input, Thank you all! 

Ok starting from the top:

you said 220m? sensors could be in 400m range? line of sight?

It would be 80 at most, and the general use case would be within 100m, however I am hoping to design in some margin, they will be in a flat field, with some burned shrubs

Pinging the nodes to request data may be problematic, Can you have a mains powered aggregator/gateway that would collect somewhat randomly timed node transmissions at a site, and then do a drive-by-query of that at a higher bandwidth?

Can you add a solar panel to each node, and only try to collect data when it is sunny?

I can definatly have an agregator node, even using much larger batteries (say 3x 18650 cells), however not mains powered, Solar panel is unknown, as the area may have dust storms, still the sensors would need to talk to this aggregator.

The nodes have a unique serial number programmed for identification.

What is the application?

reasonable to assume that you can transfer 2kBy in 8.6 seconds of TX time or less which would be an effective bit rate of ~2kbits/second net.  It only gets better from there if you can transmit and shut up even faster.

if they detect the collection unit's transmission would they transition into a mode where they communicate their data with the collector over the next few seconds to allow all of the nodes time to transfer their data.

The application is ground water, salinity and composition sensors that are driven in to the soil. and are built to be both long lasting and fairly cheap.

If I go with the above suggestion of an aggregator, then a longer receive window should be possible, they are running off watch crystals, so accurately timed receive windows for the agregator should be possible.

To the others, I have internal timers that I can use for arbitration should 2 conflict, however if there is an existing protocol I would probably trust that more than my own dreams,

As for with no arbritation node, My previous experience with multidrop RS485 was if the Id packet was garbled, the base node sent back an error, and the effected nodes xor'ed there timer value by there ID and waited that long. and tried again.

[ogden]

If I go with the above suggestion of an aggregator, then a longer receive window should be possible, they are running off watch crystals, so accurately timed receive windows for the agregator should be possible.

In case you have aggregator node which can continuosly run receiver @20mA+processing_overhead in receive+ACK mode, it can solve a lot of sensor communication difficulties. Just don't pick too narrowband channel for sensor comms because such requires high precision TCXO crystals which are not cheap.

[Marco]

however if there is an existing protocol I would probably trust that more than my own dreams

You'll probably still want to roll your own protocol because your use case is unique. Open sores code for configuration/interrupt/packethandling can be found for some modules.

Just don't pick too narrowband channel for sensor comms because such requires high precision TCXO crystals which are not cheap.

Semtech has a suggestion to work around this ... the low power node simply walks the frequencies to lock in.



PS. how do I link a YT video as a normal link instead of embedding the video?

[ogden]

Just don't pick too narrowband channel for sensor comms because such requires high precision TCXO crystals which are not cheap.

Semtech has a suggestion to work around this ... the low power node simply walks the frequencies to lock in.

You mean SiLabs? Well... They are supposedly solving problem on 169MHz which is rarely used. Better they tell how to use cheap crystals @200Hz bandwidth on 866MHz

Let's check: 11 channels * 180Hz spacing = 1980Hz. Worst case allowable drift for two crystals 1980/2=990Hz. This is ~6ppm for 169MHz. I would say it's not "standard crystal" at all

Spectrum analyzer settings and screen (video time 3:10)  is especially interesting: central frequency 3.4GHz, span 100KHz RBW 910Hz. WTF?!

Perhaps RX synthesizer spectrum picture was so bad that they had to fake it
[edit] They are showing RX VCO frequency, not LO. Then SA settings makes sense indeed.

[Koen]

If you wish to get going, grab some SX127x or some HopeRF modules including it and go. You'll be able to try LoRa or revert to FSK, GFSK, MSK, GMSK and OOK. LoRa is quite tolerant of beginner's mistakes and cheap XOs. It would be hard not to achieve 200m.

Answers above have LoRa (modulation) confused with LoraWAN (subscription-based networks) which you don't need.

[rhb]

A friend of mine designed such a device as a retrofit for water meters.  He managed to achieve a 15 year design life for the battery.  Not easy.  He was rather proud of it when he showed it to me. He used an MSP430 for the MCU.  I don't know what he did for the RF part.  The whole thing was the size of a silver dollar.

[Marco]

RFM95 915MHz uses a rebadged SX1276 BTW.

[Lord of nothing]

does anyone here use 169 MHz?
That was the only tread I could found who is talking about.
Duty cycle limit of 0.1 %. -->