Fancy building a DIY RC transmitter? Then read on…
This blog is part of a general look at DIY RC transmitters, see RC Transmitters – DIY.
Using a broken RC Transmitter shell, and using standard commercial Transmitter/Receiver modules, you can build your own DIY transmitter, using an Arduino Nano and this open source RC transmitter software for the Arduino. Note that, as it stands, version 1.5.5 of ‘arduinorc‘ will only compile with Arduino IDE v1.0.5 (see video), although evidently (I have not been able to verify this), according to Arduino Radio Control – Software Installation: Prerequisite,
Version 1.5.6-r2 appears to be the latest that will compile this software without errors.
In order to get it to compile with the Arduino IDE 1.6.x, make the following changes:
static PGM_P ...
static PGM_P const ...
const char *...
const char* const...
in the file
static PGM_P ...
static PGM_P const ...
in the file
PGM_P const ...
in the files
These are the resources I used to make the changes, in order to get arduinorc to compile on Arduino IDE 1.6.x:
- avr-lic 2.0.0: <avr/pgmspace.h>: Program Space Utilities
- avr-lic 2.0.0: Data in Program Space
- Arduino Playground – PROGMEM
- PROGMEM and PGM_P syntax question
- From Nick Gammon:
See also, although somewhat out of date:
The best explanation is to be found on compile error since IDE 1.5.8, by bperrybap:
The short answer is that the newer IDE is shipping with a newer avr-gcc toolset
and some of the older ways of doing things no longer work.
However, there are ways of doing declarations that work with both the new and the old avr-gcc toolset.
A bit more information.
Things like prog_char, progmem, PROGMEM, etc.. are not part of Arduino nor the IDE. They are AVR specific and are technically not part of gcc. They are proprietary AVR capabilities provided by AVR libC which is included
with the avr version of gcc.
The progmem stuff is kind of a hack that allows using FLASH storage for constant data since the internal AVR h/w architecture does not allow it to use the normal C language constructs for constant data that can be used on other processors like ARM, pic32, x386, 68k, etc… i.e. the AVR couldn’t store constant data in flash because its architecture was incompatible with C’s notion of address space.
Because the AVR progmem stuff was implemented as kind of hack in the libC library vs being really supported by the compiler, it has some issues particularly with C++, and that is why you get warnings when it is used in C++.
The AVR progmem stuff also played a bit fast and loose with some of the rules.
As avr-gcc has been updated over the years, changes and additional modifications/updates have been made to the actual compiler to better support Harvard architectures like the AVR, which has required that some changes also had to be made to the AVR progmem stuff. As a result some of the earlier progmem definitions have been changed, deprecated, or have been removed.
Also some of the syntax that was technically incorrect still worked with the older compilers no longer works with the newer compiler. In fact, many of the examples on the Arduino progmem page were wrong and were in that “technically incorrect but worked” category.
The prog_ data types have been deprecated for quite some time. The Arduino has been shipping old versions of the avr-gcc tools but now with the newer compiler, they no longer work.
Building the hardware
To build this project on veroboard, as in the example at the top of the gallery,
I have made the additional images:
To make the 6, or 9, channel version with Veroboard, following the same layout as the PCB versions
The enlarged images
To make the 6 channel version with Veroboard
To make the 9 channel version with Veroboard
There appears to be an error, stemming from the PCB design which was carried over into the veroboard layouts, with respect to R1 and R2, the PPM ariel connection and the Arduino Nano output D10. From the ArduinoRC hardware page, in the circuit diagram:
and the Fritzing diagram
the PPM output is taken from between R1 and R2, with R1 and R2 serving as a potential divider.
However, in the PCB diagram, the output of D10 goes to the potential divide point, between R1 and R2, and the PPM output is at the top of R1, which is clearly wrong:
This error was then carried over to the veroboard layouts above. The corrected layouts are below:
Note that R2 is now connected to R1 and the PPM output.
Using a Pro Mini en lieu of a Nano
The pin layout of the Pro Mini is different to that of the Nano,
calls for a slight redesign of the Veroboard layout:
- Because the location of the pin D13 has moved, so the LED connector has moved, as has the associated resistor R3 (R6).
- This causes one of the potentiometer connectors to be moved up the board, although the remaining potentiometer jumpers remain in the same position, if a little reordered (From the bottom of the board up: Pot6, Pot7, Pot8, Pot1, Pot2, Pot3, Pot4, Pot5).
- Also, some flying leads are required to deal with the unorthodox positions of A4 and A5. These flying leads go to D4 and D13 (veroboard coordinates) respectively).
- The battery check resistors (R4 and R5) also have to move.
- The D11 and D12 outputs are rerouted so that the jumpers stay in the same position.
- Because of the new location of D10, the associated potential divider resistor (R1), for the PPM, is moved.
The new diagrams: