Whilst the easiest method to control data to the NTX2 is via the onboard UART this isn't the only method available. Below are an outline of some of the more advanced techniques. If you found this page first you might want to read the raspberrypi guide first.

Two things to consider when using these advanced techniques are how quickly the pin can be enabled and disabled and how accurately you can achieve this timing. As Linux is not a true real time system it's much harder to guarantee accurate timing.

To use these techniques you will need to use a suitable language (likely C or C++). As timing is important you might find that other languages cannot provide a good enough timer resolution or are unable to switch a GPIO pin fast enough. There are some test results of how quickly different languages/libraries can enable and disable a GPIO pin at http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/

Whilst there might be other ways that work my experimentation so far has been using code based on the C example on the Raspberry Pi Wiki (http://elinux.org/RPi_Low-level_peripherals#C_2)

This can be used to send RTTY in a similar way to the Arduino & NTX2 example code on the wiki by enabling and disabling a gpio pin with a suitable delay loop. In early tests this appeared to work even when providing some load to the CPU.

With further testing (including use of a Logic Analyser) whilst the RTTY was good enough most of the time there was a fair amount of jitter on the bits sent. This can be improved by setting the rtty process to have a SCHED_RR or SCHED_FIFO scheduling policy rather than the standard SCHED_OTHER policy.

This is effectively big banging a gpio in a way that gives a suitable voltage. Whilst in theory it may be possible to generate a mode like DominoEX16 via this method in practice it doesn't seem to be possible due to the time taken by the various delay timers (The shortest delay I could achieve through any method was around 3ms). It might be possible to generate RTTY tones via this method however it's much easier to use the resister divider method instead.

It may be possible to control the switching via a timer interrupt, this could provide better timing and a lower CPU overhead.

Using a kernel module it might become easier to provide better timing for controlling a GPIO pin.

One of the benefits of using a GPIO pin to send data is that it could allow the use of other Data Modes.

Obviously the easiest and safest mode of doing RTTY is to use the UART to provide the timing, However using a GPIO pin using the methods outlined above would allow the use of more than one transmitter or allow the gps module to use the UART without having to share the UART with the NTX2. This could become important for faster telemetry updates.

Whilst it doesn't seem possible to produce DominoEX 16 using Software PWM it might be possible using the Hardware PWM module. With the new NTX2B modules this could become a future mode of operation.

The easiest method of producing APRS is likely to be via the soundcard. However again Hardware PWM might be an option.

The Sandals radio tracker code uses this method of generating RTTY using a threaded C++ Class. This code has yet to be tested in a real flight. The tests folder also includes a Software PWM sample for DominoEX16 which shows the method for generating the tones - although not working due to the issues with delay times.