Software Defined TX using Arduino and Android?

[humblehacker]

This concept occurred to me in the midst of this discussion about flashing the Arduino Due with the same firmware as the 9xrPRO- viewtopic.php?f=84&t=7166

It has always seemed like a bitter irony that we in the RC community have managed to produce such incredibly sophisticated tools through open source development when it comes to flight controllers, ESCs, software etc... yet we still must rely on a confusing mess of incompatible proprietary protocols when it comes to one of the most critical tools in the form of the RC Transmitters. Talk of a truly "universal" TX has been with us since the beginning, but a practical alternative has only emerged somewhat recently. In this article entitled Creating an Open-Source Multiband RC Transmitter (http://www.eetimes.com/author.asp?secti ... id=1322957) the authors propose an approach based in a method that is rapidly gaining popularity in hacker circles called "Software Defined Radio". Currently, SDRs are popular with amateur radio hobbyists and other hackers as an inexpensive means of using software to perform tasks that normally require sophisticated, specialized hardware. SDRs have been used as everything from a cheap passive radar system to receiving satellite imagery in real-time, but AFAIK there are only a few examples of a software defined RC Transmitter. The examples that do exist such as this one- http://www.rtl-sdr.com/controlling-remo ... ar-hackrf/ don't exactly inspire me to trade in my Turnigy 9xr just yet... However, its possible it can be accomplished using open source components and source code already in-use by the RC community.

The hardware for such a device would require an MCU to handle the tactile controls, a CPU where the heavy processing would occur and a means of wireless transmission.

The CPU would need to be as compact as possible. While various MiniPCs like Raspberry Pi have found their way into embedded applications, I personally believe that we need look no further than our smart phones for the best processors in many cases. Android apps like the MultiWii EZ-GUI already have waypoint mission planning, telemetry and even direct control capabilities while mainstream products like the Parrot Drone recognized long ago that mobile interfaces represent the most accessible method to reach abroad market. The Parrot BeBop drone even includes a tablet-based transmitter wherein the tablet fits into the center akin to smart phone-based game consoles like the Moga controller. Of course, these examples are limited by the range of bluetooth and/or BLE which makes smart phones unsuitable for outdoor transmission. The developers of the small indoor nano-drone called the Crazyflie have come up with an interesting approach to the bluetooth problem. They use the Bluetooth to connect a standard Six-Axis Gamepad for the tactile controls, while the actual transmission is handled by a low-cost nrf24lo1 transceiver connected via USB. As it happens, a beefed-up version of the same transceiver can be used as a DIY OpenLRSng system.

While its possible that an Android compatible gamepad like the MOGA could be hacked for use with a TX, a truly customizable controller would need to have the analog inputs designed from scratch. I originally considered using the pots, switches and shell of an old Dx5e to house the new electronics, but such a design would negate much of the spatial advantage of using the smartphone. With many of the channel switches controllable from the app, one would only require space for the two sticks and maybe one or two analog switches (more or less depending on preference). In any case, the analog inputs will require an MCU to translate the analog inputs into digital values. The tool of choice for such applications is normally an 8bit Arduino microcontroller though more recently 32bit chipsets like the STM32 or the SAM3xx have been gaining in popularity. Various open source firmwares like OpenTX have been tested with boards like the Arduino 2560 and as both the Turnigy 9xr-Pro and the Arduino Due are based on the ATSAM3xx chipset, the DUE can likely mimic the capabilities of a 9xr-Pro. Furthermore, the DUE has built-in support for Android's "Accessory Development Kit" or "ADK" which means an Android app can be developed with native support for hardware controlled by the DUE.

Another advantage to using a 32bit chip based on Arduino compared to the STM32 is the enormous range of libraries and applications that are readily available thanks to Arduino's unmatched user-community. One of the more popular applications for the arduino is to use it combination with the ultra-cheap NRF24L01 RF Transceivers. As both the transceivers and the Due run at 3.3v, various libraries have been written with support for both. As mentioned earlier, the NRF24 transceivers can also be used as the basis of a DIY OpenLRSng system. Such a system is already well regarded as one of the most capable wireless protocols in RC, and a DUE+DIY OpenLRS TX should be compatible with any commercial OpenLRS receiver already available.

So that is my proposal for a software defined, RC TX... The stack could utilize source code from open source projects including MultiWii EZ-GUI, OpenTX, and OpenLRSng while hardware would require an Android phone, An Arduino Due (or the more recent Arduino Zero), an NRF24 transceiver and a custom built housing with the pots and hardware switches. The housing would need to be designed to house the DUE, RF module, manual controls while also mounting an Android phone in a central postiion. All other functions should be controllable from within the app.

Any constructive thoughts, comments or questions will be greatly appreciated.

[rperkins]

I dont think the hardware you mention in your last paragraph would be considered SDR. the NRF24 is not SDR.
My limited understanding of SDR is that it usually uses an fpga to simulate the hardware of a transceiver.
once you get away from the ISM band ( typically 2.4ghz), you are going to need to modify the antennas of the units. Secondly what licenses are going to be needed to operate in these other frequencies. third is the cost.

I think I understand what you want to create but dont believe SDR is the correct terminology for your project.
the one article you link to mentions a Lime Micro chip. a reddit user listed its cost at $35, and only goes down to 300 mhz( the article does mention a 50mhz version though)
http://www.limemicro.com/products/field ... -lms6002d/

yes getting all the module manufacturers to settle on some common protocols would be good, but the current cost/benefit of a SDR radio seems unbalanced.

[humblehacker]

I dont think the hardware you mention in your last paragraph would be considered SDR. the NRF24 is not SDR.


Of course the NR24 can't be considered a Software Defined Radio... Nor could any other hardware component for that matter! The whole point to the SDR is that it should be as platform agnostic as possible. If you meant to say that OPENLRSng can not be considered an SDR platform then thats another conversation entirely. Obviously, if we stretch the definition of "Software" too much then anything with open firmware could be considered an SDR, so it is important to keep things in context. However, as OpenLRSng development continues at an impressive pace, its not difficult to imagine its capabilities will resemble that of a "true SDR" in the near future.
In any case, the NRF24 is only meant to be one component of a broader system that will be software-oriented by design. So it might be best not to rely too heavily on 433mhz or any hardware for that matter. Assuming the NRF24 does turn out to be the most versatile option, then the task would then be to create a derivative project based on the most relevant features of OpenLRSng as well as those of MultiWii EZ-GUI, OpenTX etc... into one master system controlled by the CPU.

RE- Licensing Issues...
In the U.S. we can count on the FCC being about as helpful as the FAA... That is to say "not at all!"... Nevertheless, developers for both true SDR systems like the HackRF and OpenLRSng recommend applying for an amateur radio operators license as a failsafe. Although this would leave out Canada and a few others countries in Europe where the band is illegal.

[Kilrah]

OpenLRSng is a great system which now has lots of "high-level" features and it would be easy to make it drive a different hardware RF chip in whatever band you wish. At some point I was thinking about porting it to run on unmodified FrSky hardware which has the advantage of being great and cheap, so that we could achieve better integration.

The big problem is precisely the certification procedures that basically make it impossible to distribute an open design commercially beyond DIY / hacker / ham circles. It's precisely why the Taranis uses a separate RF module with closed firmware so that people can not mess with the transmission parameters. It's a certification requirement in most places.

And indeed to be strict with naming nothing in there is related to SDR. You'd get there only by removing the specific RF IC.