FCC Regulations for  Intentional Radiators in the 902 – 928 MHz Band

In the US, the Federal Communications Commission (FCC) regulates the use of frequencies for wireless communication. The FCC rules and regulations are codified in Title 47 of the Code of Federal Regulations (CFR). Part 15 of this code applies to radio frequency devices operating at unlicensed frequencies and is often colloquially referred to as FCC Part 15.

In the 902-928 MHz band, are no restrictions to the application or the duty cycle which makes this band very popular for unlicensed short range applications such as general wireless sensing and control whether periodic or even driven.

Wireless nodes operating in the 902 – 928 MHz ISM band are classified as intentional radiators and their emissions are subject to the limits given in FCC section 15.209. The maximum power allowed for unlicensed short range applications is –1.23 dBm (EIRP) or -3.38 dBm (ERP).  This limit is applicable to PHYs such as FSK and GFSK.

Even higher output power can be used if the system employs some form of spread spectrum such as frequency hopping or direct sequence spread spectrum. The reason such allowances are made is that spread spectrum systems are less likely to interfere with other systems than are single frequency transmitters. They also have the advantage in that they are often more immune to interference from other systems. The limitations and qualifications of a spread spectrum transmitter are defined in FCC section 15.247

Frequency Hopping Spread Spectrum

  • ≥ 50 channels: +36 dBm (EIRP)
  • < 50 channels: +30 dBm (EIRP)
  • Requirements
    • The transmitter pseudo-randomly hops between frequencies that are separated from each other by at least the 20-dB bandwidth of the data channel, but not less than 25 kHz. 
    • The 20-dB bandwidth of the hopping channel is not larger than 500 kHz.
    • If the 20-dB bandwidth of the hopping channel is less than 250 kHz, the system must use at least 50 hopping frequencies. The average time of occupancy at any frequency (dwell time) must not be larger than 0.4 seconds within any 20 second period.
    • If the bandwidth of the hopping channel is larger than 250 kHz, the system must use at least 25 hopping frequencies. The average time of occupancy at any frequency must not be larger than 0.4 seconds within any 10 second period.


Spread Spectrum using Direct Sequence or Spread Spectrum using High Data Rate Digital Modulation 

  • +36 dBm (EIRP)
  • Requirements
    • The 6 dB bandwidth of the modulated signal is not less than 500 kHz.
    • The peak power spectral density conducted to the antenna must not be greater than +8 dBm within any 3 kHz bandwidth. This corresponds to distributing the +30 dBm output power uniformly over the 500-kHz bandwidth.

As the numbers clearly show, FHSS and DSSS radios are allowed to transmit with much higher power.


Spurious emission requirements for intentional radiators in the 902-928 MHz band.

For non spread spectrum radios, the spurious emission limit is -41.2 dBm (EIRP). 

For spread spectrum radios, the emission in any 100-kHz bandwidth outside the 902–928 MHz band must only be at least 20 dB below the emission in the 100-kHz bandwidth within the band that contains the highest power. There is a catch though. For fundamental signals in the 902–928 MHz band, the 3rd , 4th , and 5th harmonics all fall into restricted bands. Section 15.209 puts a more stringent limit of -41.2 dBm (EIRP) on these harmonics leading to some design constraints on the output filtering in these systems.


Restricted frequency bands relevant to radiators in the 902-928 MHz Band (Section 15.205)

Harmonic # Harmonic Frequency Range Overlapping Restricted Band Frequency Range
1st Harmonic / Fundamental Freq 902 MHz – 928 MHz None
2nd Harmonic 1.804 – 1.856 GHz None
3rd Harmonic 2.7 – 2.78 GHz 2.6 – 2.90 GHz
4th Harmonic 3.6 – 3.71 GHz 3.6 – 4.40 GHz
5th Harmonic 4.5 – 4.64 GHz 4.5 – 5.15 GHz



For queries, write to contact@wisense.in
web: http://www.wisense.in


Wireless Sensor for monitoring Insulin Temperature

We are working on a wireless temperature monitor for Insulin. Insulin (like the one in the image below) needs to be stored between 2 and 8 degree Celsius. Insulin can be expensive. A single pack containing 5 NovoRapid insulin cartridges costs around Rs 2600 (about $37) . Insulin gets damaged if it freezes. It also gets damaged if exposed to high temperatures. An in-use cartridge can tolerate up to 30 deg C but it should be consumed within 4 weeks.

Even inside a refrigerator there can be lot of variation in temperature from one spot to another. Whenever the refrigerator door opens, temperature rises because of exposure to warm air from outside and it takes some time for the temperature to return to normal after the door is closed. In some refrigerators, the cyclic variation in temperature around the set point (which may be user settable) may result in temperature falling below zero during some part of the cycle.  For instance, a set point of say 2 degrees may result in temperature falling below zero and then rising above zero periodically.

Our solution is a small form factor, single CR2032 coin battery powered sub-GHz wireless node suitable for continuous temperature monitoring. The sensor sends ambient temperature and battery voltage to gateway node which in turn forwards this data to the cloud over WiFi.  A single gateway can handle up to 128 sensor nodes.

We are offering three variants –

  • With FCC certified radio.
  • With ETSI certified radio.
  • WPC/GOI compliant radio for India.

The images below show the tag without enclosure.


Low profile temp tag_smaller

We did not use a BT-LE (Bluetooth Low Energy) radio because of its limited range. These tags will usually be inside a refrigerator while the gateway may be in some other room (next to a wall socket). Sub-GHz radios operating at a low data rate (1.2 Kb/s) will provide a stable link in this situation where as 2.4 GHz BT-LE radios with data rate of 1 Mb/s will most probably not work.

Transmit Power is +10 dBm.  Receiver sensitivity at 1.2 kbps is -112 dBm.

Our solution provides 24/7 monitoring where as a BT-LE only radio talking to a cell-phone will be useful only when the cell phone is in range of the temperature tag.

WiSense offers a gateway with a sub-GHz radio interfaced to a Photon WiFi module.  Here’s a pic of our gateway. We also offer another version with internal antennas.




For more information on WiSense products, please visit wisense.in.

Temperature tracking in reefer trucks

We are currently working with a client to add wireless temperature sensing to their fleet of reefer trucks.  WiSense wireless sensor nodes are a perfect fit for such applications.  These nodes have a sleep mode current consumption of less than 2 micro-amps – vital for achieving long battery life.  They operate in the license free 865-867 MHz ISM band which has a longer range and better penetration compared to the 2.4 GHz band. Whats more , the sub-Ghz band is virtually unused in India.

Reefer trucks are a vital component of any cold chain.  These trucks have a refrigerated cargo unit to keep perishable goods such as fruits, vegetables, ice cream etc at the optimal temperature.  I was talking to a group of reefer drivers near a cold storage facility in East Bangalore. This group had just delivered trucks full of Amul ice cream from Gujarat to Bangalore – a non stop journey of forty hours in the blistering heat of  an Indian summer.

Here are some pics courtesy Eicher – a major supplier in India.

The solution required interfacing our coordinator/receiver node  with a GPS/GPRS tracking device. The trucks are currently equipped with a wired temperature sensor. This sensor is installed near the AC inlet at the front of the container. The sensor is wired to the GPS/GPRS tracker inside the truck’s cab. This wiring is also making the solution unreliable,  hence the move to a wireless link.


How does the system work ?

We have a high accuracy temperature sensor (with probe) connected to a WiSense WSN1120-P node. This node has an internal PCB antenna and is powered by a couple of AAA batteries.  This sensor node can be installed outside the container with the sensor probe inserted into the container through a hole in the body.  The other option is to install the whole node inside the container.  If the Reefer container is a metal box, it will form a Faraday’s cage which can severely impact RF communication between a sensor node inside the container and the receiver in the truck’s cab. Having said that, reefer containers are not perfect Faraday cages. We placed our sub-GHz transmitter node inside the  container. The coordinator/receiver node in the cab continued to receive packets from the sensor node although we did observe packets being dropped now and then. To avoid any reliability issues, it may be better to install the sensor nodes on the outside of the reefer container.



Our coordinator/receiver node is connected to a GPS/GPRS tracker device. We used an analog input on the tracker to forward temperature data received from our sensor node. The receiver node converts the temperature data in to an analog voltage signal using a DAC. This signal is converted in to a digital value by an ADC in the tracker unit and sent to the cloud. The cloud software converts this voltage value back in to temperature.

Here are some pics of the installation.







Here’s a snapshot of the sensor’s data visualized in the cloud.

Temperature Graph


For more information on WiSense products, please visit wisense.in

802.15.4 CSMA/CA

The WiSense MAC is based on the IEEE 802.15.4 standard. It uses the un-slotted CSMA/CA algorithm for transmission of all frames (data and control).

Each time a device wishes to transmit data frames or MAC commands, it waits for a random period. If the channel is found to be idle, following the random back-off, the device transmits its data. If the channel is found to be busy following the random back off, the device waits for another random period before trying to access the channel again. Acknowledgment frames are sent without using a CSMA-CA mechanism.


The algorithm is implemented using units of time called back-off periods, where one back-off period shall be equal to aUnitBackoffPeriod.

In un-slotted CSMA-CA, the back-off periods of one device are not related in time to the back-off periods of any other device in the PAN.

Each device  maintains two variables for each transmission attempt: NB, and BE.

  • NB is the number of times the CSMA-CA algorithm is required to back off while attempting the current transmission; this value shall be initialized to zero before each new transmission attempt
  • BE is the back-off exponent, which is related to how many back-off periods a device shall wait before attempting to assess a channel. BE is initialized to the value of macMinBE.


MAC  constants


  • Description: The number of symbols forming the basic time period used by the CSMA-CA algorithm.
  • Value:  20


MAC PIB attributes


  • Data Type: Integer
  • Range: 3–8
  • Description: The maximum value of the back-off exponent, BE, in the CSMA-CA algorithm.
  • Default value:  5



  • Data Type: Integer
  • Range: 0 – macMaxBE
  • Description: The minimum value of the backoff exponent (BE) in the CSMA-CA algorithm.
  • Default value:  3



  • Data Type: Integer
  • Range: 0 – 5
  • Description: The maximum number of back-offs the CSMA-CA algorithm will attempt before declaring a channel access failure.
  • Default value:  4



  • Data Type: Integer
  • Range: 0 – 7
  • Description: The maximum number of retries allowed after a transmission failure.
  • Default value:  3



CCA is performed by the radio chip (CC11XX) when requested through the STX command.

  • In IDLE state: Enable TX. Perform calibration first if SETTLING_CFG.FS_AUTOCAL = 1.
  • If in RX state and PKT_CFG2.CCA_MODE != 0: Only go to TX if channel is clear.

If the radio controller is in RX when the STX or SFSTXON command strobes are used, the TX-on-CCA function will be used. If the channel is clear, TX (or FSTXON state) is entered. The PKT_CFG2.CCA_MODE setting controls the conditions for clear channel assessment.



Baud Rate:  20000 symbols/sec, symbol_time is  50 microsecs

Assume macMaxBE is 5 and  macMinBE is 3.

The CSMA/CA procedure starts with BE  = macMinBE

Back_off_duration = (rand((2^3)- 1)) * aUnitBackoffPeriod * symbol_time 

Assume rand(7) returns 7 in which case

Back_off_duration = 7 * 20 * 20 = 2800 micros  = 2.8 milli-secs.

If the  rand(7) returns 0 in which case   “Back_off_duration = 0  microsecs

If BE is set to macMaxBE (5), then

Back_off_duration = (rand((2^5)- 1)) * aUnitBackoffPeriod * symbol_time 

Assume rand(31) returns 31 in which case

Back_off_duration = 31 * 20 * 20 = 12400 micros  = 12.4 milli-secs.


If macMaxBE is set to 8 – 

If BE is set to macMaxBE (8), then

Back_off_duration = (rand( (2^8) – 1)) * aUnitBackoffPeriod * symbol_time 

Assume rand(255) returns 255 in which case

Back_off_duration = 255 * 20 * 20 = 102000 micros  = 102 milli-secs.



Radio power and range – recap

From Wikipedia –

“In electromagnetic and antenna theory, antenna aperture, effective area, or receiving cross section, is a measure of how effective an antenna is at receiving the power of electromagnetic radiation (such as radio waves).

The power received by an antenna (in watts) is equal to the power density of the electromagnetic energy (in watts per square meter), multiplied by its aperture (in square meters). The larger an antenna’s aperture, the more power it can collect from a given electromagnetic field.”

Power density at a distance “d”  from the transmitting antenna (with output power  Pt) is given by

Pd =  Pt / (4* (pi) * d*d)

Where  pi  is 3.1414.  The denominator is the surface area of a sphere of radius “d”.

As the distance increases, the power density reduces as square of “d”.

Assuming receiving antenna has an aperture “Ar” sq-m, then power received is  given by:

Pr = pd * Ar = (Pt * Ar)/ (4* (pi) * d*d)

Let us  assume that the receiver is d0 meters away in line of sight from the transmitter and there are no obstructions in between (completely ideal scenario).  Assume Pt0 is  the  transmitter’s  power output.  Then Pr0 is theoretically given by:

Pr0  =  (Pt0*  Ar)/(4*pi*d0*d0)

Let us  calculate the power required if we  want  to double  the  distance “d”  but  still receive  the  same power Pr0 at the receiver.

Pr1 =  (Pt1 * Ar)/(4*pi*d1*d1)

Here d1 = 2*d0   and Pr1  = Pr0

d0*d0 = (Pt0 *  Ar)/(Pr0 * 4 *  pi)  –      [1]

d1*d1 = (Pt1 *  Ar)/(Pr1 * 4 *  pi)     – or –    4*d0*d0 = (Pt1 *  Ar)/(Pr0 * 4 *  pi)  – [2]

Using [1] and [2]

4  * (Pt0 *  Ar)/(Pr0 * 4 *  pi) =  4*d0*d0 = 4 * (Pt1 *  Ar)/(Pr0 * 4 *  pi)

– or –

Pt0 =  Pt1 / 4

– or –

Pt1 = 4 * Pt0

The transmitter has to increase it’s output power 4 times to reach twice the distance such that the receiver sees the same power as before.

How much is this increase in “dB” ?

10 * log (P1/P0)  = 10 * log (4) ~ 6 dB

So for every 6 dB increase in transmitted power, the range should double (under ideal conditions).

Let us take a real example. Assume transmitter power is 14 dBm and the receiver is around 1000 meters away and receiving the signal at -106 dBm.

The path loss here is 14 – (-106) = 120 dB.

120 = 10*log(F) =>     12 = log(F)   =>    F =  10^12

The received signal is 10^12 times weaker than the transmitted signal.


Let us say, we use a bad RF cable to connect the radio PCB to an external omni-directional antenna on the transmitter and the RF cable has a loss of say 1 dB. How much range loss does this translate to ?

Let Pt0 be the power (in watts) out of the transmitter’s antenna  when using an RF cable of say 0 dB (ideal) loss. Let Pt1 (In watts) be the power out of  the transmitter’s antenna when using an RF cable of  1 dB loss.

10 log (Pt1/Pt0)  = -1 dB

Pt1/Pt0  =10^(-0.1)

Pt1 = Pt0 * (.795)    [3]

The output power at the transmitter’s antenna is now 0.795 times the previous  power.

Pr0  =  (Pt0 * Ar)/(4 * pi * d0 * d0)         [4]  When using cable with 0 dB loss

Pr1  =  (Pt1 * Ar)/(4 * pi * d1 * d1)         [5]  When using cable with 1 dB loss

We  are interesting in finding the new distance  “d1” at which Pr1 is same as  Pr0.

Pr1 = Pr0       [6]

From [3], [4], [5] and [6]

(Pt0 *  Ar)/(4 * pi * d0 * d0) = ( 0.795 * Pt0 *  Ar)/(4 * pi * d1 *d1)

We  get,

d1*d1  = 0.795 * d0 * d0    =>     d1 = 0.891 *  d0

The range has reduced by around 11 %.

If power loss is 2 dB,  range loss is 20.5 %.  For 3 dB loss in power, the range loss is 29.2 % and so on.  We think 1 dB loss is not a big deal since we are not used to thinking in dB. As you can see now, small losses here and there (low quality cables and connectors, non optimum RF layout,  mismatched antenna etc) and add up to considerable loss in radio range.



Solar Li-ion charger board for sensor nodes

We got our first batch of 100 machine assembled solar Li-Ion charger boards useful for powering all kinds of outdoor electronics like wireless sensor nodes and associated sensors/actuators etc.





Here are the specs for the WLIBPSU v4.0

  • Max  input (solar panel) voltage:  10.5 V
  • Max charge current: 2  A
  • Max  battery discharge  current: 4 A
  • Li-Ion battery charged in 3 phases (trickle charge,  pre-charge, constant  current and constant voltage).
  • Battery under-voltage lockout supported as load is not connected directly to battery.
  • Charger IC can power the load and charge the battery simultaneously.
  • NTC thermistor as required by charger IC.
  • Multiple output voltages (On separate headers/connectors)
    • ~3.3V  (Max 1 A)
    • 4.9V (Max 50 mA)
    • Li-Ion battery output (Max 4A). This supply is gated by a load switch which can be controlled by a signal external to the PSU (for example – by an external micro-controller).
  • On PCB current and voltage sensors (two ICs) which measure the parameters listed below. All values reported over a single I2C bus.
    • Solar panel output voltage
    • Solar panel output current
    • Battery voltage
    • Battery current
      • Positive values reported when battery is getting  charged
      • Negative values reported when battery is getting discharged
  • PCB specs
    • Layers: 4
    • Dimensions:  48.5 mm x 48.5 mm
    • Mounting holes:  4
    • Finish:  HASL
    • All terminals are 2.54 mm pitch

Assembled in Bangalore using genuine components (including passives) from USA.

We have tested this PSU with a 3W solar panel and  2600 mAh Li-Ion battery.

Test Panel Specs

  • Peak  power: 3  Watts
  • Voltage output at peak power point (Vpeak): 8.5V
  • Current output at peak power point (Ipeak): 300 mA

Test Battery Specs

  • Chemistry:  Single cell Lithium-Ion Battery
  • Capacity: 2600  mAh
  • Output voltage: 3.7 V  (nominal), 4.2 V (full charge)


Here is a pic of a WiSense 866 MHz wireless low power wireless node (WSN1120L) powered by the  WLIBPSU v4.0.

Charger PCB, enclosure and battery are inside the enclosure




Battery Voltage Data


In the snapshot above, you can see the Li-Ion battery voltage falling during the evening/night and recovering quickly in the morning. This WSN1120L node is operating in RFD mode in which the node stays in ultra low power sleep mode (< 2 uA consumption) and wakes up periodically (in this case every 10 minutes) to sense and transmit data.

If you want to use this charger in your product, we will provide the driver ( c code) for reading the current and voltage measurements.  Note that the charger IC works in stand alone mode. It does not need any external configuration. The voltage and current measurements are performed by two separate sensor ICs (external to the charger IC).  These sensors can be accessed over I2C. You may choose not to read this data.

If you want to use a solar panel with a different Vpeak, we will change the relevant passives free of cost to suit your panel.

For more information on our products, visit wisense.in.

New product: WiSense WiFi Gateway for cloud connectivity

We are adding a new product to our portfolio – a WiFi gateway for the WiSense LPWMN (low power wireless mesh network). This gateway (WGP20CL) includes a WiSense coordinator node (the WSN1120CL) and a Photon WiFi board from Particle (https://www.particle.io/).







Here are the specs.


WiFi Interface: Photon from Particle (https://www.particle.io/)

Based on Cypress’s WICED architecture, the Particle Photon Series combines a powerful STM32 ARM Cortex M3 micro-controller and a Cypress Wi-Fi chip.

WiSense LPWMN Interface :  WSN1120CL WiSense  LPMWN Coordinator.


Power Supply:  500 mA/5V through USB Cable with Type A connector.

Includes 2200 mAh battery  and Li-Ion charger with auto switch over in case external power is lost.


  • External Sub-GHz half-wave dipole antenna (3 dBi gain). Connects to the U.Fl connector on the WSN1120CL’s radio board.
  • External 2.4 GHz WiFi dipole antenna (2 dBi gain). Connects to the U.Fl connector on the Photon.

Enclosure:  ABS Box (105 mm x 105 mm x  62 mm)

Visual indicators:  3 LEDs

  • LED1: Heart beat to indicate the gateway is powered and running.
  • LED2:  Blinks whenever the Photon receives a sensor  data message from a sensor node  via  the attached coordinator node.
  • LED3:  Blinks whenever the Photon posts sensor data to the Particle cloud.

Cloud interface: Particle cloud platform. Particle also allows data to be forwarded to other platforms such as ThingSpeak, Google Cloud platform, Google maps, Azure IOT  platform etc.

We have ported a portion our gateway application to the Photon. This code receives  sensor data messages from the attached  LPWMN network and forwards them to the Particle cloud.  We have  also tested Particle’s integration with the ThingSpeak platform. We are able to get our sensor data on the ThingSpeak platform via the Particle cloud.


For more information on our products, please visit wisense.com.




Sending WiSense sensor node data to the cloud (ThingSpeak.com)

This week we sent data from bunch of WiSense sensor nodes to the thingSpeak cloud platform. The wireless sensor nodes were registered to a WiSense network coordinator (WSN1120CL) which in turn was connected to a Windows laptop running our gateway application (a C program running under Cygwin).

“ThingSpeak” is an IOT analytics platform that allows the collection,storage, visualization and analysis of sensor data in the cloud. You can create a free “ThingSpeak” account which  limits the per channel data streaming (upload) rate of once every 15 seconds.

The WiSense gateway app (which can be run a Linux system or under Cygwin on a Windows machine) sends data to the “Thingspeak” platform when run with the “mon_ts” command line argument instead of the usual “mon” command.

prompt> ./gw.exe    / dev/ttyS9   mon_ts

Note that each WiSense sensor node is permanently identified by it’s 64 bit extended address which looks like “0xfc:0xc2:0x3d:0x00:0x00:0x1e:0xd0:0x40”. This is an IEEE assigned globally unique id.

We decided to create a separate “ThingSpeak” channel for each WiSense sensor node.

“Channels store all the data that a ThingSpeak application collects. Each channel includes eight fields that can hold any type of data, plus three fields for location data and one for status data. Once you collect data in a channel, you can use “ThingSpeak” apps to analyze and visualize it.”

Each “Thingspeak” channel can have up to 8 sensor data fields. We map each sensor  (on a  WiSense sensor node) to a separate field. A free “Thingspeak” account accepts channel data once every 15 seconds only.

We use a text file named “ts.txt” to associate a WiSense sensor output (each having a unique 8 byte extended address) to its corresponding field in a “Thingspeak” channel.  The WiSense gateway app reads and parses the “ts.txt” file when run with the “mon_ts” argument. When this app receives sensor data from any sensor node in the attached WiSense LPMWN (low power wireless mesh network), it looks up this table for a  matching row and if found, sends the sensor data to the ThingSpeak cloud using the HTTP “POST” method specifying the channel API key and field.

The mapping table below is the actual “ts.txt” used in our setup.

<$<  fc:c2:3d:00:00:00:db:40     NCT4JOQR1ZI5DEHB       013    field1   >$>
<$<  fc:c2:3d:00:00:02:b9:9b     4WZBK65FZNTO6JWS     013    field1   >$>
<$<  fc:c2:3d:00:00:10:82:97     XXTNNZSMAZQKMIL5    009    field1   >$>
<$<  fc:c2:3d:00:00:11:1a:ea     ZBT7N4IKJKCND80L        120    field1   >$>
<$<  fc:c2:3d:00:00:11:1a:ea     ZBT7N4IKJKCND80L        009    field2   >$>
<$<  fc:c2:3d:00:00:11:1a:ea     ZBT7N4IKJKCND80L        176    field3   >$>
<$<  fc:c2:3d:00:00:11:1a:ea     ZBT7N4IKJKCND80L        177    field4   >$>

For each unique sensor data stream produced by a WiSense sensor node, there is one row  in the mapping table.

  • The first column is  the 8 byte IEEE assigned  globally unique address of a WiSense sensor node.
  • The second column is the  Write API Key of the associated “ThingSpeak” channel. Note that one “ThingSpeak” channel needs to be created per WiSense sensor node.
  • The third column is the 1 byte device-id of the Sensor output (example – ambient temperature) sent by the WiSense node. Note that if a single sensor has multiple outputs (such as both temperature and relative humidity), then each output will be assigned a separate device id.
  • The  fourth column indicates the channel field assigned to this particular sensor output.

The mapping table shows four different Write API Keys each corresponding to a unique  “ThingSpeak” channel. The last four rows have the same Write API Key and correspond to the 4 different sensor outputs received from the associated WiSense sensor node. Note that each of these four rows has a unique field column.

In the table above, the different sensor output ids are –

  • 013 :  NTC thermistor data (NXFT15XH103  from Murata).
  • 009:  LM75B temperature data (NXP)
  • 120:  MSP430 On chip supply voltage data (TI)
  • 176:  RH data from a CC2D33S sensor  (Amphenol advanced sensors)
  • 177:  Temperature data from a CC2D33S sensor  (Amphenol advanced sensors)

Here is a snapshot of the sensor data visualized by ThingSpeak for one of the sensor nodes with four sensor outputs (the last four rows in the mapping table at the top).



Here’s a pic of the setup showing a windows laptop running the WiSense gateway app under Cygwin, a WiSense coordinator node connected to the laptop and a WiSense sensor node generating 4 sensor output streams corresponding to the last 4 rows in the mapping table shown above. The laptop is sending data to the ThingSpeak cloud over a WiFi/broadband connection.



For more information on our products, please visit wisense.in.



Ref: https://thingspeak.com/

Wireless Temperature Tag

Albert (our 3D printing expert) is designing enclosures for our wireless temperature sensor tags. We have gone through a few 3D printed versions already.  The enclosure material is ABS.

These tags are suitable for sensing temperature indoors (warehouses, cold chains etc). You can see the sensing element (a thermistor) sticking out of the tags. These tags are powered by two coin cells  (3V CR2032) which can last more  than three years assuming 1 transmission every 5 minutes.  The tags have an internal PCB antenna but also have a  U.Fl connector for an external whip antenna.

The tags operate in the 865-867 MHz license free band in India.




Please visit wisense.in for more information on our products.

Wireless Temperature Sensor for Cold Storage



We are currently testing our smallest form factor wireless temperature sensor node.

Dimensions: 50 mm x 50 mm x 10 mm.

Antenna options

  • External whip antenna
  • Internal PCB antenna

The temperature is sensed by a thermistor with 1% tolerance.  Thermistor is visible outside the enclosure

Powered by a single CR2032 coin cell battery with 220 mAh capacity and 3V nominal voltage.

Transmit power of +12 dBm

Operates in the 865-867 MHz license free India band.  Operating at this frequency has the following advantages:

  • This band is mostly free throughout India so very low possibility of interference.
  • 3 times higher range compared to 2.4 GHz (assuming same link budget)
  • Greater penetration through obstacles such as walls etc

The sensor node is  configured to operate as a reduced function device which means that the node is sleeping in low power mode most of the time, only waking up to sense and transmit temperature data if absolutely required. Sleep mode power consumption is less than 2 micro-amps.

Sensor node can send data to a WiSense LPWMN coordinator node (WSN1120CL) directly or indirectly through one or more WiSense LPWMN routers/FFDs (WSN1120L).

Each message from sensor node also reports the battery voltage.

Sensor node can be configured to –

  • Report temperature data at fixed intervals where the reporting interval can be dynamically adjusted from every 1 second to once every day.
  • Report temperature data when temperature drops below or rises above configurable threshold values.
  • Report temperature data only if temperature changes by a configurable percentage or absolute value in deg C.
  • Any combination of the above.
  • Report battery voltage and temperature data if battery voltage falls below configurable threshold.


For more information, please visit wisense.in.