[Updated the PCB/SCH with the latest version:

- added a diode for the LEDs to drop the voltage from 5V to lower so the input (3v3) is lower than 0.7 VCC

- fixed some parallel traces on the top and bottom of the board

- broken out i2c on another pin header]

I started working on a custom FC board for silkopter and soon I will receive the first PCBs.

It's meant to be used as a Raspberry PI HAT and all the software (silkopter) runs on raspbian.

The board is 2 layout and can be printed (I hope, still didn't receive them yet) using DirtyPCB for ~30e for 10 boards. It was developed with the free version of eagle (hence the 2 layer limitation) in the past week.

Eagle schematic and PCB layout are on github 

My goal with this board is to have solid, long range RF integrated into the board, add sensor redundancy and experiment with SMD as a side quest.


- Dual MPU9250 9-axis IMU, one on SPI and one on I2C. They will both perform @1Khz

- Dual MS5611 barometer, one on SPI and the other on I2C @100Hz for both

- ADS1115 16bit ADC for current/voltage sensing

- Input for a serial GPS like any ublox (3.3V signal)

- Input for a serial sonar like MaxSonar. Works both with UART and RS232 signals (normal or inverted, 3.3V both)


- Either a RF4463F30 board (-126dBm sensitivity, 1000kbps, 30dBm power)

- Or a RFM22B board (-126dBm sensitivity, 256kbps, ~20dBm power)


- 6 PWM. I plan 4 motors and 2 for gimbal

- 3 RGB leds (NeoPixels or WS2812b)

A skilled developer could adapt Arducopter to support this board in 1-2 weeks. The trickier part would be the RC part to make it use the RF board instead of a classic RC receiver.

I'm also developing a custom RC system with a Raspberry PI, a touchscreen for FPV digital video (800x480 resolution, 2000kbps), a 3 axis gimbal for yaw/pitch/roll and a motorized slider for thrust control.

I'm working now on the component selection and schematic.

The build log is  here.

Feedback is welcome, it's my second PCB ever and my first one with SMD and especially a QFN package.

Views: 1744

Comment by Marc Dornan on July 10, 2016 at 8:22am

May I suggest that you check ULRS out http://www.rcgroups.com/forums/showthread.php?t=2037442

It is quite active now and if you adapted your design a little you could maybe use it to for long range telemetry and radio control. The firmware is not open source although the hardware designs are all open and freely available.

Comment by Bill Bonney on July 10, 2016 at 10:27am
I'd suggest not building the Radio on the pcb, but separate via a serial link. It much more flexible. And less interference when you can move it away from other components.
Comment by JeanLeFlambeur on July 10, 2016 at 11:06am

@Marc - thanks for the link. I'm going through the huge topic now. It's encouraging that these 433Mhz modules can reach so far. I definitely don't aim for such a long distance but it's nice to have the extra dBm there in case of trees in between, etc. I already lost a quad due to signal loss and don't plan to do the same thing again (video)  :)

@Bill - you mean the radio getting interference from the PCB or the other way around? I mean 1W is a lot but I doubt there's anything that sensitive on the PCB or the raspberry pi itself. I designed the PCB traces to avoid ground loops and devices feeding power of each other (I think/hope) so I'm hoping for very little interference radio->pcb. For the other way around, I've played for a few months with the Navio+ board that has the UBlox GPS on-board, which has around -160dBm sensitivity and it reported very little to no jamming. The radio is ~100dBm at the bitrate I aim for so there's a lot of room for noise before it bothers. This is based on my loose understanding of RF noise so I might be in for a surprise. 

In any case, I'll try my SDR spectometer on the 433Mhz band around the raspberry pi to see if I pickup any EMI.

Power supply interference might still be an issue, especially with the RFM22B which is feeding power from the RPI 3v3 regulator. The big RF4463 module is powered directly from raw 5V as it has its own regulator on board so I think with a big LC filter between the power module and the PCB I can remove most interference.

Anyway the reason for the 'compact' design is that I'm aiming for the smallest quad I can, around 650-700 grams with AUW (gimbal + camera included) while still having +15 min of flight time. This limits my space quite bit...

Thanks for the comments!

Comment by Marc Dornan on July 10, 2016 at 11:54am

I am trying a pixracer on a ZMR 250 frame with Feiyu Mini 3 axis gimbal. I have seen brilliantvresilts. Good luck with your quest. 

And given your name. Allez Les Bleus!

Comment by Alex Wright on July 10, 2016 at 1:36pm

@JeanLeFlambeur I would be interested in trying this board out as I recently lost my quadcopter with a pi2 and navio2 board onboard. I have raspilot boards that don't work and would be interested in trying another pi based solution. I currently use the bbbmini board with my beaglebone black.

Comment by JeanLeFlambeur on July 11, 2016 at 12:51am

@Alex testing this board will require the custom RC system as well and I didn't finish that one yet. I think that in 1-2 months it will be ready for a test drive but it will require some soldering and assembly on your side.

Out of curiosity, how did you lose your quad?

Comment by Alex Wright on July 11, 2016 at 6:39am

@JeanLeFlambeur http://bit.ly/29JevDB here is a picture of the quad i lost. this was pictured with my beaglebone black on the quad. I had my navio2 and raspberry pi2 on the quadcopter without the gps antenna and no telemetry dongle as well. I was testing recording video with a logitech c920 on memorial day. I use 4s lipo with 2300kv motors and 6 inch dal props. I have never had a fly away etc. I let my cousin fly the quad and he took it out of range of the receiver not realizing what he was doing. I got my hands on the transmitter too late and watched as it went down behind a house in field/farm land. This happened in plant city florida. The receiver I was using is a r615x and from taking a look I should have bound the receiver with the throttle at mid or slightly below. It seems as though it went out of range the fail safe kicked in and it just dropped like a rock. I have search for about 2+ weeks for it. I sent my cousin a list of parts that came up to almost 600 dollars.

Comment by Patrick Poirier on July 11, 2016 at 11:08am

@JeanLeFlambeur ,

I know that there is many post about this,  but I just got to ask:  How the PWM will be correctly implemented without jitter ? Most , if not all , PWM-RPI implementations (Including my Mini Zee)  are made using hardware , either PCA9685 - STM32 - FPGA or other.

Second question: Do you think that adding secondary IMU & Baro on the same board makes any added value ? Wouldn't it make more sense that you install the I2C based Imu & Baro sensors on a separate board so you can get a real differentiation of signals and provide an optimal sensor fusion.

@Alex, really sorry for the lost - reminded me to install a Buzzer on all my builds, and  do a real range test & confirm as well that the failsafe is kicking in.

Comment by JeanLeFlambeur on July 11, 2016 at 11:50am

@Patrick - For now I'm using the PIGPIO library that does the DMA trick for almost-hardware PWM. I'm using a 5 micos step on PIGPIO and could go down to 2 micros if needed. Keep in mind that most AVR FCs drives the PWM from 8 bit timers normally which gives a 7.8 micros resolution - and I don't think it ever caused problems. BLHeli with OneShot used 100 different throttle steps for a while (if I remember correctly) which resolves to ~20 micros resolution.

I measured the waveform with an oscilloscope and couldn't see any jittering, up to what my oscilloscope could capture (10 micros). This means a possible jitter of <= 0.5% (out of a 2ms PWM cycle) which I think is beyond acceptable considering that it will be smoothed out by the inertia of the prop+motor. Not sure what the bandwidth of the motor+prop is but I think it's way lower than 100Hz.

I used the PCA9685 as well (on the NAVIO) and tried it together with PIGPIO and they behaved the same - as far as I could tell. Didn't compare them side-by-side on the oscilloscope though.

Theoretically PIGPIO should be very stable except if memory bandwidth is saturated. Silkopter is very very far from this point on the Raspberry PI 2/3 as it's using ~10-15% CPU right now and next to no memory bandwidth.

The idea of dual IMU was that I actually had 2 chips (from 2 Drotek 10 DOF IMU boards) and I wanted to combine them to get less noise. Having each on a separate bus adds some redundancy in case I2C gets blocked for example. Not sure how relevant this is as it's a quadcopter to there is no other redundancy and anything that fails will result in a crash - but I do get less noise. For the baro it's more relevant than for the IMU to be honest..

I do get your point though and that's a nice idea. With another sensor positioned somewhere else on the quad I could remove the centrifugal from the measurement...

Or even better, have one sensor on the PCB on a anti-vibration mount and another sensor on the quad directly without anti-vibration. Like this I could probably remove motor/propeller noise from the measurement more efficiently than a simple LPF.

@Alex - sorry for the loss. I know how it feels - I lost the first silkopter prototype in a forest in a fly-away due to a GPS + RC glitch. I looked for it for an entire day before accepting defeat.

Comment by Jerry Giant on July 12, 2016 at 3:10pm

better move away the GPS module as far as you could from the USB ports...


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service