← Todas as publicações

Projetos e Engenharia de Software

Do HFTA ao OpenHFTA: conectando décadas de conhecimento científico à tecnologia web

Como um projeto de radioamadorismo reúne engenharia de software, Python, Fortran, APIs e computação científica para tornar a análise de terrenos e antenas mais acessível.


Fernando Fernandes | Desenvolvimento de Software, Engenharia e Radioamadorismo

Quando o radioamadorismo encontra a engenharia de software

Quem pratica radioamadorismo, especialmente nas modalidades de DX e competição, sabe que o desempenho de uma estação depende de muito mais do que a potência do transmissor ou o ganho nominal de uma antena.

A altura de instalação, as características do terreno, a direção de transmissão e os ângulos de elevação podem influenciar significativamente a maneira como o sinal é irradiado.

Uma antena instalada a determinada altura pode apresentar resultados muito diferentes dependendo da topografia ao seu redor. Uma elevação, uma encosta ou mesmo uma mudança relativamente pequena no perfil do terreno pode alterar seu padrão de radiação.

É nesse contexto que entra o HFTA (High Frequency Terrain Assessment), uma ferramenta que se tornou referência na análise da influência do terreno sobre o padrão de radiação de antenas de HF.

Meu envolvimento com o OpenHFTA nasceu justamente dessa aproximação entre duas áreas que fazem parte da minha vida: o desenvolvimento de software e o radioamadorismo.

A oportunidade de participar de um projeto que conecta algoritmos científicos desenvolvidos ao longo de décadas com uma arquitetura web moderna foi especialmente interessante. Mais do que construir uma interface, o desafio envolve preservar o conhecimento existente, compreender o funcionamento de tecnologias diferentes e estabelecer uma integração confiável entre elas.

O que é o HFTA e por que ele é importante?

O HFTA foi desenvolvido por Richard Dean Straw, N6BV, radioamador e engenheiro que contribuiu significativamente para o desenvolvimento de ferramentas de análise de antenas e para a literatura técnica da American Radio Relay League (ARRL).

Seu trabalho com o HFTA teve origem em estudos e desenvolvimentos iniciados na década de 1990, e o programa passou a integrar o material do ARRL Antenna Book a partir de 2003.

A proposta é relativamente simples de compreender, embora sua implementação envolva modelos matemáticos complexos: avaliar como o perfil do terreno modifica o padrão de radiação de uma antena em diferentes ângulos de elevação.

Em modelos convencionais, frequentemente analisamos o desempenho de antenas considerando um terreno plano. Essa aproximação é útil, mas nem sempre representa as condições reais de uma instalação.

O HFTA permite considerar um perfil topográfico específico, levando em conta parâmetros como frequência, altura da antena, características do solo, reflexões e difração.

Para operadores interessados em contatos de longa distância e competições, essas informações ajudam a responder perguntas práticas:

  • Qual altura de antena apresenta melhor desempenho para determinada direção?
  • Uma torre mais alta necessariamente produzirá melhores resultados?
  • Como uma encosta ou elevação próxima influencia os ângulos de radiação?
  • Vale a pena mudar a localização de uma antena?
  • Como comparar configurações de antenas e alturas antes de investir em uma instalação?

O programa não elimina a necessidade de experimentação ou medições reais, mas oferece uma base técnica para fundamentar decisões.

O ângulo de elevação e sua importância

Nas comunicações de longa distância por HF, grande parte dos contatos depende da propagação ionosférica.

O sinal irradiado em determinados ângulos pode encontrar condições favoráveis de propagação, dependendo da frequência, da região de destino, das condições ionosféricas e de outros fatores.

O HFTA permite visualizar como a energia irradiada se distribui pelos diferentes ângulos de elevação, considerando a influência do terreno em uma direção específica.

É importante compreender essa distinção: o HFTA não prevê sozinho se um contato será realizado. Seu foco está no comportamento do sistema antena-terreno.

As condições da ionosfera, o ruído, a potência, a estação receptora e diversos outros fatores continuam sendo determinantes para o resultado de uma comunicação.

O legado de Dean Straw, N6BV

A importância do HFTA vai além de sua utilidade operacional.

Dean Straw contribuiu para aproximar conhecimentos de engenharia, modelagem matemática e radioamadorismo prático, permitindo que operadores avaliassem suas instalações com ferramentas antes pouco acessíveis.

Seu trabalho também envolveu outras aplicações conhecidas, como Yagi for Windows e Transmission Lines for Windows.

Dean faleceu em julho de 2025, deixando um legado importante para a comunidade radioamadorística.

A continuidade desse conhecimento é uma das motivações centrais do OpenHFTA.

O próprio projeto se apresenta como uma iniciativa de preservação, tendo como referência o comportamento do HFTA original.

A intenção não é simplesmente substituir um programa antigo por outro mais moderno, mas preservar sua utilidade, tornar seu funcionamento mais acessível e permitir que novas gerações estudem e utilizem esses conhecimentos.

Essa preocupação também orienta uma decisão importante de engenharia: mudanças no núcleo numérico precisam ser avaliadas com cuidado, porque uma alteração aparentemente pequena pode modificar os resultados dos cálculos.

OpenHFTA: preservação científica e modernização tecnológica

O OpenHFTA é uma iniciativa de código aberto voltada à análise de terrenos e padrões de radiação de antenas de HF, com o objetivo de reproduzir o comportamento do HFTA original em ambientes modernos.

O projeto mantém uma implementação numérica em Fortran, disponibilizando uma interface em Python para executar análises e trabalhar com seus resultados.

Conheça o site do projeto: OpenHFTA — plataforma web.

A implementação pública pode ser consultada no repositório do RIO DX Group:

github.com/RioDXGroup/openhfta

A evolução para uma interface web acrescenta outra dimensão ao projeto: permitir que as análises sejam solicitadas e visualizadas pelo navegador, sem exigir que o usuário final instale ou compile o núcleo científico.

Essa evolução exige integrar componentes com responsabilidades bastante diferentes.

De um lado, temos algoritmos numéricos que executam cálculos de propagação. Do outro, uma aplicação web precisa receber parâmetros, validar dados, processar arquivos, executar rotinas e apresentar resultados compreensíveis.

A solução para esse problema passa por uma arquitetura organizada em camadas.

A arquitetura: React, FastAPI, Python e Fortran trabalhando juntos

Um dos aspectos mais interessantes do trabalho com OpenHFTA é a integração entre tecnologias de diferentes gerações.

Na arquitetura web apresentada para o projeto, o processamento segue este fluxo:

React → FastAPI → Python/NumPy → ctypes → Fortran → JSON → Plotly

Cada componente possui uma responsabilidade específica.

React: a experiência do usuário

A aplicação web utiliza React para construir a interface com a qual o radioamador interage.

É nessa camada que o usuário informa parâmetros da análise, seleciona arquivos de terreno, escolhe configurações de antena e visualiza os resultados.

O React não executa os algoritmos científicos de propagação.

Sua função é oferecer uma experiência organizada e facilitar a comunicação com os serviços responsáveis pelo processamento.

Essa separação permite evoluir a interface sem precisar modificar diretamente o núcleo matemático.

FastAPI: a comunicação entre a web e o processamento

O backend utiliza FastAPI, framework Python voltado à construção de APIs HTTP.

Sua responsabilidade é receber requisições, validar parâmetros, tratar arquivos de entrada e organizar a execução dos cálculos.

A arquitetura descrita utiliza endpoints como:

  • POST /api/analyze, para solicitar análises.
  • POST /api/compare, para trabalhar com comparações entre cenários.

Os parâmetros e arquivos de terreno podem ser enviados utilizando multipart/form-data, permitindo que uma única requisição contenha campos e arquivos.

A API valida os dados antes de encaminhá-los ao processamento. Em situações de falha de validação, o FastAPI normalmente utiliza o código HTTP 422.

Ao final, o resultado é disponibilizado em JSON, um formato estruturado que pode ser interpretado pela interface ou por outros clientes.

Essa abordagem cria um contrato claro entre frontend e backend.

Python e NumPy: preparação dos dados

O Python atua como camada intermediária entre a API e o núcleo numérico.

Antes de executar o cálculo, é necessário preparar os parâmetros, interpretar os arquivos e garantir que os dados estejam representados de maneira compatível com as rotinas Fortran.

É nesse ponto que o NumPy contribui, oferecendo estruturas eficientes para trabalhar com arrays numéricos.

Essa preparação envolve cuidados importantes, como unidades de medida, tipos numéricos e organização dos dados em memória.

Um erro nessa etapa pode comprometer o resultado mesmo quando a rotina científica está funcionando corretamente.

ctypes: a ponte entre duas linguagens

A integração entre Python e Fortran utiliza o módulo ctypes, parte da biblioteca padrão do Python.

Por meio dele, o Python pode carregar uma biblioteca nativa compilada e executar funções disponibilizadas por ela.

Isso permite aproveitar o desempenho e a lógica numérica implementada em Fortran sem reescrever os algoritmos na linguagem utilizada pelo backend.

Fortran: o núcleo científico

O Fortran ocupa uma posição central nessa arquitetura.

Embora seja uma linguagem associada às primeiras gerações da computação, continua relevante em aplicações científicas, engenharia e processamento numérico.

No OpenHFTA, o núcleo Fortran executa os cálculos matemáticos relacionados à interação entre a radiação da antena e o perfil do terreno.

O código considera fenômenos como reflexão, difração e interferência entre diferentes trajetórias de propagação.

A escolha de manter essa camada em Fortran não é apenas uma questão de desempenho.

Reescrever algoritmos científicos em outra linguagem exige mais do que traduzir instruções. É necessário demonstrar que os resultados continuam compatíveis com o modelo de referência.

Preservar o núcleo e criar interfaces modernas ao seu redor permite reduzir o risco de introduzir diferenças numéricas não intencionais.

Plotly: transformando resultados em informação

Depois que o cálculo é concluído, seus resultados precisam ser apresentados de maneira útil.

Na interface web, o Plotly permite produzir gráficos interativos, facilitando a visualização dos padrões de elevação e a comparação entre diferentes cenários.

A biblioteca possibilita explorar curvas, observar valores específicos e compreender visualmente o comportamento calculado.

Essa é uma etapa importante porque um resultado numérico, isoladamente, nem sempre comunica claramente seu significado.

Docker e Nginx: a infraestrutura

A arquitetura também utiliza Docker para empacotar os serviços e organizar seu ambiente de execução.

O Nginx atua na entrega da interface web e no encaminhamento das requisições para a API, por meio do proxy reverso.

Essa organização facilita a separação dos componentes e a manutenção dos serviços.

Um detalhe importante é que o usuário final não precisa instalar um compilador Fortran em seu computador. O núcleo compilado é executado no ambiente do servidor.

O desafio técnico mais delicado: Python conversando com Fortran

Uma das partes mais interessantes dessa integração acontece em um nível que o usuário não vê.

Quando dois sistemas se comunicam por HTTP, normalmente trabalham com representações como JSON e contratos definidos por rotas e estruturas de dados.

Já na chamada de uma biblioteca nativa, o contrato é diferente.

Nesse cenário entra o conceito de ABI (Application Binary Interface).

A ABI define como os dados e as funções são representados e utilizados no nível binário. Ela envolve tipos, tamanhos, passagem de parâmetros, organização da memória e identificação das funções exportadas.

No OpenHFTA, a integração utiliza o símbolo ytwcore1_, disponibilizado pela biblioteca nativa OpenYTWCore na configuração documentada.

Entre os cuidados necessários estão as correspondências de tipos:

  • REAL*4, utilizado no núcleo Fortran, corresponde a um número real de 32 bits, representado por c_float no ctypes.
  • INTEGER*2 corresponde a um inteiro de 16 bits, representado por c_int16.
  • Os arrays precisam ser organizados de maneira contígua e com os tamanhos esperados.
  • Os parâmetros devem respeitar as convenções de passagem por referência utilizadas pelo núcleo.

A rotina principal também disponibiliza o buffer Pattern_dB(0:139), contendo 140 posições correspondentes aos ângulos de 0,25° até 35°, em intervalos de 0,25°.

Esses detalhes são fundamentais.

Um desacordo entre os tipos ou entre as estruturas de memória pode produzir valores incorretos, corromper dados ou até provocar falhas de execução.

Python e Fortran precisam concordar não apenas sobre o valor transmitido, mas sobre a maneira exata como ele está representado na memória.

Esse é um excelente exemplo de como o desenvolvimento de software exige compreender conceitos que vão além da sintaxe de uma linguagem.

O que acontece dentro do cálculo?

O núcleo científico trabalha com conceitos de eletromagnetismo, ótica geométrica e métodos numéricos.

Não é necessário dominar todas as equações para compreender a proposta, mas alguns conceitos ajudam a entender o funcionamento.

Reflexão no terreno

Quando uma onda eletromagnética encontra o solo, parte de sua energia pode ser refletida.

A intensidade e a fase dessa reflexão dependem de fatores como a geometria de incidência, as propriedades elétricas do terreno e a polarização.

O HFTA utiliza coeficientes de reflexão de Fresnel para representar essa interação.

A combinação entre o campo direto e os campos refletidos pode produzir reforços ou cancelamentos em determinados ângulos.

Difração em obstáculos

A difração está relacionada ao comportamento das ondas ao encontrarem bordas e obstáculos.

No terreno, cristas e mudanças na topografia podem influenciar a distribuição do campo eletromagnético.

O modelo utiliza princípios da Uniform Theory of Diffraction (UTD), permitindo representar contribuições difratadas que a ótica geométrica, isoladamente, não descreve adequadamente.

Ray tracing e composição dos campos

O núcleo utiliza técnicas de traçado de raios para analisar trajetórias associadas à propagação direta, reflexões e difrações.

É importante lembrar que uma trajetória desenhada em um modelo não equivale, por si só, a uma medição de potência.

As contribuições precisam considerar amplitude e fase.

O campo resultante é calculado pela combinação dessas contribuições, permitindo construir o padrão de elevação.

O modelo implementado tem como foco a polarização horizontal e a análise de um perfil de terreno em uma direção específica.

Não se trata de um simulador tridimensional completo de todas as formas de propagação.

Traçado de raios sobre o perfil do terreno no OpenHFTA, com trajetórias diretas, refletidas e difratadas.
Visualização do traçado de raios sobre o terreno. As cores distinguem os tipos de trajetória calculados. Ver em tamanho original ↗

Arquivos de terreno e estatísticas de propagação

Dois formatos merecem destaque no funcionamento do HFTA e do OpenHFTA.

Arquivos .PRO

Os arquivos .PRO representam perfis topográficos.

Eles contêm pares de valores que descrevem a distância em relação à estação e a elevação correspondente do terreno.

Essas informações permitem representar a topografia em um determinado azimute, que será utilizada pelo núcleo para calcular a influência do terreno no padrão de radiação.

A qualidade desse perfil é importante. Dados imprecisos, unidades incorretas ou uma direção inadequada podem comprometer a interpretação da análise.

Perfil topográfico do arquivo PX9-30.00.PRO, com altitude em metros ao longo da distância.
Perfil de terreno utilizado na comparação. Os dois cenários usam o mesmo perfil topográfico. Ver em tamanho original ↗

Arquivos .PRN

Os arquivos .PRN contêm distribuições estatísticas de ângulos de chegada associadas a determinados cenários de propagação.

Essas informações permitem relacionar o padrão calculado com a frequência estatística de ocorrência de diferentes ângulos.

É nesse contexto que aparece a métrica FOM (Figure of Merit).

O FOM utiliza uma ponderação dos resultados pelos ângulos de chegada, permitindo comparar configurações de antenas considerando determinado cenário estatístico.

Entretanto, essa métrica precisa ser interpretada corretamente.

Um FOM maior não significa que uma antena será superior em todas as condições operacionais. Dependendo dos objetivos da estação, determinadas faixas de ângulo podem ser mais importantes do que o desempenho médio.

Da mesma maneira, valores apresentados em dB precisam ser interpretados conforme sua referência. O HFTA original documenta resultados calibrados em dBi, mas implementações e visualizações devem preservar explicitamente a referência e as condições de normalização utilizadas.

Um exemplo prático: avaliando a altura de uma antena

Imagine uma estação de radioamadorismo que utiliza uma antena Yagi de três elementos na faixa de 20 metros, operando em 14,2 MHz.

A antena está instalada a 15 metros de altura, e o operador deseja avaliar se uma instalação a 18 metros proporcionaria alguma vantagem.

A comparação pode seguir um processo relativamente simples.

Primeiro, obtém-se um perfil topográfico .PRO na direção de interesse.

Em seguida, são definidos o modelo de antena, a frequência, as características do solo e as alturas que serão analisadas.

O sistema encaminha os parâmetros para o núcleo científico, que calcula os padrões correspondentes.

Os resultados podem então ser comparados visualmente.

A análise pode revelar mudanças na posição dos lóbulos, na intensidade relativa do campo em determinados ângulos e na distribuição do padrão de elevação.

Não é possível afirmar antecipadamente que a instalação mais alta será melhor. O resultado depende do cenário analisado.

O valor da ferramenta está justamente em permitir que essa decisão seja estudada antes da realização de alterações físicas na estação.

Para quem participa de concursos de radioamadorismo, essa capacidade de comparação pode contribuir para o planejamento de antenas, torres e configurações operacionais.

Imagens de uma comparação no OpenHFTA

As capturas abaixo mostram um cenário diferente do exemplo hipotético anterior: um dipolo em 28,50 MHz, com alturas de 10 e 15 metros, utilizando o perfil PX9-30.00.PRO e o arquivo PT9-EU.PRN. Os valores pertencem a essa simulação e não são medições de campo.

Resumo da comparação entre dipolos a 10 e 15 metros em 28,50 MHz, com métricas de pico, ângulo de elevação e FOM.
Resumo numérico dos cenários A e B, incluindo as métricas de comparação e os resultados de cada configuração. Ver em tamanho original ↗
Gráfico comparando padrões de elevação dos cenários A e B, referências de terreno plano e estatísticas PRN na faixa de 10 metros.
Padrões de elevação para os dois cenários. As curvas pontilhadas mostram as referências de terreno plano; as barras representam a distribuição estatística PRN. Ver em tamanho original ↗

Relatório da comparação em PDF

O arquivo disponibilizado acompanha as imagens para consulta e download.

Comparação OpenHFTA PDF · 210 KB Abrir relatório ↗ Baixar PDF ↓

O desafio de modernizar sem comprometer o conhecimento original

Trabalhar com software científico legado apresenta desafios diferentes daqueles encontrados em uma aplicação web convencional.

Em muitos sistemas corporativos, uma modernização busca principalmente melhorar desempenho, manutenção, segurança ou experiência do usuário.

Em uma aplicação científica, existe uma responsabilidade adicional: preservar a coerência dos resultados numéricos.

Mudanças em precisão de ponto flutuante, compiladores, tratamento de arrays, unidades ou ordem das operações podem provocar diferenças entre implementações.

No caso do OpenHFTA, o repositório estabelece a compatibilidade com o HFTA original como objetivo central.

Isso torna importantes os testes de regressão, a comparação com resultados de referência e a documentação das decisões técnicas.

A própria implementação pública contempla estruturas para testes diferenciais com a biblioteca legada, quando os arquivos originais estão disponíveis no ambiente de testes.

Esse cuidado reforça uma lição importante:

Modernizar um sistema não significa necessariamente substituir todas as suas tecnologias. Em muitos casos, a melhor decisão é preservar aquilo que já foi desenvolvido e validado, criando novas possibilidades de utilização.

A arquitetura com Python, Fortran e API HTTP é uma aplicação prática desse princípio.

Da implementação à apresentação para a comunidade

Uma experiência especialmente significativa foi participar da apresentação do OpenHFTA no encontro comemorativo dos 50 anos do Araucária DX Group, realizado em outubro de 2026, no Paraná.

O evento reuniu radioamadores, operadores de competição e pessoas envolvidas com projetos técnicos e com o desenvolvimento da atividade.

Na apresentação, procuramos dividir os assuntos de maneira complementar.

Enquanto a parte mais diretamente relacionada ao radioamadorismo abordou os fundamentos e a aplicação da ferramenta, minha participação foi direcionada à arquitetura de software, à integração entre tecnologias e à maneira como o núcleo científico se comunica com a aplicação web.

O desafio era explicar conceitos como API, chamadas nativas, Fortran e contratos de integração sem transformar a apresentação em uma discussão exclusivamente sobre programação.

Foi uma experiência importante porque colocou em prática algo que considero fundamental: a capacidade de comunicar soluções técnicas a públicos com diferentes conhecimentos.

Além do aprendizado técnico, projetos colaborativos como esse mostram o valor de reunir pessoas com experiências distintas em torno de um objetivo comum.

Assista à apresentação

Trecho da apresentação sobre o OpenHFTA, de 1:26:00 a 2:14:00 (48 minutos).

OpenHFTA: apresentação e integração entre tecnologias. Trecho selecionado: 1:26:00–2:14:00.

Assistir diretamente no YouTube a partir de 1:26:00.

O que aprendi com essa experiência

Minha participação no OpenHFTA reforçou algumas percepções que já fazem parte da maneira como procuro trabalhar com tecnologia.

A primeira é que compreender o problema é mais importante do que escolher antecipadamente a tecnologia que será utilizada.

A segunda é que sistemas desenvolvidos em épocas diferentes podem continuar relevantes, desde que suas interfaces e formas de utilização evoluam de maneira responsável.

Também ficou evidente a importância dos contratos de integração.

A interface web, a API, a camada Python e o núcleo Fortran precisam trabalhar com responsabilidades bem definidas. Cada componente possui suas particularidades, mas todos dependem de acordos claros sobre entradas, saídas e comportamento.

Outro aprendizado está relacionado à validação.

Não basta que uma aplicação execute sem apresentar erros. Em sistemas científicos, é necessário compreender se os resultados fazem sentido, se as unidades estão corretas e se a implementação preserva o comportamento esperado.

Por fim, o projeto mostra como interesses pessoais podem contribuir diretamente para o desenvolvimento profissional.

O radioamadorismo me proporciona oportunidades de estudar, experimentar e colaborar em desafios que envolvem engenharia, desenvolvimento de software e telecomunicações.

Conclusão: preservar o conhecimento também é inovar

O OpenHFTA representa uma conexão interessante entre a história da computação científica e as possibilidades oferecidas pelas tecnologias atuais.

De um lado, existe um legado de pesquisa, modelagem matemática e experimentação desenvolvido por pessoas como Dean Straw, N6BV.

Do outro, temos ferramentas como Python, FastAPI, React, bibliotecas nativas e containers, que permitem construir novas interfaces e ampliar as possibilidades de utilização desses conhecimentos.

O aspecto mais interessante dessa integração não está simplesmente em executar código Fortran por meio de uma API.

Está na possibilidade de tornar um conhecimento técnico acumulado ao longo de décadas mais acessível, preservando sua essência e abrindo caminhos para novos estudos, contribuições e experimentações.

Para mim, participar desse trabalho reforça uma ideia que considero importante tanto no radioamadorismo quanto na engenharia de software:

A inovação nem sempre começa criando algo do zero. Muitas vezes, ela acontece quando conseguimos compreender, preservar e conectar conhecimentos existentes para resolver novos desafios.

E é justamente essa combinação entre curiosidade, investigação, colaboração e tecnologia que continua me motivando a aprender e desenvolver novos projetos.

73!

Fernando Fernandes | PT9TI


Referências e leitura complementar