I recently gave an interview through email to master’s student Julia Eichler, studying at the London College of Communication, on why I chose the Wifly module for the Arduino Wifly Mini, what other communication methods I would like to try, and advice for anyone starting a similar RF communications project. I have posted this here, with Ms. Eichler’s permission, in case anyone else finds this information useful.
Why did you chose WiFi? I assumed you wanted to transmit everything (video, driving commands, FFB) over one channel, but because the WiFi BacPac has not been released, yet, you had to send the video data separately. Is that the reason or did you have another motive?
That’s right. Video data is sent separately since, as you say, the WiFi BacPac hadn’t been released, and now that it is, live streaming still appears not to be available. (The GoPro website says “coming soon.”) The frequency at which WiFi operates, as you know, can handle a lot of bandwidth, and so being able to send everything over one channel would have been very convenient. There was a second big motive: I started the project with the hope I would be able to control the car through a cellular data network like 3G or LTE. Since iPhone and Android phones can create WiFi hotspots, my idea was to connect the Wifly module and the WiFi BacPac to one in-vehicle 3G/LTE device. Initial testing with my 3G iPhone was disappointing. I could connect the Wifly to the iPhone hotspot and could, via 3G, send packets from the Wifly to my home computer, but not the other way around. Performance was very slow, so a live video transmission would likely be too lagged to be usable in a land-based vehicle (an aircraft might be another matter). However, this isn’t the end of the road for cellular networks. I will eventually get my hands on an Android LTE device and give it another try. One concern I have is interference between the Wifly module and the WiFi BacPac. But here we have yet another of 2.4GHz benefits: you can select a different channel and greatly reduce interference by a shift of only a few MHz. I remain hopeful.
You said if you developed it further you would want to use another technology to transmit the data. Which one would that be most likely? Or did you actually enhance the project? Which approach did you use? XBee (802.15.4), OpenLRS or even LTE? I would suppose XBee Series 1 would be a suitable solution since the range of the video transmitter you used would limit the range to approximately 2 km anyway (Is that correct?). This, however would only increase the range as far as the video transmitter can reach. Is that sufficient for your intentions?
As I said above I would love to give LTE a try, especially when the WiFi BacPac becomes capable of live streaming. Regarding other technologies: I’ve tried OpenLRS and ImmersionRC, and even though I have not yet tested the full range of these systems, my first experiments with them showed out-of-the-box range is much further than the Wifly. When using one of these LRS systems, I’m able to maintain control of the vehicle beyond usable video range. With its antenna raised approximately two feet from the ground, the in-vehicle 1.3GHz, 300mW video transmitter provides approximately 800 metres of clear picture. In this circumstance, on the video receiver I was using a dipole antenna, but if we switched it for a directional antenna mounted on a tracking apparatus, we would probably improve the range considerably; I suspect your estimate of 2 kilometres is a good ballpark of the upper-limit of such a configuration. If we wanted to go further we would need to increase the output power of the video transmitter in the vehicle – something I’m planning on trying. As for XBee: It happens that I only became aware of XBee’s capabilities after I had invested in LRS equipment. Actually, it seems Xbee – particularly the 900MHz variety – are capable of considerable distances. I have seen long range flights with RC planes approaching the 30 kilometre mark! The only reason I probably won’t be fiddling with Xbee in the near future is because I already have OpenLRS and ImmersionRC equipment to experiment with. Regarding my intentions: This short-range stuff is only the testing and prototyping phase. I’d love to drive or fly a machine right across Canada. Or around the world. Perhaps it would have to be solar powered. Anyway, I have ideas for such a vehicle kicking about, all of them would have to be manifested over the long-term, and unfortunately nothing is set in stone. Who knows what other ideas will crop up?
If you haven’t already answered that in question 2: Do you still fancy the mobile phone idea, to control the Mini via a 4G phone?
Absolutely. :) (see above).
Was it difficult for you to find the appropriate wireless transmission technology? If so, why?
It wasn’t difficult. I was fortunate enough that when I started the project, Arduino had already been around for quite some time and companies like Sparkfun were supplying shields like the Wifly module. This was the progression of events: I needed a method to communicate with the Arduino (which would control the vehicle), and I wanted it to be very long range. My first thoughts were 3G and LTE. I have an iPhone. This might not still be the case, but six months ago connecting an iPhone physically to an Arduino was not particularly easy and would require an Apple developer membership if I was to do it effectively. And I wanted something more flexible, something that could be picked up easily by the Maker community – at that time I didn’t know that’s what it was called – something a person could use with her Android if she wanted, or by me when I eventually got my hands on an Android LTE device, with much less fiddling to make it work. I understand WiFi to be more robust than Bluetooth. Both the iPhone and Android can make WiFi hotspots. Ergo, WiFi appeared to be the best choice.
What would you advise someone who wants to start an RF communication project?
Think through what it is you want to accomplish and select the system that will do what you need. Do your research, make the most logical choice, and you’ll be fine. If you’re using more than one RF system, be wary of the potential for interference. I had a heck of a time containing the noise from my video transmitter (the WiFi couldn’t hear the router when the video transmitter was on). So I needed to implement a filter in-line with the antenna and ferrite rings around the video transmitter’s power cables. Actually, thinking through where I struggled with my project, a couple things have just occurred to me that might be quite helpful in terms of estimating the amount of time and effort needed to bring your idea to life. First, don’t assume the path to what you want to do will be nicely paved. I didn’t really expect my project to be a cakewalk, but I did assume that UDP packet transmission between the Wifly module and Processing would be a given. Consider that the Arduino Ethernet shield features a fairly robust library to go along with it, UDP and all. For the Wifly, this simply isn’t so. As far as I could tell, only one or two people had managed to successfully send UDP packets from their Wifly devices, and no one had clearly laid out how to do it. Your communication technology might face similar challenges, so if you can muster the initiative I’d recommend during the planning phase being diligent in this regard. Secondly, if your RF project is like mine in that it will depend on your devices recognizing a set of characters symbolizing various commands and information, consider how exactly this is going to work. If my vehicle experiences a 2G force in the front accelerometer, and sends a packet whose payload contains “X1Y1Z2″ (intended to mean, G forces over axes X, Y, Z of 1, 1 and 2 respectively), how does your receiving device know how to differentiate between them? As far as I know C doesn’t have anything like an XML parser! You’re going to need code that will separate the components of the packet. It will need to recognize the X, the Y, and the Z, and the values that follow. Once they’re separated, you need a function that’ll interpret the data. How do you handle values that have decimals? Consider that values transmitted that are often with fractions won’t always be; do you still want to take up the bandwidth by sending 2.0, or will you incorporate a step in your interpreter function that won’t get confused when there’s no decimal? Does this kind of bandwidth saving even matter to your project? And now consider that your other device might operate in a considerably different language, and you’re probably going to need similar functions so it can understand commands, too. I find it easy to overlook details like this, but they consume a substantive amount of time.
Thank you very much!
You’re welcome!
Update: Having just now read through this interview again to prepare it for posting, I see I made a statement about not trying out Xbee. Well, I should have foreseen that another project has cropped up and I’ve just ordered some Xbee modules. All 2.4Ghz. I’m excited to give them a try. I might try using them for telemetry and Force-Feedback information for a larger version of the Arduino Wifly Mini (an Arduino Truck).
