Show Posts
Pages: [1] 2 3
1  Development / Other Software Development / Re: Library "... does not define a type" on: November 28, 2013, 02:15:49 pm
I've done circular deps before and been just fine, but removing them fixes this... C++...
2  Development / Other Software Development / Re: Library "... does not define a type" on: November 28, 2013, 03:20:09 am
Thanks for the reply, but I don't think that's it; the errors aren't the same, and, as I stated, Line 59 throws no errors, even with 58 commented. Why would Time work and Date not?
3  Development / Other Software Development / Library "... does not define a type" on: November 27, 2013, 05:59:41 pm
I've been working on my own time and date library recently. I am just about finished, but I've hit a snag that I just can't figure out. I'm getting a "... does not define a type" and I, obviously, have no idea why. Here's a link to the project GitHub, to keep the post small: https://github.com/Matchlighter/Time The error is occurring on line 58 of DateTime.h, saying that "'Date' does not define a type". Line 59, does not have a problem, even though Time.h and Date.h are the same syntactically. What am I doing wrong?

Thanks!
ML
4  Using Arduino / Networking, Protocols, and Devices / Re: WiFly Solid Green Block on: June 29, 2013, 04:27:47 pm
Yup, forgot to do that, sorry. See OP.
5  Using Arduino / Networking, Protocols, and Devices / WiFly Solid Green Block on: June 29, 2013, 02:07:59 pm
I am having an issue with my project involving my WiFly. After a little while, the green light stops blinks and just stays on (which apparently means that it has an active TCP connection). When this happens, I have to reset the Arduino in order to perform any more communications with the WiFly. I discovered an old post (http://forum.arduino.cc/index.php?topic=50042.0), but restarting the browser doesn't help (as it did in his/her case), and he/she doesn't see fit to share the final solution.

I did find one thing that is interesting: when I open DD-WRT on my router, I find that the WiFly has an active UDP connection to 255.255.255.255 on port 55555 that has a status of 'UNREPLIED' and a renewing timeout. EDIT: However, this appears to be open even when things are working.

(Hopefully) needless to say, I have Googled the problem, but haven't found anything. Has anybody encountered this before and found the solution?

EDIT: Here's the code. I've cleaned it up a little for the post, but all the WiFly stuff is present.

Code:
#include <Roomba.h>
#include <SPI.h>
#include "WiFly.h"
#include "TwitterWiFly.h"
#include "Credentials.h"

Twitter twitter(twitter_oAuth);

Server server(80);

#define MinutesBetweenConnectionTries 5 //Time to wait between connection re-atempts, in minutes

void setup() {
  WiFly.begin(); //Initialize the WiFly
  while (!TryWiFly()) {
    delay(MinutesBetweenConnectionTries*60000); //If the connection failed, wait minutes defined and try again
  }
  randomSeed(analogRead(0)); //Make things really random
  server.begin();
  pinMode(8, OUTPUT);
}

uint8_t buf[52];
void loop(){
  bool ret = roomba.getSensors(3, buf, 10); //roomba.pollSensors(buf, 52);

  if (ret) { //ret is true when the checksum is correct

      //23,24/25,26
    battery_Current_mAh = buf[7]+256*buf[6];
    battery_Total_mAh = buf[9]+256*buf[8] | 0b00000001;
    //if (battery_Total_mAh == 0) {
    // battery_Total_mAh=1;
    //}; //Don't want to try and divide by zero.
    battery_percent = battery_Current_mAh*100/battery_Total_mAh;

  }


  CheckWebServerClients(); //Check for clients to the Webserver
  delay(10); //No need to go faster. Roomba only checks its sensors every 15ms. Going faster will only slow the Roomba down.
}
void CheckWebServerClients() { //Mostly Sample code here
  Client client = server.available();
  if (client) {
    // an http request ends with a blank line
    boolean current_line_is_blank = true;
    String requestString = String("");

    while (client.connected()) {
      if (client.available()) {
        char c = client.read();

        if (requestString.length() < 30) { //read char by char HTTP request
          requestString.concat(c);
        } //store characters to string

        // if we've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so we can send a reply
        if (c == '\n' && current_line_is_blank) {

          if (requestString.indexOf("/SeekDock") > 0) {
            roomba.coverAndDock();
          }
          if (requestString.indexOf("/BeginClean") > 0) {
            roomba.cover();
          }

          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println();

          client.print("<a style=\"color:rgb(");
          long PercentToByte = map(battery_percent,0,100,0,255); //Fancy bit of code to fade the text color like the Roomba's power LED
          client.print(255-PercentToByte);
          client.print(",");
          client.print(PercentToByte);
          client.print(",0)\">");

          client.print("Battery mAh is ");
          client.print(battery_Current_mAh);
          client.print(" of ");
          client.print(battery_Total_mAh);
          client.print(" (");
          client.print(battery_percent);
          client.print("%)");
          //client.println("<br />");
          client.print("</a>");
          client.println("<br />");
          client.print("Charging State: ");
          client.print(ChargeTypes[chargingState]);
          client.println("<br />");

          client.println("<a href=\"/BeginClean\"> Clean </a>");
          client.println("<a href=\"/SeekDock\"> Dock </a>");
          break;
        }
        if (c == '\n') {
          // we're starting a new line
          current_line_is_blank = true;
        }
        else if (c != '\r') {
          // we've gotten a character on the current line
          current_line_is_blank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(100);
    client.stop();
  }
}
6  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: November 01, 2012, 05:00:32 am
I've successfully sampled the same item from TI more than once, they don't seem to check that you are "resampling".  Done the same with Maxim and ON too.  I would suggest that if 30 days has passed on your last TI sample, get a few more.  Then you can have a few more parts to play with and use to eliminate the chance that the TLC itself is the problem.

OK, I've requested a couple today...let's see what happens.

I should say that I have had lots of problems with TLC5940 chips before and burnt out several of them myself.  For a chip with a "serial" interface it is complex and really you should have control from the uP of seven lines -SIN, SCLK, XLAT, BLANK, GSCLK, and DCPRG and VPRG

Yep, controlling it is quite tricky. The TLC library is quite well done though and takes all the work out of it.

I've done it with just three pins on an ATtiny85: http://arduino.cc/forum/index.php/topic,125212.0.html


Did you receive the samples? How'd it go?
7  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 15, 2012, 12:29:05 pm
I've successfully sampled the same item from TI more than once, they don't seem to check that you are "resampling".  Done the same with Maxim and ON too.  I would suggest that if 30 days has passed on your last TI sample, get a few more.  Then you can have a few more parts to play with and use to eliminate the chance that the TLC itself is the problem.

I should say that I have had lots of problems with TLC5940 chips before and burnt out several of them myself.  For a chip with a "serial" interface it is complex and really you should have control from the uP of seven lines -SIN, SCLK, XLAT, BLANK, GSCLK, and DCPRG and VPRG as well because it seems to me that you can't load dot correction data or change the source for dot correction data with these just tied to high and low respectively like the example in Arduino Playground.  Arduino Playground says tie DCPRG to high which means take dot correction information from the DC register but tie VPRG low which means you cannot program the DC register.  But the DC register is not guaranteed to be set to any particular value at startup ("The values in the input shift register, DC register and GS register are unknown just after power on.").  How that even works I have no idea.  The MAX7219 is a breeze to use compared to the TLC5940 but no PWM which makes me sad smiley-sad.

This guy controls the extra two lines in his example and uses it to explicitly set GS data:

http://flipmu.com/files/2011/04/Demystifying-the-TLC5940.pdf
If I remember correctly, the DC register/Dot Correction (DC?) is a different method of limiting current, so I should make sure to set that before using the chip? I suppose I will do as you suggested with more samples. I'll stress test one at 5V for a little longer this time as well - I never had problems with 5V until after the chip burned out, but maybe I didn't go long enough. Be nice if there was a MAX7219 for PWM. I have never used it, but I don't know how anything can be as bad of an experience as the TLC5940...
8  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 14, 2012, 03:38:32 pm
Another possibility is that the chips are getting ESD damage. 
From where? They work fine for a minute. And then spontaneously (or so it seems) stop working. I don't touch the chip or move the bar at all from the time I plug it in to the time that it stops working. And, I could be wrong, but it seems unlikely that a "3rd party" source could knock out two chips.
9  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 13, 2012, 05:55:36 pm
Where did you buy/get the chips from?

Sampled them from Ti.
10  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 12, 2012, 06:16:17 pm
Assuming a (low) 3V forward voltage for the LEDs, that leaves a 3V drop on the output of the 5940.  Iref is setting the output to 20mA so that means the chip is dissipating 3V * 20mA = 60mW per channel.  Even with 10 channels you're only at 600mW worst case, which is well below the 3W the DIP package is rated to handle at 25C.

Overall your use of the chip should not result in them failing.  I have never had a TLC5940 fail when used properly.  So let's look for some secondary things that might be caused unexpected problems:

1.  What is supply the 5V to the TLC5940 and are you using decoupling capacitors?
2.  What is the supply used for the LEDs and what is its current rating?  Is it a switching supply?  Does it have a known minimum load requirement?  Have you measured it while the LEDs are operating?
3.  Have you checked with an ohm meter to ensure you picked your resistors for Iref correctly?

1. I'm using a 5V regulator and decoupling capacitors. (I think I remember the regulator getting warm, but for 12 > 5, that shouldn't be too unusual?)
2. It's a 12V switching mode PSU. Rated for up to 600mA. Got it from https://www.sparkfun.com/products/9442
3. The two resistors total 2k, if that is what you mean. (If not, please explain)

Thanks for your time in helping me!
11  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 12, 2012, 04:09:35 pm
I am getting confusing reports here. Some say that I am within tolerance, and some say I am far out of it.
That is the nature of a free support forum.  You sometimes get people answering questions with only bits of understanding.  Most people do not understand how the TLC5940 works and give (sometimes very) bad advice.

Should I just use a 100R resistor between the TLC and the LEDs?
Absolutely not.  That's what the Iref pin does, it sets the current limit.

The TLC5940 is a constant current source.  It will act like a resistor to limit or allow current to flow, based on the Iref pin.  There is a forumla that is used to determine the current based on an internal voltage reference and the resistor being used.

The 5940 does NOT provide a voltage on its output pins.  So your voltage supply must be large enough to drop the forward voltage of all of the LEDs connected to a channel AND leave some small voltage drop for the output of the 5940.  Otherwise, it will not be able to limit current correctly.

I am not sure I understand how you are wiring up your LEDs.  Could you please provide a diagram of how your LEDs are connected to the TLC5940 and what resistor value you are using for Iref?

Here.
http://i.imgur.com/PuIJf.jpg
12  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 11, 2012, 07:16:24 pm
You do not need to get the transistors, if you are driving the light bars at 12V at 20mA, you should be fine as long as the light bars are made up of 4 or 5 leds, your voltage drop should be enough for the tlc5940 to handle. 
So basically you are saying that 2V per channel is too much? That is not enough to drive a 4th LED. Should I just use a 100R resistor between the TLC and the LEDs?
13  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 11, 2012, 10:34:19 am
If the chip is not getting hot then what about the power supply you are driving it from. It could be that this is shutting down. Make sure the ground of this supply is connected to th ground of the TLC chip and that that is connected to the arduino ground.
I think I can rule that out. I have taken the chips and put them back in a breadboard design (that worked before) and they exhibit the same behavior.

I am getting confusing reports here. Some say that I am within tolerance, and some say I am far out of it. What is the case here? Should I just invest in some PNP transistors and resistors to drive the LEDs?
14  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: October 11, 2012, 03:02:41 am
Again, sorry for the belated post. *adds direct bookmark*

I am only running the LED clusters at 12V @ 20mA.

How are you setting the current and what voltage are the LED clusters dropping, off that 12V?

It's a TLC5940, you set the current via a resistor on the TLC5940 itself and hook the cathodes of the displays to the TLC5940.  If you are using a matrix you have to control the top side of the matrix as well using PNP/P-channel transistors or MIC5891 or whatever.  If you are just controlling 16 individual LEDs you just connect the anode to +V.

"I am only running the LED clusters at 12V @ 20mA"

The resistor sets channel maximum current, not "cluster" current.  There are 16 channels.  16 channels @ 20mA @ 100% PWM = 320mA.  Free air maximum output current for the package is 130mA, supposedly.  I am not good at reading these parts of the specs sheets, can someone take a second look at this?

http://www.ti.com/lit/ds/symlink/tlc5940.pdf

But you say it is not getting hot.  Mine were definitely  getting hot while I abused them.

By 'cluster' I mean 3 LEDs in sequence. So +12V -> LED -> LED -> LED -> TLC5940. This is essentially the same as one LED, right?

Yes, quite enough.  The absolute maximum settings is 6v.  There is a table that says "Absolute Maximum Settings".
That's for VCC and not for the chip's outputs.  The outputs are rated to 18V.

Ok, that's what I thought. This is strange. Is it possible I just got a bad sample?
15  Using Arduino / LEDs and Multiplexing / Re: TLC5940 Dropped Output on: August 14, 2012, 11:39:27 pm
Sorry I haven't followed my own thread here. I expect to get email updates... Anyway, each LED is 3.2-3.6v, so together that is 9.6-10.8v. Is that enough for the DIP version of the chip to be overheating? Also, if I remember correctly, I don't remember the chip being hot. Nor do I remember running more than one cluster at a time when the chips stopped working. However, I am probably wrong. I guess it's time to break out the transistors and external resistors again...

Ethan

P.S. Thanks for the link. I will have to look at it more in depth when I get some time.
Pages: [1] 2 3