Arduino, ESP32 and 3 hardware serial ports

When working with ESP32 WiFi/Bluetooth MCU under Arduino SDK for ESP32, you will notice that Serial work just fine. But Serial1 and Serial2 do not. ESP32 has 3 hardware UARTs that can be mapped to almost any pin. But, Serial1 and Serial2 will not work. In case of ESP32 this just has to be done in a slightly different way:

The trick is to use HardwareSerial library to access UART 1 and 2 instead of Serial1 and Serial2

  • Class HardwareSerial accepts one parameter in constructor, it is a number of UART. Values from 0 (UART 1) to 2 (UART 3)
  • HardwareSerial(0) is the same as Serial so be aware
  • begin method accepts 4 parameters
    • baud speed
    • UART mode
    • RX pin
    • TX pin

The real beauty of this solution is that almost any pin can be used as TX or RX pin for any UART. Most ESP32 dev boards have labels like TX2 or RX2, but you really do not have to exactly those pins. Every other GPIO pin can act as Serial RX, but only the ones between GPIO0 and GPIO31 can be used as TX. Still, that gives plenty of pins to choose from…

Read More

Crossbow LRS, hardware

Weather outside is bitchy. Period. It rains, then it's windy and then maybe there is some direct sunlight for 15 minutes. No way to fly or test my DIY RC radio link.

Weather is bitchy

But, there is some progress after all. My latest changes seems to be working just fine. On a bench link was stable for almost 3 hours. Later I too it for a standard range test: 2.8km LOS. It also worked, I still had around 5dB of link budget left on a ground level.

Back to the topic. Crossbow LRS is open source and open hardware. Maybe open hardware is too much, since there is almost no hardware to build. After all, first iteration is based on LoRa32u4 II development boards and running good old Arduino.

RX module requires no additional hardware:

Crossbow LRS receiver module

TX module is slightly more complex. It required voltage stabilizer and inverter/level shifter made with single 2N7000 FET transistor. I2C OLED display is an option:

Crossbow LRS transmitter module

Read More

Crossbow LRS, I was doing this wrong…

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.

To give you a full picture:

  • Link is build using LoRa32u4 II Arduino compatible boards that utilizes HPD13 868MHz LoRa radio module. HPD13 uses Semtech SX1276 radio chipset
  • 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!

Read More

Project Dualcopter – worklog #4

More than a year after staring this damn project, I finally decided what goes where. And on top of that, short description how Dualcopters works (or at least should work).

  1. There are two counter rotating propellers on top. They are responsible for thrust and YAW control
  2. When both props turns faster, dualcopter gains altitude
  3. When clockwise propeller turns faster, whole design starts to rotate counter-clockwise. When counter-clockwise propeller turns faster, it rotates clockwise
  4. Roll and Pitch axis control is archived by two flaps at the bottom of the design moved by two servos
  5. Since propellers are always rotating, there is almost always enoughair passing through flaps to have enough force for stability control and maneuvers
  6. To generate enough torque, center of gravity should be far above flaps. This way, even relatively small force on an end of long lever, there is always enough torque for roll and pitch stability

Dualcopter working principle

Keeping above in mind, it will look like this:

Dualcopter what goes where

What is still missing? Place to put battery in and electronics. Next update as soon as I will have any update 😉

Read More

A proper way of doing read callback receive with Arduino LoRa

Arduino LoRa is a great library that brings LoRa support (SX1276/SX1277/SX1278/SX1279) to Arduino world. I'm using it in my Crossbow LRS project (still not stable enough for flight, work in progress). Until now, the biggest problem with this library I've found is that examples suggests that heavy protocol processing inside interrupt callback is fine.

Unfortunately, it is not. It can lead to unexpected processing delays, create conflicts with other interrupts, bus clashes and other hard to debug things. This is why, the better way is to do packet reading (and processing) inside main loop and use read callback only to set a flag. Like this:

Only please remember to set all variables modified in ISR routine as volatile.

Read More

Video tutorial: 5.8GHz Inverted Vee antenna for FPV

Today another video tutorial. It's just simpler to show how to make something on video than with text and images. So, without further ado: How to make Inverted Vee antenna for 5.8GHz FPV at home. All that is required is:

  • coax cable (here RG316)
  • SMA/RP-SMA connector
  • copper welding wire
  • caliper
  • soldering station
  • basic tools

At the end we have small and light FPV antenna that just works. Sometimes it's just worth to make something by yourself, right?

Read More

Crossbow LRS, range test that did not went well….

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.

Read More

DIY RC radio link: the problem of protocols

So, you want to build your own RC radio system? Long range maybe? Cool, I want to do it too. Since I'm pretty deep in that topic now, I can give you a hint or two. For example, have you thought about a protocol your radio system will implement?

RC link simplified

Or rather should I say: protocols? Why plural? If you want to do a RC link that talks with popular radios like FrSky Taranis on TX side and servos or flight controllers on the RX side, it will have to implement at least 2 different protocols. More likely 3. And if you will want to add telemetry downlink, 4 or even 5…

Continue reading “DIY RC radio link: the problem of protocols” »

Read More