Solutions by Industry

Product Engineer (Electrical)

Purpose: Develop network software for deployment in large-scale distributed
systems

Raveon Technologies is an expanding organization, focused on the wireless industrial and machine-to-machine (M2M) communication markets.

Raveon is growing its engineering team to support the expansion of a contract to build the nation’s first nationwide data network tailor-made for M2M communication.

Position Responsibilities

  1. Electrical Design of Baseband and Digital Systems. Drive development from simple concept to a feature-rich finished product. Suggest additions to product requirements, then design and implement from block diagram to PCB bring-up, debug and optimization.
  2. Mechanical Concept Design and Implementation. Develop product packaging concepts and manage product packaging development. Highly-qualified candidates will develop mechanical designs for simpler products and work closely with mechanical engineers to create rugged, reliable products.
  3. Prototype Bring-up and Debug. Follow product design with hands-on bring-up and detail-oriented test and optimization of design. Highly-qualified candidates will write firmware for straightforward products and will work alongside Raveon’s embedded software engineers when need dictates.
  4. Transfer to Manufacturing. Design with the appropriate production quantity in mind, tailoring process to suit both small concept products and large overseas production runs. Design and create documentation to support test and transfer to manufacturing. Train production personnel as needed and periodically receive feedback on improvements to speed manufacturing.
  5. System Design. Suggest the use of Raveon products in larger systems. Detail how specific existing or adjacent possible designs can be used in innovative ways.
  6. Ongoing Design Support. Continue engagement with all Raveon designs through improvements based on field testing and customer feedback.

Skillset
Digital Circuit Design, Power Supply Design, Baseband Audio Circuit Design, Schematic Capture, Design for Manufacturing, Manufacturing Documentation, Project Management

Beneficial Skills
Layout, Embedded C, Mechanical CAD, Waterproof and Mil-Spec product design, Sub-GHz RF design

 

If this opportunity is of interest to you, please send an introduction and your resume to our dedicated recruitment e-mail.

Networking Systems Software Engineer

Purpose: Develop network software for deployment in large-scale distributed
systems

Raveon Technologies is an expanding organization, focused on the wireless industrial and machine-to-machine (M2M) communication markets.

Raveon is growing its engineering team to support the expansion of a contract to build the nation’s first nationwide data network tailor-made for M2M communication.

Position Responsibilities

  1. Server Software Development. Design, develop and debug software to drive large scale wireless networks and interconnection of cellularized data networks. Create reliable, long-running communication platforms and interfaces. Develop distributed algorithms for intelligent routing of customer data while maintaining integrity and secure compartmentalization of data.
  2. Protocol Design Support. Suggest improvements to custom networking protocols and low-layer designs. Create simulations and test implementations of protocol designs and implement final protocol design in portable libraries.
  3. OS Configuration and Embedded System Design. Create software that will run on purpose-built hardware. Design installation procedures and OS images to support continuous software operation and error recovery without operator intervention.
  4. Transfer to Operations. Ensure software can be operated and debugged by multiple levels of users. Create software with reliable logging capabilities, command-line interfaces, web GUIs and developer APIs. Train operations personnel on software operation.
  5. System Design. Suggest the use of Raveon products in larger systems. Detail how specific existing or adjacent possible designs can be used in innovative ways.
  6. Ongoing Design Support. Continue engagement with all Raveon designs through improvements based on field testing and customer feedback.

 

Skillset
C++, C, Linux, TCP/IP System Design, Operating System Theory, Distributed System Design, Network Security

Beneficial Skills
Embedded C, Wireless Network Design, Communication Theory, Digital Electronics

 

If this opportunity is of interest to you, please send an introduction and your resume to our dedicated recruitment e-mail.

DART Dynamic Automatic Radio Transmission overview

image

1 Overview

DART (for Dynamic Automatic Radio Transceiver) is Raveon Technologies Corporation’s wide-area wireless networking technology. Unlike most all other radio trunking systems, DART is optimized for data,  M2M, telemetry, GPS tracking, and meter reading instead of two-way land-mobile voice. The DART trunking system builds on many of Raveon’s existing, proven technologies to create a new class of user devices and base stations.

DART is a combination of wireless protocols and technologies that together can make a very versatile wide-area radio network on narrow-band data radio channels.  It is designed to be the ideal M2M platform.

2. Wireless Device Classes

DART is provisioned to communicate to a number of different “Wireless Device (WD)Classes”.  The protocol interacts differently with the different classes, allowing manufacturers to provide devices that are optimized for various applications.  Most wireless protocols are optimized for a particular voice application, but DART accommodates many different use cases, optimized for data communications and GPS tracking.

A list of the initial Wireless Device (WD) classes a DART system supports is shown below.

Data Modem: (Very interactive communications with the base station) Used for one- and two-way data communications, M2M, SCADA, radio telemetry, text messaging, and remote control.  Communications to/from WD is via the base station and other WDs.

GPS Transponder: (Timed information reporting with light base station interaction) Used for GPS tracking of vehicles and personal locators. Tracking information and alerts are available to the end user either via connection to DART distribution network, or directly received over-the-air.

Meter Reading and SCADA: (Very infrequent interaction with base station) Used for communications to/from low-power radio modems that infrequently communicate with the system.

 

DART Feature Wireless Device Class
  Data Modem GPS Tracker Meter Reading /SCADA
Dynamic Configuration of groups, frequencies, power management, report rate, and authorization. Yes Yes Yes
Dynamic Data Bandwidth Yes
Roaming and Base Hand-Off Yes Yes
Autonomous Reporting Yes Yes
Bandwidth Priority by Net, Group Yes
Reporting Rate Priority by Net, Group Yes
Local communication without base Yes Yes Yes
Group, Net, and ID data broadcasts

Yes

Yes Yes
Group, Net, and ID Range Mass-Poll Yes Yes
Small-slot compression using slot assignments by ID and delta position reporting 

Yes

3. DART M2M Platform Features

1. Quickly deploy new radios into complex systems
2. Configures radio modems dynamically, based upon current system needs and settings.

a. Over-the-air channel/frequency assignments
b. Data transmission bandwidth allocation
c. Reporting rate
d. Priority levels and group membership
e. Base Station to associate with
f. Uses local IDs (LIDs) to communicate with WD’s, shortening the OTA packet size.
g. Many other parameters based on radio model and user needs
h. Delivers data packets reliably over the wireless network, fragmenting, retransmitting, and reconstructing them as needed.

3. Assigns channel bandwidth dynamically to devices needing to communicate
a. Retry interval and duration is managed by local base station based on loading and QOS
b.  WDs automatically find the a local base station to link-up to when they power on.

4. Balance the data communication loads based upon device priorities, system configuration and minimum QOS.
5. Utilize additional RF channels when available and as needed. Assign channels dynamically.
6. Timed configuration assignments for remote and out-of-comms continuous operation.
7. It has the capability of handling voice traffic, particularly VOIP sourced voice.
8. Very flexible ID scheme allowing for up to 4 trillion nodes.
9. End users can to assign their own IDs to their own nodes and configure message routing and deliver based on device ID, the ID they assigned, or groups the WD is a member of.
10. WDs may be assigned to groups.  Single messages may be sent to groups of WDs.  Messages may be routed to/from groups.

4. System Overview

A DART wireless network can support millions of Wireless Devices (WDs) such as radio modems and GPS trackers.  Using one to hundreds or base stations, each with one to dozens of RF channels, a DART network can span a city or a country.

DART Network

DART Network

WD:  A Wireless Device used for SCADA, meter reading, telemetry, GPS tracking, …
BSC: Base Station Controller that controls one more more transceivers at one or more base sites.
Master Gateway.  A Linux base data router that handles routing data, deviced authentication, security, and logging.

The  first generation of WDs Raveon has incorporated DART technology into is the M8 series of OEM data radio modems:  http://www.raveon.com/RV-M8S.html 

DART is a trademark of Raveon Technologies Corporation.  Contact Raveon Technologies Corporation for more information.

 

220MHZ Band Antennas

VHF and UHF antennas are easy to find, but 220MHz band antennas for data radio modem are more difficult to find.  This Tech Blog article provides links and ideas for sourcing 220MHz mobile antennas and 220MHz base station antennas.

1.   Overview

Raveon produces data radio modems at 200 MHz for Machine-to-machine (M2M) and SCADA applications.  Commercial off-the-shelf (COTS) antennas for this band can tuned to 220MHz.  This note details the process for the tuning of VHF 220 MHz antenna.  Raveon’s DART base stations and M8/TK8/TK9 series data radio modem products are available in this band.

2.   COTS Antennas

There are many different choices for 220MHz band antennas . This article identifies a few antennas suitable for use with 220 MHz radio modems.

New-Tronics Antenna Corporation

RX-220, 3.4 dB, 5/8 wave magnet-mount mobile antenna:
(http://www.new-tronics.com/main/html/mobile_uhf___vhf.html)

MX-270, 2.4dB VHF/ 4 dB UHF   magnet-mount VHF – must be cut down to resonate at 220MHz.
(http://www.new-tronics.com/main/html/mobile_mx_series_uhf___vhf.html)

Comet

HT-224, 1.3dBi 1/4 wave
(http://www.cometantenna.com/products.php?CatID=1&famID=1&childID=2)

This antenna may be available at their distributor, Ham Radio Outlet.

22ANT

Trimming an Antenna

The test equipment for tuning includes a spectrum analyzer, such as HP 8591E with tracking generator and a directional coupler, such as Narda 3000-10 and suitable connectors/adaptors. The antenna length can be adjusted by trimming the length of the rod of the antennas. Loosen the lock-screw on the base of the antenna, remove the antenna rod, and trim it so that the antenna resonates on the desired frequency. Trim a little, re-install, re-measure resonant frequency, and repeat.

The lowest standing wave ratio point displayed on the spectrum analyzer will be the frequency the antenna is tuned to.

For 220MHz, the lengths of the antennas shown above are 706 mm for the RX-220 and 524 mm for the MX-270.  The HT-224 from Comet has fixed length which is not adjustable.

sa221

Bit Error Rate Testing

With the introduction of RadioManager 5.8, RadioManager can be used to test bit-error and packet error performance of a radio link.

Bit-Error-Rate (BER) is not directly measured because RadioManager uses packets to test the link, but BER can be derived from packet-error-rate.

Raveon calls these types of tests “BERT” for Bit Error Rate Test.

To activate the BERT feature:

  1. Connect RadioManger to the radio you wish to test
  2. From the View -> BERT menu select BERT.
  3. Select the data pattern to send.
  4. Set the Interval to the number of milliseconds between packet transmissions.
  5. Click the START button, and RadioManager will begin sending the test packets to the device connected to the communication channel.

The BERT screen is show below.

BERT Screen

BERT Screen

You may select from a number of stock messages, for create your own by typing text into the second window from the top. Normally, RadioManager will put a packet sequence number at the beginning of every packet it sends, but this may be suppressed by unchecking the Add Sequence Number check box.

When running, RadioManager will automatically send a packet at the interval specified in the “Interval” box.

On the bottom of the BERT window are the communication statistics.  BERT counts how many packets it sends, and how many it receives.  It it sends more than it receives, it calculates the loss percentage and displays that.

To do a simple end-to-end link test, connect RadioManager to one radio, and on the other far-end radio modem, plug in a “loop-back dongle”.  For radio modem systems with DB9 serial ports, the loop-back dongle should connect pins 2 and 3 of the DB9 causing every byte that comes in the mode, to pass back to the transmit buffer and be re-send back over the air.

Below is a picture of a DB9 connection plugged into a Raveon M7 data radio modem.  Pins 2 and 3 are shorted together to do the BERT test.

Loop Back Connection

Loop Back Connection

 

Configure the two radios in the BERT test to communicate with each other:

  1. Same frequency
  2. Same IDs or set the ATMK netmask to 0000 to ignore the IDs
  3. Over-the-air data rate on both modems must be the same.
  4. Over-the-air protocol on both modems must be the same.

 

 

 

Testing M7 Data Radio Modem

This article describes how to do a functional test of the Raveon M7 data radio modem.  The M7 is a UHF or VHF radio modem, and using Raveon’s free RadioManger software M7 data radio modems can be quickly tested/validated ensuring they are communicating well. The tests described in this article will be useful for:

  1. Capturing the configuration / settings of the radio modem to a file.
  2. Verifying the radio modem is transmitting the correct RF power output level.
  3. The frequency of the radio modem is correctly set.
  4. The serial port parameters are correct
  5. The over-the-air baud rate is correct and compatible with the system the modem will be used in.
  6. Verifying and recording the DC power consumption
  7. Determining the packet-error-rate on the bench or in the field.

A quick functional test is HIGHLY recommended on every radio modem before it is deployed in the field.  These same functional tests can also be used to bench-test a radio modem that is suspected to be damaged or operating improperly. A lot of time can be saved by catching human errors, configuration problems, and component failures before the unit is deployed in the field.  Below is a diagram of how to connect two radio modems to perform the test.  Radio A is the radio to test, but this setup will validate that both radio A and B are communicating well.

M7TestSetupA

 

Radio Modem Test Configuration

Remember: Out of the box all Raveon data radio modems just work.  Connect power, serial ports, antennas, and they will communicate. Raveon tests 100% of all radios shipped to our customer for full functionality, plus verifies communication reliability.  Raveon also provides a customization service for customers who would like their radio modems custom-configured. When you receive modems from Raveon, you know they work together, and if you setup this test, you will quickly verify this.  It is good practice to start with this verification, then make any modification to the configuration of the radio modem’s parameters that you need to, and then re-do the test to verify that your new configuration works as expected.

Step 1 – Setup the Test Equipment

Begin by installing RadioManger onto a computer that has an RS232 serial port.  If the computer does not have an RS232 serial port, then use a USB serial bridge to convert a USB port to serial.

Connect the radios to test as show above in the Radio Modem Test Configuration diagram. The RF attenuators are typically 40dB pads. They avoid transmitting large amounts of RF power on the air. For this test, the radios are placed on the same test bench. Antennas should be connected to the attenuators, or directly connect the two attenuators together with a coax cable.

“Radio A” is the radio modem device under test (DUT).  The DUT is the unit that will be tested, recorded, and verified that it is operating properly.

“Radio B” in the test above should be a known good working radio modem, properly configured to the specifications of the system.

Step 2 – Configure the Device Under Test (DUT)

The M7 data radio modem has a lot of user-configurable parameters.  All commands and parameters are documented in the product’s Technical Manual available <here>. The most common parameters that will be configured on a radio modem are:

A. Frequency  (ATFX, ATFR, ATFT )
B. ID  (ATMY)
C. Serial port baud rate (ATBD)
D. RF power level  (ATPO)
E. Over-the-air baud rate  (ATR2)
F. Destination ID  (TOID)
G. Address mask  (ATMK)

Refer to the technical manual for information on how to set configure these parameters, and any others you wish to configure.

Step 3 – Record the Settings

There are two easy ways you can record the DUT’s configuration to a file.  1) Have RadioManager read them, and store them in the .xdat format.  2)display them using the config command, and copy/paste the displayed configuration to a text file.

Using RadioManager:

  • Turn the DC power supply on.
  • Start RadioManager
  • Select the serial port on RadioManager that the DUT is connected to. Set RadioManager’s serial port settings to match the DUT’s serial port settings.
  • Click the “Discover Radio” button.
  • Once RadioManger has discovered and connected to the DUT, click “Read Settings from Radio”
  • Once the settings have been read into RadioManager, click File > Save Settings  and store them to the .xdat file.

At a later time, you can recall these stetting, and load them back into the radio or into another radio.

Storing the Configuration into a Text File:

  • Turn the DC power supply on.
  • Start RadioManager (or any terminal program such as Terraterm or Hyperterminal)
  • Select the serial port on RadioManager that the DUT is connected to. Set RadioManager’s serial port settings to match the DUT’s serial port settings.
  • Click the “Discover Radio” button.
  • Once RadioManger has discovered and connected to the DUT, click on the terminal window in the lower right corner of RadioManager.
  • In the terminal window, type the phrase “CONFIG” without the quotes, and press enter.
  • The DUT will output all of its configuration settings, and they will appear in the terminal window.
  • Type ctrl A then ctrl C to copy them to the clipboard of the PC.
  • Open a text file using notepad, word, or some text editor, and paste the clipboard into the file.
  • Save the file

Step 4 – Electrical Tests

RF Power:

  • Turn the DC power supply on.
  • Start RadioManager
  • Click the “Discover Radio” button.
  • Once connected and communicating with the DUT, click on the terminal window in RadioManager
  • Type ATTD 3 to force the Radio A transmitter to key up sending random data.
  • Adjust the RF power to the desired level with the ATPO command.
  • Measure and record the RF power level.
  • Measure and record the DC current draw as seen on the amp-meter of the DC power supply.
  • Press the enter key to un-key the Radio A transmitter.

 

Character Echo:

Note, this test can only be done when Radio B is also configured to communicate with Radio B.  The RX and TX frequencies must be compatible.  The IDs and address masks must be set so that A and B can communicate.  On many systems, this is the normal configuration, but on some systems, radio modems only communicate one-way or with only one other radio modem.  Plan this test so that Radio B can communicate properly with Radio A.

  • Turn the DC power supply on.
  • Start RadioManager
  • Click the “Discover Radio” button.
  • Once connected and communicating with the DUT, click on the terminal window in RadioManager
  • Type any character on the keyboard.  Radio A’s STAT LED should blink red every time a character is typed, indicating the character is transmitted over-the-air.
  • Radio B’s STAT LED should blink green indicating it received the character.
  • Because of the loop-back wire on pins 2-3 of Radio B, Radio B will also transmit back the character to Radio A.
  • When Radio A receives the looped-back character, it will output out of its serial port and it will appear in the RadioManager terminal window.

 

Packet Error Rate:

Note, this test can only be done when Radio B is also configured to communicate with Radio B.  The RX and TX frequencies must be compatible.  The IDs and address masks must be set so that A and B can communicate.  On many systems, this is the normal configuration, but on some systems, radio modems only communicate one-way or with only one other radio modem.  Plan this test so that Radio B can communicate properly with Radio A.

On the bench, the packet error rate will be zero.  You may put Radio A on the real antenna to be used in the system, and Radio B at a remote site in the system, just to test the error rate to the remote site as the system will operate.

  • Turn the DC power supply on.
  • Start RadioManager
  • Click the “Discover Radio” button.
  • Once connected and communicating with the DUT, click on View > Expert to put RadioManger into the Expert mode.
  • Click View > BERT to bring up the packet error test window.
  • Set the interval to the desired test rate. 1000mS is typical for the short ABC test packet.
  • Set the test packet to use.
  • Click “Start”
  • Radio A’s stat LED will blink at the packet rate, each time it transmits.
  • The BERT window will count transmitted packets and received packets, and display the statistics.
  • Let the test run as long as you wish, record the results if desired.

 

 

 

Improving Streaming Mode Communication Range

For most applications, Raveon suggests operating the M7 VHF/UHF data radio modems in the “Packet Mode”.  In packet Mode, the radios verify the data is error-free using a 16-bit CRC.  They can be over-the-air Pinged.  The packets IDs and can be repeated.   But, in certain circumstances, such as when low-latency is required between transmit data and receive data, the streaming mode in the M7 data radios can be enabled.

In streaming mode, there are many configuration options that will affect the performance of the system.  Following is a list of some things to consider when using Streaming Mode in the radio modem.

  1. In streaming mode, the M7 data radio modems will very often output an extra few byte of random data noise at the end of a packet. The weaker the signal, the more likely the extra noise bytes are appended.
  2. On a polled radio system, consider the time-out-delays carefully. To account for serial port delay, T/R turn around, and a few noise bytes you may want to add a little extra to the time-out.
  3. As always, use the best antennas possible, and get them as high as practical. This may be a huge improvement to the link margin.
  4. Make sure all the antennas physically tuned to the right frequency.
  5. The DC power supplies must be electrically clean and able to supply enough power?  12V at32 amps is the minimum, we recommend 60 watt power cubes.
  6. To help measure link-margin, the ATRS command tells you the signal strength in dBm of the last packet received.
  7. To improve reception reliability with weak signals, configure the data radio modems to send longer pre-amble patterns.  If you have them send a 1-3 extra bytes of preamble, it will increase the reliability of the link, especially in the fringe areas.  ATR5 command sets the number of bytes of preamble transmitted before each transmission.  Normally they are set to 5 bytes, and you could try 7 or 8 and see if it helps.
  8. Some systems will work better if the Carrier Detect signal is used in streaming mode.  If ATRF is set to 1, then the modem will only try to decode over-the-air messages if the RF signal strength is above a fixed level set by ATCD.  When you have good link-margin (strong signals) this works great, and will allow a streaming mode radio to pick-up 100/100 messages.
    But… if the signal is weak, or below the carrier detect threshold, then it makes the modem miss data that it could have decoded because the modem is capable of demodulating data over-the—air on very weak signals.

RadioManager 5.8.1 Released

RadioManager 5.8.1 is now available for download! If you’ve installed RadioManager before, you already have all the dependencies and you can simply download the executable file and run it. If you are trying it for the first time, download the installer now!

New Features 5.8.1 (January 2014)

Bit Error Rate Testing

Added Bit Error Rate Testing (BERT).  By sending test packets, one can extrapolate the effective bit error rate.  This test
is actually a packet error rate test, but it can be used to measure BERT.
To activate the BERT feature:

  1. Connect RadioManger to the radio you wish to test
  2. From the View -> BERT menu select BERT.
  3. Select the data pattern to send.
  4. Set the Interval to the number of milliseconds between packet transmissions.
  5. Click the START button, and RadioManager will begin sending the test packets to the device connected to the communication channel.

Version 5.8.1 added support for the M8S radio modem module as well as the M8T and M8R versions of it.

New Features 5.6.1 (October 2013)

RadioManager 5.4.1 is now available for download! If you’ve installed RadioManager before, you already have all the dependencies and you can simply download the executable file and run it. If you are trying it for the first time, download the installer now!

Handshaking Line Status and Control

You can now easily see the status of the input handshaking lines and directly set the value of the output lines.

RadioManager allows direct visualization and control of RS-232 handshaking lines

Send Files

It’s now possible to transmit a text file to the radio by dragging the file on to the terminal. Doing so will launch the new “Send File” dialog, which will remain open allowing repeated transmissions of the same file.

File transfer timing can be fine-tuned to support executing command scripts or data transmission tests.

RadioManager can send a file line-by-line with the ability to fine tune transfer timing.

Improved, Responsive Terminal

The terminal has been overhauled to operate smoothly and intuitively. Automatic scrolling works smoothly and is automatically disabled when text is selected. Upon typing or moving the cursor to the bottom of the screen, automatic scrolling will be re-enabled.

RadioManager's Terminal mode can be used as your everyday terminal.

Improved RS-485 Simplex Support

RS-485 simplex support has been improved. RadioManager now automatically detects simplex mode and adapts its radio interaction accordingly.

 

WMX Code Examples

This article describes various software coding techniques to implement the WMX protocol.

Binary Encoding the WMX Data Field

If you are useing WMX to send 8-bit binary data, then you must encode the data as described in the WMX protocol document.  If you are sending 7-bit ASCII data, or your data will never have the ASCII charactor 255, 3, or 4 in it, then you do not need to encode the data, and yo umay simply embed your data in the data field of the WMX packet.

Visual Basic Encoding Example

Function BinaryEncodeWMX(ByRef bdata() AsChar, ByRef ByteCount AsInteger) As Array

‘ WMX encodes the charactors 0x03 and 0x04 so they never appear in the data
Dim T(1000) AsChar
Dim Y AsInteger = 0
Dim X AsInteger
For X = 0 To ByteCount – 1
If bdata(X) = Chr(255) Or bdata(X) = Chr(3) Or bdata(X) = Chr(4) Or bdata(X) = Chr(13) Then
                T(Y) = Chr(255)
                Y = Y + 1
                T(Y) = Chr(255 – Asc(bdata(X)))
Else
                T(Y) = bdata(X)
EndIf
            Y = Y + 1
Next
BinaryEncodeWMX = T
ByteCount = Y
EndFunction
 

Binary Decoding the WMX Data Field

Visual Basic Bindary Decoding Example

‘ Get the data, converting back to binary. ETXpos points to the end of the data array, SOTpos points to the beginning.
‘ WMX is a string containing the binary encoded WMX bytes as embedded inside the WMX packet.
x = SOTpos + 1

Y  = 0
While x < (ETXpos – SOTpos)
                Ch1 = Mid(WMX, x, 1)
If Ch1 = 255 Then
                    x = x + 1
Ch1 = Mid(WMX, x, 1)
‘ decode the binary encoding
                    NewWMX.DataBytes(Y) = 255 – Ch1
Else
                    NewWMX.DataBytes(Y) = Ch1
EndIf
          x = x + 1
          Y = Y + 1
EndWhile
NewWMX.ByteCount = Y

 C Bindary Decoding Example

// ***************************************************************************
// Move the data from a WMX buffer over to the txbits
// Remove any binary encoding.
// User Sends Actual data over-the-air
// 0xFF 0x00 0xFF
// 0xFF 0xFC 0x03
// 0xFF 0xFB 0x04
// byte_count is the number of bytes in the WMX data portion of the WMX frame
// Return the numberof bytes to transmit over the air
// ****************************************************************************
int move_wmxbuff(char buf_num, int byte_count, int data_location){
int x = 0;
int ret_val = 0;
unsigned char c1;
unsigned char c2;
 
while ((x < byte_count) && ( x < MAX_PACKET) && ( x < WMX_BUFFER_SIZE)){
c1 = wmx_tx_framebuff[buf_num][data_location]; // get the byte
data_location++;
c2 = wmx_tx_framebuff[buf_num][data_location]; // get the next byte
if (c1 == WMX_BINARY_CODE){
 // We detected a binary flag, so decode it.
c1 = WMX_BINARY_CODE – c2; // decode it
// Move past the second byte
data_location++;
x++;
}
txbits[txbit_put] = c1; // move the byte to txbits
txbit_put++;
ret_val++;
x++;
}
return ret_val;
}

 

 

 

 

 

Optimize over-the-air bandwidth usage with WMX modem status

Raveon’s WMX protocol is the preferred way to communicate over-the-air in advanced or tightly-integrated configurations. As of version D4 of the protocol, it is now possible to closely monitor message queuing, transmission and acknowledgement. This allows bandwidth usage to be optimized for the communication application.

Bit 5 in the WMX control field indicates whether the modem should provide additional message information back to the sender. Setting this bit in a message sent to a modem will cause two messages sent back to the receiver:

  1. A message indicating whether the message was accepted and queued (“Q”) or was rejected due to a full buffer or other condition (“N”)
  2. A message indicating that the message has been transmitted (“T”), processed locally as a command (“L”) or was flushed from the buffer and not processed (“F”)

The messages will indicate the sequence number of the message whose status is being provided.

Number of bytes

Field Name

Data

1

Message Status

ASCII Character Indicating a Message Status. It will be one of:

‘Q’ – Message has been accepted and queued for transmission

‘N’ – Message was not accepted for transmission and has been dropped

‘T’ – Message was sent over-the-air and has been fully processed

‘L’ – Message was processed locally (commands to the local radio)

‘F’ – Message was queued but subsequently flushed and not transmitted

1

Status Separator (,)

1-3

Original Sequence Number

The sequence number of the original message (the message whose status is being provided). ASCII Decimal formatted.

1

Status Separator (,)

1-4

Message TOID

The destination address of the original message (the message whose status is being provided). ASCII Hex formatted.

This information provides insight into bandwidth usage that allows optimization for the particular communication scenario. For instance, an installation using TDMA will queue data to be sent until the modems transmission slot is available. If only a single message or a set amount of data should be queued, the application can wait for the “T”, “L” or “F” messages before providing another message to send over-the-air.

Acknowledgement messages received by the modem also generate special WMX packets. When an acknowledgement is received, a message with frame type 3 will be output from the modem. This message will indicate which sequence number was acknowledged by the remote radio. With a combination of the queue full (“N”), transmit (“T”) and acknowledgement messages, it is possible to send bulk data continuously over-the-air as well as re-transmit any data that is not acknowledged.

Example code for interfacing with our radios using WMX can be found in our public code repository.

For advice on your own system implementation from a Raveon engineer, contact us today.