Do the 3DR radios support having more than two modules communicating together? Specifically the simplest possible case of having two (2) units listening on the ground, only one (1) in the air and only one of the ground modules actually sending data TO the air unit. The idea is to integrate one in a Turnigy transmitter to display vital stats so one could fly with some telemetry even without a full ground station with you.
not really, no.
As a hack you could make it work by setting the DUTY_CYCLE to zero on one of the ground units and also setting NUM_CHANNELS=1. That would do what you want, but many countries require that you use frequency hopping above a certain power level, so it may not be an option.
The current TDM system is really not meant for more than 2 radios. We could add support for this, but I doubt I'll get to it soon. Feel free to start hacking on the code though! The hardware can definately do it, we'd just need some software support for dividing up time into more than two sets of slices.
The frequency hopping is only pseudorandom anyway, based on the network ID as a seed; as long as it hops along, accepting information from the air bot not sending anything to disturb the actual telemetry link between the air unit and the other ground station, it ought to be able to listen, right? It would probably need some modification that makes it "mute" when used along with a ground station - but only in that case, since when used as the only ground unit the link forming itself would not happen if the air unit can't pair up with it. Or did I misunderstand something?
The problem with 3 radios with DUTY_CYCLE=0 on one and NUM_CHANNELS>1 is that the silent radio will also see packets from the other ground radio. Those packets will be on the right frequency as you say, but they will be tagged with a bit that tells the receiving radio to go 180 degrees out of phase for recv/transmit cycle to the other radio.
The TDM timing will tend to get confused by this, as it will keep hitting 'impossible' situations and trying to adjust the timing to cope. I think it may end up hopping channels at the wrong time.
That's why I suggested setting NUM_CHANNELS=1. It will still get confused, but it won't matter :-)
If you want to watch the TDM code working, setup the above scenario and run "AT&T=TDM". That will enable TDM debugging.
PS: I haven't actually run this test, I've just been trying to think how the code would behave. It wasn't a setup I was planning for in the code :-)
Great, thanks for the explanation. So, the mute groundstation would have to be hacked to ignore packets from the talking groundstation and only listen to the air unit. Or maybe take both into consideration somehow to always keep listening. Tricky. There isn't any identifying information on the physical layer either (about which node is the other ground station and which one is the air unit).
The normal solution to this problem would be to add a STATION_ID parameter, and a NUM_STATIONS parameter. Then it would divide up the TDM round into that number of station segments. We'd have the basis for mesh networking.
It would lose some efficiency though, as there would be more overhead bytes to send stations IDs etc. I didn't do this in the original design as I didn't think mesh networking would be a high priority for APM users.
One reason I'm a bit reluctant to add it now is that it would be an incompatible change, and would require quite a lot of testing. I think I'll concentrate on point to point for now, but I'd certainly be interested in looking over code changes if someone else wanted to add in this sort of code. I suspect its probably a 200 line patch to add this sort of functionality, if someone spends the time to work out the protocol details.
The timing could get interesting. The TDM code is constantly correcting the timing between the two radios. With N radios you could get some very strange interactions on timing if you didn't design it carefully.
Of course, this assumes you want all N radios to be able to transmit and receive. Your scenario with only 2 radios transmitting is much simpler, but still needs a bit of work to achieve reliably.
Yeah, I decided my approach was unnecessarily complicated for the actual needs for now. It is best to keep the focus on point-to-point. Even now nothing prevents me or anyone from adding a ground station into the RC Tx as long as I don't use it concurrently with a proper ground station receiver! Even if there's a need to switch over one way or the other in the field, it's just a matter of powering down one and starting up the other. The link should re-establish itself in short order, as long as the configuration was the same on both, correct? Mesh networking is beyond the scope of what practically all of us use telemetry for, so I don't see a real demand for it. Maybe when we start flying swarms of drones we can revisit this topic... ;)
Thanks for your time, and once again thank you for your work on the 3DR radios!
How about one ground station radio unit feeding two ground station 'data sinks'?
A passive (preferably buffered) split of the received serial data line will 'just work' in the way you mention - plug the Input/Output line into the full-featured ground station, and the Output-only line into your transmitter for 'handheld' telemetry.
- It would actually make a lot of sense to have the radio "base" physically attached to the normal RC Tx with the serial I/O line running back to the ground station as you're more likely to have RC Tx without ground station than the other way around.
I guess what is best depends on the individual needs. I would like to have some vital statistics available on the radio controller even with no other equipment available on the field. If you add a "proper" ground station to the mix, one might as well also lift up its antennas to the top of a mast or a pole, which would then call for a tranceiver of its own up there. Whichever you use more yourself depends on your needs, thus also the way to combine the use cases differs from user to user.
I also need point to multi-point. I want the mission planner AND my er9x TX to display the mavlink data like the Xbee's I use now ! I really want the 433mhz because our balloon will be 20 miles strait (almost) up. We Will be using yagi antennas on the ground to track the signal.
Launch is Saturday 4/14/12 so I hope the radios will be here by then. Otherwise we are using the 60mw 2.4ghz Xbee's. And 24db grid antennas on the ground. The primary tracking is on 148-150mhz satellite radio modems. (I know, overkill and we have to time the launch for the sats !)
The group is quite excited. An APM2 will be on board with a 720 HD camera with 16Gb memory card. I hope the APM2 will measure attitude with the barometer as well as the GPS (which may crap out at 18000 meters).
Mission planner on ground on laptop with internet access.
I hope to have an ATV live video TX on board also for live video. (I am N8TV) Channel 59 cable - 439.25mhz.
I will post more after flight.
P.S. This is in Edgewood NM at 9 am if you are near.
Same as Earl.
N-way comms in firmware still isn't planned ? Does anyone have put his hands in yet ?
Since standalone groundstations are available now, many people will want to use (or not) their laptop in addition to the regular groundstation without modifying anything in the setup.
I also have various ideas that would be greatly aided by the ability to have a full mesh mavlink network for drones/GSC's. Below are a few reasons why a full mesh would be helpful.
- Multiple ground stations for control from different geo points that would be geographically possible (LOS) other wise. (Failsafe for hardware redundancy while geo diverse for signal path redundancy).
- Drone to Drone to GSC to GCS
- GSC to GSC to drone to drone
- Drone to mobile drone ground unit to GCS
- Allows (multiple) GCS's to send control signals to different drones with a single transmitter (coordinates flying with multiple GCS's.)
Some possible features desired:
- Full Mesh topology to ensure as long as 1 drone can communicate with the GCS and all other all drones can receive GSC signals. (Firmware?)
- All drones/GCS's act as repeater nodes on network to extent network range.
- Any device combination up to 65534 (Drones GSC's) (255 is small and should be raised now to eliminate bottleneck seen in the future.) (Down side: more packet header space taken, maybe 1024 as a "smaller" big step?) (Mavlink + Firmware?)
- GSC command time(order) stamping to ensure commands are processed in the order given (IE if a command comes late it is ignored (or a small command que is created to allow slighly out of order commands to be reordered and executed.) (Mavlink + Firmware?)
- Allow use of parallel radio units on drones for redundancy/path diversity. (Firmware + Hardware?)
- Allow extended range control of drones via mesh network. (Ie. Daisy chained links for greater over all coverage of poor los areas) (Firmware?)
Improvements to Mavlink:
- Fields to allow drones to share collision detection information
- Fields to share intended path vector (Vector drone will move at to avoid obstacles detected)
- Ensure drones can also send Mavlink commands to other drones. (Everyone is a GSC?)
Related Improvements for APM Planner:
- Control/tracking of up to the max # of drones Mavlink allows for.
I've been looking into this and have had some success with a Rx-only radio, i.e. match NetID and set Duty Cycle to zero. See this this DIY drones thread. Multiple 3DR 915Mhz radios - one for primary ground station and oth...
My spare radio was right in front of me so I just gave this a go!
Good news - it appears to work!
I've got a the quad powered on next to me, with the Rx/Tx unit on my Android connected with DroidPlanner. The RxOnly unit (Duty Cycle set to Zero, all other config matches) is connected to my PC running Mission Planner. Telemetery is streaming through to both PC and phone :)
Only 2 things I've noticed from (Rx-Only) Mission Planner:
Now I just need to go fly it!