Herramientas Buscar en Tema
Antiguo 29/10/2015, 23:44   #2191
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Entonces que hago ???
Prueba también con la versión que yo he modificado a ver que hace, y si te funciona pues voy pensando en yo que sé, porque ya empiezo a volverme loco, he hecho hoy un millón de pruebas...
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 29/10/2015, 23:51   #2192
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Pues ya esta probado con tu versión y lamentablemente se cuelga o sea que no es la Crius.
De entrada ya he visto que parecia que le costaba arrancar y le he tenido que accionar varias veces el home, una vez arranca parece ir bien pero se me ha colgado al poco rato.
Primero he probado con el fichero de esta tarde el tiene tilt, que parece que con esta versión iba bastante peor, hasta que se ha colgado, luego he probado con el 1º fichero y al poco rato se ha flipado y empezado a girar sin parar hasta que le he quitado la bat.

Lo siento pero es lo que hay.
Simba esta en línea ahora   Responder Citando
Antiguo 29/10/2015, 23:55   #2193
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Pues ya esta probado con tu versión y lamentablemente se cuelga o sea que no es la Crius.
De entrada ya he visto que parecia que le costaba arrancar y le he tenido que accionar varias veces el home, una vez arranca parece ir bien pero se me ha colgado al poco rato.
Primero he probado con el fichero de esta tarde el tiene tilt, que parece que con esta versión iba bastante peor, hasta que se ha colgado, luego he probado con el 1º fichero y al poco rato se ha flipado y empezado a girar sin parar hasta que le he quitado la bat.

Lo siento pero es lo que hay.
Yo se lo achaco a que con esta versión tiene más cosas que hacer la crius, por lo que no atiende con diligencia al puerto serie y provoca que no se lean todos los bytes, o se lean con error, o yo que sé, que al final termina cascando.

Con la de Rangaird, las primeras veces iba vien, o lo parecía, pero como te he contado también se me ha reseteado de vez en cuando, aunque con menos frecuencia...Lo que hago es para que no sea siempre igual, probar a darle al home alguna que otra vez para que cambie la secuencia de giros de pan y parezca más un vuelo cercano.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 29/10/2015, 23:57   #2194
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por rortega Ver mensaje
Yo se lo achaco a que con esta versión tiene más cosas que hacer la crius, por lo que no atiende con diligencia al puerto serie y provoca que no se lean todos los bytes, o se lean con error, o yo que sé, que al final termina cascando.

Con la de Rangaird, las primeras veces iba vien, o lo parecía, pero como te he contado también se me ha reseteado de vez en cuando, aunque con menos frecuencia...Lo que hago es para que no sea siempre igual, probar a darle al home alguna que otra vez para que cambie la secuencia de giros de pan y parezca más un vuelo cercano.
Yo ya le he dije hace un par de días que esto pasa, pero no me creía, dice que pueden ser por tema de bajadas de tensión cuando el servo se mueve muy rápido y tal...pero eso con GPS Telemetry no me ha sucedido jamás...
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 00:03   #2195
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Si es posible que la Crius no puede con todo pero ¿puede que la trama de simulación tenga errores o algo mal? Y que le cause algún error por no poder firmar tantos errores.
Lo que si se nota mucho mucho es que no va tan fino como yo esoy acostumbrado con la mía y supongo que esta simulación tiene más velocidad de lectura de posición y en cambio va más a saltos. Puede que por la gran cantidad de errores.
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 00:56   #2196
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Si es posible que la Crius no puede con todo pero ¿puede que la trama de simulación tenga errores o algo mal? Y que le cause algún error por no poder firmar tantos errores.
Lo que si se nota mucho mucho es que no va tan fino como yo esoy acostumbrado con la mía y supongo que esta simulación tiene más velocidad de lectura de posición y en cambio va más a saltos. Puede que por la gran cantidad de errores.
Acabo de conseguir que mi versión no se me cuelgue a la primera, lleva ya un par de minutos movíendose y aún no se ha colgado.

Lo que he modificado es el archivo frsky.cpp, concretamente lalínea

#define FRSKY_RX_PACKET_SIZE 11

He cambiado el valor por un 255

#define FRSKY_RX_PACKET_SIZE 255

Vamos, que mientras escribía este mensaje ha acabado la simulaicón completa sin problema alguno.



__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 00:57   #2197
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Y que le hiciste????
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 00:58   #2198
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Y que le hiciste????
Acaba de tener un cuelgue durante la segunda prueba que he realizado.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 01:06   #2199
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Y que le hiciste????
La tercera prueba continúa sin problema...

El por qué ahora funciona mejor es porque le he hecho un buffer más grande. Era una de mis sospechas, que en algún momento no procesa o bien el final de alguna trama, o bien el byte donde se le indica el tamañao, de modo que el buffer de memoria, al tener sólo 11 bytes se desborda y produce un error que tenrmina interrumpiendo la ejecución.

Ahora me falta hacer algo para impedir que eso suceda, me explico, en lugar de tener un buffer muy grande, lo suyo es controlar en qué situaciones ese buffer debería dejar de llenarse.

Ésto ya se lo he explicado en su momento a Rangarid, pero ni caso, le reconozco el gran esfuerzo que ha hecho atendiéndome durante varios días montones de intercambios de mensajes y demás, pero me he llevado algunas respuestas que se podrían interpretar como "bordes" cuando le he sugerido que el código fallaba, a tal punto que en muchas ocasioens he tenido que dorarle la píldora...

Mientras escribía este mensaje, la tercera simulación ha acabado completa sin error alguno.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 01:13   #2200
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Voy ya por la 5 prueba sin error, habiando probado ya los 3 archivos, y sólo he exerimentado el cuelgue e la segunda prueba.

Ésto promete.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 01:37   #2201
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por rortega Ver mensaje
Voy ya por la 5 prueba sin error, habiando probado ya los 3 archivos, y sólo he exerimentado el cuelgue e la segunda prueba.

Ésto promete.
Funciona con Easing en tilt activo y todo... Sigo realizando pruebas y no se ha vuelt o a repetir el problema. Se puede decir que tenemos protocolo FrSky para el escenario NAZE32 + cleanflight por softserial + Receptor FrSky D + módulo FrsKy DJT con MOD Bluetooth.

Queda montar el tracekr y observarlo en producción. Este fin de semana no creo que pueda probarlo, tengo que impartir clases en un master la semana que viene y tengo que prepararlas.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 01:47   #2202
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Una curiosidad, tienes alguna herramienta para evaluar las pruebas o vamos a prueba y error, lo dejas funcionando y esperas a ver que pasa.

Bueno es igual no me lo espliques que igual no lo entiendo, el caso es que funcione sin cuelgues.

Por cierto me ha venido una duda, yo igual me lanzo y me decido a comprar algún modulo de Frsky con Telemetria, receptor tengo al menos uno que me vino con la Taranis.
Que modulo es mejor, el Djt o el Xjt, este ultimo parece por caracteristicas que da 10omw y el otro 60mw.

Todo esto suponiendo que le des en el clavo y funcione.

Y si llegado el caso funciona, ¿como se podría hacer que funcionara sin la Nace32? ¿debería comprar también un GPS preparado para telemetria Frsky ?.

Antes de todo este sub-proyecto, tengo que probar con un modulo de 2,4 de TurruK, si es factible el funcionamiento como repetidor, entre Rx en 2,4 y Tx en 2,4.

Bueno lo primero es que funcione lo que tienes en marcha.

Me voy al catre , buenas noches a todos.
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 02:37   #2203
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Una curiosidad, tienes alguna herramienta para evaluar las pruebas o vamos a prueba y error, lo dejas funcionando y esperas a ver que pasa.

Bueno es igual no me lo espliques que igual no lo entiendo, el caso es que funcione sin cuelgues.
Bueno, sí que manejo algunas herramientas, la principal mi cabeza, que cuenta con bastantes años de experiencia ya, y la intuición es una de mis mejores habilidades, je je je.

Mientras escribo ésto sólo puedo decir que esto funciona bien, lo tengo aquí al lado funcionando mientras escribo. La prueba de "hard" siempre es la mejor prueba.

No hay muchas formas de evaluar el buen funcionamiento, salvo prueba y error, o algo de debug. En la plataforma Arduino hay muy pocas posibilidades de hacer debug, que se basan en sacar datos por consola serie. La otra opción, es la de usar el entorno de desarrollo Atmel Studio, que digamos te facilita esa labor de sacar datos por consola serie, empleando una espcie de interfaz en la propia ventana del entrono de desarrollo, donde puedes evaluar el valor de variables haciendo un proceso de depurado paso a paso, instrucción por instrucción, o mediante la utilización de puntos de ruptura. Se puede hacer tando sobre la propia placa como sobre un arduino virtual. Yo tengo Atmel Studio instalado en mi portátil en casa, lo he usado para depurar alguna de las partes del código de esta aplicación, pero no me gusta demasiado, no me encuentro cómo con ese entorno.

Otra opción es la de utilizar un entorno de desarrollo de un tercero. En mi caso yo uso "eclipse", sobre linux cuando estoy en el trabajo o sobre Windows cuando estoy en casa (en el portátil). Se puede configurar para que se integre con Arduino, pero yo en lugar de eso, como el lenguaje de programación al fin y al cabo es el mismo (c++), lo que hago es que no instalo en el entorno de desarrollo las herramientas de compilación para arduino, sino que compilo de forma nativa para arquitectura x86, siempre y cuando las partes de código a depurar no tengan una dependencia con la arquitectura.

Por ejemplo, para depurar el parser de tramas FrSky, me he creado un pequeño proyecto c++ en eclipse, incorporando integramente los archivos frsky.cpp, frsky-common.h, telemetry.h, config.h, pero comentando aquellas partes del código que provocan la carga de liberrías específicas para manejar el hardware del arduino (los includes), y viéndome obligado a teclear algunas líneas para sumplir valores o datos.

Las tramas que me suelta mi módulo DJT las capturo con un programilla parecido al hércules, se llama sscom, pero seguramente con el hércules también lo podría haber hecho.

Esas tramas las extraigo en formato hexadecimal (texto), y luego se las paso al programa que creé con eclipse para convertirlas a binario. El extraerlas primero a hexadecimal es porque el sscom me lo facilita, y así puedo manipular los archivos de texto para ver las tramas completas, y poder analizarlas visualmente siguiendo las especificaciones del protoclol FrSky. En binario o decimal sería casi imposible para el ojo humano.

Con linux todo ésto para mí es más sencillo y rápido de hacer que con windows, pero de cualquier forma se puede hacer.

Lo bueno de usar eclipse de la forma que he explicado, es que puedo hacer con el código casi lo que me de la gana, depurarlo, usar puntos de parada, ver valores de variables, sacar datos por consola, a los baudios que quiera y en un santiamén...

En fin, que teniendo conocimiento y experiencia es como un juego, conde la dificultad no está en manejar las herramientas, sino en dilucidar el por qué las cosas funcionan mal o funcionan bien. Mi profesión consiste en ésto precisamente, en hacer uso de estas herramientas.

Cita:
Iniciado por Simba Ver mensaje

Por cierto me ha venido una duda, yo igual me lanzo y me decido a comprar algún modulo de Frsky con Telemetria, receptor tengo al menos uno que me vino con la Taranis.

Que modulo es mejor, el Djt o el Xjt, este ultimo parece por caracteristicas que da 10omw y el otro 60mw.
La cuestión no es que módulo es mejor, sino más bien preguntarse con qué protocolo va a funcionar bien el tracker. De momento sabemos que va con telemetría directa, con RVOSD y con FrSky D.

Los módlos X van con protocolo FrSky X. El desarrollo no dista mucho, y puede que no tenga tantas dificultades despues de la experiencia adquirida con FrSky D. Todo va a depender de lo que el amigo Rangaird haya copiado de por ahí... Lo que copió para FrSky D no lo hizo bien del todo y lo ha tenido que parchear tela para llegar hasta este punto.

Todo este lío de FrSky creo que se debe (y es una intiuición) a que se suponía que las tramas se tomarían desde una Taranis o una emisora con Firm OPENTX/ERX9, desde el puerto de salida que tiene para tal fin, y que se supone que las tramas ya salen filtradas, y no desde una ñapa en un módulo dándose por hecho que las tramas llegan bien, y la experiencia nos ha dicho que no, que llegan con muchos errores, y, para colmo, no hay ninguna suma de comprobación para errores en el protocolo, ni comprobación de errores en el destino (el tracker), habiéndose tenido que modificar gran parte del parser.

Ésto último me genera una gran duda ¿Funcionará el parser tal como está ahora si pillamos la telemetría desde la Taranis? Creo que la Taranis viene por defecto con protocolo X, pero creo que también se puede utilizar con el D, así que es cuestión de aventurarse, comprar los dos tipos de receptores y hacer las pruebas.

No estoy seguro, pero creo que Rangaird usaba el tracker con Taranis y receptor X.


Cita:
Iniciado por Simba Ver mensaje

Todo esto suponiendo que le des en el clavo y funcione.
Funcionar funciona, ahora si que lo creo. Aún me queda averiguar el por qué de ese cuelgue, aunque no es cuelgue total, simplemente dejó de leer datos de la UART, pero el tracker seguía funcionando, si lo giro, vuelve a apuntar a su sitio.

Sospecho que más que un cuelgue es un problema de que los datos que le llegan no dan posición del avión en movimiento, es posible que lo haya dejado parado con la velocidad a cero un rato y no me acuerde. De hecho, el cuelgue ha sido en uno de los archivos que he usado una sola vez, creo que el ccc.tx, con el último, el cap5, he probado ya no sé cuantas veces y ha ido de maravilla en todas las pruebas.

Y si es un fallo del firm seguro que tiene solución. Lo más grave ya funciona, aunque no deja de ser un parche. Me reitero en que el desarrollo original deja mucho que desear, viendo lo que ví en RVOSD y la semana que llevo luchando contra Rangaird...osú osú...Pero vamos, que la NAZA de DJI tiene también muchas cagadas...

Cita:
Iniciado por Simba Ver mensaje

Y si llegado el caso funciona, ¿como se podría hacer que funcionara sin la Nace32? ¿debería comprar también un GPS preparado para telemetria Frsky ?.
Si usas un X creo que se puede conectar el GPS directamente (eso tendría que confirmarlo, pues no estoy seguro del todo) y las tramas llegarán en formato FrSky X al destino y hay que decodificarla.

Si usas FrSky D el GPS tiene que ir a un Hub, donde se empaquetan en un formato concreto, creándose tramas tipo Hub, y luego son mandadas sobre tramas FrSky D

Cita:

Antes de todo este sub-proyecto, tengo que probar con un modulo de 2,4 de TurruK, si es factible el funcionamiento como repetidor, entre Rx en 2,4 y Tx en 2,4.

Bueno lo primero es que funcione lo que tienes en marcha.

Me voy al catre , buenas noches a todos.
Yo ya voy tarde a la cama, pero creo que el motivo a merecido la pena, si no no duermo hoy con el coco pensando en la solución al problema.

Espero que todo esto haya servido para aclarar dudas...
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 09:27   #2204
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Guillesan Ver mensaje
Ole, ole, en nada tenemos un protocolo mas y van....... Mavlink, gps-directo,rvosd, Frsky-D y Frsky-X , me dejo alguno ?
Le he preguntado a Rangarid esta mañana si funciona el tracker con GPS conectado a un recetor FrSky X y módulo XJT con Taranis, es decir FrsKy X, pero por lo que dices Guillesan ¿Lo has probado o lo ha probado él?

Y Mavlink, lo has probado tú ¿No?

Lo digo para reescribir el archivo README con información fidedigna de que todos esos protocolos los tenemos probados.

Por otro lado, comentar que la solución de poner el valor 255 es sólo un parche y que lo voy a volver a dejar a un valor menor, 11 sería lo correcto, pero como se hace una comprobación con 19 en un lugar del código, lo pondré a 19. Y el control definitivo para descartar las tramas que sobrepasen 6 bytes como bytes de datos de cada trama, según especifica el protocolo FrSky, y según he discutido con Rangaird, se va colocar en el punto exacto.

Las líneas de código del archivo frsky.cpp siguientes

Código:
case USRPKT:
        uint8_t numBytes = packet[1];
        for (uint8_t i = 3; i < numBytes+3; i++) {
            parseTelemHubByte(packet[i]);
        }
        break;
Quedarán algo como ésto:

Código:
case USRPKT:
        uint8_t numBytes = packet[1];
        if(numBytes > 6) return;
          for (uint8_t i = 3; i < numBytes+3; i++) {
            parseTelemHubByte(packet[i]);
          }
        break;
Es decir, tramas con numBytes > 6 no se procesan, las descartamos directamente.

Cuando confirme que el cambio funciona correctamente subiré la actualización al repositorio con nuevo número de versión.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 09:31   #2205
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje

Por cierto me ha venido una duda, yo igual me lanzo y me decido a comprar algún modulo de Frsky con Telemetria, receptor tengo al menos uno que me vino con la Taranis.
Que modulo es mejor, el Djt o el Xjt, este ultimo parece por caracteristicas que da 10omw y el otro 60mw.
Respuesta de Rangarid:

Cita:
Frsky X works very well. All my videos that i made in the beginning were with frsky x. have a look at this project:
https://github.com/SamuelBrucksch/diy-frsky-gps

It uses an arduino to parse ublox or nmea based GPS and convert it into frsky protocol for the RX.
Es decir, usa un arduino como intermediario...
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 10:38   #2206
Guillesan
* * * * * *
 
Avatar de Guillesan
 
Ingreso 31/oct/2008
De Barcelona
1.967 Mensajes
Buenos dias, aclarando la situacion de funcionamiento.
Las telemetrias probadas y funcionando por mi son:

GPS_TELEMETRY: Funcionando correctamente 4800 baudios 4 hz sobre Openlrs

MAVLINK: Probada la salida de este protocolo entregada por el OSD MyFlyDream, funciona correctamente , 9600 baudios igualmente sobre Openlrs (necesario usar la distribuciom Openlrs especial gitsly para transmitir correctamente las tramas Mavlink)

RVOSD: Funcionando (pruebas en casa) , gracias como no a ROrtega , telemetria por video usando la estacion RVGS propia del OSD , 115200 baudios 25 hz.
Este fin de semana pretendo probarlo en campo , pero tengo buenas impresiones .

Por ahora mis mejores resultados han sido usando la placa Crius v 2.5 integrando en ella todo lo necesario , las pruebas con placas arduino aun funcionando tienen mas problematica no solo de montaje (cables por todos lados) como por la brujula separada de la placa principal, esta influenciada por campos magneticos de los motores de los servos , etc....

Espero sirva de aclaracion.
Guillesan esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 11:34   #2207
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por rortega Ver mensaje

Código:
case USRPKT:
        uint8_t numBytes = packet[1];
        if(numBytes > 6) return;
          for (uint8_t i = 3; i < numBytes+3; i++) {
            parseTelemHubByte(packet[i]);
          }
        break;
Es decir, tramas con numBytes > 6 no se procesan, las descartamos directamente.

Cuando confirme que el cambio funciona correctamente subiré la actualización al repositorio con nuevo número de versión.
Así no va, requiere algo más de control en alguna otra parte. Estamos en ello.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 11:34   #2208
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Guillesan Ver mensaje
Espero sirva de aclaracion.
Gracias por la aclaración.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 13:25   #2209
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por rortega Ver mensaje
Así no va, requiere algo más de control en alguna otra parte. Estamos en ello.
He encontrado otro fallo.

Como uso eclipse según describí antes estoy en un escenario perfecto de ejecución, en la que un pedazo de ordenador con 2 procesadores con 6 núcleos cada uno a dos hilos de ejecución por hilo (24 cores virtuales), con 32 GB de RAM , disco duro SSD, etc..... la ejecución del parser es perfecta, casi impoluta, pues la UART no se atasca ni queriendo, pues sencillamente no la uso, ya que me dedico a leer las tramas de un archivo. Es decir, la situación perfecta en la que el hardware no va a fallar jamás.

Cientos de salidas con posiciones gps y altitud fiables que darían como resultado un seguimiento casi perfecto del tracker.

Pero esta mañana cuando me levanté pensé: ¿Qué pasaría si aleatoriamente, de vez en cuando una de las gallinas me la guardo, y hacemos que no se cumpla la ley de "las gallinas que entran por las que van saliendo"?

Lo que se me ha ocurrido hacer es que de forma aleatoria, de vez en cuando dejo de leer un byte del archivo, cosa que repito varias veces, pero no muchas, tratando de simular que la UART del arduino se ha comido un byte y no lo ha cagado (con perdón)...

El resultado es éste:

Cita:
...
Frame: 15722, Position: 38.480350, 9.023310 Alt: 199 Sats: 11
Frame: 15801, Position: 38.480390, 9.023650 Alt: 199 Sats: 15
Frame: 15880, Position: 38.480390, 9.024010 Alt: 199 Sats: 11
Frame: 15961, Position: 38.480330, 9.024370 Alt: 198 Sats: 11
Frame: 16037, Position: 625.080220, 9.024710 Alt: 198 Sats: 11
Frame: 16114, Position: 38.480080, 9.025030 Alt: 198 Sats: 11
Frame: 16192, Position: 38.479940, 9.025350 Alt: 197 Sats: 15
Frame: 16271, Position: 38.479780, 9.025640 Alt: 197 Sats: 11
Frame: 16350, Position: 38.479630, 9.025970 Alt: 197 Sats: 11
...
...
Frame: 18151, Position: 38.479080, 9.025560 Alt: 190 Sats: 15
Frame: 18228, Position: 38.478780, 9.025220 Alt: 190 Sats: 11
Frame: 18307, Position: 38.478510, 9.025210 Alt: 189 Sats: 11
Frame: 18386, Position: 2.745040, 9.025230 Alt: 189 Sats: 15
Frame: 18542, Position: 38.477740, 340.808590 Alt: 188 Sats: 15
Frame: 18619, Position: 38.477430, 9.025270 Alt: 188 Sats: 11
Frame: 18699, Position: 38.477150, 9.025290 Alt: 188 Sats: 11
Frame: 18778, Position: 38.476870, 9.025310 Alt: 187 Sats: 11
...
Y no os lo váis a creer, pero cada vez que detect olgo y se lo cuento se pone a la defensiva o me suelta algún comentario que no termina de gustarme. Hasta ahora me he controlado bastante, pero ya empiezo a cansarme de tratar con él... Luego parchea su código, los sube a su repositorio y me lo dice para que lo pruebe...En fin.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:13   #2210
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Bueno tal como lo veo yo, al menos para mi particular instalación necesitaría:

Ya que tengo el Rx de la Taranis, un FrSky X8R 8/16Ch S.BUS ACCST Telemetry Receiver W/Smart Port.

Compatibility:All 16 channels require the FrSky Taranis, or the XJT module.For 8 channels in D8 Mode you can use the FrSky Taranis or XJT, DJT, DFT, DHT and DHT-U modules.

O sea que puede funcionar con los 2 tipos de telemetria D o X y con Taranis claro que es X.

Actualmente lo que rortega esta preparando es la versión D, y por lo tanto para la X me tengo que esperar pacientemente, ya veremos si resisto.

Si con la versión X se puede utilizar un GPS Ublox, con la ayuda de un Mini Arduino, quizás sea la solución fácil y económica.

El resto de instalación ya es la misma que tengo, y por supuesto el modulo Tx Frsky sea el que sea iría montado en el Traker, como repetidor solo para señal de control, la señal de telemetria se quedaría en el propio Traker360.

Me quedo a la espera de como queda el tema y en función de como quede decido seguir con el proyecto.
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:13   #2211
Guillesan
* * * * * *
 
Avatar de Guillesan
 
Ingreso 31/oct/2008
De Barcelona
1.967 Mensajes
Te entiendo Ortega, a mi tambien "me costo" hablar con él.
tengo plena confianza en ti, te vales y sobras para sacar esto adelante, a las pruebas me remito.
Tranquilo, a lo tuyo.
Un saludo.
Guillesan esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:19   #2212
Guillesan
* * * * * *
 
Avatar de Guillesan
 
Ingreso 31/oct/2008
De Barcelona
1.967 Mensajes
Todo preparado para la prueba de RVOSD en el campo. Las pruebas en casa se me antoja que es " muy nervioso" pero hay que confirmarlo en vuelo.
Unas fotos del engendro


Guillesan esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:32   #2213
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Bueno tal como lo veo yo, al menos para mi particular instalación necesitaría:

Ya que tengo el Rx de la Taranis, un FrSky X8R 8/16Ch S.BUS ACCST Telemetry Receiver W/Smart Port.

Compatibility:All 16 channels require the FrSky Taranis, or the XJT module.For 8 channels in D8 Mode you can use the FrSky Taranis or XJT, DJT, DFT, DHT and DHT-U modules.

O sea que puede funcionar con los 2 tipos de telemetria D o X y con Taranis claro que es X.

Actualmente lo que rortega esta preparando es la versión D, y por lo tanto para la X me tengo que esperar pacientemente, ya veremos si resisto.

Si con la versión X se puede utilizar un GPS Ublox, con la ayuda de un Mini Arduino, quizás sea la solución fácil y económica.

El resto de instalación ya es la misma que tengo, y por supuesto el modulo Tx Frsky sea el que sea iría montado en el Traker, como repetidor solo para señal de control, la señal de telemetria se quedaría en el propio Traker360.

Me quedo a la espera de como queda el tema y en función de como quede decido seguir con el proyecto.
Para funcionar con X necesitas un arduino en el lado del avión
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:36   #2214
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Ok, eso había entendido, me imagino que con un pequeño Mini Arduino, que por cierto tengo uno que me paso Supercanii, ¿ me servirá para esto no?
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:40   #2215
Simba
* * * * * *
 
Avatar de Simba
 
Ingreso 04/jul/2008
4.652 Mensajes
Yo no se si me habeis entendido con lo del Repetidor 2,4g a 2,4g, seguro que Guillesan si que ha pillado la onda.

Es para utilizar el traker360, tal como lo utilizo yo actualmente, para orientar tanto la antena del Video como la del control Radio, que ademas lleva la telemetria directamente en el propio traker, y no se necesitan los Bloutooth.

Que pesao soy, no hago nada mas que repetirme.
Simba esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:47   #2216
Guillesan
* * * * * *
 
Avatar de Guillesan
 
Ingreso 31/oct/2008
De Barcelona
1.967 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Yo no se si me habeis entendido con lo del Repetidor 2,4g a 2,4g, seguro que Guillesan si que ha pillado la onda.

Es para utilizar el traker360, tal como lo utilizo yo actualmente, para orientar tanto la antena del Video como la del control Radio, que ademas lleva la telemetria directamente en el propio traker, y no se necesitan los Bloutooth.

Que pesao soy, no hago nada mas que repetirme.
Te he pillao, si, "antes muerto que sencillo".
Tu dale que me da a mi que detras hay un monton leyendo este link.
Tomando nota y demas.
Guillesan esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 14:59   #2217
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Guillesan Ver mensaje
Te he pillao, si, "antes muerto que sencillo".
Tu dale que me da a mi que detras hay un monton leyendo este link.
Tomando nota y demas.
Yo también te pillé, el gráfico del otro día fué muy instructivo.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 15:03   #2218
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Guillesan Ver mensaje
Todo preparado para la prueba de RVOSD en el campo. Las pruebas en casa se me antoja que es " muy nervioso" pero hay que confirmarlo en vuelo.
Unas fotos del engendro
Lo vas a lanzar desde el balcón y te vas a sentar en el sofá del salón a pilotarlo, o qué?
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 15:17   #2219
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Cita:
Iniciado por Simba Ver mensaje
Ok, eso había entendido, me imagino que con un pequeño Mini Arduino, que por cierto tengo uno que me paso Supercanii, ¿ me servirá para esto no?
Simba, me falta información sobre este tema. Pero por lo que le he entendido a Rangaird, se trata de construir un DIY GPS, imagino que se trata de poner el arduino leyendo las tramas de un gps UBLOC, y condificando mensajes para mandarlos vía receptor X.

Si te fijas, en el código fuente, en el config.h tines lo siguiente:

Código:
/* #### DIY GPS / Fix Type ####
*
* If you use the diy GPS the fix type is transmitted with the satellites on Temp2. The value is calculated like this:
* Num of Sats: 7
* Fix Type: 3
* Value = Sats * 10 + Fix Type = 7*10 + 3 = 73
*
* If you use the native frsky gps or fixtype is not present comment to disable.
*/
//#define DIY_GPS
Por tanto no necesitas comprar un GPS específico para conectarlo al recetor FrSky, sino que puedes usar cualquiera pero usando un arduino como intermediario.

Eso es exactamente lo que hace la NAZE32, además de volar el dron (lo bueno de la NAZE32 es que habla los dos idiomas, el D y el X, así que si algún día decido pasarme a X y comprar una Taranis, me basta como cambiar un parámetro en la configuración de la cleanflight y listo, vamos, seleccionar X en un desplegable, y rezar que el código FrSky X funcione. Pero bueno, no es tu caso.

Lo que yo no sé es que firmware hay que subirle al arduino, no sé si en la wiki del proyecto original se explica.
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando
Antiguo 30/10/2015, 16:56   #2220
rortega
* * * * * *
 
Avatar de rortega
 
Ingreso 20/abr/2012
3.816 Mensajes
Bueno, me he despedido amigablemente de Rangarid, no vuelvo a contactar con él ya se pueda venir el mundo abajo. Os pongo aquí mi respuesta a su último mensaje, no pongo el suyo por aquello de la privacidad, no vaya a ser que encima tenga problemas por hacerlo. En mi últim mensaje le sugiero la forma de solventar el último error que he reportado aquí, y se ha negado a hacerlo, invitándome a que corriga posibles problemas en el lado de la NAZE32 y cleanflight (ya me ha dicho en varias ocasiones que su parser funcionaba muy bien, y no me lo creo, a las pruebas me remito). Mi respuesta a su negativa dice así:

Cita:
Cita:
Before changing the code in that way you really should evaluate, where the error is coming from...
Have you realy tested how the FrSky D parser works over RC transmitters and receivers, flight controllers, GPS devices that differs of those of your own ones before publishing it in your repository? After reading the wiki and the readme file where you explicitly say that it works with FrSky D, I thought that it would work within one scenario like I described: NAZE32 + cleanflight + DJT transmitter+Bluetooth.

After changing many message with you, I've realized that you use Taranis with FrSky X, translating NEMA frames to FrSky X with the help of an Arduino board. And as I see in your videos, it works fine. But have you tested the FrSky D parser too with the D receivers and and DJT transmitters and bluetooth on other RC transmitter? I think that not, that this is the first time somebody do it, I apologize if it sounds bad, but is my perception after this crazy week.

I think that there are things that It's not possible to control in the side of the hardware of FrSky devices, and in fact we can only act on both extremes of the channel.

I reviewed the cleanflight code which encode FrSky Hub Telemetry data, and it seems to be perfect, there is no place to errors in that code. I reviewed the configuration of the parameters and every thing is ok. The GPS send out NMEA 0183 frames at 1HZ at 9600 bauds, which are read by cleanflight and sent to the rx pin of the reciever in a clear and direct way. What is happening inside the reciever and the transmitter is dificult to know, perhaps a update of the firmware could be needed, I didn't checked it.

I've tested with two differents DJT modules, with 6 different bluetooth modules, with a real GPS and a NMEA simulator, and other community user has also tested with a different hardware (but the same captures, of course), and the conclusion is that the parser is not ready to work in this escenario, perhaps because nobody tested it before, perhaps becaus the scenario in which you tested FrSky D is almost perfect.

If I don't solve the problem by modifiying the firmware, I will be forced to buy a different, newer and expensive hardware for try to use the open360tracker, and I thought after read the wiki, the readme, your forum and my forum, that it was a great, open and flexible proyect that could be used in many different escenarios. This is the reason why I'm interested on your project, and also on geting your help.

Previous getting in contact with you, I solved many bugs and improved your firmware with new functionalities (of course that my version also have errors which I will correct after the users will test it) as you know, and I think that these days you have noticed that I know what I say when I say it, but it seems as if you don't trust me every time I write to you suggesting something. Many times, your first reply is a negative answer, but after I give you proofs than your code contains errors, after some hours, you modify the code and upload the change to your repository which is available for every body ¿Why do you share the code if you think that the problem is in the side of NAZE32 + cleanfligh? I apologize again if my words seems to tray to attack you, but what I only want is to know if this FrSky D parser is already tested by other users or is the same case as the RVOSD parser I've corrected.

Well, I will not disturb you any more with this topic, I'll try to do the best I can with it and try to solve my problems.

Sincerely, a appreciate too much your help and give you again the thanks for the big effort you've done this days. Great job!!!
__________________
WiiFPV Team: VIMEO - YouTube
rortega esta en línea ahora   Responder Citando


Herramientas Buscar en Tema
Buscar en Tema:

Búsq. Avanzada

Ir al foro

Temas similares
Tema Autor Foro Resp. Último mensaje
Ayuda! antena tracker darylkorn R/C Antenas, Emisores, Receptores y Comunicaciones 0 14/04/2015 10:25
Opiniones antena tracker mdf o rv antoniobernal R/C Antenas, Emisores, Receptores y Comunicaciones 7 14/07/2014 10:34
Busco antena tracker duckcrazy MERCADO de COMPRA / VENTA 0 15/06/2012 08:45
Opiniones Recomendarme un Antena Tracker jonpeter R/C Antenas, Emisores, Receptores y Comunicaciones 3 06/05/2012 20:30


Tu hora GMT +1. Ahora son las 17:20.


2015