Banner publicitario de PCBWay

Problemas con el módulo Bluetooth HC-05

Claro que es solo un puerto serie.
Claro que se puede conectar directamente con un celular.
Hace falta un programa en el celular, sin él el módulo desconecta.
 
Hola a todos.
Tengo un módulo HC-05 y he tenido algunos problemas configurándolo.
Al conectarlo a la placa no hay ningún problema, entra en modo de conexión y configuración.
El problema es al conectarse con el teléfono, aparece como dispositivo disponible, pero al conectarse se conecta un par de segundos y se desconecta.
También en el monitor serie cuando yo pongo "AT" debería regresarme "OK" pero no me regresa nada.
Ya intenté invirtiendo TX y RX y nada. Estoy usando un HC-05 con botón.

Estoy intentando con este código:
C++:
#include <SoftwareSerial.h>

SoftwareSerial BTserial(2, 3); // RX | TX
  // CONECTA DESDE EL HC-05 TX AL ARDUINO PIN DIGITAL 2.
  // CONECTA DESDE EL HC-05 RX AL ARDUINO PIN DIGITAL  3

char c = ' ';

void setup()
{
    Serial.begin(9600);

    Serial.println("ARDUINO ESTA LISTO");  // para agregar comados AT

    Serial.println("TENER PRESENTE EN EL MONITOR SERIAL NL & CR");

    //LA VELOCIDAD DE COMUNICACION DEL  HC-05 POR DEFECTO DEL MODO AT ES 38400 EN ALGUNOS CASOS
    BTserial.begin(38400);
}

void loop()
{
    if (BTserial.available())
    {
        c = BTserial.read();
        Serial.write(c);
    }

    if (Serial.available())
    {
        c =  Serial.read();
        BTserial.write(c);
    }
}
 
Estuve investigando un poco, y descubrí que algunos cables de ese tipo solo sirven para pasar corriente, pero no funcionaban para transmitir datos. Ya compré otro por mercado libre y a ver que tal.
 
El baudrate para entrar en el modo de configuración es de 38400 Bps, pero no suele ser el mismo en estado activo.
Aquí veo lo siguiente:
C++:
    //LA VELOCIDAD DE COMUNICACION DEL  HC-05 POR DEFECTO DEL MODO AT ES 38400 EN ALGUNOS CASOS
    BTserial.begin(38400);
Y eso de "en algunos casos" yo creo que es en raros casos, porque en todos los módulos nuevos que he usado, el baudrate por defecto está en 9600 Bps.
Esto se puede comprobar en modo de configuración con el comando AT+UART?
Que debe regresar algo así: +UART:9600,0,0
Para establecer los parámetros UART se hace con el comando AT+UART=<Param>,<Param2>,<Param3>

La hoja de datos muestra que 9600 Bps es por defecto:
HC-05 Default Baudrate.jpg

Verifica el baudrate de operación o realiza una prueba a 9600 Bps.
Por ahora ya no tengo módulos para probar, pero creo recordar que tras un restablecimiento también quedaba en 9600 Bps.
Comando para restablecimiento: AT+RESET

Edit:
Buscando entre mis cacharros encontré un módulo.
Apliqué el comando AT+UART? para conocer el baurate actual . (Anteriormente este módulo fue configurado)
Me apareció lo siguiente:
HC-05 Configurado.jpg
19200 Bps es la configuración UART que tiene ese módulo. (La que seguramente usé)
O sea: 19200, N, 8, 1
Tras un reset "AT+RESET" me seguía apareciendo el mismo baudrate de 19200, así que usé "AT+ORGL"
Con esto ya quedó en 38400 Bps.
HC-05 AT+ORGL.jpg
Con esta prueba se podría considerar que por defecto también serían 38400 en modo activo.
Lo cual contradice lo que está en la hoja de datos, aunque no es algo que preocupe porque esto se puede configurar.

El problema es al conectarse con el teléfono, aparece como dispositivo disponible, pero al conectarse se conecta un par de segundos y se desconecta.
Con respecto a eso, mira lo que se menciona en estos mensajes:
Post #39
Post #41
 
Consulta. Estoy probando el módulo HC-05
Con el bluetooth serial lcontroller bajo y subo PWM pero lo hace lento.
¿Có
mo puedo variar el código para que corra más rápido?

C:
#include <16F883.h>
#FUSES NOWDT
#FUSES HS
#FUSES MCLR
#use delay(internal=4000000)

//-------------------------------------------------------------------------------
#USE RS232(stream=SERIE, BAUD=9600, PARITY=N, XMIT=PIN_C6, RCV=PIN_C7,BITS=8)


#define LED pin_C0
int16 valor=0;

void main(void)
{


   setup_ccp1(CCP_PWM);
   setup_timer_2(T2_DIV_BY_4,249,1);   // 1000 Hz. @ 4 MHz.
   ;

while(!kbhit()) //Pregunta si hay algun dato recibido
while (TRUE)
 {
       
     
     
       char Caracter = getc (); //Guarda el caracter
       if (Caracter == '0')
       {
          output_low (LED); //Apaga el LED
       
       }

       if (Caracter == '1')
       {
          output_HIGH (LED); //Enciende el LED
         
       }

      if (Caracter == 'a')
       {
       delay_ms(5);
             valor+=10;
     
       if( valor > 249) valor=249;
       
         
       
       }
           
         

          if (Caracter == 'b')
          {
           delay_ms(5);
                 valor-=10;
         
          if( valor <= 10) valor=20;
         
             
         
          }
     
      set_pwm1_duty(valor);
     
  }
}
 
Última edición por un moderador:
..encender el led más rápido cuando sostenes el botón y tarda mucho, raro...

Osea que...

En el presente hilo me ocurre que:
a) Mi pregunta no tiene nada que que ver con la velocidad del PWM
b) Lo que quiero es que el PWM cambie más rápido
c) Copié el código de algún sitio y no tengo ni idea de que hace ni como
d) Todas las anteriores son ciertas

Scooter dijo:
¿Serán los delays?
En realidad Scooter lo estaba afirmando pero bueno, lo dejó como pregunta para que el preguntante pensase un poco.

Pregunta 2, ¿Si quitando los delays sigue funcionando lento que vas a hacer?
a) Dejar los delays porque total no importan
b) Hacer que incremente y decremente de dos en dos
c) Poner más delays, si están ahí será que son buenos para algo
d) Volver a preguntar en el foro


PD el pwm de la pi pico es de 16 bits, si lo pruebas verás...

¡Ostras!
¡Que cabeza la mía!

¿A que velocidad está el autorepeat de tu teclado?

Revisa todo, y lo más lento, ¡Eso es!
 
Última edición:
No se, pero debería encender el led más rápido cuando sostenes el botón y tarda mucho, raro... le baje el tiempo a la app de celular, sumo la variable más 10 para que avance, creo que la comunicación con el bluetooth debe ser lenta!
En programación y cuestiones técnicas, no existen ni sirven COSAS como --> MUCHO ó POCO .
Si algo tarda, tenes que decirnos ¿cuanto tarda? y si es rápido ¿ que tan rápido ? ¿0,5 segundos ó 2 horas?

A mi ese número en el código ( 4 millones DELAY no me gustó)

¿Moño grande pidió la maestra o moño chico ?:rolleyes::unsure:
 
He instalado un módulo Bluetooth HC-05 en el interior del mando Skywatcher Synscan V4 de la montura de mi telescopio para poder controlarlo mediante Bluetooth y aplicaciones astronómicas como SkySafari.

Lo he hecho siguiendo este tutorial:
Skywatcher SynScan V4 Bluetooth Mod | n1k0ism!
Con eso, el módulo conecta y funciona bien.

He intercalado un interruptor en el cable positivo para poder encender y apagar el módulo Bluetooth a voluntad, independientemente del mando; pero hay un inconveniente:

El módulo Bluetooth sólo funciona correctamente si se enciende a la vez que el mando Synscan.
Es decir, si enciendo el mando primero, le dejo que inicialice, y luego enciendo el módulo, éste no funciona.
Ni siquiera aparece en la lista de redes Bluetooth disponibles.

Podeis pensar que eso no es un problema y que qué más da.
Pero resulta que el mando Synscan, una vez inicializado, pide las coordenadas geográficas, la fecha, la hora, etc.. para poder generar el mapa celeste. Y eso me tarda un tiempo. Y como tarde mucho en configurar el mando, el módulo Bluetooth deja de escuchar conexiones y ya no conecta al pc, móvil o tablet y toca apagar el mando y empezar de nuevo.

Esto no sería un problema si el módulo esperase conexiones durante más tiempo o funcionase si se enciende cuando el mando ya está configurado.

¿Se os ocurre alguna solución?
 
Las normas del foro indican que debes preguntar allá donde obtuviste tu circuito, lo cual es lógico porque los demás no conocemos a ese señor, no sabemos en que pensaba ni que ocurrencia hizo.

Pese a ello mi bola de cristal me dice que el "mando Synscan" se pelea con el HC05 y pasan cosas raras ahí. Esto ya lo digo yo; no es bueno conectar en sitios sin desconectar a donde iban esos sitios, pero si los cortas dejas de tener la conexión que antes tenías. Si del pin de un integrado sale una pista es porque va a algún sitio y está haceindo algo, si ahí conectas otra cosa, se pueden pelear.

Se me ocurren algunas cosas para intentar solucionarlo:
  • Que preguntes al que inventó el coso ese que tampoco dice nada, dice "suelda aquí y aquí, fin" .
  • Que pruebes con otro HC05 comprado en otro momento en otro sitio, hay versiones de firmware y recuerdo de algunos que no me funcionaban con tal teléfono y otros que si.
  • Que pruebes con otro PC, otro software etc
  • Que alimentes al HC05 de otro sitio; puede que se desconecte por fallo de alimentación o falta de corriente, por ejemplo al mover los motores baje la tensión y pierda la sincronía
  • Si el software de tu PC solo "escucha" como se mueve y no "habla" quita el pin TX del HC05 y deja solo el RX, esto evitaría el conflicoto de señales
  • Usa un HC06 que tiene menos configuraciones. El 06 solo funciona como receptor mientras que el 05 puede funcionar de dos formas; no se ve en el blog pero lo mismo dejó el pin de modo al aire y está cambiando de modos continuamente y por eso va errático, si sigues usando el 05 lee el manual porque creo que hay un pin de "modo" que habrá que poner a 0V o a 5V o a 3V3 o a lo que sea pero seguramente no se pueda dejar al aire. Eso lo miré en su día y no me acuerdo ni me quiero acordar; cuando necesito algo lo miro.

Discleimer:
Y si no es eso es que es otra cosa porque ni tengo un telescopio ni un sinescán ni sé que haces con el PC ahí en medio ni sé que hizo el inventor del engendro ni en qué estaba pensando si es que pensó. Solo me suena un poquito porque un amigo que tiene un telescopio y me cuenta cosas de que hace el aparato para el seguimiento de las estrellas...
 
Gracias por responder, Scooter.
El propietario del blog del que saqué el apaño lo tiene abandonado, por eso no le pregunté.

La cosa va así:
La montura tiene el mando Synscan, que le manda órdenes para moverse hacia los objetos celestes.
Pero también se puede conectar un PC o tablet a la montura por Bluetooth para dirigirla, mediante el HC-05, que sirve de interfaz, sin necesidad de desconectar el mando Synscan.
He estado haciendo pruebas este fin de semana y he sacado varias conclusiones:
-Yo también pensé que habría un conflicto, ya que el mando y la tablet mandan ambos órdenes a la montura, pero no lo hay si no se las mandan a la vez.
-Sí podría ser un tema de falta de corriente, pues ya le ha pasado a algunos. Esa falta de corriente provoca desconexiones y mal funcionamiento en el HC-05. Tendré que probar un apaño
-La comunicación entre el mando y la tablet es bidireccional.
Al momento de conectar, la tablet envía al mando las coordenadas de latitud y longitud que obtiene mediante la Ubicación o el GPS, además de la fecha y la hora.
Si se mueve la montura a un punto del cielo, el mando Synscan envía a la tablet las nuevas coordenadas celestes.
Y viceversa, si es la tablet la que mueve la montura, el mando actualiza la nueva posición.
 
Gracias por responder, Scooter.
El propietario del blog del que saqué el apaño lo tiene abandonado, por eso no le pregunté.
Suele pasar
La cosa va así:
La montura tiene el mando Synscan, que le manda órdenes para moverse hacia los objetos celestes.
Pero también se puede conectar un PC o tablet a la montura por Bluetooth para dirigirla, mediante el HC-05, que sirve de interfaz, sin necesidad de desconectar el mando Synscan.
Ahí está el tema, si está conectado a capón encima del otro mando lo mismo se pegan entre si o se rompen mutuamente. A priori es una burrada conectar sin pensar en dos sitios random de una placa.
He estado haciendo pruebas este fin de semana y he sacado varias conclusiones:
-Yo también pensé que habría un conflicto, ya que el mando y la tablet mandan ambos órdenes a la montura, pero no lo hay si no se las mandan a la vez.
Si lo hay siempre porque "no decir nada" no es dejar la línea desconectada, es dejarla a "0" o a "1" y contra ese 0 o 1 se pelean los otros 0 y 1 lo cual puede llevar a la destrucción de ambos dispositivos o a la entrada de datos erróneos. Para eso se usan drivers triestado, se "desconecta" uno y se conecta el otro, en la práctica "desconectar"=poner en alta impedancia, pero ese driver tirestado lo tiene que controlar alguien, y tu sistema no lo tiene previsto.
-Sí podría ser un tema de falta de corriente, pues ya le ha pasado a algunos. Esa falta de corriente provoca desconexiones y mal funcionamiento en el HC-05. Tendré que probar un apaño
Aliméntalo desde otro sitio
-La comunicación entre el mando y la tablet es bidireccional.
Lo suponía.
Al momento de conectar, la tablet envía al mando las coordenadas de latitud y longitud que obtiene mediante la Ubicación o el GPS, además de la fecha y la hora.
Si se mueve la montura a un punto del cielo, el mando Synscan envía a la tablet las nuevas coordenadas celestes.
Y viceversa, si es la tablet la que mueve la montura, el mando actualiza la nueva posición.
Me he perdido, ¿No están los tres puestos todos contra todos? ¿Están A <-->B <-->C?


Prueba a alimentar desde otro sitio
Verifica la conexión del pin del HC05 o usa un HC06 que no tiene dos modos el pin EN y el STATE que estén como tienen que estar y no al aire que puede dar problemas.

De todos modos vas a tener el problema del choque de datos.
 
El mando Synscan usa el protocolo RS-232. Se alimenta con 12 V.
Contiene un PIC, una memoria que alberga el firmware, drivers para los motores de la montura y reguladores de tensión.

El mando responde a los comandos enviados por el puerto serie, Bluetooth o WIFI desde un software astronómico como SkySafari (instalado en PC, tablet o móvil) y con ellos gestiona y mueve la montura.

Por ejemplo, si se envía una "V", responde con la versión del firmware. Otros comandos mueven la montura a las coordenadas indicadas, o responden con las coordenadas celestes a las que apunta el telescopio.

Pongamos que:
A= mando Synscan
B= PC o tablet con software astronómico
C= montura motorizada

La conexión es así:

B --- HC-05 --- A --- C

Y la comunicación es así:
A-> C
B-> HC-05 -> A -> C
A<-HC-05 -> B

No hay conflictos o no parece haberlos, salvo que A y C envíen a la vez (cosa que no se me ocurriría hacer). Cuando B envía , A lo recibe y mueve C. No se puede prescindir de A.


Por las pruebas hechas hasta ahora, he llegado a la conclusión de que esto necesita más chicha y que se debe seguir un orden de pasos muy concretos para que se establezca la conexión y se mantenga.

Probaré a alimentar el HC-05 con una fuente externa para garantizar una buena conexión y a habilitar ENABLE, para no dejarlo flotante.

Por cierto: No sabes la suerte que tienes de tener un amigo con un telescopio. Dile que te invite a una sesión de observación. Verás cómo disfrutas.
 
Última edición:
Ok, @Scooter, asunto resuelto.
Basta con alimentar el equipo con 14 V. y 3 A. (que no le falte chicha), para que deje de haber problemas de desconexiones del Bluetooth.
Eso sí, la condición para poder conectar el Bluetooth por primera vez es esperar a que el mando Synscan haya inicializado completamente (normal, por otra parte).
Así, bien alimentado, el Bluetooth ya conecta y desconecta de la tablet a voluntad, sin sufrir cortes.

Muchas gracias.
 
Atrás
Arriba