No es el protocolo ideal para ver las condiciones de propagación pues WSPR tiene un margen adicional de 5dB sobre FT8 pero es posible usarlo como Beacon aprovechando redes como pskreporter para su monitorización.
El proyecto de diseñar una baliza para FT8 presenta varias diferencias con respecto a WSPR:
- WSPR es un protocolo unidireccional y FT8 es bidireccional. Este punto no es relevante pues solamente usaremos una llamada "CQ".
- Como ya hemos avanzado los mensajes WSPR pueden ser decodificados con una relación S/N de 5dB peor que los mensajes de FT8.
- Las redes que centralizan los mensajes recibidos son distintas WSPRnet para WSPR y pskreporter
- Los mensajes de WSPR son de 162 símbolos que se transmiten dentro de un intervalo de 110,6" mientras que los de FT8 son 79 símbolos que se transmiten en apenas 12,74", a consecuencia de ello el ancho de banda de WSPR es de 6 Hz, mientras que el de FT8 es de 50 Hz (Requiere mas ancho de banda, a mayor velocidad de transmisión mayor ancho de banda)
- WSPR usa la modulación de 4-FSK mientras que FT8 usa 8-FSK (mas tonos)
- WSPR requiere de una precisión en la frecuencia +/- 1 Hz mientras que la de FT8 es de +/- 1,5 Hz (mas tolerante)
Un mensaje con formato para ser monitorizado sigue el siguiente esquema
CQ <indicativo 6> <locator 4>
PRUEBAS
ESp32+SI5351
Una primera prueba se realizó aprovechando una ESP32 y una Si5351. Una vez depurado el programa al ejecutarse se observó que no generaba una transmisión correcta, por lo que no era decodificable.
El posible motivo es que Si5351 no es capaz de responder a la velocidad que le exige la transmisión en FT8 por ello se decidió probar con un DDS como AD9850.
También se pensó en prepara una nueva versión que usara los datos precodificados con el fin de aligerar el procesado por si ese era el problema pero se obtuvo el error:
E (19740) i2c.master: s_i2c_synchronous_transaction(945): I2C transaction failed
E (19747) i2c.master: i2c_master_receive(1268): I2C transaction failed
que sugiere que los cambios de frecuencia son demasiado rápidos
ESP32 + AD9850
Como consecuencia se decidió conseguir una placa de desarrollo DDS AD9850 0-70MHz 0-40MHz capaz de generar 2 ondas sinusoidales y 2 ondas cuadradas concretamente la "HC-SR08 DSS_AD9850" (Disponible en Aliexpress por unos 10 €)
Aprovechando el tiempo muerto se buscó una placa de reloj de precisión del tipo DS3231 AT24C32 IIC dada la mayor exactitud demandada por FT8. Con este módulo ademas de disponer de una mayor precisión aunque haya fallos NTP y/o wi-fi se le da mas autonomía al no necesitar ni GPS, ni NTP de forma continua (Disponible en Aliexpress por unos 2€).
AD9850 0-70MHz 0-40MHz
Conviene calibrarlo con un programa de test y recibiendo la señal con un SDR
Segun el modelo:
- AD9850: Banda de frecuencias 0-40MHz; reloj de 125 MHz
- AD9851: Banda de frecuencias 0-70MHz ;reloj 30 MHz
Dispone de 4 salidas
- QOUT1 / QOUT2 Señales cuadratura (I/Q) TTL
- ZOUT1/ ZOUT2 Señales diferenciales internas del DAC TTL
Especificaciones
PLACA DE DESARROLLO ESP32
Se usa la placa ESP32 LiLYgo LORA32 T3 V1.6.1 con pantalla OLED, si bien este proyecto no usa LORA32 y es opcional usar la pantalla OLED. En cualquier caso se necesita el pinout de la placa de desarrollo ESP32 usada
Conexiones LILYGO T3 - AD9850
Frecuencias FT8
80m: 3573000 Hz
40m: 7074000 Hz
30m: 10136000 Hz
20m: 14074000 Hz
17m: 18100000 Hz
15m: 21074000 Hz
12m: 24915000 Hz
10m: 28074000 Hz
6m: 50313000 Hz
COMPILACION
Descargar https://github.com/F4GOJ/AD9850 y desde Sketch de IDE Arduino incluir biblioteca ZIP
PRUEBAS
Por el momento y con una maplificador TQP3M9037 se ha obtenido una salida visible con un SDR con el programa de TEST, pero no se obtiene ninguna decodificación, ni señal visible con el programa principal
(En construcción)
Referencias
https://github.com/pengowray/ft8play
https://github.com/kholia/ft8_encoder_web
Prohibida la reproducción parcial o total de este artículo sin permiso previo del autor






No hay comentarios:
Publicar un comentario