3D printed racing drone, part 2

My 3D printed racing drone is done. More or less. I was able to finish it a few weeks ago and even perform a maiden flight. It survived the experience, but I also discovered few problems I will have to solve before officially calling this project a success.

First of all, the decision about hard mounting a flight controller and not installing a capacitor on mains was a bad one. Not only motors are "twitching" from time to time, a video is very noisy. I hope big low ESR capacitor will solve that, since there is no way for soft mounting for this frame.

Besides that, it worked just fine. I will try to prepare a video from the maiden flight in a few day, for now only a few pictures and final specification:

• Frame: PLA 3D Printed, 220mm motor-to-motor diagonal
• Motors: EMAX RS2205S 2300KV
• ESC: Racestar RS30A BLHeli_S
• Flight controller: FrSky XSRF3O running Betaflight 3.2
• VTX: TS5823 200mW
• Camera: RunCam Swift
• Total weight, no battery: 380g

Total build is, of course, heavy, but not that heavy as I feared. I was expecting something way above 400g. The frame is also quite stiff. I wonder how much beating it will be able to take....

Crossbow LRS: ready for next tests

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
• It is still LoRa32u4 II 868MHz based but I'm considering different hardware. For example ESP32 with LoRa. Time will show

Next test hopefully this weekend. If weather allows, of course. We have very wet autumn this winter in central Europe this year...

Worth to see: 250m inside of a chimney in a FPV drone

I'm posting this not without a very specific reason. A few days ago one of my friends accomplished something quite amazing: he "dived out" a 250m tall chimney of an abandoned factory. By "dive out" I mean: flew inside a chimney at its base, climbed 250m up inside the chimney and then flew out. Simple, right? Well, no :) Just think of it like this: how to get a solid video link when TX is 250m away inside a structure made from reinforced, thick, concrete?

I'm waiting for a video of "dive in" for sure!

The most popular flight controller for INAV - Q4 2017

It's been a few month since, for the last time, I presented to you the most popular flight controllers used together with INAV firmware. So, as you can suspect, it is time for the next one. This time, I've looked into last 3 months of the year 2017: October, November, and December.

Important, this is not the number of boards flashed with INAV, but rather the number of times a board was connected to Configurator!
This counts TARGET software name, not retail name. For example, all clones of Naze32 will be counted as Naze32

Remaining 10% of market share is distributed among other targets.

As you can see, Omnibus F4 series dominates. All revisions of this board have 30,5% share when combined. Also, all F3 and F1 based flight controllers are giving ground to much more powerful STM32F4. To compare, in August 2017, all F4 boards had 25% when combined. Right now they have 39% market share when combined. And this is good!

Another good news is that share of OSD equipped flight controllers is also growing. In August 2017, 47% of boards were equipped with OSD. Now it is 50,5%.

How to wind an electric brushless outrunner motor with dLRK winding schema, part 2

My memory is not as good as it used to be. I just realized, that third part of my motor winding series was not yet announced over here. So here we go...

In this video I terminate motor into Delta pattern and do first test of freshly winded motor.

LoRa versus FSK modulation signal spectrum

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 ;)

Crossbow LRS: first live test that is almost a success

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.

Just as reminder, by RC link is as follows:

• Based on LoRa32u4 II development boards
• Semtech SX1276 868MHz
• Programmed with Arduino
• Planned range: up to 5km

Next test, this time without twitching, in a few weeks.

CC1101 868MHz Wireless Transciever Pinout

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:

RaceFlight One GPL violation drama, there might be more of that

Previous parts of this cycle are available here and here.

Betaflight community has a grudge against RaceFlight. And they have a reason. Two potential, or maybe I should say confirmed, GPL violations in one year is fully enough. That just does not looks good no matter how you look at it. This whole situation stinks. So it's not a surprise that what leaked as RaceFlight One source code is analyzed like crazy.

Latest news: RF1 code might have at least 2 potential license violations:

STMicroelectronics license violation

* @attention
*
* <h2><center>&copy; COPYRIGHT(c) 2016 STMicroelectronics</center></h2>
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*   1. Redistributions of source code must retain the above copyright notice,
*      this list of conditions and the following disclaimer.
*   2. Redistributions in binary form must reproduce the above copyright notice,
*      this list of conditions and the following disclaimer in the documentation
*      and/or other materials provided with the distribution.
*   3. Neither the name of STMicroelectronics nor the names of its contributors
*      may be used to endorse or promote products derived from this software
*      without specific prior written permission.

If RaceFlight do not have an agreement with STMicroelectronics, point 2 is violated since bin is the only way RF1 is distributed

Atollic TrueSTUDIO(R) license violation

**  Environment : Atollic TrueSTUDIO(R)
**
**  Distribution: The file is distributed �as is,� without any warranty
**                of any kind.
**
**  (c)Copyright Atollic AB.
**  You may use this file as-is or modify it according to the needs of your
**  project. Distribution of this file (unmodified or modified) is not
**  permitted. Atollic AB permit registered Atollic TrueSTUDIO(R) users the
**  rights to distribute the assembled, compiled & linked contents of this
**  file as part of an application binary file, provided that it is built
**  using the Atollic TrueSTUDIO(R) toolchain.

One more time, if RF do not have separate agreement with Atollic, they are violating license above. I have not seen information that RF1 was built with Atollic TrueSTUDIO(R) toolchain.

I will leave it without any additional comment.

Standalone Betaflight Configurator, since Chrome Web Store apps are dead

Google finally did what they announced last year: Chrome Packaged Apps for Windows, Mac, and Linux are dead. OK, maybe not 100% dead, but they were removed from search and browse in Chrome Web Store. If you still have link, you can install (no idea for how long tho).

So, how to live with that? Our hobby is driven by Chrome Packaged Apps. Betaflight Configurator, INAV Configurator and Cleanflight Configurator are all Chrome Packaged Apps. Did we lose the ability to set up our drones? Luckily no. Thanks to fantastic project NW.js, chrome apps can be packed together with Chromium and distributed as a single file without dependencies. I've prepared a short video how to install Standalone Betaflight Configurator, for INAV it's the same procedure. And for Cleanflight... well... Cleanflight is dead. Or rather dying...

• Betaflight Configurator download
• INAV Configurator download