Proyectos con Android

[groundman]

  pues ya tengo el programa hecho .ademas de obtener el CRC de una trama de bytes.como puede ser la trama del protocolo MODBUS.que como sabemos trabaja
con el polinomio A001.
tambien podemos enviar la trama completa con el CRC invertido.que es como trabaja este protolcolo.sin la necesidad de escribirlo en la trama.ya que se
incluye automaticamente.

solo tenemos que escribir los bytes en los EditText y pulsar el boton.para obtener el CRC en la esquina inferior izquierda de la pantalla.
y si quisieramos transmitirla por bluetooth,daremos a CONECTAR.y seleccionamos el dispositivo al que queramos conectarnos.

y pulsamos Enviar.y se enviara la trama completa con el CRC incluido.insisto no hay que añadirlo al texto.

ahora me toca realizar la recepcion.para el acuse de recibo del esclavo. mas retos

PD.os invito a que hagais pruebas y me indiqueis si se produce algun error en el calculo del CRC.para asi poder solventarlo.




http://www.4sync.com/rar/Kio26rgU/SerialModbus20final.html

[groundman]

bueno.casi una semana despues.sigo atrancado en la fase de la recepcion.el problema que tengo es que pierdo el primer dato recibido.tal y como comente en algunas respuestas al principio del hilo.
si mando un caracter este no se pierde.pero si mando mas de 1 el primer caracter de la trama se pierde.
he visto por donde mas o menos esta el fallo.pero no logro entenderlo.
resulta que al recibir datos o caracteres.segun queramos usarlos.el buffer de entrada de datos bluetooth contiene los datos recibidos.asi que cuando se recibe un caracter,
se produce un evento que hace que hace que se ejecute un hilo.y este es el encargado de ejecutar una rutina para gestionar los datos recibidos en el buffer de entrada bluetooth.

la cosa esta en que el primer dato que parece perderse,realmente no se ha perdido.lo que pasa es que cuando se recibe el primer caracter de la trama.este queda almacenado en el buffer de entrada;
pero antes de recibir el segundo caracter,se produce un nuevo evento que hace cargar el buffer de entrada con el resto de caracteres.realmente no se porque se produce esto.y si podria anular la forma
de que se produciera el siguiente evento.y de esta forma cargar todos los datos en el buffer de entrada de una sola vez.dado que no se hacer esto.he probado a almacenar en el buffer un solo dato.
y funciona.pero claro,hubiese sido mas efectivo cojer los datos directamente de buffer.ya que es una array.y de esta forma tendre que crear yo mismo el array.

o tambien puedo unir el primer caracter al array de caractres.vere que es lo mejor.y si llega a funcionar.

[groundman]

al final he podido realizar la parte de la recepcion de datos.se necesitan un monton de calculos y conversion de tipos de valores.resumidamente lo que hago es
tomar los datos del buffer de recepcion y convertirlos para visualizarlos.ademas de generar el CRC de la trama recibida.y compararlo con el CRC que
tambien lo trae la trama recibida.y si es correcto lo visualizo en un EditText.

y aunque funciona.se me presenta un problema bastante gordo.y es que cuanto mas largas son las tramas recividas.mas fallos tiene la transmision.
dandose ocasiones en que se necesitan 10 transmisiones para recibir una trama correcta.

resulta que cuando recibo una trama,la trama la mayoria de las veces no se recibe completa.aveces se pierde la cabeza del mensage.otras veces faltan caracteres
por la mitad.etc

estoy pensando en recibir los datos uno a uno.haber si de esta forma tiene menos fallos.quise hacer esto anteriormente.pero como todabia no se gestionar los
tiempos en android.pues me decante por usar el buffer completo.veremos haber que tal me sale.

[groundman]

bueno.ya he terminado con la recepcion de las tramas bluetooth.durante el desarroyo de esta aplicacion,se me ha presentado infinidad de problemas.ya sea
por fallos mios.o por no entender bien el funcionamieto del sitema bluetooth dentro de un terminal con android.yo ya he llegado al final de la comprension
de este sistema.y no quiero decir que lo sepa todo sobre el.el problema es que no encuentro mas informacion respecto al comportamiento interno del hardware
del bluetooth.

he aprendido lo suficiente para el descubrimiento y conexion a dispositivos bluetooth.tambien he aprendido a enviar datos por el buffer de salida de datos
que dispone android.
pero no entiendo bien el funcionamiento del buffer de entrada.en las primeras aplicaciones que hize.tambien se producia fallos durante la recepcion.
incluso con caracteres ASCII.

cuando enviamos una trama de datos al terminal.en el programa se produce un evento que ejecuta un thread.el cual envia los datos recibidos al hilo principal
mediante un Handler.
la cosa esta en que al recibir la trama,normalmente se produce un evento con el primer dato recibido.y seguidamente recibimos otro evento con el resto del
la trama.
si no gestionamos esto.se producirian dos llamadas al hilo principal mediante el Hndler.por eso he realizado unas instrucciones para que los dos eventos.
se traduzcan en el envio de una sola trama al hilo principal.

pero abezes en una misma trama se pueden producir varios eventos.quizas debido a una interferencia.o algun retardo en el tiempo entre datos.o quizas
un evento producido en nuestro terminal... yo no lo se.

tambien he visto como datos residuales de una trama anterior.se han quedado en el buffer de entrada.y he tenido que limpiarlos enviando una trama de ceros.
ya que no se como limpiar este buffer con algun tipo de instruccion del android.he mirado en el SDK y no he visto nada al respecto.

con todo esto.he llegado a la conclusion,de que el envio de datos atraves de bluetooth necesita de una buena comprobacion de los datos recibidos.
de ahi que use el CRC.pero ademas veo que es mejor usar tramas cortas para que se produzcan los menores fallos posibles.

esto no creo que sea un problema para el manejo del protocolo MODBUS.ya que en vez de direccionar los datos a enviar a una sola direccion con una trama larga.
podemos usar varias direcciones con una trama mas corta.

segun las pruebas que he hecho con esta aplicacion.raramente la trama no se envia a la primera,cuando la trama no excede de 10 datos hexgesimales.
tambien he hecho pruebas con 15 datos con 1 acierto un por cada 5 intentos,20 datos con 10 intentos para 1 acierto.y cuanto mas larga,mas fallos hay e incluso igual nunca se produce el acierto.
aunque esto no conlleva ningun problema en cuanto a la fidelidad de los datos.que llegaran bien gracias a la comprovacion del CRC. que sera el esclavo el que decidira cuantas veces le pedira al maestro
que la embie de nuevo.
claro esta que cuantos mas fallos,mas se ralentizara el proceso que tenga que realizar el esclavo ante la falta del dato que precisa.



pues aqui pongo la aplicacion.no exenta de bugs ya que soy novato en esto.y aunque he intentado por todos los medios calcular diferentes combinaciones
ante la generacion del CRC o transformacion de valores,puede que en algun calculo se desborde algun valor y esto haga que la aplicacion se pare.
asi que si alguien hace pruebas y le sale algun error.me lo indique para ver de donde viene el fallo.



http://www.4sync.com/rar/uHfEss_Z/SerialModbus37.html



En esta aplicacion en la parte de la transmision tambien he implementado  el poder escribir las tramas de envio en minusculas.aunque tambien funciona con
mayusculas.

y en la parte de la recepcion.he añadido un contador de errores y aciertos.ademas de un reset en el menu para ponerlos a cero.

debajo de estos se ubica la trama recibida correcta.y abajo del todo todo el trafico de entrada separado por puntos y coma por trama recivida.


espero que le sea util a alguien.y podais aprender.

si aprendo mas cosas sobre el buffer de recepcion,ya modificaria el programa.
ahora no se si empezar a realizar circuitos y sus respectivas aplicaciones.o empezar con la recepcion/envio de datos mediante Wi-Fi.

[groundman]

hola.ya hace algun tiempo que he dejado de seguir poniendo aplicaciones por aqui.y es porque estoy realizando una
aplicacion para la apertura de puertas electronicas.

el proyecto lo tengo precticamente acabado.basicamente lo que hace es enviar una trama modbus a un pic.comprobar si
la trama es corecta mediante su CRC.y si lo es activar una salida del pic.

hasta aqui todo correcto.pero el problema se me presenta cuando envio desde el pic a la aplicacion.la trama de confirmacion
como en los ulimos programas que he ealizado,sigo teniendo el problema de la recepcion.

aveces recivo la trama correctamente y otras no.y aunque en esta aplicacion no es muy importante.si quisiera
realizar una aplicacion de monitoreo de datos.si que seria un serio problema.

como ya estube investigando.el problema creo que esta en la recepcion de tramas largas en el buffer de recepcion.
asi que intentare realizar una recepcion caracter a caracter.espero que los tiempos entre caracteres no excedan
del maximo estipulado de las indicaciones del protocolo modbus.

[groundman]

he logrado crear un byte array que se le van sumando los valores recibidos en el evento de recepcion.ahora me queda lo mas dificil.
crear una rutina que cada vez que se reciba un evento de recepcion,una temporizacion se resete cuando de reciva otro evento de recepcion.
y que el byte array quede preparado para su uso.pero que si se sobrepasa esta temporizacion,se iran añadiendo valores al array.

supongo que podre hacerlo con un thread.pero no es tan facil.creo

[groundman]

por fin logre lo que queria hacer.he modificado la aplicacion anterior para poder conseguir que no se produzca ningun error al recibir los datos
desde el master.de 100 intentos no ha fallado ninguno.solo ha tenido fallos cuando me he alejado del modulo bluetooth unos cuantos metros y sin perder la conexion han podido perderse algunos datos.

eso si.el unico problema que conlleva la modificacion.es que al recibir los caracteres de uno en uno.es que se pierde mucho tiempo en la gestion de estos datos.
no es lo mismo que recibir el buffer lleno y coger los datos necesarios.

en esta aplicacion que recoge los datos uno a uno. tenemos la ventaja es que los datos recividos van a llegar correctamente.
sea cual sea la cantidad de estos.
a no ser que se contaminen con una interferencia o la mala recepcion de ellos.
lo malo es que el master va a tener que enviar los datos con un retardo de 0.1s cada uno.claro que tambien dependera de la velocidad de procesamiento de nuestro terminal.el mio es un HTC one s a 1.5Ghz

este desfase de 0.1s hace que aunque los datos que contiene una trama MODBUS sean totalmente compatibles.el espacio inter dato,no lo sea.
y la trama seria descartada por cualquier dispositivo compatible MODBUS.
aunque estamos ablando de la recepcion de nuestro terminal.no sucede lo mismo con la transmision que si es totalmente compatible.

de ahi que este tipo de sistema solo lo use para terminales con conexion bluetooth.

espero que cuando aprenda ha hacer esto.pero con wi-fi.no tenga los mismos problemas.espero que el buffer de recepcion en wi-fi.llegen
todos lo datos en condiciones.



respecto a la modificacion que he hecho.las modificaciones que hice en la clase BluetoothCommandService.las he dejado como originariamente
las encontre cuando me baje el archivo de internet.

pero en la clase Main.en el mHandlerBT.en la parte case MESSAGE_READ:

si he tenido que modificarlo.y tambien he incorporado otras rutinas para la gestion de la trama recivida al final de la clase.solo hay que comparar los programas.



PD.  de todas formas si queremos usar el primer sistema.tampoco es mala opcion para tramas cortas.lo que mas suele fallar es el primer envio.los sucesivos no suelen dar problemas.por eso se me ha ocurrido.enviar una primera trama de prueba antes de enviar la informacion importante.asi supongo que ira bien.



aqui dejo el link de descarga: http://www.4sync.com/rar/GaCFolkc/SerialModbus40mod.html
 

[josexp]

hola me gustaria q me ayudaces con una conexion con un dispositivo bluetooth que estoy haciendo para hacer una app pulsometro a travez de una banda polar wearlink bluetooth solo me falta la parte de la conexion con este y x supuesto q me envie las pulsaciones a la app si me ayudaces con algun ejemplo

[groundman]

siento no poder ayudarte por ahora.estoy bastante ocupado con otras cosas.pero en este tema he puesto muchos ejemplos.te sugiero que los leas y practiques.
y si tienes alguna duda te informo.

saludos

[josexp]

hola logre que el la banda se conectara solo que ahora envia datos estraños por pantalla como hago para traducir ese codigo me darias una manita solo con eso recomendandome que hacer

[groundman]

Si recibes datos extraños es porque no tiene bien configorada La velocidad de transmision

[josexp]

y donde configuro eso   disculpa la falta de conocimiento

[groundman]

josexp.no me pones muchos datos.segun he mirado por internet tu cinta transmite los datos codificados.no se que quedran decir ellos con esto.

sabes ya que protocolo usan para transmitir los datos? y como decodificarlos si es que estan codificados.

porque si no sabes tratar los datos que te envia la cinta.de poco te sirve recivirlos correctamente.

[groundman]

aqui tienes una aplicacion para esto. https://play.google.com/store/apps/details?id=HRnavi.HRnavigator&feature=search_result#?t=W251bGwsMSwyLDEsIkhSbmF2aS5IUm5hdmlnYXRvciJd

no se si habras probado tu banda con otras aplicaciones.en todo caso busca el SDK haber si lograras entender la comunicacion.

[josegr]

baud rate por defecto?