Proyectos con Android

[josegr]

baudrate por defecto del bluebas18?

[Suky]

Probaste 115200??

[josegr]

La verdad solo probé con 9600 y 19200 sin buen resultado. Estás seguro que ese es el que está por default?

[josegr]

hay alguna manera de cambiar el baud rate desde el codigo fuente?

[Suky]

De manera fácil no, tenes que instalarte NDK y trabajar con alguna librería de forma nativa.

http://en.wikibooks.org/wiki/Serial_Programming/termios


Saludos

[josegr]

Gracias, me ha sido muy útil la información. En caso de no ser 115200 el baud rate por default, tienes idea de algún otro valor con el que pueda funcionar?

[groundman]

hola de nuevo a todos.ya hace tiempo que no posteo por aqui.ya que estube con otros proyectos.pero adjunto al control bluetooth.

queria poner mi experiencia con respecto el bluetooth de android.
en una aplicacion de android que estoy realizando con eclipse.ya hace tiempo que pude hacer funcionar una comunicacion con un modulo HC-05 y un PIC.
en esta aplicacion envio datos en una trama MODBUS.y estos datos llegan perfectamente al pic.puedo extraer los datos de la trama,comprobar el CRC y
enviar una respuesta de retorno.tal y como se indica en el protocolo MODBUS.respetando los tiempos de cabecera y entre datos.

pero el problema esta en la recepcion.segun todas la pruebas que he realizado.el primer dato que envio en la respuesta se pierde cuando se envia una trama
de mas de dos caracteres.

no es el caso si es que envio los datos caracter a caracter.de esta forma logro enviar una trama aunque tampoco excesivamente larga.ya que de hacerlo
asi.se me producen muchos errores en tramas que se reciven a lo largo del tiempo.
ademas la recepcion se demora excesivamente al tener que realizar una pausa entre caracteres.ya que si recorto el tiempo de esa pausa.se producen mas errores.


asi que ahora que retomo el proyecto.he estado haciendo pruebas que han mejorado los resultados.aunque no son infalibles.
a costa de mejorar la comunicacion en sacrificio del protocolo MOSBUS.he optado por enviar una trama sin pausas entre caracteres.pero con un
caracter extra en el inicio.ya que este se pierde cuando se usa este sistema.ademas el caracter es el dato 0xAA ya que a mi parecer al ser en binario
b10101010 .parece que sincroniza mejor y no se producen tantos errores.


se me paso por la cabeza que el proble pudiera ser del pic que no enviara correctamente los datos de respuesta al modulo HC-05.pero puse
el hiperterminal en esos pin.y los datos son correctos.asi que descartado.

tambien cometi el error de conectar tx del pic al rx del HC-05.pero tambien configure este pin como colector abierto y poner una resistencia pull-up
a 3.3v .y no funciona correctamente del todo.pero no se si ya dañe los modulos.haber si me llegan otros que tengo pedidos.pero me estraña
que el problema de los datos incorrectos sea porque se han averiado los modulos.ya que en ese caso nunca irian bien.que no es el caso.

alguien tiene alguna experiencia respecto a estos tipos de problemas con bluetooth? me parecio haber visto algun proyecto de este tipo de nocturno.
pero no se si lo termino.

[groundman]

bueno.al final logre mejorar la recepcion.ya puedo recibir datos sin casi errores.y eso para tramas de 20bytes.con tramas cortas no hay errores.
o un 1% por poner algo.

todo el tema esta en la forma en que se reciben los datos por bluetooth.yo pensaba que la trama se recivia completa con todos los bytes que se transmiten.
y esto no es asi.
cuando se recibe una trama.esta va diseccionada.por norma general primero se recibe un solo caracter.esto podria servir para determinar la cabezera de la trama.
posteriormente se recibe el resto de la trama.pero sin un orden en la recepcion respecto al numero de bytes recibidos.pero para esto hay un dato
muy importante para ordenar la trama recibida.y es el numero de bytes recibidos.
con esto y los trozos de trama recibidos.he desarroyado una rutina que los ordena y crea un array de bytes con la trama ya ordenada.

en esta rutina cada vez que se recibe los datos.los voy ordenando dentro de la clase BluettothCommandService.que es la encargada de
la recepcion de los datos bluetooth.
en una prueba que hize.los datos los iva ordenando en un Handler de la actividad principal.pero al parecer se perdian datos. porque aunque
si que llegaban al handler de la actividad principal.llegaban sin poder ordenarlos en la rutina que hize.por eso la rutina va en la misma clase donde se
reciben los datos.

pero para poder recibir la trama completa.hay que identificar la cabecera.y esto lo realizo en una temporizacion que empieza cuando se recibe
el primer caracter suelto.
aparte esta temporizacion se determina con un tiempo multiplicado por el numero de bytes recibidos.
esta temporizacion se mantiene hasta que se dejan de recibir datos.y es entonces cuando se  prepara la rutina para recibir otra nueva trama.

y el array recibido es transferido al receptor de anuncios de la actividad principal.


para una correcta recepcion de la trama.el microcontrolador tiene que enviar los datos con un pequeño retardo entre dato y dato.pero este retardo
puede ser nulo para tramas de 9bytes.sin embargo si que debe de haber un retardo para tramas largas de 20bytes.por eso yo he puesto un retardo
intermedio y va bien.quizar mas adelante haga una rutina que modifique este retardo segun bytes a enviar por el microcontrolador.

[KILLERJC]

bueno.al final logre mejorar la recepcion.ya puedo recibir datos sin casi errores.y eso para tramas de 20bytes.con tramas cortas no hay errores.
o un 1% por poner algo.

Y el bluetooth no tiene nada para corregir los errores ? o para verificar si hay un error y volver a enviarlo ?.
Parece raro que siendo un sistema que se transmite por aire no tenga vaaaaaaarios bits para la deteccion y correccion de errores.

[groundman]

hola KILLERJC.el bluetooth transmite los datos perfectamente sin problemas.todos los bytes van por el aire hasta que un dispositivo los recibe.
el problema esta en la recepcion.ya porque se ha producido una interferencia,que el dispositivo este lejos,o que la aplicacion android
este haciendo otro trabajo y se pierda algun dato.

por eso en el receptor hay que comprobar mediante un CRC si la trama es correcta.si no lo es pues podemos enviarle la peticion de que nos envie de nuevo
la trama.

yo creo que la mayoria de los errores que se producen es por la gestion que realiza android para recibir los datos.si pusieramos un HC05 como maestro.
y otro HC05 como esclavo.no creo que se produciese ningun error.almenos por gestion.otra cosa seria por interferencias o distancia excesiva entre dispositivos.