So I thought about using SoftPWM with the TLC5940 library to try and control more LEDS from the unused arduino pins but it seems SoftPWM and the TLC5940 library do not play nice with eachother. Is there any way to use the additional arduino pins to control additional 20ma RGB LEDs or should I give up on that idea?

You have to use interrupts, there are a number of ways. Make sure your hall sensor can switch fast enough too

http://www.societyofrobots.com/robotforum/index.php?topic=14973.0

German but you can use google translate and code is still the same
http://saduino.ch/mechatronic/index.php?article=umdrehungsgeschwindigkeit-von-stirling-motor-mit-hallsensor-messen

This code also depends on whether you have a latch sensor or not.

Thanks mike for your reply. The LEDS are common anode so you are right, it's a 4 pin LED that can only be connected in parallel. Can I place them in parallel with a resistor for each and just have no resistor to ground on Rref?

I have a single tlc5940 and plan to use 8 RGB Leds with it. 4 on their own channels and 4 in series on a single channel. Am I right in thinking this is OK to do and that I can use the same R(I ref) resistor with or without the LEDs in series?

@pYro_65, Yes ofcourse you are right, my mistake there.

@PaulS Well this isn't actually part of any code, it's just me thinking out loud with examples of enum switch cases from the internet. I'm not sure how complete code will help but nonetheless here is a complete sketch I wrote based on them as an example where enum instances are not hardcoded:

Code:

String content = "";
char character;
enum Color { UNDEF, RED, ORANGE, YELLOW, GREEN,  BLUE, PURPLE };
Color clr;

void setup(){
}

void loop()
{
 
  while(Serial.available()) {
      character = Serial.read();
      content.concat(character);
  }

  if (content != "") {
    clr=content;
    switch (clr)
    {
      case UNDEF: break;
      case RED: clr = BLUE; break;
      case BLUE: clr = YELLOW; break;   
      // etc
      default: break;
    }
  }
}

In this example if it reads "RED" on the serial it changes "clr" to BLUE. That is if it compiled.

is the use of an enum switch-case pointless in anything but hardcoded use?

Perhaps I'm not very good with google search but I cannot figure out how to use enum with switch-case. The examples I've seen (including on this forum) look like this:

Code:

enum Color { UNDEF, RED, ORANGE, YELLOW, GREEN,  BLUE, PURPLE };

void setup()
{
  Color clr = RED;
 
  switch (clr)
  {
    case UNDEF: break;
    case RED: clr = BLUE; break;
    case BLUE: clr = YELLOW; break;   
    // etc
    default: break;
  }
}

void loop()
{
}

However these examples do not seem practical since the enum instance is always hardcoded in them.
Is there something like Enum.Parse in the arduino IDE? since code like this will throw a compiler error

at Color clr = arg:

Code:

char *arg;
arg = //*Some output from some function*;
enum Color { UNDEF, RED, ORANGE, YELLOW, GREEN,  BLUE, PURPLE };
Color clr = arg;
...

which obviously throws the error

Code:

cannot convert "char*" to "clr" in initialization

Is there a special trick I can use similar to Enum.Parse in C#? or am I better off just using "if, else if"?

Hi dc.
I have, it's ~12V. The pc817 has the following max ratings on the output:

Collector-emitter voltage, V_CEO: 35 V
Emitter-collector voltage, V_ECO: 6V

I have successfully replaced a push button with an optoisolator for arduino control of an unknown circuit. Everything works fine so far but I wish to know if I might run in to trouble later. I measured the current across the switch of the unknown circuit as 1.6mA. I'm using a Sharp pc817 optoisolator which has a CTR of 50% and a max current of 50mA. on one side of the optocoupler (LED Side) is an arduino output pin and a 150 Ohm resistor to limit current. On the other side (transistor side) I put no resistor at all. is this OK? I assumed that the current will be limited to 1.6mA so there was no need for one but I'm not sure if it is safe.

did you see exactly this when you did rfcomm?:

Code:

rfcomm0: xx:xx:xx:xx:xx:xx channel 1 clean

(without xx:xx... of course ) Make sure you didn't get something else. It would be nice to see a complete copy of your terminal output while you are doing these things too. It's difficult to diagnose a problem without knowing what exactly happened.

Do

Code:

$ sdptool browse local

You should find something like this in the output

Code:

Service Name: Serial Port
Service Description: COM Port
Service Provider: BlueZ
[...]
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
  Channel: 1

then do

sdptool records xx:xx:xx:xx:xx:xx

(with your BT shield address)
you should see something like

Code:

Service Name: SPP
[...]
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1

make sure all the channel numbers match each other and your rfcomm.config file. Also make sure your cat and echo commands output file name match the actual rfcomm. e.g make sure it isn't >/dev/rfcomm0 when your shield is on rfcomm1.

If that still doesn't work then I've ran out of ideas, maybe your bluetooth shield is faulty.

OK lets do things manually, do not rely on blueman. remove any pairing there. Then do
 
   

Code:

    $ sudo sdptool add SP
    $ sudo /etc/init.d/bluetooth restart
    $ sudo rfcomm bind all
    $ rfcomm

you should see

Code:

rfcomm0: xx:xx:xx:xx:xx:xx channel 1 clean

then

Code:

cat /dev/rfcomm0

open another terminal and do

Code:

echo Hi > /dev/rfcomm0

let me know if you don't get a response in the first terminal.

Do

Code:

cat /etc/bluetooth/rfcomm.conf

and post the output.

My one looks something like this:

Code:

rfcomm0 {
         # Automatically bind the device at startup
         bind yes;
         # Bluetooth address of the device
         device xx:xx:xx:xx:xx:xx;
         # RFCOMM channel for the connection
         channel 1;
         # Description of the connection
         comment "Arduino";
}

again where "xx:xx:xx:xx:xx:xx" would be the address for your particular bluetooth shield.

I don't know what the problem could be, far too many things could be wrong and without being able to see how your linux box or shield is set up it's hard to say. when you type "rfcomm" at the command line does it show your bluetooth device?

Code:

rfcomm0: xx:xx:xx:xx:xx:xx channel 1 closed

where "xx:xx:xx:xx:xx:xx" is the address of your particular bluetooth shield?

Thanks dc42. I think I understand the concept of a triac now. The isolated circuit would need to drop below threshold voltage on the  main terminals of the triac otherwise it will remain on indefinitely. This happens automatically on an AC circuit at a given frequency but not on a DC circuit. Darlington pair opto-isolators it is then. Thanks again for your help.

I'm currently looking to buy some opto-isolators, however, I see a lot of different types and I'm not sure what the best choice is. The types I've seen are Regular (no details), Darlington pair, TRIAC, and Zero Cross TRIAC.

The first two I think I understand

Regular Opto-isolator= LED inside turns isolated photo transistor on
Darlington Pair Opto-isolator= Same as regular but with higher gain (therefore higher current transfer ratio)

It's the second two which I'm not so sure about
TRIAC opto-isolator= Same as regular but is bidirectional for AC circuits
Zero Cross TRIAC optoisolator= Zero Cross detection? good for AC dimmers.

I don't understand how the ZCD TRIAC optoisolator works. Is a TRIAC opto-isolator always more advantageous than a regular optoisolator. For example can a MOC3062 (pictured)



 be used as a regular DC optoisolator to turn an isolated LED on off with a PWM signal, or would it not work at all since there is no actual zero crossing?

Thanks CrossRoads for the insightful read about V.reg damage. Thanks everyone for the advice regarding the battery and daisy chaining regulators too. It is a standalone Atmega328p project as some of you may have guessed. I currently use a power jack but the the thought of using a 9V battery crossed my mind since I have some spare rechargable 9Vs but I will look into the better suited alternative batteries.