Yo mandé a comprar afuera uno de esos, IDÉNTICO, pero de otro fabricante, costó unos $9.00 USD desde China, está trabajando 100% desde hace 2+ años, básicamente es ese mismo, pero parece que al traducirlo del inglés cometieron un error usual (en traductores de PC) que es invertir el orden.
El mio lo dice todo en inglés, "Video and S-Video to VGA converter"... si antena > cajita (video) > conversor > VGA > monitor de PC LG de 17 pulgadas + speaker y tienen un TV con cajita... jejeje

¿Es en Photo Service? ese mismo está aquí en Photo Service Camagüey, con errores de traducción y todo... y creo que más caro 30+  si mal no recuerdo...
Tu como cliente tienes el derecho a que te prueben las cosas, lleva el dinero, dile que te lo prueben...
Es simple: que te le conecten un monitor VGA por las salidas VGA y toca los botones debe salir un menú. Evidentemente si no sale el menú es porque no es en ese sentido...

Si no te lo dejan probar en la tienda, exige hablar con un jefe y dile que lo compras y pruebas en casa ya que ellos no te lo prueban, si no te sirve lo devuelves... TIENEN que aceptarlo, si no lo aceptan, pide el libro de quejas y si es CIMEX busca en los carteles y jala por un celular y llama al número único y quéjate (ES GRATIS!!! FREE!!!)...
Ellos tienen la obligación de probarte los efectos electrónicos, y si no tienen los medios TIENEN que aceptar la devolución si no te sirve luego de que lo pruebes en casa, es un derecho como consumidor (cliente)
Saludos.
 

Saludos Mandy !!!!

Jajaja tiempo sin verte. Ahora veo unos mensajes que reportaron al moderador (yo) que no veo manera de ponerlos o mostrarlos...

jejeje los reportaron como contenido "Malo" y eso los "esconde" pero no encuentro la manera de publicarlos... por eso me encontré este hilo...

Si revisas los comentarios hay una parte donde dice:

"Hay una variante que se llama ax25lib tcp o algo así para windows, que por debajo no es más que una mezcla del driver de MixW con el soundmodem de Linux compilado para windows: no vale la pena... el soundmodem de linux en windows no era muy eficiente, tenía una pérdida de paquetes enorme..."


Precisamente estamos hablando de la misma cosa... es el ipoverax25 [https://ipoverax25.wordpress.com/], ese mismo, lo que no recordaba el nombre... el turko usa el soundomdem de linux compilado como una DLL y pone su stack (o pila) de ax25 con un driver que funciona, pero como el módem es de regular pa' malo...

Por cierto el sitio no es funcional, todo el contenido dice "se movió a http:///...." otra página que no dice NADA del ipoverax25... por lo que veo solo se desarrolló en 2011 y por uno o dos meses... ni siquiera las descargas funcionan...

Sobre la incompatibilidad que comentas no entiendo, si el tipo dice que soporta TCP/IP es porque soporta el estándar, así que tienen que hablar directo, o será el jnos que como es ya viejito no se entiende con él... no se desde aquí no puedo hacer como mandrake y adivinar sin meterle las manos en las tripas y ver detalles técnicos... sin embarrarme de grasa... tu sabes...

Con jnos mi experiencia es limitada, trabajé mucho con "node" que es la utilidad para hacer BBS en Linux (en su forma básica, porque recuerden que CO9JAZ no era un BSS, por lo tanto solo dejaba hacer connect, ping, telnet; con mensajería y otras cosas deshabilitadas) node es simple y fácil... sin complicaciones, jnos siempre lo vi muuuuuy complicado para la tarea...

Saca tus conclusiones... acerca de ipoverax25 según mis comentarios... en nuestra red nunca funcionó eficientemente; o sea funciona, pero no al nivel de las otras alternativas...

En las últimas versiones de Direwolf (en desarrollo, no la oficial) este tiene ya por fin el modo conectado en la interfaz AGW y el modo KISS por red ya es full KISS con dos interfaces simulando un KPC3 como si estuviera en puerto serie...

A lo mejor habría que re-visitar a flexnet y linkearlo por KISS a soundmodem a ver que da... el punto débil de FLEXNET era que la interfaz de KISS de direwolf era muy básica y había que meter un programa en medio que simulara un puerto serie y es el que se conecta con el KISS del direwolf que está escuchando en la red interna de la PC... todo un enredo de los buenos... jejeje

Hum en estos días estuve cacharreando con una cosa que se llama vagrant que permite automatizar cosas con maquinas virtuales que está para chuparse los dedos... a lo mejor en las vacaciones me embullo y creo una solución con vagrant para correr linux sobre cualquier windows usando virtualbox y que tenga perfiles, etc... veremos...

73 & 88 de CO7WT.

parte nuevo y final,

73 y voy tumbando la mula que ya es tarde...

La modificación a los radios TK-760 G y no G, veremos si para en los adjuntos del foro...

Esto data de aquellos tiempos...

PS: va en varios post picados porque por restricciones de tamaño no pasa entero, pedazos de 200k...

Son 9 partes, 4 aquí, 4 en otro y uno final con uno solo

73

Por cierto se me olvidó mencionar en el piquete a CO7GG que era otro de los asiduos del packet en Camagüey, ahora es KO7GG...

Como decía, yo estaba probando en linux el soundomdem y me di cuenta que podía tener ambos modems alaire en la misma frecuencia y atender a dos colegas al mismo tiempo, uno por 1200 AFSK y el otro por 4800 AFSK...

Eso funcionaba ok en mi pc, luego de muchas pruebas hicimos pruebas con soundmodem de Linux en el server y funcionaba MUCHO MEJOR que con los TNC de fábrica, e incluso mucho mejor cuando combinaba los dos modems que cuando usaba uno solo de manera independiente... luego aprendí que era porque al combinarlos el soft imponía a la tarjeta de audio un samplerate (muestreo) más alto logrando mejor calidad en RX...

La calidad de la red la medíamos en dos aspectos, si porque almenos una vez a la semana hacíamos pruebas de cambios y mejoras tanto de soft como de hadware...

Llegamos a refinar los parámetros como TXDELAY, PPERSIST, PACLEN, etc a los objetivos de nuestra red y logramos un pacto de caballeros con una frecuencia de fonía obligatoria para coordinar cuando se estuviera en packet... si... por lo que verán.

Afinando los parámetros nos dimos cuenta que podíamos ser más agresivos en el canal y mejorar tanto el rtt (round trip time, o se el tiempo que demora un paquete en ir y virar a tu PC) como la pérdida de paquetes, que por cierto, para conexiones estables en packet si no tienes menos del 20% de pérdida de paquetes estas frito... incluso con el 20% es incierto, lo ideal es por debajo del 15%...

Estos parámetros eran la vara para medir si los cambios se mantenían o se daban para atras...

La frecuencia de fonía era para preguntar antes si alguien estaba usando el packet quien iba detrás, cosa que en todo momento estuviera el server con una sola estación tirando para mejorar el uso del canal, que que cuando salían varias estaciones era un problema... Este pacto de caballeros se mantuvo todo el tiempo de vida del nodo... de lo cual me enorgullezco.

Luego pasamos a 9600 baudios FSK directo al modulador, ajustamos la interfaces y demás parámetros y notamos que el comportamiento de los radios se mantenía, ahora era incluso más definitorio... Kenwood SI hacía 9600 sin lio, los demás no.

Todos pasamos a kenwoods... jejeje el problema con la velocidad es que requiere un S/N alto, o sea que la relación de nivel señal contra ruido se a alta y no puede haber ruido o interferencia de fase. Recuerdo que había una estación lejos en la ciudad, al otro lado... Vladimir... no recuerdo el indicativo... que su antena quedaba detrás de una loma y no tenía visión directa clara, cuando mirabas te dabas cuanta que su estación quedaba en el borde de la loma... nunca pudo hacer packet a 9600, pero si a 4800.

Cuando mirabas el espectro de audio en el Server veías que había distorsión de fase, provocado por la difracción de la señal al pasar por el borde de la loma... eso en 9600 es crítico, no tanto en 4800 FSK donde es más manejable...

El estaba a unos 5-7 Km de la estación de packet, yo a unos 3 Km, CO7KD a solo 200m, CO7YB 1-2 Km, CO7GG a unos 3 km... etc...
Todos dentro de la ciudad, la antena siempre fue una J a unos 10m en el RC, con almenos unos 20m de coaxial.

Por eso se dejó 9600 y 4800 baudios FSK en el server, para que Vladimir pudiera usarlo... todavía no recuerdo el indicativo...

Luego encontré a Direwolf, con unas innovaciones en el tratamiento de la señal de packet y desarrollado para linux, hay versión para Windows pero el jugo se le saca en linux... contacté con el desarrollador y entré en la lista de discusión del proyecto, recuerdo que John (autor) y David Ranch (soporte) me ayudaron mucho, en esa época fue que pude dar explicación al porque muchas de las pruebas no funcionaron y empezamos una nueva ronda de pruebas, ahora con basamento teorico y comentarios de personas que saben de eso.

Sobre el Direwolf, decirles que existe un CD de grabaciones reales de tráfico packet a 1200 baudios (tengo una copia) que es lo que se considera la prueba del estándar del mercado en los TNC ya sena por hardware o software.

Direwolf es por mucho el único que saca más de 1000 packets válidos de la pista de audio de prueba, seguido por el soundmodem de UZ7HO y luego algunos hardwares incluidos el PK-323MBX y la serie KPC.... MixW no se queda mal, está en la media; pero Direwolf está escapado y fuera de ligas... lástima que en windows no se le puede sacar todo el jugo...

Sobe todo porque si tienes CPU para gastar el puede al vuelo hacer correcciones sobre los bits dañados de los paquetes y corregirlos, tiene varios demoduladores en paralelo que aplican diferentes patrones de actualización para ajustarse a las variaciones de los diferentes radios y el canal de enlace de radio, etc...

Esto es una solución a medias... porque por el pobre algoritmo de la suma de chequeo del packet no es matemáticamente suficiente para que se reconstruya el paquete satisfactoriamente, o sea es posible que se reconstruya y de la suma pero el paquete sea incorrecto. Esto es un problema menor con TCP/IP pues el tiene su propio esquema de chequeo fuerte y cuando vea que no sirve vuelve a pedir el paquete.

Las pruebas comprobaron que era mejor que reconstruyera (2-5% pérdidas) contra la variante sin reconstrucción (5-8% pérdidas) por lo que dejamos siempre la reconstrucción de un solo bit activada.

Por ejemplo para ilustrar cuando pasamos a 9600 FSK con soundmodem teníamos 10-12 % de paquetes perdidos promedio y rtt de unos 900 msec (0.9 seg) y cuando pasamos a direwolf con 9600 logramos pérdidas de paquetes del orden de 2-5% y rtt de aprox 600 msec (0.5 seg) ya eso es un canal muy usable y estable...

Sobre el ancho de banda útil: saquen cuentas con el mismo cálculo son aprox 0,36 kB/s pero en la práctica se lograban después de tunear los parámetros una conex con un promedio de 0,6 kB/s cuando estabas bajando/subiendo algo y el tráfico es mayormente en un solo sentido.

Al final probé otros tweaks (retoques) que solo funcionaban linux a linux (ya dije que el server era siempre linux, pero mi estación siempre fue linux también; al contrario de los demás users que usaban mayormente WinXP como cliente con MixW + TCP/IP)

Estas modificaciones hacían compresión de cabeceras al vuelo, compresión de datos al vuelo e incluso un tunnel ssh com compresi´on end-to-end, y logre exprimir incluso más el canal sacando en algunos contenidos (emails que viajan por a red en texto plano, html sin imágenes) hasta casi 1 kB/s... indudablemente linux es superior y muy configurable en cuanto a muchas cosas con respecto a windows.

Sigo en otro post sobre la evolución interna de los servicios que tenía y algunos detalles del hardware.

73 de CO7WT.

Ahora voy a almorzar, por la tarde les cuento técnicamente las lecciones aprendidas y las mejores opciones...

Hasta dentro de un rato...

El secreto de las fuentes a mosfet es que el voltaje de salida después de rectificado y antes de el regulado tiene que ser entre 4 y 8 volts más que lo que se desea.

Esto es por varias razones:

• Los mosfets tienen la zona lineal muy pequeña, porque están diseñados para trabajar como interruptores, no como reguladores.
• Lo que provoca que si no aseguras que existan al menos 4 volt por encima de la salida a máxima carga la fuente oscilará con toda la potencia desarrollada, y una oscilación de fuente de apenas 2V en un equipo de 2m no hace nada más que ruido, pero en un HF puede ser muy dañina.
• Como la zona lineal es corta y se supone que los mosfets no están diseñados para trabajar en ella, los encapsulados no son muy eficientes disipando el calor generado (porque se supone que trabajando en corte no generan calor), súmale que si usas 24V para regular a 13.5V el mosfet debe disipar el resto, que a unos modestos 5 amperes son ( 24 - 13.8 ) * 5 = 51W por lo que trabajarán MUY calientes, si pasan la zona de equilibro térmico explotarán, porque no están diseñados para manejar esa potencia de disipación, no por los parámetro, sino por temperatura. Moraleja: no uses más de 6-8 volt por encima de lo que quieres lograr, para el caso de 13.8V la fuente debe dar unos 18-20V, no más.
• Para las fuentes prefieran mosfets que tienen la aleta metálica expuesta y no los que son plásticos completos, para mejorar la transferencia de temperatura.

Estos son algunos detalles según mi experiencia.

73 Pavel CO7WT