Recent Posts

Pages: [1] 2 3 ... 10
I have LED strip of 300 pixels, and I'm sending data (only commands, not pixel-by-pixel) through the serial to an Uno, however when I try to use more pixels (requiring more memory), I get inaccuracies in the serial communication. If I lower the number of LEDs, I get more and more stable communication. So it is perfectly stable when the compiler says "leaving 1634 bytes for local variables" (20 LEDs), but when using 80 LEDs the free memory is at 1454 (so 70% of all memory) it gets unstable, meaning that the commands mostly get through, however most of the time with wrong arguments, and sometimes it gets it right. Higher LED counts lower the accuracy.

Do you have any idea why is this happening? Am I using maybe serial incorrectly? I'm using the serial command library (, and the FastLED library.

Code: [Select]
#include <FastLED.h>
#include <SerialCommand.h>

#define LED_PIN     6
#define BRIGHTNESS  255
#define LED_TYPE    WS2812B
#define NUM_LEDS    150


SerialCommand sCmd;

uint16_t noiseParam[8];

void setup() {
//  delay(3000);
  FastLED.setCorrection( CRGB( 255, 115, 70) );
  FastLED.setDither( 0 );

  while (!Serial) ;

  sCmd.addCommand("BRI", cBRI);             //fill solid hsv

  sCmd.addCommand("FSH", cFSH);             //fill solid hsv
  sCmd.addCommand("FGH", cFGH);             //fill gradient hsv



void loop() {


void cFSH() {
  int argInt[3];
  char *arg;

  for (byte i = 0; i < 3; i++) {
    arg =;
    if (arg != NULL) {
      argInt[i] = atoi(arg);    // Converts a char string to an integer
    fill_solid(leds, NUM_LEDS, CHSV(argInt[0], argInt[1], argInt[2]));
    Serial.print(F("fill solid hue "));
    Serial.print(argInt[0]); Serial.print(F(" "));
    Serial.print(argInt[1]); Serial.print(F(" "));

void cFGH() {
  int argInt[2];
  char *arg;

  for (byte i = 0; i < 2; i++) {
    arg =;
    if (arg != NULL) {
      argInt[i] = atoi(arg);    // Converts a char string to an integer

  fill_gradient (leds, 0, CHSV(argInt[0], 255, 255), NUM_LEDS - 1, CHSV(argInt[1], 255, 255), SHORTEST_HUES);
  Serial.print(F("fill gradient hue "));
  Serial.print(F(" --> "));

void cBRI() {
  int argInt;
  char *arg;

  arg =;
  if (arg != NULL) {
    argInt = atoi(arg);    // Converts a char string to an integer


  Serial.print(F("Brightness: "));

void unrecognized(const char *command) {
Hardware / Re: WatchDog e reset inaspetta...
Last post by steve-cr - Today at 12:59 pm
... pericoloso e sconsigliato ... basta un errore di programmazione che mette in OUTPUT ed HIGH uno di quei pin e ... lo bruci (va in corto il +Vcc con la massa attrverso il pin).

Sempre meglio una resistenza ... 4.7K va benissimo e eviti danni in caso di grossolani errori.

Sono d'accordo con te. Ma davo per scontato che mettere in OUTPUT e poi in HIGH una porta NON è solo un grossolano errore di programmazione: c'è la aggravante del dolo !  :)
Project Guidance / Re: Satellite tracking
Last post by TurtleForGaming - Today at 12:58 pm
Am I understanding you right?  You are planning to send the position of a satellite from a PC to the Arduino and  then use the Arduino to slave an Aerial sitting on top of your little mechanism controlled by motors so that it points to the satellite..

When to turn it ON, how do you know what az/el the aerial is pointed in?

Is the PC software going to give absolute angles of az/el?
Which means you need some sort of feedback from the actuator so it knows where it is.

Is the PC software sending HOW much to move the az/el?
Which means you need feedback to make sure the actuators do not try and go passed their mechanical stops.

Are you going to make the aerial do a scan to find the satellite?
If you want to use a magnetometer to setup initial conditions, you will need to take into account the difference between celestial north and mag north.

Tom... :)
Orbitron is sending absolute coordinates and that's the question WHAT sensor does I need to use to know the azimuth and Elevation that I'm pointing (like 3axis compass). And why would I need to scan to find the satellite if the computer is giving me it's position

And why you would want to link up a GPS, I do not know, these antenna rotator setups are normally used at a fixed location.
That's why i mention portable

Unless the directional antenna is very large (for large gain) then you would be far better off using a high gain omni, they dont need tracking at all, no GPS, no Compass, no tracking software or PC controller needed, highly portable too. 

The size of directional antenna that would be a significant improvement over a good omni is going to need some seriously powerful motors to drive it, and making this sort of setup 'portable' is not going to be that easy. 
That's not the point I want to try to make this as a project I don't care if it fail I just want to try the challenge
Displays / Re: LCD 1602A won't display Da...
Last post by groundFungus - Today at 12:58 pm
Code: [Select]
LiquidCrystal lcd(2,3,4,5,6,7);
rpt007 asked.
1. Did you check the connections if they match with the constructor?
Looking at the Fritz, the LCD is wired
Code: [Select]
LiquidCrystal lcd(7,6,5,4,3,2);

What about this?
Better, but, as far as I know, none of the LiquidCrystal libraries for the 1602 displays have a display() method and lcd.println() is not supported.

slowsteps are not the question. The speed of the steps are not the question, but how big these steps are. That is why I would like to know how to do microsteps with this hardware
there are natural steps.  these are the balance of magnetic forces and are a fundamental psychical world balance.
There are contrived steps,  a balance of created magnetic forces.  ie: microsteps.

When you remove power, the contrived steps vanish and the natural steps balance the rotor in the magnetic fields.
This will effectively eliminate any quantity of assumed contrived steps.  This requires a re-zero after the loss of power.

The concept of micro-stepping is to make the lower speeds a smoother motion instead of the cogging you would get with a stepper.

As you slow the motor by creating long pauses between micro-steps, you may run the risk that the forces on the driven thing are stronger than the forces of the contrived steps.   In most applications, there is momentum and part of the force is the flywheel effect of the device being driven (load) and rotor.

What you are essentially doing is removing the flywheel effect.

That said, whatever you are driving may be well under the forces needed to rotate, so, it might be a perfectly acceptable application of the motor.

Just wanted to point this bit out because as you slow things down, you are moving from a function that most are familiar with into a realm of the un-familiar.  And as we all know, odd things just seem to happen for no reason. If you just loose any movement when you start to micro-step, you might look at the forces generated by micro-steps as compared to forces needed to drive your thing.  It is a function of near magnetic fields (natural steps) where the forces are highest and near-by magnetic fields where the forces drop drastically.

if your movement seems to get smoother, then as you try to slow it down more, it just starts cogging and gets more jumpy,  move back towards full steps.  Full steps are the strongest power from the motor, then half, then quarter, you get the idea.

It is interesting to watch the thread and as it has developed, your actual goal has come to light.
paraphrasing, you are looking to rotate in a near-imperceptible motion, breaking down the rotation of the drive into as small a rotation as possible.

Please keep us informed as your testing progresses.

Deutsch / Re: Netzteilfrage
Last post by Heislflo - Today at 12:56 pm
Also 2,8 ohm pro Wicklung
Programming Questions / Re: Nano ATMega168 Compilation...
Last post by AWOL - Today at 12:56 pm
Code: [Select]
DHT dht(DHTPIN, DHTTYPE); DHT is the case, dht is the object.
Project Guidance / Re: Satellite tracking
Last post by srnet - Today at 12:53 pm
Like what the best sensor for an compass, etc ...

Well I was planing to just send the Az/El directly to an arduino mega with a software like orbitron.
For precision as long as I can get a clear signal comming from the satellite It's ok.
And the rest Is a lot of good question that I don't really understand

Unless the directional antenna is very large (for large gain) then you would be far better off using a high gain omni, they dont need tracking at all, no GPS, no Compass, no tracking software or PC controller needed, highly portable too.  

The size of directional antenna that would be a significant improvement over a good omni is going to need some seriously powerful motors to drive it, and making this sort of setup 'portable' is not going to be that easy.  
Making some fixes my script start, but 2.3.0 version does not fix the issue
Project Guidance / Re: Weather forecast for heati...
Last post by MarkoY - Today at 12:49 pm
Finally i had some time to look at this again. Winter is coming and working system would be nice :D

After some months of ocassionally manually resetting the device i noticed it wasn't only timeClient getting stuck on updates, it just happens to be first on line when shit happens. After converting this to use  NTPClient it was evident the same might happen after any of http request the device makes.

Timeout was indeed kind of the problem

The "readStringUntil()" method has a timeout which may be too long, especially if it does not find the search character.

The real problem as i understand lies in WiFiClient or common misunderstanding (client.connected() which apparently only knows there is unread data in buffer or has been a connection. As well the connection might be lost or possibly server just doesn't send anything back so buffer stays empty and the code is sitting there forever waiting the never arriving data  :o

Fixed all the requests in my code and libraries used in this system with few lines, the first one replaced with latter:

Code: [Select]

while(client.connected()) {
   while((size = client.available()) > 0) {
      line = client.readStringUntil('\n');
      // example:
      // date: Thu, 19 Nov 2015 20:25:40 GMT

Code: [Select]

const int kNetworkTimeout = 30*1000;
  unsigned long timeoutStart = millis();
while ((client.connected() || client.available()) && ((millis() - timeoutStart) < kNetworkTimeout)){
    if((size = client.available()) > 0) {
      line = client.readStringUntil('\n');
timeoutStart = millis(); // reset the timeout counter
      // example:
      // date: Thu, 19 Nov 2015 20:25:40 GMT

No stuck devices after adding the timeouts so all Ok again. Seems strange though cause many other codes i have looked at has the same exact issue. Ofcourse with rock solid connection and servers there's no problem..
Pages: [1] 2 3 ... 10