RFD900, RFD900+ - New long range radio modem

Hi All,

I would like to introduce you to a new radio modem that we developed for very long range datalinks!

http://rfdesign.com.au/RFD900.php

Some of the key features of the RFD900 are as follows:

  • Multi point and point to point link capability.
  • Long range >40km depending on antennas and GCS setup.
  • 2 x RP-SMA RF connectors, diversity switched.
  • 1 Watt (+30dBm) transmit power.
  • Transmit low pass filter.
  • > 20dB Low noise amplifier.
  • RX SAW filter.
  • Passive front end band pass filter.
  • Open source firmware / tools, field upgradeable, easy to configure.
  • Small (30 x 57 x 13 mm), light weight (14.5g).
  • Compatible with 3DR / Hope-RF radio modules.
  • License free use in Australia, Canada, USA, NZ.

 

These modems are designed to support long range applications, while being easy to use and affordable.  

These modems have been flying in various platforms and have demonstrated excellent performance in real applications. 

RFD900 modems are now available at: http://store.rfdesign.com.au

Support within APM planner and the radio configurator from Michael Oborne is already available.

It works seamlessly with APM planner, all radio Mavlink parameters are available.

Update, December 2014:  The RFD900+ with improved specifications is available now at:

http://store.rfdesign.com.au/rfd-900p-modem/

Seppo Saario

rfdesign.com.au

 

Views: 111015

Reply to This

Replies to This Discussion

Hey everyone,

I have two RFD900+ radios that I'm trying to connect to each other. The problem is, one of them is stuck in bootloader mode and neither of them will connect to my PC. I've tried using both the drivers that Windows wants to use as well as the drivers from rfdesign's site. In the RFtools I can see the right COM port that the radio is plugged into but when I try to connect to the radio it says that the radio 'Failed to enter command mode.' I'm running Windows 10 64 bit, build 17134.

Anyone have any suggestions? Thanks in advance. 

Andrew,

I've had problems getting some of the tools to work as well.

I've been able to use the Settings window.

I get the same error as you when attempting to use the Terminal window.

And I can't ever seem to get the RSSI window going.

But, as far as basic function goes, everything in the radio seems OK. The key was using another terminal program to communicate with the radio. I have "Terminal v1.9b" by Br@y++. I'm not sure it's the best, but I was able to connect with the ground RFD900+ and capture my failsafe settings with the correct AT command.

The radios seemed very picky about connection state. If you connected with Mission planner first, I couldn't get anything else (settings window or terminal program) working. If I got one of those going first, I couldn't get a Mavlink connection w/o power cycling.

I used a genuine ftdi driver and windows 10 for the above.

I'm now setting things up using a Raspberry PI for the telemetry stream. It connects reliably. And it's very persistent (I can power cycle the ground radio and the PI, let them reboot (~20 seconds), and the Mission Planner connection picks back up with no intervention on my part). Only thing that's bugging me at the moment is that the failsafe PPM setting has mysteriously vanished. So I'll be connecting terminal again before I fly.

You said it starts in bootloader mode?  Make sure that you don't have any serial data being transmitted to the radio while it's powered on.  This can confuse it.  If you can't get it out of bootloader, I think I've managed to load the firmware onto it again to get it reset.

I have now tried connecting to the radios using a PC running Windows 7 (without success), so I don't think that the drivers from Windows 10 are to blame. Like the other PC, neither the Windows drivers nor the latest drivers from the FTDI site are letting me connect. I can see the COM port but can't read/write or upload any firmware to it.

The part that really puzzles me is that one of the radios blinks green just fine, but still won't connect to the PC.

Is it worth going through RFD's outdated drivers and hoping for luck?

I never loaded an RFD900 driver.

In reality, the drivers are for the FTDI, not the radio. Many of the cloned FTDI cables apparently do not work. Are you using a legit FTDI cable with a 3.3 v interface? Do you have something else with a serial interface that you can connect to? Can you connect directly to the Pixhawk with that cable?

RR

An update with some information I would have found useful. I won't state these as entirely definitive, but they may prove helpful to other folks:

  1. Firmware needs to be updated on each radio without an operating link.
  2. I'm guessing that the Modem Tools only work if the link is quiet (or if another terminal program stops any chatter, I could issue the +++ attention with Brays terminal and then move over to the settings tab of the modem tools). Or, better yet, disconnecting the PixHawk side and working with that end avoids the chatter entirely.
  3. Make sure you are using the peer-to-peer manual if you are per-to-peer. The AT command set is different.
  4. The configuration needs to be saved to make the PPM stream recording persistent.
  5. If the airborne radio power cycles and the ground radio is not communicating or if the ground setup is not sending a PPM stream when the airborne radio recovers power, there is no PPM output (in other words, it's not sending the proper failsafe to the flight controller). You must have a PPM stream started (requires the TX radio to send to the ground modem and the ground modem to send to the air modem) before you get ANY PPM output. Once the PPM output is established, the air modem will send the failsafe PPM stream if it's no longer receiving a PPM stream (e.g., TX radio trainer cord unplugged from modem, ground modem powered down).
  6. The GPIO pins can be configured to follow the other end. If the link drops, the GPIO pin will hold the last setting it got from the other side.

RR

I would also like to make a request for a RFD900x peer-to-peer firmware change. An easy one. :-)

I'd like to be able to associate one of the GPIO pins with "link state" (high=link connected, low=link lost or vice versa).

I know this data is readily available. It's exactly the same information that's conveyed by the blinking or solid green LED, but it would be more usable if it:

  1. Came out to a pin (adding a wire to the surface mount LED looks to be beyond my soldering ability)
  2. Was a solid "off" indicator, rather than a flasher (when the link was lost).

The benefit of this option: The signal can be used to help select between a primary and backup radio PPM stream. If the RFD900x doesn't have a connected link, there's no reason not to use the backup radio's PPM stream. If the RFD900x does have a link, I'd logically AND that (externally) with a mirrored GPIO pin output signal to enable ground selection of the PPM stream via a toggle switch.

The GPIO pins alone are not sufficient for this function, since the GPIO outputs remain in their last state during link loss. Thus if you have the RFD900x PPM stream selected and lose the link (say the ground-station battery powering the RFD900x dies), you can't switch back to the other PPM stream.

I'd be more than willing to do the beta testing for this feature!

RR

Roger,

This is available. Parameter GPO1_3STATLED will allow gpio1.3 to act as status led (ATS19, in latest version, check your version ATI5? to see where it is)

which shows when link is active. low when link is active. ie. pull a LED down to ground to show link is active,

or flashing as per LED on radio.

Feature is available from V2.61.

Kent


Roger Ronald said:

I would also like to make a request for a RFD900x peer-to-peer firmware change. An easy one. :-)

I'd like to be able to associate one of the GPIO pins with "link state" (high=link connected, low=link lost or vice versa).

I know this data is readily available. It's exactly the same information that's conveyed by the blinking or solid green LED, but it would be more usable if it:

  1. Came out to a pin (adding a wire to the surface mount LED looks to be beyond my soldering ability)
  2. Was a solid "off" indicator, rather than a flasher (when the link was lost).

The benefit of this option: The signal can be used to help select between a primary and backup radio PPM stream. If the RFD900x doesn't have a connected link, there's no reason not to use the backup radio's PPM stream. If the RFD900x does have a link, I'd logically AND that (externally) with a mirrored GPIO pin output signal to enable ground selection of the PPM stream via a toggle switch.

The GPIO pins alone are not sufficient for this function, since the GPIO outputs remain in their last state during link loss. Thus if you have the RFD900x PPM stream selected and lose the link (say the ground-station battery powering the RFD900x dies), you can't switch back to the other PPM stream.

I'd be more than willing to do the beta testing for this feature!

RR

Kent,

This is excellent news. However.....

Where can I download 2.61? The web site (http://files.rfdesign.com.au/firmware/) has 2.55, 2.53, and 2.60 as point-to-point firmware downloads. No 2.61.

I'm running 2.60 and I get this from ATI5?:

ATI
RFD SiK 2.60 on RFD900xR1.1
ATI5?
S0:FORMAT(N)[0..255]=34
S1:SERIAL_SPEED(L)[1..460]=57{1200,2400,4800,9600,19200,38400,57600,115200,230400,460800,1000000,}
S2:AIR_SPEED(L)[4..750]=64{4,64,125,250,500,750,}
S3:NETID(N)[0..255]=27
S4:TXPOWER(N)[0..30]=30
S5:ECC(B)[0..1]=0{Off,On,}
S6:MAVLINK(B)[0..1]=1{Off,On,}
S7:OPPRESEND(B)[0..1]=0{Off,On,}
S8:MIN_FREQ(N)[902000..928000]=915000
S9:MAX_FREQ(N)[902000..928000]=928000
S10:NUM_CHANNELS(N)[1..50]=20
S11:DUTY_CYCLE(N)[1..100]=100
S12:LBT_RSSI(N)[0..255]=0
S13:RTSCTS(B)[0..1]=0{Off,On,}
S14:MAX_WINDOW(N)[20..400]=20
S15:ENCRYPTION_LEVEL(L)[0..1]=0{None,128b,}
S16:GPI1_1R/CIN(B)[0..1]=0{Off,On,}
S17:GPO1_1R/COUT(B)[0..1]=1{Off,On,}
S18:ANT_MODE(N)[0..3]=0{Ant1&2,Ant1,Ant2,Ant1=TX;2=RX,}
S19:PKT_DROP_RSSI(N)[0..255]=0

Roger,

I sent a friend request.

Please send me your email, and I'll send it to you.

Thanks,

Kent

Roger Ronald said:

Kent,

This is excellent news. However.....

Where can I download 2.61? The web site (http://files.rfdesign.com.au/firmware/) has 2.55, 2.53, and 2.60 as point-to-point firmware downloads. No 2.61.

I'm running 2.60 and I get this from ATI5?:

ATI
RFD SiK 2.60 on RFD900xR1.1
ATI5?
S0:FORMAT(N)[0..255]=34
S1:SERIAL_SPEED(L)[1..460]=57{1200,2400,4800,9600,19200,38400,57600,115200,230400,460800,1000000,}
S2:AIR_SPEED(L)[4..750]=64{4,64,125,250,500,750,}
S3:NETID(N)[0..255]=27
S4:TXPOWER(N)[0..30]=30
S5:ECC(B)[0..1]=0{Off,On,}
S6:MAVLINK(B)[0..1]=1{Off,On,}
S7:OPPRESEND(B)[0..1]=0{Off,On,}
S8:MIN_FREQ(N)[902000..928000]=915000
S9:MAX_FREQ(N)[902000..928000]=928000
S10:NUM_CHANNELS(N)[1..50]=20
S11:DUTY_CYCLE(N)[1..100]=100
S12:LBT_RSSI(N)[0..255]=0
S13:RTSCTS(B)[0..1]=0{Off,On,}
S14:MAX_WINDOW(N)[20..400]=20
S15:ENCRYPTION_LEVEL(L)[0..1]=0{None,128b,}
S16:GPI1_1R/CIN(B)[0..1]=0{Off,On,}
S17:GPO1_1R/COUT(B)[0..1]=1{Off,On,}
S18:ANT_MODE(N)[0..3]=0{Ant1&2,Ant1,Ant2,Ant1=TX;2=RX,}
S19:PKT_DROP_RSSI(N)[0..255]=0

I have been using MP SiK 2.4 for some time now on a project with multiple sensor nodes on a mesh network.  Now I would like to conserve battery power by having the sensors go to sleep and periodically wake up, sniff the network for packets and either respond or go back to sleep.  The polling rate for sensors is 10Hz per sensor so the base node is sending polling frames at 10Hz x the number of sensors.  I thought a sensible time to stay awake and sniff for activity would be two polling periods (200ms) and then sleep for several seconds which should drop the average current into the uA range but I'm finding that the sensors never detect network activity in that amount of time even though I know it is there because I have an extra node connected to a terminal program and I can see the polling frames coming from the base node.  I looked through the datasheets for both the Si1000 and teh RFD900 but could not find a specification for time from power on reset till valid UART data.  I think this would be a function of both the MP Sik firmware design and hardware synchronization on the RF side but I couldn't find any information on this anywhere.  I tried detecting this time delay myself but it seems very random ranging from a few hundred milliseconds, to almost five seconds.  Can anybody on this forum shed some light on this question for me?

Joe

Thought I should update the thread on selecting between a primary and backup radio PPM stream.

I actually built the hardware to use the RFD900X's link status and another GPIO pin as switch inputs. However, link status is a 1 second square wave (so I needed a retriggerable one shot) and I ended up with 3 ICs. Plus, it didn't switch over if failsafe was caused by the transmitter on the ground or the cable to the ground radio.

So, I decided to go a different way. I used an Arduino Nano (and the Claymation PPM library) to inspect the PPM stream from the RFD900X. If the Nano doesn't detect PPM, detects failsafe on the throttle channel, or can't find a heartbeat (that I send from the transmitter) on channel 12, it directs a NOR gate to switch to an FRSky XSR receiver PPM stream.

This allows me to use the XSR (with 8 channels) directly from my FRSky transmitter. But, if I need more range (or want to also use channels 9-11), I can plug in my trainer cord from the GCS, throw a switch, and use the RFD900X PPM.

I still have a RC control path if either receiver fails and should retain a path even if the Nano fails (although it will be uncertain which radio the NOR gate will select in the absence of proper Nano behavior).

And the Nano + the NOR gate is smaller/weighs less than the 3 IC solution.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service