Monthly Archives: January 2016

RCP (the new RUDP)

Some months ago I found this awesome blog with research and a usable implementation of rfmon for uni-directional wireless communication. It uses libpcap and a modified firmware for the TP 721N dongle to send encoded video packets and telemetry to the GS. It’s unidirectional and this has some advantages. The biggest advantage for me was that it doesn’t require pairing nor connection handshake. Perfect for a quad!

So I included rfmon in RUDP and renamed the result to RCP (Reliable Comms Protocol…). It’s bidirectional in my case as I need to send control data to the quad as well but the advantages still apply.

Performance is great, I can send 1024×768 video @30 FPS, 2Mbps using around 4-4.5Mbps with very little CPU usage.

The problem I’ve hit is this: the more data I send, the more packets get lost due to interference, etc. Having a fixed retransmit rate – like every packet 3 times – requires a fixed amount of bandwidth but doesn’t scale at all to low-bandwidth situations. So I need a way to use the least amount of bandwidth possible while still ensuring that frames arrive at the other end.
One solution is to add ACK packets to reduce retransmission – which is what RCP does – but this also has an issue. Every confirmation packet keeps the channel busy for a little while – in turn dropping the total bandwidth of the system.
Current solution is to gather many confirmations and send them with low frequency – around MAX_RETRANSMIT_TIME / 2 (currently every 10ms). So fast enough to avoid retransmission, but not as fast as to keep the channel busy unnecessarily. So far this works beautifully.
Code time!

The brain on the UAV uses RCP setup with a RFMON socket:


auto s = new util::RCP_RFMON_Socket("mon0", 5);//5 is the end-point ID
m_rcp.reset(new util::RCP);

util::RCP::Socket_Handle handle = m_rcp->add_socket(s);
if (handle >= 0)
    m_rcp->set_socket_handle(SETUP_CHANNEL, handle);
    m_rcp->set_socket_handle(PILOT_CHANNEL, handle);
    m_rcp->set_socket_handle(VIDEO_CHANNEL, handle);
    m_rcp->set_socket_handle(TELEMETRY_CHANNEL, handle);


So – this code adds a socket to the RCP instance and then instructs all channels to go through this socket. Same for the internal data – which represents the ACKs, pings (for RTT estimation) and connection requests.

The reason for this indirection is to allow different sockets for different channels. For example – use RFMON for unidirectional video streaming and another socket over a 433Mhz radio (like this one) for all other comms and ACKs.

In the near future I’ll try this – sending all channels except video through the RFM22B socket, as this should give me better range & penetration compared to 2.4Ghz.


GPS Jamming #2

A few days ago I got a RTL-SDR dongle to play with and I thought to give it a shot and measure the interference levels coming form the raspberry pi camera.

This is what I got around the GPS L1 frequency.


Camera off:

Screenshot from 2016-01-24 16-04-05.png

Camera on:

Screenshot from 2016-01-24 15-58-54.png

Notice the 2 peaks at 1,574.996 Mhz of -68db and 1,576.468 Mhz, -70db. They are very close to the GPS L1 frequency of 1575.42 Mhz and I’m sure the are the cause of the interference.

The big issue is that they radiate a long distance around the quad, dropping by about 10db 0.5m away from the quad. The pattern is not uniform, there are gaps where the interference disappears and I assume it’s due to reflections.

Note that changing the resolution and bitrate of the camera doesn’t change anything…


Next step – since I can now measure it – is to see how I can eliminate it.

A few options come to mind:

  • tin foil (although last time I tried this there was no change)
  • replace the flex cable with a shielded hdmi cable
  • replace the camera with another one? Not sure if this will change anything