What is the difference between M2M and IoT?

What is the difference between M2M and IoT? In this introductory article we will take a high level look, and introduce the novice to some fundamental concepts.

First off, both M2M and IoT are acronyms. M2M stands Machine to Machine (communications) while IoT is the Internet of Things. The acronym M2M has been around for a while, and in fact Raveon Technologies has been involved in M2M solutions for a decade. At the same time IoT is generally speaking a much newer acronym. Some people may consider M2M and IoT as the same thing, while others will have a very different viewpoint. In our own view IoT includes M2M solutions, but more as well.

As we have already mentioned, machine to machine communications has been around for a while. M2M involves two or more machines in communications, either in one direction, or in both directions, with the general goal of automating some function or process, that otherwise would be perfumed by humans. A classic example of this is a water tower and water pump, communicating in some manner to keep the water in the tower between suitable level boundaries. Here is a picture:


Here the pump house or monitoring station received updates from the water tank on water levels. When the water level reaches a certain low point the water pump turns on, and when the water level reaches a certain high point the pump turns off.

The nature of blue line between the tower equipment and pump equipment represents the communications link for the machines to talk. In this particular example the communications link only needs to be one-way. Using Raveon wireless data radio modems the communications link would typically be a narrowband UHF or VHF radio frequency. However, a hard wire connection, a telephone lease line, a cellular modem, a satellite link, or multiple others forms of data communications could be used.

In the example above, what if the blue line was the public Internet, or even a private ‘Intranet’ owned by the water utility? Certainly two ‘machines’ are still in communication, but has this crossed over into the realm of an IoT example? This is up to the reader to decide.

Certainly the Internet in general connotes a certain level of presence, approaching ubiquity. For years the Internet has been used to communicate between two people and evolved to multiple people and multiple stores of information. Up to the present the Internet has been considered primarily an information communications network, but as more machines become Internet connected their M2M communications purpose begins to morph into an Internet of Things application.

What useful purpose might an IoT serve that an M2M application does not? Consider the same example above, but now with a great number of water towers and pumps.

In a complex system, spanning perhaps a city or region, it can become important to make management decisions over a much greater group of criteria. How do you provide reasonable water pressure to all users while demand may fluctuate greatly? How many pumps can run simultaneously? What are the pipeline capacities? What happens if a pipeline springs a leak? What is the demand on electricity? Do electricity prices vary during the day? Can we use weather forecast models to project temperatures, sunlight, and evaporative loss, and thus plan ahead for heavy demand? With the growth of devices and more complex decision making the ability for information of all sorts as well as pumps, valves, and sensors control and feedback to be available increases greatly in importance.

This is only a rudimentary example. Use your imagination to think of complex oil, gas, or electric distribution systems. How about traffic light control? How about vending machines which signal sales allowing restocking vehicles to be routed automatically, while tying into inventory control? Think about your own home, with ‘smart homes’ and ‘intelligent’ devices such as refrigerators and pantries keeping track of your grocery list and automatically ordering groceries to be delivered by drones, in a just-in-time delivery model, that notifies your phone via your Internet presence so you know what is happening and don’t need to stop at the store.

As more devices are imbedded with a level of artificial intelligence, and as more information is shared to make human life better, or at least human drudgery more automated, the ‘things’ that will connect to the Internet are projected to grow exponentially, and the Internet of Things will become more of a reality.

At Raveon Technologies Corporation we are working not only on improving communications, but allowing these complex communications networks to become more expandable and more efficient, while improving manageability as well as security. We welcome the reader to visit http://www.raveon.com/dart/ to learn more about what we are doing today to enhance your tomorrow.

Larry Top

Raveon at IoT Evolution 2016

Raveon exhibited at this year’s IoTEvolution Expo in Ft. Lauderdale. At this years event Raveon presented it’s dynamic plug and play Narrow Band wireless data solutions while also introducing it’s upcoming line of small, high performance Daisy radios.

One of the highlights during the Expo was Raveon’s introduction of it secure, protocol independent, and high device volume DART gateway application.

Raveon is a manufacturer of Wireless Data Radio since 2004. Our passion is the manufacturing of reliable long life plug and play wireless connected data radios unconstrained by protocol, application, or connectivity limits resulting in one radio for virtually all your IoT and M2M application.

For more information about Raveon and future event opportunities;
David Raine

What protocol will make it through the innovation stage?

Billions of connected devices will require thousands of applications to manage the transmission, reception, distribution, and sharing of this immense amount of data. In any fast emerging market there are fast emerging solutions; LoRa, Xigbee, Alljoyn, OIC, IIC, Z Wave, Thread, IPv6 and many more.

Adaptation and consumer value of connected devices will be driven by the user’s overall experience and benefit to all this great data now capable of being shared. Today the largest benefactors of IoT are from tracking objects, even if it’s just themselves, and utility scale telemetry. Smart Homes are projected to be the largest market segment representing over 3.5 billion devices by 2020, followed by smart building at 1.7 billion, then general industry at 1.5 billion, medical and transport at 400 million each.

The money typically leads a market. With homes and commercial buildings being a primary driver in connected devices the most likely connectivity protocol will be wi-fi and Bluetooth connected devices. This is primary driven by our current devices in which we’ve grown very dependent on. The average US home has 6 mobile devices, the average UK home has 7.

The carriers are pushing hard to build out the IoT market with LTE standards while these same subscription based services are driving the market towards other solutions such as wi-fi and Bluetooth. The question is do you really want to pay a subscription package fee per month to connect your fridge to your toaster? I feel adaption of IoT within the home will be driven by the manufacturers in incorporating connective capabilities that leverage the most common free accessible tools available. A majority of the protocols out there today are dependent on the LTE subscription based services. Similar to the web the IoT space in order to evolve will need one common protocol and like the web it will be difficult to charge a subscription fee within a culture already expecting free connectivity.

An important factor in determining the most promising standard protocol will depend greatly on its ability to handle the projected billions of devices soon to be talking to each other. Major networks are already planning for that future. Cellular has 5G just around the corner with carriers already separating out their networks into mobile and IoT sectors allowing for lower band allocation to IoT devices and IPv6 available today is gaining fast ground allowing for substantial increase in networkable IP based devices.

There are approximately 57 major US cities with citywide free wi-fi connectivity with a user base of less than 2%. Will this not be 200 cities in the next 5 years and open access means a new opportunity for free device connectivity.

David Raine

Carrier Detect and Busy Channel Lockout – A Collision Avoidance Mechanism

In a number of radio operating environments, whether data radios or voice radios, either system logistics or regulations may suggest a radio device listen for a signal on the intended frequency prior to transmission. This can serve a very useful purpose, as two radio transmissions occurring on the same frequency simultaneously within the same area will likely interfere with a receiver’s ability to clearly distinguish one transmission from another. This occurrence is conventionally called a collision, and thus collision avoidance is the goal.

One way to avoid two simultaneous transmissions on the same frequency interfering with a receiver is to physically space the two competing radio systems far apart. This is the primary reason why the Federal Communications Commission licenses radio frequencies to individual users. As the use of specific radio frequencies are licensed, their location of use is noted and the relicensing of the same frequency is coordinated to ensure that the competing systems are far enough apart to avoid interference with one another. This is also the reason why Raveon recommends the use of licensed frequencies in most applications. Still, upon occasion interfering signals will appear unexpectedly and a radio collision will occur. Certainly this occurs with regularity when unlicensed frequencies are available for anyone to use. Finally, even within a single radio system it is important to coordinate transmissions effectively and avoid collisions.

In systems operating within any particular area the most common technique utilized by transmitters in collision avoidance is to first listen on the air for potential interference before transmitting. This technique is called Carrier Detect or alternatively Carrier Sense. Raveon radios feature Carrier Detect capabilities where the radio modem listens on the intended transmit frequency. When the frequency appears busy either from a transmission within the system, from another system, or simply due to background noise, the radio can be prevented from transmitting, waiting a brief random duration before once again preparing to transmit the same message. This prevention of transmission feature is termed Busy Channel Lockout. It is important to note that the transmit and receive frequencies on the radio modem must be identical for this feature to work. Following is how Carrier Detect and Busy Channel Lockout features are used in concern on Raveon data radio modems for Collision Avoidance. The commands and parameters discussed can be found in the Raveon RV-M7 data radio modem Technical Manual.

First, a Carrier Detect Threshold is specified. This is the signal strength level the radio will listen for to determine another transmission may be taking place, and is measured in dBm. By factory default the threshold is -113, which correctly implies that Carrier Detect capability is always enabled. The larger the absolute value (the further from zero) the weaker the external signal strength is at the receiver, although it may still be detected. One immediate effect of signal detection is that the STAT LED on the radio (if available) will flicker green This is very roughly analogous to a squelch setting in a voice radio. The command mode command to set or read this value is ATCD. Typing ATCD will read back the current value, and typing ATCD “x” (where x is the dBm value) will reinitialize the parameter. For instance ATCD -105 will reset the parameter so that signal levels less than -105dBm (-106, -107 and beyond) are ignored. The command syntax calls for the minus sign to precede the integer value. The Carrier Detect Threshold may alternatively be set utilizing Raveon Radio Manager software.


If the threshold is changed, the value should be carefully selected by comparing the background or interfering signal level to the received signal level of an intentional transmission. While Raveon radios are very good at distinguishing intentional signals above background noise and receiving data correctly, a minimum of a 20dBm difference should exist between intentional and background signals. A 30dBm difference is even better. For example, if your intentional transmission is received at -85dBm, you want to ensure that background signals stronger than -105dBm are heeded, and your system does not attempt to transmit. Thus you may set the Carrier Detect Threshold to -105dBm, a smaller value, or use the default of -113dBm.

You can take an instantaneous sample of the signal level heard by your receiver, by typing the command ATRQ. You can also determine the peak background signal found within a defined period by using the Bandscope feature of Radio Manager. Finally, you can determine the received signal strength of any specific transmitter in your network by the PING command and function. When a remote radio responds to a PING, the local radio will also display the RSSI (Relative Signal Strength Indicator) signal level of the response. The PING function is also available on the Interaction tab of Radio Manager.

Bear in mind that you want to be selective in determining your Carrier Detect threshold or trigger level. If you set your Carrier Detect threshold too close to the ambient noise level, any ambient noise variations may prevent the radio from transmitting. It is best to balance your Carrier Detect threshhold somewhere between your ambient noise level and weakest true signal level, trying to ensure your Carrier Detect threshold is at least 20dB stronger than ambient, if this is possible within your environment.

Once your Carrier Detect threshold is established (or if you choose to use the default), enabling Busy Channel Lockout is as simple as turning it on. It is important to note that the Raveon factory default has Busy Channel Lockout disabled. When this is the case, the radios still respond to background noise in excess of the threshold by blinking the STAT LED green. This STAT LED function is useful for a quick assessment of ambient interference, in an otherwise quiet system. To enable Busy Channel Lockout, either issue the command ATBC 1 (ATBC 0 turns BCL off), or check the Busy Channel Lockout box in the Basic Settings Tab of Radio Manager:


When Busy Channel Lockout is enabled, the Raveon radio will first listen to the radio channel and if no signal is detected above the Carrier Detect Threshold, the radio will transmit. However, if an excessve carrier signal is detected the radio will not transmit, and will retry upon some random minimum delay. The delay period is randomized intentionally, and random backoff times are the de facto industry standard. The number of retries can be set by the ATRB command with 0-99 being the valid range of retries.

Use caution when setting your Carrier Detect Threshold and enabling Busy Channel Lockout, as a carrier wave interferer, PC with poor shielding, or some other source of RF can prevent the modem from transmitting.

Finally, while Carrier Detect with Busy Channel Lockout is an often used Collision Avoidance technique, it is not the most efficient use of bandwidth. Statistically, approximately 30% of overall bandwidth utilization is achieved with this technique. In systems where internal interference (where other in-system transmitters are the potential offenders), more sophisticated and deterministic mechanisms such as TDMA (Time Division Multiple Access) may be used. Statistically TDMA is projected to come close to 100% available bandwidth utilization, and for busy systems may be the technique of choice. A number of Raveon devices are available with TDMA. See this link or contact us for more details: http://ravtrack.com/GPStracking/tdma-time-slots/71/

Larry Top