Sometimes you win, sometimes you lose. This time I've lost. Not by much, but always. During testing of my DIY LoRa RC link, radio caught a glitch during a flip few meters above a ground. It was not even a failsafe situation. Link recovered a few milliseconds later, but it was too late and quadcopter crashed into the ground.
During a roll, while being behind a tree, RX antenna got hidden behind a carbon fuselage and both antennas were at 90 deg. That was enough.
Damage is not severe, nothing I can not 3D print in one evening. It's more like a discredited honor or something.
The glitch was so short that is was not even recorded in blackbox log. RSSI was fine, no locked rcData. Quadcopter just kept 90deg attitude for too long.
There is a slight chance it was not faulted in software or hardware. Maybe there was a strong rouge TX polluting the aether. Why? I've caught a failsafe on a different quad (2.4GHz FrSky link) while being only a few meters away and a friend caught a failsafe on a TBS Crossfire. So maybe it's not entirely my fault after all.
Looks like I was able to solve all major known problems with my DIY long range radio system Crossbow. I'm writing known, since no idea what lies beneath… Anyhow… What changed? Quite a lot:
I've extended Arduino-LoRa library with ability to transfer full packet in single SPI transaction. Right now, each read of write to SX1276 uses single transaction. Previously, there were 2 transactions per byte…
The same library now has ability to send packets in async mode. Previously it was blocking code execution until LoRa packet was transmitted. Huge waste on processing time
With OpenTX 2.2.1 on the loose, I was finally able to drop PPM input from Taranis to TX module and replace it with S.BUS. But not without problems. According to specification, S.Bus should be SERIAL_8E2. But my Taranis clearly outputs it as SERIAL_8N2
For now, OLED display is disabled. It was taking too much time to update it using I2C and TX module was loosing S.Bus packets
I've improved RC channels processing time, time required for encoding/decoding went down by 1ms
LoRa modulation has some advantages. Like superb receiver sensitivity and immunity to interference. Has some problems, true, but at the end, it's a great way to send small packets of data to long ranges using low power.
Anyhow, today only one picture: how LoRa spectrum compares to FSK signal spectrum? Like this:
Those two peaks are nearby FSK stations, while plateau is 250kHz wide LoRa signal. Difference is at least clearly visible 😉
Finally, much later than I originally expected, Crossbow LRS, my DIY medium range RC radio link was used to control something that flies. Not much, and not far. It was only my experimental 6" GPS Racer quadcopter. And I reached only 350m. Small steps, I had no intention to beat and records after all.
CC1101 is another example of modern radio modules. I might not have the receiver sensitivity or LoRa SX1276, but with proper antennas should give more than 1 km of radio transmission. Recently I got a couple of them, so expect some new projects with CC1101 and Arduino.
Now, something that took me some time to find out, so you will not have to: CC1101 pinout:
Only two weeks ago I thought I solved all my major problems with DIY LoRa RC link. I was wrong. I was able to solve one problem (link unstable due to rouge packets messing up with protocol decoding), but an old problem came up again: PPM input from Taranis is no longer stable. At least I know why since this is a second time this is happening.
Current code read bytes from SX1276 buffer inside interrupt callback procedure (ISR). PPM decoding is also done in ISR. How many threads ATmega has? What happens when one ISR is triggered while second is still executed? Problems. The solution is to keep ISRs as simple and fast as possible. My code was not simple and fast enough.
On top of that, it turned out that Arduino LoRa library I’m using is not efficient. It performs 2 SPI transactions to read one byte from SX1276 FIFO buffer. So, 12 bytes of typical data packet equals 24 SPI transaction… Looks like I will have to do some low-level coding I wanted to avoid in the beginning… Oh well…
Last update on Crossbow LRS DIY RC link I'm currently building was 2 weeks ago. Back then, it did not went well: crashed an airplane beyond field repair. Last weekend I was able to do what I planned, but that did not went well as well. This time from completely different reason…
Link was catching failsafe every few minutes, even when RX was only few meters away from TX. To make things worse, link needed few seconds to recover. And twice it got stuck and required RX restart. It took me quite some time to discover what was the reason of that and a way to fix it.
SX1276 has 256 bytes of memory is divided equally for RX and TX FIFO queue
I was testing in LoRa rich environment
To reduce the probability of race conditions on SPI access and ISR locking, radio RX fifo was read in main loop. Radio interrupt was only setting a flag that data is present
The reason for hanging link was a combination of all points above: From time to time, when radio received a rouge long LoRa packet (by long I mean longer than 128 bytes), both RX and TX were stuck processing it and as a result buffer was never fully emptied and protocol state set to IDLE. In theory, there was a air protocol reset routine, but since SX1276 FIFO was overloaded, it was not working like I expected.
The solution (or at least I hope it will solve the problem) is as follows:
Radio interrupt checks if received packet size is a probable air protocol packet. Since its between 7 and 12 bytes, everything else is rejected
When probable packet is detected (size between 7 and 12 bytes), it is copied to temporary buffer, read and decoded in main loop
Radio buffers are flushed after each packet (put SX1276 in sleep and wake again)
Right now, link is up and running on a bench with other LoRa stations talking around for 2 hours. Not a single failsafe or any other problem so far. Look good. Unfortunately it is raining, so not further live testing this weekend I'm afraid.
By the way, there were good things during my last test too. At 500m distance link still had around 80dB of link budget left. That means I should be able to reach my goal: 5km range is within reach!
Yestarday I wanted to make a first "real" range test of my DIY LRS system. "Real", because RX was supposed to be on a flying wing, but only as an passenger. Actual control was supposed to be happening via FrSky X8R. Crossbow RX was only to measure RSSI and check for failsafes.
It, well, did not ended up very well. Just watch the video.
Hey, don't leave yet, there is more!
Do you know that there is a YouTube channel with awesome, drone and FPV related video? Why don't you give it a try?