GETting The Most Out of SNMP

Published by Davicom on January 22 2018

GETting the most out of SNMP

As SNMP becomes more widespread across many industries, it is important to understand some of the subtleties of using it to interface with various pieces of equipment.

One of the important points to consider when using SNMP is the syntax of GET commands, and the ability of SNMP managers, appliances or hardware to make sense of the data returned by a GET command.

The results returned following a GET will always be made up of a binary code, but what this binary code represents is of key importance. The code could be defined as a number, a text, a string of bits representing switch positions, an IP address, a true or false or a whole set of other meanings, and the definition of what these bits represent is called the syntax.

The SNMP standard has defined a certain number of syntax types varying from integers to display strings all the way through IP addresses and counters. However, some rudimentary SNMP managers or devices can only accept basic syntax types like integers, counters or truth values, and this can leave users in a bind if the devices they need to monitor via SNMP provide their data in other formats. In these cases, the monitoring device will not be able to do anything useful with the data, it won’t have the capability of understanding the results. Something like Lost in Translation!

Davicom’s built-in SNMP manager understands many different syntax types. This ensures easier communications between monitored devices and monitoring units.

The table below shows the principal syntaxes supported by Davicom units:


Integers 32-bit signed integer (can be sent to a metering input, and may need to be multiplied or divided—see below)
Octet Strings Binary number that is similar to a display string, but not strictly ASCII
Display Strings ASCII or Unicode values
Object Identifiers Yes, an OID within an OID!
IP Addresses Plain IP address like
Physical Addresses MAC (physical-Ethernet) device address like ‎30-8D-99-6A-29-FD
Counters32-bit counter
GaugesValue that can be sent to a Metering input
Time TicksIndicates time since last power-up of device. Can be used to check if a device has powered-down since the last checkup. Similar to what is used in Linux systems
Bit StringsValue like 00001000, where a single bit indicates a condition.
Unsigned IntegersImportant distinction with the Integers shown in #1 above
64-bit countersSelf-evident
Truth Values1=true and 2=false (go figure—this is the SNMP standard!)


In addition to these standard syntax types, Davicom has added extra functionality to ensure its RTU’s can understand “special dialects”. One of these additional syntax types is the Float from String type. This syntax is not part of the SNMP standard, but it is extremely useful for taking readings from devices whose designers have used “poetic license” in their equipment.

Some equipment manufacturers code actual numerical readings in the “Display String” format. For example, one transmitter manufacturer codes the data returned to a GET request as the ASCII values for the readings. So for a 100W power, they return ASCII 1 followed by ASCII 0 and ASCII 0. This is fine if the final goal is just to display the returned value, but if we wish to have a machine monitor that value and check it continuously for out-of-bounds conditions, the process isn’t simple. If the value had been coded as a direct 32-bit integer, it would have been easily readable and useable by a machine.  This is exactly what the Davicom unit’s Float from String type does. It converts a string of ASCII characters into a floating-point number that is readily useable to check for out of bound conditions.

It is crucial to know what type of result will come out of your GET command, so that you can get the most out of SNMP.




Published by Davicom on April 30 2015

In North America, most consumer and professional electronic equipment must conform to FCC or Industry Canada standards. These standards govern the unintentional RF emission levels allowed from equipment and are useful as far as reducing the overall “RF background” noise present in our society. Without these standards, bad design and the race to the cheapest product would quickly make the electromagnetic spectrum unusable due to the generation of parasitic signals.


On the other hand, our modern lives are increasingly dependent on intentional RF emitters such as cell phones, Wi-Fi networks, microwave links, television and radio broadcast transmitters, public safety radios and mobile/fixed radios and repeaters. These intentional emitters legally produce RF signals (some at very high levels) in many frequency bands of the electromagnetic spectrum.


In our line of business, I’d say that electromagnetic immunity is more important than electromagnetic emissions since our monitoring equipment will often be used on remote sites with RF transmitters. Since there are no mandatory standards for immunity in North America, and since we do want to ensure our equipment will operate correctly in complex/hostile electromagnetic environments, our fall-back solution is to use the European CE Immunity standards that are part of the European EMC Directive.


These standards, which were developed in the mid to late 90’s have evolved over time with the addition/refinement of different product categories. The category under which we now test our Davicom Remote Monitoring and Control Units is Information Technology equipment and the levels of immunity for this category are defined in the EN 55024 standard.


The actual procedures for the tests are described in another set of standards. For example the Radiated RF immunity procedure is described in EN 61000-4-3. In these tests, a device under test (or DUT) is placed in a high-level RF field and monitored for any change in its behaviour. This field can be produced by an antenna in an anechoic chamber, or by a transmission line in a Transverse Electromagnetic Cell (or TEM Cell). Comlab uses a large TEM cell.


Electromagnetic immunity is concerned with much more than just radiated RF. Think of any time a spark jumps from your fingertip onto your computer’s keyboard (and your computer crashes!).  These sparks are known as electrostatic discharges (or ESD) and are also the subject of an EM immunity standard, in this case the test procedure is described in EN 61000-4-2. Tests are carried out with an ESD Gun that generates sparks of up to 15kV which are applied to the DUT while monitoring its behavior.


EM immunity extends into the wired aspect of electronic equipment also. By different inductive and capacitive principles, RF energy can be coupled into various conductors leading into and out of equipment. This RF energy can wreak havoc with circuit and software operation if it is not controlled, filtered and eliminated. The procedure for carrying out these tests for immunity to conducted RF energy is described in EN 61000-4-6. The tests are performed with a high-power RF signal generator and a clamp-on inductive loop to inject the RF energy into the cables of the DUT while monitoring its operation.


EM immunity even covers the field of utility power. Although you may have a tendency to take your utility power for granted, and assume that it is delivered to you as a nice clean 120V, 60 Hz (or 240 V, 50 Hz) sine wave, this is never the case. The utility power spectrum is a jungle of parasitic signals, harmonics, overloads, glitches, back EMF peaks and even lightning surges. This is another area where testing the immunity of equipment is important to ensure reliable operation.


If lightning hits the power utility pole feeding your site, you want your equipment to survive this back-door attack into your system. This is where the tests for surge voltages described in EN 61000-4-5 come in handy. These tests are performed with a special device that capacitively injects large surge voltages on the power cord while checking for proper behavior of the equipment.


If your power line is also feeding large motors, air conditioning compressors, and your high-power transmitter, you don’t want power glitches, such as your transmitter suddenly shutting down for protection, to crash your remote control system. The tests described in EN 61000-4-4 simulate these conditions.


When these standards first came out, they seemed very intimidating and difficult to satisfy. However, hard work, good design practices, practical RF experience and continuous testing in our EMC lab over the years have produced consistent results at satisfying and even surpassing these standards for all our products.