Thread Tools
Jun 21, 2014, 06:16 AM
Dave the Rave
dmccormick001's Avatar
Hey Guys! I know the rule is "If it ain't broke, don't fix it", but I thought I'd throw my 2 cents in as far as the "reversed" transistors in this circuit are concerned.

I think I may have spotted the problem. You have the (+) side of the LEDs connected to the transistors, and the (-) side of the LEDs connected to V+. If you simply reverse the polarity of those LEDs, I think that circuit will work more like you expect it to. Normally, if you want to drive an NPN transistor using a PIC, you would connect the base to the PIC (as in your circuit), the emitters would be grounded, and the collectors would go to the (-) side of each LED. Then the (+) side of all the LEDs would go to V+. You have the (+) side of the LEDs going to the transistors, and the (-) side of the LEDs going to V+

I suspect Eagle didn't report any ERC errors because of the jumpers on the LEDs. If your schematic had included actual LEDs instead of jumpers for them, it would likely have shown you the error.
Sign up now
to remove ads between posts
Jun 21, 2014, 10:05 AM
Registered User
Gerry B's Avatar
The + on the jumper was put next to the wrong pin number on the jumper in the schematic. All of pin 2's are tied together and go to V+ and pin 1s go to each transistor.

You can see in the every circuit test schematic that I did, the portion to left is wired as on the schematic, and to the right is as on the original board version. The every circuit shows a large current difference but my bench test only showed a total difference of 200 micro amps
Jun 21, 2014, 01:06 PM
Registered User
LukeZ's Avatar
Thread OP
Actually, the little red "+" on the schematic on the jumpers doesn't signify positive at all, it represents the pivot point of the graphic within Eagle. If you look at the three-pin jumpers, or even the FTDI jumper (you have to look closely), they all have the same red "+" but in different locations. When you select this schematic component on your Eagle screen, and rotate it, the red "+" indicates the axis around which it will pivot. It is purely for schematic placement.

I agree however it is quite confusing.

The LED polarity is correct on both the schematic and the board. The pre-made LED strings you buy from China come with a specific polarity and the "jumpers" as you call them (JST connectors on the board), are correct for those strings.

The error that does (did) exist is the one hamburg3r found, which is that the transistors were incorrectly defined in the Eagle library, and so were facing the wrong way on the board, although their schematic representation was correct. That has been fixed in v1.4.

But as Gerry says, and as you can see in the videos, the lights work either way.
Jun 21, 2014, 09:18 PM
Registered User
Gerry B's Avatar
Sorry about that Luke, I should have looked closer.

I had the Beaver out for a couple more flights today...I have to get on those lights, everyone keeps asking when I will add lights.
Jun 22, 2014, 01:20 AM
Dave the Rave
dmccormick001's Avatar
Well I'd sure like for somebody to explain to us why this circuit works the same way even with the transistors turned the other way. That goes against everything I think I know about it, and against the experience I've had wiring up similar circuits. I've actually gotten transistors in "backwards" before, and had to pull them out and reverse them to get the circuit working. I just don't understand how the transistors can conduct in reverse and not be damaged.
Jun 22, 2014, 12:35 PM
Registered User
LukeZ's Avatar
Thread OP
It's an interesting question and one I have searched the web for already, mostly in vain. What I have found is that truly understanding the physics of transistors is not as simple as I first thought.

However: since there are literally only about two people on earth who have the incorrect board other than myself, and since the new version has been fixed, and since the discussion of transistor theory is a bit off-topic from this thread, I'd suggest maybe we can pursue reverse transistor current in a new thread, and focus this one solely on the Open Source Lights project.
Jun 29, 2014, 08:48 AM
Registered User
I have some questions.

I want to make your program fit to ATMega32U4 and AT90USB1286 used in Teensy 2.0 and Teensy++ 2.0. But I will create my own hardware only with this controllers on it.

Can I use every pin to read the radio signals or is the pin change interrupt function needed? Or is any other alternate pin function needed?

How do you messure the pulse time?

Sorry for all the questions, but I'm normaly using Atmel Studio for programming. Arduino IDE is something new for me and there are many things happening in background I can't see.

I can post a link to our german forum when the hardware is ready to use. But this will need a couple weeks, maybe longer.
Jun 29, 2014, 02:16 PM
Registered User
LukeZ's Avatar
Thread OP
Hi Yoshi,

Sorry I don't have a lot of info to give you specific to Atmel.

The way we are reading the radio channels is with the Arduino PulseIn command. On the Arduino it can be used on any input pin, it doesn't require interrupts. It is entirely a software routine that just waits for the pin to change states.

It is a crude arrangement and if you had lots of channels to read, or lots of other interrupts, it would not work. I have another project where I read 8 channels and PulseIn simply didn't work, it takes too much time. But here we are only reading 3 channels and turning some lights on an off, so we can get away with it.

I'm sure there are similar functions available for the ATMega chips if you search. You could easily replace PulseIn with something else and use the rest of the code as is.

By the way, all the source code for the core Arduino functions are freely available. Here is the source for PulseIn, maybe it will help you:

  wiring_pulse.c - pulseIn() function
  Part of Arduino -

  Copyright (c) 2005-2006 David A. Mellis

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General
  Public License along with this library; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place, Suite 330,
  Boston, MA  02111-1307  USA

  $Id: wiring.c 248 2007-02-03 15:36:30Z mellis $

#include "wiring_private.h"
#include "pins_arduino.h"

/* Measures the length (in microseconds) of a pulse on the pin; state is HIGH
 * or LOW, the type of pulse to measure.  Works on pulses from 2-3 microseconds
 * to 3 minutes in length, but must be called at least a few dozen microseconds
 * before the start of the pulse. */
unsigned long pulseIn(uint8_t pin, uint8_t state, unsigned long timeout)
	// cache the port and bit of the pin in order to speed up the
	// pulse width measuring loop and achieve finer resolution.  calling
	// digitalRead() instead yields much coarser resolution.
	uint8_t bit = digitalPinToBitMask(pin);
	uint8_t port = digitalPinToPort(pin);
	uint8_t stateMask = (state ? bit : 0);
	unsigned long width = 0; // keep initialization out of time critical area
	// convert the timeout from microseconds to a number of times through
	// the initial loop; it takes 16 clock cycles per iteration.
	unsigned long numloops = 0;
	unsigned long maxloops = microsecondsToClockCycles(timeout) / 16;
	// wait for any previous pulse to end
	while ((*portInputRegister(port) & bit) == stateMask)
		if (numloops++ == maxloops)
			return 0;
	// wait for the pulse to start
	while ((*portInputRegister(port) & bit) != stateMask)
		if (numloops++ == maxloops)
			return 0;
	// wait for the pulse to stop
	while ((*portInputRegister(port) & bit) == stateMask) {
		if (numloops++ == maxloops)
			return 0;

	// convert the reading to microseconds. The loop has been determined
	// to be 20 clock cycles long and have about 16 clocks between the edge
	// and the start of the loop. There will be some error introduced by
	// the interrupt handlers.
	return clockCyclesToMicroseconds(width * 21 + 16); 
Jun 30, 2014, 12:01 AM
Registered User
That's syntax I can understand.


This code will slow down the whole program. Sure it won't work with eight channels. While the code is waiting for one channel the others aren't observed.

Maybe I write my own function with using interrupts. That should work much better.

I know that all code in Arduino IDE is free available. My problem is to see the diffence between Arduino code and user written code. Is the code source Arduino or another user. In Atmel Studio it's easy to see. You have to include all the .h and .c files from forrein code. Arduino IDE is doing this in background.
Jun 30, 2014, 03:43 PM
Registered User
LukeZ's Avatar
Thread OP
You are correct, much of the Arduino functionality is abstracted behind a curtain. This makes it easy for beginners to get started without having to worry about complex coding. But for advanced users, you can always look under the hood.

The nice thing about Arduino is the vast number of libraries already written and available. Here is one for reading RC receiver pulses that uses pin change interrupts: Arduino Playground - Read Receiver.

There are others if you search. Perhaps one of them will give you some code you can use in your own application.
Jun 30, 2014, 08:39 PM
Registered User
That's helpful. This code isn't perfect for my application, but I can modify it. It will save a lot of work and time.

Thanks, one more.

I don't like Arduino IDE but I have to use it. Only with Arduino IDE some more can use our hardware to create own applications. Using Atmel Studio would be too complicated.

An own programming executive running on windows would be nice. Maybe one of our programmers could do this later.

I'm planing the hardware using an AT90USB1286 in this moment. It will have up to 32 switching channels. I think that should be enough for scale boats or scale trucks and any other larger application. If it's possible, it should read up to 8 RC-channels.

A smaler version should also be possible by using an ATMegs32U4. Then it will have up to 16 switching channels and read up to 4 RC-channels, maybe more.

A version for lager currents would also be possible. For switching motors or other things. And maybe speed controled by PWM. We will see.
Jun 30, 2014, 09:03 PM
Registered User
LukeZ's Avatar
Thread OP
If you want a robust hardware implementation to read 8 channels of RC, you may look at what the APM team has done with their PPM Encoder. They use a standalone 32u4 chip to read 8 channels of incoming PWM and it outputs a single PPM stream for use by the main processor. This requires two processors on the board of course...

They have a standalone version based on the Atmega 328P, firmware is quite similar.

Note they are not using Arduino to program these. The code may be useful to you, it is very robust, but if you wanted the end user to modify the code in Arduino, you would have to do what APM does, and have two processors on your board - one for the encoder, and the other a standard Arduino.

APM documentation is horrendous, so you will have to do some searching to find the latest versions of the code.
Jun 30, 2014, 09:10 PM
Flying Wood For Fun
irun4fundotca's Avatar
this will handle the current for large lights
30V or 6.5A
Sep 18, 2014, 10:11 AM
Registered User
4x4_RC_Pit's Avatar goes OSL

Hi Luke,

my name is peter, from germany. thank you for developing this very nice project and for sharing it with us. dreams come true !

i posted some informations in our german forum and found some rc-folks who wanted to start a test with your hard- and software. so i ordered few boards from OSH and the parts needed from digikey. Parcel reached my letterbox in 3 days with UPS, very fast.
First of all, we are now starting to solder the boards and by the way we learn, how your software works and what the ideas are. later i'll write another reply here when we have the first results.

I have some minor informations for you, we hope they are helpful:
- the holes for the FTDI-Pins are not lined up, maybe OSH can fix this
- the holes for the LED's (green/red) are too small. maybe they can use "snap-in-plugs"
- the board itself is kind of "gold platet", looks good, but hard to solder. better use a tin-coated version; you may need a special "solder forming flux" for soldering gold. it's enough to drive a "solder rookie" mad

so let's see whats coming next. we are working on it and i post again when we have news for you. thank you again for doing this very good work for us !

peter, a happy man
Sep 18, 2014, 12:52 PM
Registered User
LukeZ's Avatar
Thread OP
Hi Peter! Thanks for posting here. I was able to find your thread by searching but of course I can understand very little even with Google Translate. Thankfully your English is good, and I will be happy to answer any questions you have in this forum.

I recently ordered a few boards from OSH but I haven't soldered them yet. I just wanted to check the layout. So I can confirm a few things you say:

1) The zig-zag (uneven) pattern of the FTDI holes is intentional. Spark Fun developed this idea and called it a "lock" pattern. The header will still fit in the holes, but since they are not lined up, there will be some tension on the header. This will help the header stay in place while you solder it.

2) I just checked my LED headers and you're right, the holes on the board are just a little bit too small. I can still get the header most of the way in if I force it, probably with solder it would stay in place, but not ideal. The side-entry fit better than the vertical. The holes are correctly defined in the files, so this is an OSH problem. But I can enlarge them a little bit to accommodate. I'll let you know when I've posted the updated files.

3) I have not tried to solder these boards yet so I can't speak to how easy it might be. What kind of solder are you using, standard 60/40?

I will try my hand at soldering one to see how it goes. The old BatchPCB ones (green) were very easy to solder I remember.

In your thread people mention the cost of ordering these boards from the US and then having them imported into Germany. If you can find a fabrication company in Germany you are free to provide them with the Eagle files. In other words, you don't necessarily have to buy from OSH Park.

Welcome to RCGroups!

Quick Reply

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Arduino Nav Light Controller chuck99z28 DIY Electronics 65 Mar 23, 2019 06:25 PM
Discussion Linux Based Open Source Control System (OSRC) Gizmoman31 UAV - Unmanned Aerial Vehicles 10 Mar 18, 2012 11:26 AM
Idea Linux Based Open Source Control System (OSRC) Gizmoman31 Aerial Photography 9 Mar 18, 2012 11:25 AM
Question Any open source ARM based multi roter heli? ctrl Multirotor Drone Talk 7 Jul 20, 2011 05:44 AM