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
Replies
@Seppo,
Where can I find the original firmware (not binary) for RFD868x and RFD900x versions?
Product link: http://store.rfdesign.com.au/rfd-868x-modem/
In the above link, this statement sounds misleading: "The software solution is an open source development called "SiK". It has been re implemented to suit the new processor architecture available on the 32bit ARM processor core. A boot loader and interface is available for further development and field upgrade of the modem firmware via the serial port."
1) Does this mean the source as seen on RFDesign SiK firmware is no longer applicable and source code for RFD868/900x is closed source? We see no relation to firmware used in the github and ARM chip. Also, given that the last commit is also 1 year old. I would like to have a look at the 'latest' firmware from which the binaries in firmware bin have been produced (as its stated to be open source); although I understand hardware is closed source.
2) We have checked out the firmware and it supports Si1020 chip for encryption (based on 8051). But it is mentioned you use 32-bit ARM processor. Could I have some clarification on this part on what is used in terms of architecture?
Look forward to your answers.
Thanks,
Shyam
Hi Kent,
Power setting was default with the new firmware, yet to relaunch model outdoors with the tracker. Let me chew through that wonderful new info and will report back in with results. Thank you so much for your time.
Cheers!
Rico,
Try setting serial break detect (ats6) to 2.
You power is set to 10, assuming your outside this should be higher.
Also you are using global addressing. You really should be routing through node 2.
How are you relaying the data though node 2?
You need a micro there or some other method to relay the data through.
For one way comms you can loop tx and rx on relay node, but addressing will only go one direction
You will need both directions for mavlink data.
i.e. node 1 dest node 1> node2=2
node 2 dest = 3 (result is 1->2->3 but not 3->2->1)
It can also use the new SAS packet encapsulation to direct packets through a relay node to the desired destination, but this requires a micro at each end to direct through a dumb relay node.
We have been working or packet forwarding but as yet that feature has not been fully tested and there are some problems with it.
Other than that you can have a micro at the relay node to direct traffic to the right location.
i.e. set relay node encap rx and tx to SAS. The micro will see packets and the source address, and then be able to send SAS packets back to serial port with the correct destination. The end nodes can then be dumb and both have node 2 as destination.
Rico said:
Thank you Kent,
It's good to hear that 2 RFD modem can work in the same drone. No, for sure I'm not using for PPM control, only for telemetry and other data transmission.
Kent,
Not sure how much you realize how happy I am to hear from you...
This is a fairly new setup so open to any configuration changes (and education) you suggest. The intention was to use the antenna tracker as the relaying hub as it has yagi antennas on it, so would that be two way for the AAT modem and one way for the aircraft and mission planner station? NodeID's 1,2 & 3. As far as latency times are concerned, it was possible to manually fly the aircraft on the mission planner HUD before, now it seems to take an eternity to update. I do have slip rings to install into the AAT but am trying to minimize the amount going through there to power and the least amount I can get away with. No PPM yet, still using the trusty EZuhf with a rapid find manual mode switch. You're probably going to laugh at the settings.
2017-09-07.png
Rico,
Great it's working. To know what latency to expect I need to know your configuration.
There are a number of parameters that affect it.
The serial protocol format you are using, I expect it is mavlink.
I can't recall how it decides when to send packet with mavlink, I'll have to check.
Also the addressing. Global will typically take longer.
There is a roughly 10mS delay due to preamble for each packet. This varies with air rate.
Also depends if you are sending data back the opposite direction as it will randomly retry if data is coming back the other way.
What times are you requiring?
For lowest latency use one direction only, and use addressed data.
Are you running PPM as well?
Thanks
G'day Kent, appreciate your time.
I gratefully received V2.45 of the Async firmware and we now have comms with Mission Planner (small workshop dance). Just a couple of things before I can use it - I need to learn how to get rid of the latency and I can't switch between modems on mission planner with the Control-X shortcut. I have one modem in the laptop, one in the antenna tracker and one in the aircraft.
Cheers!
Hi Minh,
Yes , and Yes. That is to say you can set the network id differently on each set.
This will give them a different hopping sequence, they will not pick up the other radios data, but occasional collisions will occur and cause some loss.In theory it should work reasonably ok. But be careful if you are using PPM control on one radio set, loss here will effect controls so tread carefully if doing this and test it isn't too bad for flight. I'm talking about SiK code, assuming that is what you are using?
Another option is to separate the band in half and run each on completely different spectral range.
This would mean 1/2 the number of channels as well, so this would not be compliant for regulatory spectral requirements.
Minh Tran Quang said:
Hi Rico,
Sorry to hear problems with async, Can you tell us what exactly happened with mission planner?
Sometimes MP or copter needs to be updated. This has happened on a number of releases with MP.
Can you get MP to work with Sik Code using the same MP and copter as async test?
If there are problems we would like to get them fixed.
As far as multipoint goes, tridge did do a version on it, but it's usefulness is limited so it was not brought forward with a view of Async replacing it. I'm not sure if tridge made that branch public.
Time is better spent on Async (for us anyway) due to limitations and problems with mutlipoint.
Rico said:
Hi Seppo,
Can I use 2 RFD modems on the same drone (of course, on different channels). May they interfere each other?
-
4
-
5
-
6
-
7
-
8
of 65 Next