Radar de velocidad

Buenas tardes chicos, mi nombre es Bernardo (Chuma) y estoy hace un par de meses explorando el mundo de Arduino.

Con un amigo estamos haciendo sistemas para Countrys, y uno de ellos, es radar de velocidad.

Investigué mucho, hasta que en lo ultimo fui cayendo en el sensor doppler. Hay HB100 y un CDM. Quisimos amplificar la señal, ya que es debil, pero no hubo caso. Hasta que dimos con Limpkin. Me compré el sensor con su amplificador, todo hecho por él.

Pero tengo un problema, que no se si es de software o de hardware. Usando su codigo de ejemplo, dentro de mi casa, parece funcionar, pero con mucho ruido, y a veces le cuesta tomar lectura. La conexion a Arduino es facil, VCC a 5v, GND a GND y FOUT al pin 4, VOUT no porque no tengo un monitor para revisar, o al menos eso entiendo yo.

Suponiendo que el problema era la interferencia, me armé un regulador de 9v a 5v con 7805 y capacitores, para que? Para poder usar un Display LCD, y como arduino no soporta tantos componentes, por las dudas, alimento por fuera.

Asique, Arduino alimentado por bateria de 9v, y el LCD conectado para mostrar las lecturas, del HB100 de limpkin que se alimenta de otra bateria 9v con un regulador. Lo probamos hoy en la calle y las lecturas son erroneas, como que sigue leyendo ruido. Ni acercando la mano reacciona. Pero si vuelvo a casa desde la PC funciona 10 puntos.

Adjunto imagenes de como quedo armado en una caja estanca jajaja, y abajo,la parte del codigo de limpkin donde imprime las lecturas, pero con una modificacion para reflejarlo en el LCD.


#ifdef PYTHON_OUTPUT
  lcd.print(Freq/doppler_div);
#else
  
    //Serial.print(Ttime);
    //lcd.setCursor(0,0);
    //lcd.print(Freq);
    //lcd.setCursor(5,0);
    //lcd.print("Hz");
    lcd.setCursor(0,0);
    lcd.print(Freq/doppler_div);
    //lcd.setCursor(0,1);
    //lcd.print("km/h");
    delay(500);
    lcd.clear();
     #endif
  }
else
  {
  #ifndef PYTHON_OUTPUT
      lcd.setCursor(0,0);
    lcd.print(".");
  #endif
  }

Gracias de antemano, se que el primero va a ser surbyte corrigiendome :wink:

EDIT:
HB100 by limpkin
Sensor Doppler

Display LCD 1602
Especificaciones LCD 16x2

1 Like

Con esas baterias no te va a funcionar.
Busca algo potente tipo un powerBank o usa una LiPO de 7.4V de algunos miles de mAh

Cada vez que alguien pregunta por problemas con baterias de 9V el problema son las baterias de 9V.
Prueba con alguna de GEL de 12V 7Ah o una de 4Ah a ver como se comporta.

Muevo tu hilo a Hardware porque tu hilo no es para proyectos.

surbyte:
Con esas baterias no te va a funcionar.
...
Prueba con alguna de GEL de 12V 7Ah o una de 4Ah a ver como se comporta.

Muevo tu hilo a Hardware porque tu hilo no es para proyectos.

Perfecto, pruebo con algo mas potente. Con una sola puedo alimentar a los 3? (arduino, hb100 y LCD)

Pense que en proyectos estaba bien, gracias por la reubicacion.

Despues comento como me fué

EDIT:
Consegui esta, no es de gel, pero son 12v 7ah

Si claro pero vamos por partes.

Supongo que tu radar tolera 12V? Tendre que buscarlo porque no lo se.

El LCD alimentalo con el Arduino o sino debes poner datos del LCD de su consumo aunque deben ser pocos mA.

Busque HB100 de Lipkin algo que tu debiste haber puesto como link para hacer fáciles las cosas, perdona el regaño pero espero que alguien lo lea y al menos en algun momento se tome como norma hacerlo. Lo dicen las normas del foro que todos deberían leer pero nadie lee o aplica.

Dice que consume 40mA a 5V de modo que alimentalo con el Arduino.
Tanto LCD como tu radar.

Usa la batería y si crees que calienta mucho coloca un step-down regulado a 7V y estará trabajando muy cómodo el simil de 7805

Creo que todo tu problema son las baterías de 9V, con la de gel de 12V directo al arduino deberia andar perfecto y algo mas prolijo seria usar un stepdown para que no caliente el regulador pero hablamos de 40 del radar y 20 del LCD no creo que se muera nadie.
Sumados no llegas a 100mA.
Intenta medir el consumo de todo a ver como se comporta.

surbyte:
Creo que todo tu problema son las baterías de 9V, con la de gel de 12V directo al arduino deberia andar perfecto y algo mas prolijo seria usar un stepdown para que no caliente el regulador pero hablamos de 40 del radar y 20 del LCD no creo que se muera nadie.
Sumados no llegas a 100mA.
Intenta medir el consumo de todo a ver como se comporta.

Habiendo conectado ambos a arduino, recuerdo (creo), que no funcionaba bien el LCD, y para no compremeter a los componentes, decidi alimentarlos por separado. Hoy pruebo todo alimentandolo desde la PC, y despues pruebo con la bateria...

Hablando de la bateria, ya tengo un regulador a 5v hecho por mi, 7805 con 2 capacitores....Deberia tolerar algunas pruebas...

Bueno el 7805 externo si no pones un disipador estas igual que el 7805 del Arduino. No cambias nada.

Porque no das datos del LCD? Debe tener algo especial para no funcionar debidamente.
Ya te lo pedi antes, aporta datos de los elementos involucrados. Siempre hazlo asi porque nosotros no estamos en tu mesa de trabajo.

surbyte:
Bueno el 7805 externo si no pones un disipador estas igual que el 7805 del Arduino. No cambias nada.

Bueno pero es una prueba de 2 minutos, es para ver si realmente funciona el hb100 de limpkin

surbyte:
Porque no das datos del LCD? Debe tener algo especial para no funcionar debidamente.
Ya te lo pedi antes, aporta datos de los elementos involucrados. Siempre hazlo asi porque nosotros no estamos en tu mesa de trabajo.

Comparto lo que pude averiguar. Repito, el LCD es para ver las lecturas del HB100, si todo funciona, paso a un 7 segmentos de dos digitos.
Especificaciones de Display LCD 16x2

Y ya que estamos, dejo lo del HB100
Sensor Doppler

EDIT:

Ahi conecte el display el hb100 juntos a Arduino, mediante protoboard. Ahora si lo quiero probar remotamente con la bateria y el regulador....los positivos de ambos cables se pueden juntar en una ficha del positivo del regulador? Lo mismo con la masa. Porque dentro de casa con la PC de escritorio, parece que hay mucho ruido y me da valores hasta 100km/h y solo estoy haciendo unos pasos.

El link del display no funciona pero como te dije, no deberías tener problema.
Yo y todos hemos alimentado LCDs I2C o paralelos desde los 5V de arduino sin problemas y tu sensor LipKin no consume mas de 40mA

Debe haber algun otro problema o tu bateria de 9V esta descargada. por eso no me gustan siempre que las usé en el pasado me hacian eso, las especificaciones dicen que tienen buena capacidad pero al usarlas se desgastan rápido o bien uno no considera el consumo que tiene que es mas del que pueden soportar en el tiempo claro esta.

surbyte:
El link del display no funciona pero como te dije, no deberías tener problema.

Corregido

surbyte:
Yo y todos hemos alimentado LCDs I2C o paralelos desde los 5V de arduino sin problemas y tu sensor LipKin no consume mas de 40mA

A esto me refiero, si puedo empalmar los dos positivos y negativos a este regulador (unos cables van a venir de arduino + LCD, y otros cables del sensor

Disculpá con la insistencia

Veamos posibles conexiones.

SI tu fuente de 5V alimenta todo, entonces

GND de la fuente ira a Arduino a LCD y al Radar
+5V de la fuente ira a +5V de Arduino a Vcc de LCD y a Vcc de Radar

Si alimentas el arduino via VIN o por plug externo, entonces comparte GND entre tufuente de 5V LCD Radar y Arduino y alimenta Radar y LCD con la fuente que has hecho pero el arduino se alimentará digamos si te entiendo bien desde los +12V de la bateria

Tu diras cual es la conexion que usarás.

No se me ocurre como alimentar el LCD y el HB100 despues de Arduino, salvo que puedan compartir el mismo pin (siempre hablando sin protoboard)
Asique, esto es lo que se me ocurre. Via Plug, 12v puede entrar tranquilo a arduino, segun lo que lei en este foro.

Y claro que debes compartir el pin.
No entiendo tu comentario, como pretendes alimentar cosas a una tensión dada si no compartes el pin o los pines. El pin de GND y el de 5V.

Si alimentas Arduino por un lado y sensores por otro solo comparte el GND de las fuentes diferentes.
Si usas la misma fuente, es obvio.

Bueno, actualizo.

Arduino tiene dos pines de GND, asique reparti uno para cada uno (sensor y LCD). Consegui una fuente de 12v 7ah de gel, y estoy alimentando arduino con eso, sin stepdown, solo para probar unos segundos. Pero el cable que alimenta, es de audio, me conto un compañero que trabaja con electronica, que a lo mejor sea el ruido lo que no me deje leer en la calle. Adjunto imagenes.

Este empalme, con una pequeña soldadura en la punta, sale de 5v de arduino para el sensor y el display

Y aca esta el cable armado que sale de la bateria de 12v, que termina en un jack para arduino (un poco largo por cierto)

Sospecho que la NO lectura, debe ser por la alimentacion. Me recomendaron cables "mallados". Lo extraño es que mediante USB desde la PC, al menos lee algo, y con ruido tambien, remotamente con la bateria, NO.

Creo que es la 3ra vez con esta que te hablo del tema GND.

Porque repartis los cables GNDs?
Aunque esto no va a cambiar nada, cablear adecuadamente es importante que se fije en el cerebro.
Porque todo debe ir a un mismo nodo o punto. Por que todo se comporta como un nodo. O sea : si la corriente tiene dos caminos de gnd buscará el camino de menor resistencia, y el otro qué? Por el también va a circular corriente, y abrá una caida de tensión en la pista que conecta este con el mas fácil de circular.
Todo debe llegar a un mismo GND y con un cable de dimensiones relevantes que justamente no provoque esto.

Lo que estas alimentando (radar 40mA y LCD 20mA) no cambia mucho las cosas. 100mA (sumando arduino) no va a hacer que falle. Pero tenelo en cuenta.

El cable de Audio no es tan de audio pero si claro, habitualmente le decimos de Audio. Yo pensé que era uno de esos finos. Ese cable esta bien, es el que usamos todos y es la primera opción que tenes cuando vas a compra algo en Argentina.
Nada que reprocharte con el cable.

Disculpame Surbyte, pero a veces es dificil de entenderte por la manera de escribir. Por eso cuando aca me decis que es la tercera vez que me decis lo de GND, repase tus respuestas y trate de comprender.
Tiene logica lo que decis. Si uso una salida de 5v, deberia tambien sacar una de GND.

Exacto.

Donde esta complicada mi forma de escribir?

Avances...

Bueno, decidi cambiar el codigo de Limpkin, que no usa libreria, hasta donde pude ver...Asique decidi navegar bastante por google y buscar y buscar hasta que di con un codigo sencillo, pero con una libreria que no podia conseguir porque ya no existia la pagina...Me costo un buen rato hasta que lo consegui.

Codigo, con algunas modificaciones:

#include <FreqPeriod.h>
#include <Wire.h>      // libreria de comunicacion por I2C
#include <LCD.h>      // libreria para funciones de LCD
#include <LiquidCrystal_I2C.h>    // libreria para LCD por I2C

LiquidCrystal_I2C lcd (0x27, 2, 1, 0, 4, 5, 6, 7); // DIR, E, RW, RS, D4, D5, D6, D7

double lfrq;
long int pp;

void setup() {
Serial.begin(9600);
  FreqPeriod::begin();
  lcd.setBacklightPin(3,POSITIVE);  // puerto P3 de PCF8574 como positivo
  lcd.setBacklight(HIGH);   // habilita iluminacion posterior de LCD
  lcd.begin(16, 2);     // 16 columnas por 2 lineas para LCD 1602A
  lcd.clear();      // limpia pantalla

  Serial.println("FreqPeriod Library Test");
}

void loop() {
  pp = FreqPeriod::getPeriod();
  if (pp) {
    //Serial.print ("period: ");
    //Serial.print(pp);
    //Serial.print(" 1/16us / frequency: ");

  lfrq = 16000400.0 /pp;
  //Serial.print(lfrq);
  //Serial.print(" Hz ");
  //lcd.setCursor(0,0);
  Serial.print(lfrq/19.49);
  Serial.println( "km/h");
  lcd.print(lfrq/19.49);
  lcd.print( "km/h");
  delay(200);
  lcd.clear();  
}
}

Dejo dos links (GIFS, para ser livianos) donde se ve la prueba que hice aca en casa..

Prueba 1
Bug de la prueba

Lo probe en la calle con la bateria 12v, y no pude leer varias veces porque el LCD no mostraba nada, como que se bugeaba. de 15 autos que pasaron, entre 7 y 8 pudimos tomar la velocidad, el resto, o mostraba solo ruido, o se borraba la pantalla. Será el delay? No encuentro otra manera de limpiar el LCD.

Lo que llamas a stepdown, seria como una fuente multivoltaje? Esto?

La fuente step down que yo menciono es esta. Esa puede ser pero no me convence. Esta si porque la uso y la usa todo el mundo acá y no te da problemas.
Lm2596 Fuente Step-down Dc-dc 1,23-35v 3a Arduino

Respecto del código, con un delay de 200 mseg es lógico queno puedas leer un objeto que se muevo muy rápido. Deberías apuntar a algun objeto del que sepas su velocidad.

Prueba a ver este código si trabaja bien.
Modifica el valor de INTERVALO a 200 si quieres que trabaje como el que posteaste anteriormente.
Me parece que 500 a 1000 son valores mas adecuados.

#include <FreqPeriod.h>
#include <Wire.h>      // libreria de comunicacion por I2C
#include <LCD.h>      // libreria para funciones de LCD
#include <LiquidCrystal_I2C.h>    // libreria para LCD por I2C

#define INTERVALO   500UL  // modifica este valor para cambiar la visualizacion

LiquidCrystal_I2C lcd (0x27, 2, 1, 0, 4, 5, 6, 7); // DIR, E, RW, RS, D4, D5, D6, D7

double lfrq;
long int pp;
unsigned long start;

void setup() {
  Serial.begin(9600);
  FreqPeriod::begin();
  lcd.setBacklightPin(3,POSITIVE);  // puerto P3 de PCF8574 como positivo
  lcd.setBacklight(HIGH);           // habilita iluminacion posterior de LCD
  lcd.begin(16, 2);                 // 16 columnas por 2 lineas para LCD 1602A
  lcd.clear();                      // limpia pantalla

  Serial.println("FreqPeriod Library Test");
}

void loop() {
  char* buffn="";  //Cadena donde almacenaremos el número convertido
  char buffer[20]=" "; //Buffer de la cadena donde se devuelve todo, número formateado y cadena concatenada
  pp = FreqPeriod::getPeriod();
  if (pp) {
      if (millis()-start > INTERVALO) {
          lfrq = 820954.336 /pp;
          // Serial.print(lfrq);
          // Serial.println( "km/h");
          dtostrf(lfrq,5,1,buffn); //Llamada a la función
          char* formato="%6s km/h"; //Cadena con la mascara a convertir
          sprintf(buffer, formato, buffn);
          lcd.print(buffer);  
          start = millis();
      }
  }
}

MMMMM probé tu codigo, compila pero con errores, y algunos movimientos, por el amplio delay, no lo devuelve.

te cito uno de los errores.

sketch.ino:35:25: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

           char* formato="%6s km/h"; //Cadena con la mascara a convertir

Si le saco el delay, son buenisimos los resultados, son reales, pero en el LCD no se ven, si lo sigo con la computadora si. Tengo que buscar la manera de usar el codigo que pase, para que de 4 o 5 lecturas seguidas, me muestre la mas alta, pero sin delay.

Algo como este video

De donde saco la librería FreqPeriod.
Yo no puedo compilarla justamente porque no has puesto de donde la descargaste.
Cuando colocas un código en el foro conviene hacer esto.

#include <FreqPeriod.h> // https://github.com/Jorge-Mendes/Agro-Shield/tree/master/OtherRequiredLibraries/FreqPeriod

NO se si esta es la librería. Probaré con ella a ver que tal se comporta.

Bueno obtuve esto

Building .pio\build\nanoatmega328\firmware.hex
Memory Usage -> Redirecting...
DATA: [== ] 24.0% (used 492 bytes from 2048 bytes)
PROGRAM: [=== ] 27.3% (used 8378 bytes from 30720 bytes)
========================= [SUCCESS] Took 63.77 seconds =========================

O sea no hay errores y eso que me indicas es un Warning o advertencia. Pero no es un error.
No le gustan los punteros
Pero he modificado parcialmente el código para que no tengas Advertencias no Errores.

void loop() {
  char buffn[6]=" ";  //Cadena donde almacenaremos el número convertido
  char buffer[20]=" "; //Buffer de la cadena donde se devuelve todo, número formateado y cadena concatenada
  pp = FreqPeriod::getPeriod();
  if (pp) {
      if (millis()-start > INTERVALO) {
          lfrq = 820954.336 /pp;
          dtostrf(lfrq,5,2,buffn); //Llamada a la función
          char formato[20]="%s km/h"; //Cadena con la mascara a convertir
          sprintf(buffer, formato, buffn);
          lcd.print(buffer);  
          start = millis();
      }
  }
}