Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 1 of 1

Thread: Speeds using $4 FM/FSK data radios at high rates with Teensy3 and AVR

  1. #1
    Senior Member
    Join Date
    Jun 2013
    So. Calif

    Speeds using $4 FM/FSK data radios at high rates with Teensy3 and AVR

    EDIT: Attachments hosed up by forum software.

    Often, radio modules (not chips) in the $4 class are on-off-keying and one-way.
    Ones like these
    are in a higher class.
    Bi-directional, up to 100mW (good), FM/FSK, programmable speeds/bandwidth, etc. Packetization, CRC16 error checks, optional AES128 encryption.
    Sub-GHz for longer range than, say, 2.4GHz. And no WiFi interference. (Frequency band choice is country-specific).

    Often these are used at speeds of 2-10Kbps for things like cable-replacement for HVAC systems and remote controls.

    Here are recent higher speed test results (using my DXRP throughput test software- PingPong).
    Using protocol stack: RadioHead, with reliable datagram protocols (ACK per packet, retransmissions for error correction done within the stack).
    Setup two radios for unusually high, 250Kbps.

    Enclosed is a screen grab from the test. Click to zoom size.
    Column headings' meaning (column names are right-aligned above column of numbers)

    • Secs - Elapsed time of test, seconds
    • RSSI - received signal strength in dBm at the reporting node
    • R_OK - Packets received error-free
    • R_err - Packets dropped due to too many retransmission attempts
    • T_OK - Packets transmitted and ACK received (packets are sequence-numbered to detect lost/duplicate)
    • T_err - Packets lost due to too many retransmissions and no ACK
    • reTX - Packets retransmitted for error correction
    • % - Percent of transmitted packets needing retransmission (correctable packet errors)
    • IDerr - Packet sequence number error - out of sequence. Value of 1 is OK - due to startup condition
    • Tbyte - Bytes transmitted so far
    • Rbyte - Bytes received so far
    • PPS - Packets sent + received, per second -Excluding ACK packets
    • TR_bps - bits per second of net throughbout, two-way. User data only. Excludes ACKs, preambles, header, CRC

    These higher speeds need an RSSI of -50 or better for a low packet error rate.
    Note the reTX rate is less than 1% - due to the high SNR of the benchtop test.
    I have other tests and low SNR, where RSSI is -80 or poorer, and the bit rates have to be reduced greatly.

    Tests were done with the PingPong software having set the packet sizes to 60 bytes one way and 10 bytes the other way- rather typical of many systems.
    This is a ping-pong test; all transmitted packets get an ACK then a data packet. Then the cycle repeats.

    For the 250Kbps raw bit rate, the 52.5Kbps of net throughput was seen.
    If the unreliable datagram (no ACKs) were used, this would increase.

    At the high bit rate and channel width, with 60 byte packets one way and 10 bytes the other way, the rate is about 200 packets/second and ~56Kbps net user data rate (sum of directions).

    the next step down, 125Kbps, throughput was about 40Kbps and a relaxation of the required RSSI by a few dB.

    click to enlarge
    Click image for larger version. 

Name:	Grab1.jpg 
Views:	277 
Size:	126.7 KB 
ID:	2718

    Here's a run at a much lower bit rate, lower RSSI (radio/antenna and micro running on battery and placed inside a steel coffee can/lid to attenuate signal.

    click to enlarge
    Click image for larger version. 

Name:	Grab2.jpg 
Views:	266 
Size:	77.2 KB 
ID:	2714

    The RSSI in the radio-in-can is about 60dB lower. That can correspond to attenuation in the path between the two radios- due to distance and/or obstructions of various types.
    At the radio's frequency, 64dB is the line-of-sight path loss for 300 ft. At 600 ft. this goes to about 66 dB. And so on, thanks to the inverse square law in RF. (At 2.4GHz, the losses are far greater).
    Below is a screen grab from the serial monitor window, from the PingPong software's Sniffer mode.

    In these tests, a teensy 3.1 was used as the sniffer it can keep up with the high packets per second rate, capture data and ACK packets, format to text, and display via the USB/UART to a serial terminal monitor. The 16MHz AVR cannot keep up.

    Here's a screen grab from the sniffer output during a high packet rate test.
    Column heading meanings:
    • mSec - delta time since last received packet (by the sniffer), including ACK packets. Note for this test, the packet arrival rate is high - more than 1,000 per second.
    • RSSI - Signal strength at the sniffer
    • From - Source (sending) node's address
    • To - Destination node's address (255 is a broadcast)
    • ACK - Highlights ACK packets whose payload length is 1 and the ACK flag is present in the header.
    • Len - Byte count of payload (user) data. In this test, one node was sending 60 bytes/packet and the other, 4 bytes.
    • ID - the packet sequence number. Used to match ACKs and detected duplicate and lost packets.
    • flags - packet header flag bits. Leftmost 4 are used in the protocol stack. Rightmost 4 are used by DXRP to define the destination "port" number - to segregate data traffic without user data flags.
    • Msg - the content of the payload, if printable ASCII. If not, "." is displayed.

    click to enlarge
    Click image for larger version. 

Name:	grab3.jpg 
Views:	223 
Size:	80.3 KB 
ID:	2715

    To see timing "for real", the sniffer software toggles 3 pins on the microprocessor (AVR or Teensy):
    • packet received
    • packet sent
    • scope sync - this is a 1uSec pulse for data packet received. Does not pulse for ACKs received.

    Here's a 'scope screen grab of the received data/ACKs (top) and sync pins (bottom).
    1 mSec / division. Since the packet sizes each way differ greatly in this test configuration, the 'scope timing for messages and ACKs alternates.
    Lots of packets per second!

    Click image for larger version. 

Name:	grab4.jpg 
Views:	179 
Size:	62.3 KB 
ID:	2716

    The PingPong test software accepts user commands from the serial terminal. These permit on-the-fly changing of the bit rates/modulation orders, deviation, packet size, delay between packets (if any), zero the statistics, reboot, etc. Adjusting theses enables one to simulate packet sizes, rates, and packet transmission delays for an application's behavior.

    For one-node-unattended: Commands entered on one node are sent over the air to the other node so it will reconfigure to match. The passive sniffer overhears these and reconfigures to match.
    If no packets are exchanged for 30 seconds, the nodes revert to the last-saved defaults, e.g., a low bit rate.
    These command allow one to put one node out of reach in an RF can, or place it far distant and remotely control it, and recover from using bit rates too high for the RSSI conditions - then step down rate and repeat.

    The test data was sent on DXRP port 0. Commands are sent on port 1 without affecting the format of port 0 data. This is how DXRP can be used, for its 16 ports.

    So, this is showing interesting results at low cost FSK radios at rather wide channels.
    Last edited by stevech; 09-24-2014 at 12:04 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts