In full disclosure I work at a company that builds WiFi Access Points, routers etc for enterprises and I just put a hotspot on a drone for fun
It is hard to imagine now, but Ethernet as we know it today (802.3) was not the obvious choice for wired performant connections in 1996, many competing technologies like ATM, Token Ring, RS485, 802.4 etc seemed like more reliable choices, but because Ethernet was fast and cheap (among other reasons) it won out - since then it is hard to imagine a new technology displacing it.
Like Ethernet, WiFi is in the process of subsuming all adjacent technologies (802.15.4, Bluetooth, etc) and for all connections beyond the WAN (which will likely be LTE) it has the ability to be lower power, have better range (within reason) and perform better. This is not because WiFi is necessarily better spec'd - in fact it is unnecessarily complicated - it is because the R&D dollars are focused on it rather than competing technologies. A modern 3x3:3 802.11n chip has massive DSP resource and with .11ac we are seeing double the compute inside the mac/baseband. In addition we are seeing huge improvements in frame detection, phased antenna arrays and RF front ends which has the consequence of increasing link budget (link budget is roughly analogous to signal strength).
Okay, so where am I going with this: as a community we should be looking to use WiFi to consolidate our communication paths with our drones rather than 900MHz telemetry, 2.4GHz remote, 5.8GHz analog. Only fully integrated products like the Parrot AR drone use WiFi and I think that is a mistake. Here are a few reasons why WiFi makes sense:
- We put a digital RX with -95 db sensitivity inches away from a video transmitter transmitting at 23 dBm (in my case, or if you go illegal 36dBm) - this desensitizes our RX significantly reducing link budget. While this is one example, putting a high power transmitter next to a high sensitivity receiver is a bad idea always and we do it 3 times on drones.
- We need to deal with varying ranges and qualities of TX/RX pairs, complicated antenna and ground station setups.
- Analog video is incredibly susceptible to multi-path, limiting quality and antenna types. Don't we all want HD?
- Wouldn't it be convenient to just have one communication path? with maybe a remote as a backup.
Because there are naysayers (correctly so) out there, I thought I would point out common arguments against WiFi:
- WiFi requires a much higher SNR than 802.15.4 - this is true, but the quality of receivers and transmitters along with techniques MRC overcomes much of this and gives you a link that has a much lower duty cycle making it less susceptible to interference and provides superior error checking. A distance of 2-4km is totally practical with WiFi assuming good radios and modest antennas (we do a lot further at my company without too much issue)
- Using WiFi requires IP - yup… but does anybody think this isn't inevitable for us?
- WiFi is unreliable - okay, this needs a 2 part answer - WiFi is actually extremely reliable… it offers very good error checking (CRC) and will do 9 retries before dropping a frame at which point the higher level protocol will also send retries. On the flip side, we are often used to the crappy WiFi found in an Acer laptop (not picking on Acer, just mentioning a random pc vendor) where the radio is placed poorly, the analog front end is poorly designed and the antennas are in odd positions - remove those limitations and buy a $20 card from a reputable manufacturer and you will find superior performance.
- WiFi is really hard to integrate, especially when you need connections beyond serial speeds - I actually dont have an argument here. Most WiFi cards today use a soft MAC which means that most of the radio runs in software - replicating that in Arduino is infeasible. This is why the Arduino Yun uses a linux and a SoC to deliver WiFi. The obvious fix would be to put Autopilot on a linux based platform like OpenWRT, Android or Raspberry Pi
I don't think that it is a question of whether WiFi will become prevalent on drones, it is only a question of when. In the meantime I am working on my WiFi drone, I have 4G and WiFi on mine, Telemetry and Video are the next pieces to get working. I will update as I progress.
Comments
@Bertold
Software Defined Radio
A comment had been made radios now are Software. I envisioned changing the frequency and leaving the 802.11x in place. An idea bred from my ignorance of the devices.
A transverter? I did not know of them - good to learn here. That is an idea. It complicates the system a little but, it sounds logical to implement. This would be a proof of concept ??? on which to converge the other processes for the UAV? Then a more specific solution could be inserted at a later date when all the nuances and problems are realized and solutions are suggested?
Band? From what you noted and what is currently used I am not sure? The lower 433MHz requires US license and I do not know if 868MHz is legal in the US. I was going to suggest the 1.2GHz but, it requires license in US and you note it is not legal in EU. Maybe just to get a system working do as you had suggested earlier and work with 5.8GHz and suffer the short comings. There is bound be a future solution. That seems to be how the new world works. Something can not be done today - Tomorrow it is common place.
The statement of a computer was based on Adam having written to use OpenWRT via Android on a Pi which is a computer with an OS running an application. And, I confess, I also was thinking of multiple applications running on an OS. You have put forth that multiple communication streams on radio can be managed by an FPGA with a transverter and a WiFi chip? We still would have to work on how to combine and use our flight control, telemetry and video. Yes? If, yes, then with my limited knowledge I thought threads or processes on a known OS which brings us back to Adam's proposed Application on an OS on a computer. Could we port the FC firmware environment to a beefed up mcu with an RTOS of some flavor and an external memory? A smaller computer again.... Oh, we would need a physical video connection with analog processing of the video stream to overlay on the radio? and handling capability?
I'll go back to reading earlier posts. Thanks for info, thoughts and discussion.....
Making a radio with the performance of a 3x3 802.11n MIMO system is extremely complex. It is a multi year effort at least and it will be obsolete when completed. If all you want is a different frequency it is likely much easier to put a transverter in front of the card. Or use a chipset with a separate frontend and baseband chip, then you can connect your own frontend working on whatever band you want.
Which band do you propose BTW? 433MHz en 868MHz do not have sufficient bandwidth (only a few hundred kHz that can be used). 1.2GHz is not legal in Europe, 2.4GHz is a little crowded and 5GHz has less than optimal propagation.
Why do you say that using wifi cards implies using a computer to fly? A SoC with PCI master and cpu (eg OpenRISC) can be made on a FPGA costing 20€. Off the shelf PCI SoCs are also available, but they often come in annoying very fine pitch BGA packages. Altera Cyclone IV FPGA's are available in TQFP, even for quite large devices. Or you can just use an off the shelf wifi access point instead of trying to build one. And then attach a transverter if you want a different band.
@Adam
Ok - I re-read your beginning. WiFi? Available, applicable, associative - YES. You suggest a computer flying. OK. Means New hardware, new software, and new systems. I now will suggest since it is Software Radio - We take all WiFi process and transition to a different frequency from the WiFi of Things. IP- YEAH! From Day one sometime in 1995 I've championed IP. The supreme De facto networking way. We not use the World of WiFi.
History
Ethernet was not fast and it was congesting. It also was not set for distances. There weren't effective mediums - That is why some were pushing for ATM, Token and others. It was also said to not scale because we had noisy sharing hubs at the time. Switching was developed along with massive fiber routers and these brought new life to Ethernet and IP. An additional side of history: In the 90's several companies put massive amounts of resources into global, national and regional Ethernet-IP systems and at least one of the companies had more than $10 Billion cash built into their Global IP network. These companies also were in a race for telephone on IP which our Global traffic or telephone services are today mostly transmitted via IP over fiber. Ethernet and IP were 'defacto'. I and many others did not want to learn, buy equipment, provision, or transition our networks to other topologies. That would have meant a rewrite and learning and much more. Thankfully, new companies built Gigabit Ethernet Switches and Routers and new Fiber Optic devices and the world of IP just scales. :-) Oh, the C company is the only network company worth working for. ;-) IMHO. Lol....
802.11 is both a specification for hardware (the physical layer) and software (the MAC). BTW: Modern radio's are almost entirely software, the signal is generated digitally by a high performance task specific DSP and unconverted to the desired frequency.
PPP is not part of TCP/IP, it is a datalink layer protocol that can carry IP packets (but it can carry other types of packets as well, or even plain data). The packets comming out of PPP still need to be transmit somehow. I don't see what is gained by using PPP (with some undisclosed lower layer) over 802.11.
A 1023 bit CDMA code is an option, but all codes must be orthogonal for CDMA to work, you can not just take random 1023 bit string and hope that it works (it will somewhat, but it will be far from optimal). You need a code with an autocorrelation that is ideally zero or negative at other offsets (it should have a single peak at offset=0). You want a cross correlation that is as low as possible. Gold codes are a good option, these can be generated using LFSRs. Gold codes are used in GPS. Note that if you use a code of 1023 chips you can send only 1 bit per 1023 chips. Your signal bandwidth is thus multiplied by 1023, aka spread spectrum.
But you still need active power control for it to work, and this requires central control we don't have. If central control is available (eg: one modem talking to several drones) the hadamard matrix scheme can be used to assign codes.
In practice the signal from a device using another code is not despread (so no coding gain is achieved) but it appears as white noise increasing the background noise level. A non coded wideband signal will also do the same. A strong transmitter nearby utilizing another code will increase the noise floor so much after the despreader that the signal from a far away transmitter utilizing the correct code will disappear. This is a problem for W-CDMA phone systems, as the range of a cell depends on the number of users within it, this makes network planning difficult.
PPP is part of TCP/IP not 802.11. Not same thing. One is software the other is hardware.
We should be able to worry about our UAV. Our WiFi will not be ON the Internet and will NOT require a service provider. I suggested we should NOT use WiFi because the 2.4GHz spectrum IS intended and being designed to be filled with JUNK. ---- Internet of Things ---- And the things I listed in my earlier posting. But, WiFi is here now and on the phones.
CDMA - Code Division Multiple Access. The UID codes I mentioned are and will be pre-programmed in IC devices and are 1,023 bits in length. Not likely to run short of numbers. The devices are built to allow many millions of them. Our use would be hundreds of thousands but, not in one spot.
For some good reading See: http://www.radio-electronics.com/info/rf-technology-design/cdma/cdm...
Here is a quote:
" The CDMA orthogonal spreading codes are one of the major elements within the whole CDMA system. The CDMA orthogonal spreading codes are combined with the data stream to be transmitted in such a way that the bandwidth required is increased and the benefits of the spread spectrum system can be gained.
The CDMA codes are specific to each channel / user so that the different users can gain access to the system and communicate as required."
I guess I'll re-read the op posting on the first page and start thinking simpler.
@ Adam Conway
I have used wifi for control of a (land based) vehicule. I had some problems with TCP congestion control, often the problem is not interference, but a dropout due to an obstruction of the path. The link is perfect when passed the obstruction, but the TCP transfer speed has been reduced and slowly rises again. Probably in a UAV this will be less of a problem unless you are really pushing the range.
TDMA seems like a world of pain - the world has standardized on csma/ca and csma/cd, choosing something else means choosing something proprietary or something out of date.
It is not obsolete. It is very good if you want to give deterministic bandwidth. Suppose you have two drones sending 1mbit/s video and they cannot receive each other, so the hidden node problem will cause CSMA/CA to fail (RTS/CTS in wifi can solve this, but gives extra overhead). Wifi has a mode called PCF that almost does this, but I have never seen equipment that supports it. Of course you typically configure the system with a few fixed timeslots for contention free access with a deterministic birate (eg the video and manual control) and then you make a large timeslot where CSMA/CA is used for non critical traffic.
I have worked with industrial control networks and TDMA wireless links are used all the time. You are right that they are often proprietary, but nothing prevents us from creating our own standard. There probably is no standard for communication between drones and groundstations. After all, MavLINK is also a standard developed specifically for drone use. I would keep the wifi physical layer though, as it are very good, cheap and easily accessible radios. Certainly the MIMO based ones. I have interfaced a mini-pci wifi card to a FPGA a long time ago (for some unrelated project) and that is relatively easy to get going. The specifications of the chipsets are often not open, but you can find them on chinese sites. The linux and BSD kernel drivers are also a valuable resource. USB wifi cards should be easier, but carrier grade usb cards seem to be difficult to find (do you know of any?). PCI-E is a nightmare. It requires expensive FPGA's with pci-e transceivers (often only delivered as BGA), if you have such an FPGA it is not that difficuly, routing the PCB is certainly easier for PCI-E than for PCI lol.
@Brian Stott
CDMA is a very bad option in an unmanaged environment. While the codes in almost orthogonal, the cross correlation is not zero. This requires dynamic power control. If a transmitter very near you is transmitting in a different code with the same power as a transmiter 2km away it will still jam you. W-CDMA spends over 10% of its bandwidth for a very tight power control loop. Contrary to a frequency or time based hopping system, this is continuous interference making the link impossible instead of degraded. Multipath effecs further degrade the orthogonality of the code. There also is a limit to the amound of codes you can create. They should have special mathematical properties preventing you from simply taking some random string of bits.
Furthermore, CDMA is just another method of spread spectrum (DSSS). It degrades more gracefully in the presence of interference, but not enough to justify the complexity. DSSS can also be used with short codes so provide some coding gain against narrowband interferers and resistance against short term fading. This DSSS signal can then be frequency hopped.
Wifi actually does this. 802.11b uses a barker code (which is pure DSSS), while the higher speed modes use OFDM with higher and higer modulation orders. Perhaps the best method would be to implement COFDM and then use adaptive bit loading to ignore bad channels. Wifi does not do this but it used a strong error correction code to reduce the impact of a bad channel. (OFDM without bitloading or coding is terrible, since the BER is dominated by the worst carrier). Implementing a radio system that does COFDM and MIMO is almost as difficult as making a Wifi card from scratch (I have made a compatible transmitter, that is the easy part and it was already quite a lot of work). There is some serious DSP code running on that chipset.
I don't understand why you want to use PPP. Is standard 802.11 nog good enough?
@Adam. I agree the WiFi shouldn't be that bad - yet. I am in Pittsburgh, PA and at midnight now there are 8 wireless networks including mine broadcasting in my locale. But, why shouldn't we plan for more congestion. I currently do not use my spread spectrum wireless phone because local WiFi kills it. I recently picked up a Crazyflie Quad and am finding it impossible to get a clear 2.4GHz channel where the Quad can fly without being dropped out of the air. So, I've a noisy environment and I've not even finished my Quad yet to see what issues with communications there will be. I am hoping with The Frsky system it will hop enough to hop through issues.
I understand your point about TCP. I've been staunch a TCP/IP supporter since 95 setting up nationwide Frame networks and then designing and configuring server farms in data centers. But, we just now overlooked another component which our open air communications will not have the luxury of ---- Much of IP networks is Switched on the hardware and also then encrypted in the air. Yet, our devices are just spreading noise within an increasingly congested environment. Now, my worry is just having lived through 14.4 modems, 128K Frame Relay and ISDN, 1Mbit T-lines interfacing on a networked hub at 10Mbit Ethernet. Yes, we had congestion, fears of growth and the unknown to scale. Taking that type of scenario as a history now if we just plan ahead --- no worries.
Yes - Ethernet hardware has had the csma/ca & cd for a number of years. That is a method of error detection, transmission negotiation, collision avoidance, retransmission and the like. A sort of process. Not quite like the multiple access protocols which carve up the available bandwidth for PPP. I recall this was heavy for Enterprise Switches, Routers and VPNs? It became more important as we began to implement VoIP. That was a mess and headache. The pre-dawn of hopes was for phone everywhere and video and more web graphics and java apps. I had to implement an early first of kind VoIP into a 50 person company across two remote offices. UGLY. Sorry, my information will be dated, obsolete and sometimes forgotten. Back to error corrections in communications - It takes up hardware overhead to process the noise. That is why heavily utilized and provisioned networks slow down. They are having to process, direct, negotiate, wait, signal, request, retransmit, cache, etc.... Noise.... Good thing many of us are not still on Hubs. Except me- I've got cable Internet and that still operates a hub like mess. I believe.
Oh, it matters not at what Layer transmits or retransmits occur --- it is all on band. In order to communicate from one machine to another they have to transmit and receive across a medium. WiFi - 2.4GHz in our case.
So, we have recognition that a transmitted packet is missing, then we request a retransmit and receive the repeated transmission. All used hardwire bandwidth or wireless RF bandwidth. I think it would be amazingly cool and efficient and smart if we are able to effectively plan, organize and use our resources. I know that our UAVs really do not need to become multi-core 32-64 bit multi-Megabyte computers. Do they?
- Adam - With 1AP per 100 Sqft doesn't give the important information of utilization/provisioning. This could be a very quiet environment. I know the contractors and they do not think or plan with much depth. I have planned networks for business too. A very important point to share is not only AP # but, how many wireless devices are using and for what purposes. If they sit there with just occasional db access, a several page print, an e-mail exchange then there is not much to be concerned with any bandwidth use, broadcast and continous interference. Now, if you guys are Active Traders in an exchange/brokerage or a gaming company or a video production firm then we would have some meat to chew on. Those guys really chew up bandwidth.
RTT? I cared about for connectivity testing using Ping and Traceroute but, we did not set. You could adjust your testing tools to filter. You monitor RTT from L4 tools which can indicate a broken network connection or congestion at a remote node but, ??? There is no start or stop with Round Trip Time for a communication. Did I miss something? Generally our networks were tight and we'd congestion at a coop network node then we contact the other network to see if they were aware of congestion at their particulate device or node. Video is in Internet muticast because it casts to multiple destinations. No care about ACK'd you either got it or not. The next frame is coming anyway. We should not even be doing multicast from/with our UAV. IF we design this correctly. Right now they are Broadcasting/Multi-Cast. For UAV - single PPP from Tx to Rx. Our Video will be just another data stream. Sorry, getting tired. I should go to bed. G'night.
I think you are overestimating the impact of interference in WiFi, unless you are flying in Manhattan the airtime consumption that will trigger the WiFi CCA will be lot duty cycle. Yes, there are lots of transmitters out there, but most don't trigger the CCA, and those that do are likely low duty cycle. TCP does better than you think on WiFi mostly because most of the retransmits happen at L2, it is really rare to see a retransmit at L3 (requires 9 retransmits at L2) so the biggest impact on TCP is RTT which will not initiate a slow start. For Video multicast can be used, as multicast frames are not ACK'd in WiFi.
I work in a building with 1AP per 100 Sqft (I work at a WiFi company) and I can get a usable video stream. TDMA seems like a world of pain - the world has standardized on csma/ca and csma/cd, choosing something else means choosing something proprietary or something out of date.
I agree with your assessment that our transmitters should just spew data. As I think you noted, this is why the high frequency of data manipulations can allow a UDP like communication. But, you surely agree that a periodic keep alive or acknowledgement be sent back. I guess this would be our RSSI and other telemetry giving us the assurances of amply reliable communications. Good discussion.
OK - MAC. :-) Back 15 - 20 years ago when in networking we generally discussed numbered layers. MAC was only hardware. OK, with us today --- MAC: media access control. Times change. Thank you. I understand now.
The 24GHz isn't mostly free if we Spread Spectrum broadcast across it. You begin to operate in an area with others it gets more poluted. Also, we need to remember that home and business WiFi is 2.4GHz. So are many car alarms, Blue Tooth, Zigbee, Microwave Ovens(Mine leaks), Security Cameras, Closed circuit TV, wireless TV and Stereos in the home, wireless web cameras, baby monitors, and wireless Telephones (Mine is and good to over 30 feet outside my home.). And did you know the 'Internet of Things' with Electric Imp has the goal of puttng toasters, toilets, coffee makers, refrigerators, heating and cooling systems, garage doors, etc on WiFi? We need to plan ahead.....
I see Spread Spectrum is inefficient because - My thin understanding is it is OK if you have a few participants in a single area. Their individual random spread spectrum frequency hopping has a lower probability of interferring for the entire time. Interference will be only intermittent and random. Kinda like a food fight with popcorn. Corn everywhere and few hitting others around us. But, as more join everyone gets hit and the place is a mess. For our future, as more UAV exist, we will fill the entire frequency space and it will become a band of high energy noise. This will be sooner without efficient use of the bandwidth available. The multiple access schema addresses congestion with management of space. TDMA creates time slots but there will be no master to referee or organize those slots. This will not be efficient. We don't necessarily want our devices spending too much time negotiating and cooperating with other devices. This is time consuming and fraught with another source of communications problems as you noted with TCP.
I think some of the UAV random mystery behavior and fly-aways are interference with the vehicles. Our communications and operations are fully open for exploit.
We know that UAVs are real and going to exist. Just as the Internet is real and will continue to exist. Yes? Then, it is better for usto think and development for 5, 10 and more years into UAV development. TDMA is OK for a phone company or network on a closed system with fixed routers being able to handle the management of Time slots for each communications stream. But, we are in the open FREE air.
Now, into Chaos and Random environments without central management. I do not want to suggest nor do I want to have a governing management for our vehicles. There will be enough demand of control soon enough over our devices without us now developing the systems for some greedy UAV Operation Service charging us to be allowed to have operation time on their network. We have to manage ourselves without interfering or affecting other operting vehicles. That is a good reason to have CDMA. I see, agreeably, our discussion sort of has dropped WDMA because I realize now WDMA also must be actively managed - As a Network Router is managed. Our environment will not be a preplanned managed environment but, an adhoc random association of UAV operations.
My argument for CDMA is that it is code based. Our hardware will carry UIDs (A unique code seed.) from component manufacturers. There is no input from us. This is Easy. We use our firmware which will contain a pre-conceived communications algorithm. Now, we can simply plug and play our hardware, upload our firmware, configure our vehicle and let GCS or firmware RF communications algorithm generate the globally unique code to allow us to fly anywhere on the planet without interfering with another vehicle. We, soon, incorporate and use the prevailing airspace alert system common to our country to communicate our locations and trajectory for collision avoidance and traffic control - we are done. Everyone will have their own unique VPN for their respective vehicle. Operate uninterfered, uninterferring and with minds to our purpose.
We can then grow the hardware and the communications just get better without having changes to the base radio systems. Just like we humans will still be communicating with known language and not having to completely reorient how we communicate with hands or feet. Yes? --
Our operating systems (OS) gets better, our peripherals change. Then, we will simply install a new application driver or service or client and we are off and running. MP already has that portion going with its great interface. Check some boxes, change some attributes and configurations and it goes out on the net to reconfigure the firmware if required. HEY---- It is almost here! If we manage to keep Windoze out of screwing into our UAV we don't have to contend with the constant crashing, interface needlessly changing and the hourly, daily etc bugged anti operational updates to keep us from operating.
On TDMA. I believe it is very good but, not in a random environment. Remember, it is Time slice based spectrum use. Time slots hae to be assigned and managed to be effective in a congested environment or managed luck if unmanaged. This means it is best suited for a controlled environment where each communications stream is managed and assigned. This is why uncontrolled environment operations have selected to use CDMA which is a code based method of communications. CDMA is not reliant on constant management. GPS is an example of a CDMA applicaton. They used predefined IDs and an algorithm to calculate a unique code for communications. With the inclusion of UID within ICs we can follow the example of the GPS and similar systems to have our UAV systems be relatively autonomous in any environment. Their communications stream will be unique. There would not be a need to frequency hop. But, there would conceivably be a need to have better radios for bandwidth control. Here I'm not familiar but, a guess based on the preent designers, manufacturers and low costs of our equipment.
Sorry if I repeat. This is fun....
You are talking about the MAC address, which indeed is the hardware address of the card. It is stored in (EEP)ROM. I was talking about the MAC as in Medium Access Control layer: http://en.wikipedia.org/wiki/Media_access_control
The MAC-layer handles data comming from higher protocols. It tells the device when to transmit and processes received packets. If you want to make WiFi more robuust for a specific use case this is what you must change.
TCP/IP absolutely DOES NOT SCALE well if you have dirty links with a lot of packet loss. The hosts will think the network is badly congested and resort to transmitting extremely slow. I think the drone protocol needs to be able to send datagrams with guaranteed delivery and datagrams without acknowledgements (for example control data, retransmitting it is useless as it will be outdated, simply transmit the new values). Above the guaranteed datagrams a layer could be made that reliably transmits a byte stream.
What is inefficient about spread spectrum? You use a larger amount of bandwidth, but the power per bandwidth is lower than a fixed carrier system. Therefore the spread spectrum system is less likely to cause interference (or to be interfered with). What is extremely wasteful are (high powered) analog video links.
I think a TDMA MAC is the way to go, as this allows assigning deterministic amounts of bandwidth to different platforms and services. Since all devices now have a synchronized clock (to do the TDMA) it is also easy to implement frequency hopping. Most wifi chipsets can do more than the standard 13 channels, you can directly program the fractional-N pll in them. Fast hopping is not possible, most chipsets do some elaborate calibration when changing channels (but it only takes 1ms or so).
Frequency hopping is very useful, as most of the 2.4GHz band is actually free. Most WiFi access points simply send beacons every 100ms. This gives annoying interference on video links, but is no problem for a digital transmitter. Sometimes a network is busier, giving more continuous interference, the frequency hopping makes the system robuust against this.
One final important point that needs to be changed is the association procedure, once the drone is armed and flying the system should just start transmitting. This helps in the case where a short dropout was present. The reconnection time goes from seconds to zero.
-
1
-
2
-
3
-
4
-
5
of 6 Next