2
$\begingroup$

I'm working on a project to transmit and receive data by radio. For the transmission, I'm using a Raspberry Pi 3 and the NTX2B transmitter for the transmission. For the receiving end, I am using NooElec Mini 2 SDR as the receiver and the CubicSDR program to see a waterfall diagram of the received signal.

I've used instructions from Yannick, Linking an Arduino to a Radiometrix NTX2B Transmitter and Dave Akerman to get as far as I have. The image below shows the circuit diagram (from Dave Akerman).

Layout (from Dave Akerman)

Sending 1s and 0s using a GPIO port

Initially, rather than connecting the transmitter input to the TX port on the pi, I connected it to one of the GPIO ports, number 18. I instructed port 18 to switch on and off every five seconds, and was able to see the frequency shift on the waterfall diagram on my laptop. :) Success!

from time import sleep
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM) 
GPIO.setup(18, GPIO.OUT)

GPIO.setmode(GPIO.BCM) 
GPIO.setup(26, GPIO.OUT)
GPIO.output(26, True)

while 1:
     GPIO.output(18, False)
     sleep(5)
     GPIO.output(18, True)
     sleep(5)

Output for 0s and 1s

Serialising data using the TXD port

The next step was to send data by connecting the NTX2B to the TXD port on the Pi. I was expecting to see a double peak, one for 0, and another for 1 at a higher frequency, on the waterfall diagram. However, I get just a single peak, and so I'm not sure if I'm actually transmitting the data. I tried using setRTS to digitise my signal (similar to the previous experiment), however the waterfall diagram didn't show any change. Can anyone help me with this? :(

import serial
import time
from time import sleep
import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM) 
GPIO.setup(26, GPIO.OUT)
GPIO.output(26, True)

ser = serial.Serial("/dev/serial0",
                    baudrate = 115200,
                    parity=serial.PARITY_NONE,
                    stopbits=serial.STOPBITS_ONE,
                    bytesize=serial.EIGHTBITS,
                    timeout=1)
ser.setRTS(False)
time.sleep(5)
ser.setRTS(True)
time.sleep(5)
ser.setRTS(False)
time.sleep(5)
while True:
    ser.write(b'hello!')
# ser.close()

Output for serialised data

$\endgroup$
  • 1
    $\begingroup$ Reduce and simplify the problem. Think the Tx port isn't working? Try blinking an LED instead. $\endgroup$ – Phil Frost - W8II Jul 23 '17 at 11:24
  • $\begingroup$ @PhilFrost-W8II the Tx port is definitely working. I connected the output of the Tx port to the Rx port on the pi, and then wrote a script that reads the data. I got the output h, e, l, l, o as I expected. $\endgroup$ – bluprince13 Jul 23 '17 at 11:27
  • $\begingroup$ So if it's definitely working, why isn't it working? Check the output voltage with a voltmeter. Simplify. $\endgroup$ – Phil Frost - W8II Jul 23 '17 at 11:28
3
$\begingroup$

Your frequency deviation in the plot is somewhere in the range of 1 or 2 kHz – so, you really can't modulate it with 115.200 kHz of symbol rate!

Try 9600 bd on the interface instead. It looks like the TXD input directly modulates the output – and that means that the data clock is identical to the on-air data clock.

Personally, to me, this sounds like you shouldn't be using an UART to talk to the device. Instead, use the SPI interface, in hopes you can make constant-rate, seemless, multi-byte transmissions.

Package your data in packets (for example: take 8 byte of data at once). Each time before you start sending, send a preamble byte (e.g. 10101010b==0xAA==170) so that your receiver can find your transmission, and achieve clock synchronization (yep! that's necessary!).

Then, to improve the likelihood of successful transmissions (reduce the bit and packet error rates):

  • Add channel coding in your software – a 3/4-rate simple block code might do. That adds redundant info to your transmit data – but that info can be used by the channel decoder in the receiver to recognize and often even reverse bit errors
  • Interleave the bits throughout the 8 byte packet. That means that if two consecutive transmit bits are disturbed (e.g. by a short interference), these two "damaged" bits end up at very far-away places in the bit stream after deinterleaving, and that means it's easier for the channel decoder to correct them
$\endgroup$

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.