Recent Posts

Pages: [1] 2 3 ... 10
Hi everyone
I have a basic question
Can you tell me if any function is available in remote XY that allows us to have a notification on android phone like ringing or vibration or anything else

I'm going to make an anti robbery system and I want a notification on my phone when there is a person in place.

Project Guidance / Re: Solutions to getting a lot...
Last post by Wawa - Today at 05:27 am
Two PCA9685 breakout boards (Adafruit, ebay).
I2C (two Arduino pins) and hardware PWM.
Sensors / Re: ProSense PTD25-20-0200H pr...
Last post by marinek9 - Today at 05:26 am
250ohm means you're going to use default Aref, and rely on the stability of the Mega's 5volt rail.
Bad idea.

The Mega has in internal 2.56volt Aref (called in code), which is potentially much better.
That means the sense resistor should be ~125ohm.
That also would eleminate the need for a 5.1volt zener, which is also a bad idea (temp dependent non-linearity).

Wise to use a 10k resistor between sense resistor and Arduino pin (safety), and a 100n cap from Arduino pin to ground.
Let us know if you need a diagram.
I def. would if you could.... 

Programming Questions / Re: Is there really no way to ...
Last post by 232 - Today at 05:22 am
So it works (?) but...
Just for drill, or future reference,look up"passing
An Array to function".
Hi Robin2,  I have tried different ways to try and get your solution to work.  May be it the way the number is writen in the file?  But then what i dont understand is with original code the number displays on Serial monitor, With your solution i dont get any read out except a ? in Serial monotor.  Any advise please

This is in regards to my project that drives 24x individual LED strips using mosfets. I need to use PWM in order to control the brightness of the led strips (yes, each LED strip need it's own Individual PWM control).

Now when I was testing this on an Uno, it was fantastic, the PWM pins ran fine, controlled the mosfet and everything worked as it should. But the Uno doesn't have enough PWM pins. I need 24 PWM pins. I can't really use a Duo or a Mega because even Software PWM can't handle running all these pins in  PWM constantly AND also run my code reliably. So - I need something that offers 24 PWM pins BUT there is a BIT requirement. And this is important - I need a positive PWM line signal, NOT a ground (sink) signal.

I've looked into the TLC5947 which is a 24 PWM LED driver. Great, but it works by controlling the ground lines, NOT the positive line. So essentially the TLC5947 is a chip with 24 PWM Ground connections. Now one of the biggest issues I have with TLC5947 is also that it's not meant for rapid refresh applications - like fast moving "displays" (LED signs) It's meant to be refreshed once in a while (like changing the sign every 5 seconds) The chip does a lot of weird hanky panky when you continuously send data to it 30 times a second. It's just not meant for that application.

When googling, I see a lot of Constant Current Sink solutions. So all the "outputs" are actually varying the connection to ground. The Arduino worked great since it's not sinking the PWM but outputting PWM.
I think an actual schematic would be orders of magnitude better than the photo, and you should attach the current code to the current post as you update it.

MKR1000 / Re: Connect MKR1000 directly t...
Last post by baqwas - Today at 05:15 am
Sorry for not being very helpful here because I am unaware of any MS SQL connector for the board. The convoluted way to solve your predicament would be use an intermediate hop (or traffic cop) with a platform that has the direct connectivity to MS SQL instances and equally communicates to your board via one of the standard protocols (an extra hop, an extra headache may be your comment!).
MKRZero / Re: Transfer data to PC with U...
Last post by ballscrewbob - Today at 05:15 am
Too much of an ambiguous question to answer properly.

You would need to give a LOT more detail as to the project before anyone could give an answer.
In theory anything is possible but in practice its down to things like bottlenecks.
Adding Ethernet may improve things but thats just a wild assumption until you give details.

Any thoughts on how I can pull off external interrupts correctly for the op-amp outputs while maintaining the accuracy of the very first iteration of this project (first code attached)?
You're very close there with the interrupts, it may be getting a bit confusing because you don't want your main code to stop and wait.

You can attach the interrupts in setup() and leave them attached (don't bother with detachInterrupt at all)

You can simplify the ISR routines a bit and have a function which tests if something has happened
Code: [Select]

// Interrupt routines for Gate1 and Gate2
// - simply captures microseconds
void gate1ISR()
  g1T= micros();
void gate2ISR()
  g2T= micros();

// Start timing
// - just zero the gate times
void startTiming()
  g1T= 0;
  g2T= 0;

// get timing info
// returns:
//    0 if nothing seen
//    1 if only gate1 tripped
//    else returns time in microseconds
uint32_t getTiming()
  uint32_t elapsed= 0;
  if( g1T != 0 ){      // if something happened on gate1
    delay( 50 );       // wait long enough for any projectile to have passed
      if( g2T == 0 ){
        elapsed= 1;      // no gate2 time
        elapsed= g2T - g1T;
  return elapsed;

Your shooting() function could be as simple as:
Code: [Select]

// Sensor Reading Function //
void shooting() {
  digitalWrite(greenLedPin, HIGH);
    elapsedT = getTiming();
  }while( elapsedT == 0 );  // wait for something to happen

  if( elapsedT == 1 )
    ... show error
    ... show result

However, this still means the code is 'stuck' in that loop waiting for something to happen which it need not do now that the important timing stuff is done in interrupt.

You could have a main loop() which sequences the operation of the chronograph
the following is a rough example of switching thru a number of modes which might give you food for thought :)

Code: [Select]

enum mode{
mode chronoMode= RESET;

void loop() {
  uint32_t shotTime;

  switch( chronoMode )
  case RESET:  // reset the chrono
    digitalWrite(greenLedPin, HIGH);
    chronoMode= WAITING_SHOT;
  case WAITING_SHOT:  // wait for a shot
    shotTime= getTiming();
    if( shotTime != 0 )
      if( shotTime == 1 )
        chronoMode= SHOW_ERROR;
        chronoMode= SHOW_RESULT;
    if( digitalRead(modeSwitchPin) == HIGH )
       chronoMode= TROUBLESHOOT;

    adjustPot();       // do whatever that troubleshoot thing is
    chronoMode= RESET; // then go back to RESET
  case SHOW_ERROR:
    // show the error...
    // set some sort of timer or test a reset button
    chronoMode= END_DELAY;
    // show the result...
    // set some sort of timer or test a reset button
    chronoMode= END_DELAY;
  case END_DELAY:
    // wait before resetting or something
    // then...
    chronoMode= RESET;


Pages: [1] 2 3 ... 10