OpenX6X00 v0.3.7 adiciona planos de banda regionais e aprimora o Winlink nos rádios Xiegu

A versão mais recente do firmware comunitário acrescenta planos de banda regionais, um fluxo de trabalho mais claro para o Winlink e o modem experimental Mercury aos Xiegu X6100 e X6200. Ela também mostra quanto uma rádio definida por software moderna pode mudar com programas executados diretamente no próprio equipamento.

Por muito tempo, um transceptor de HF foi definido principalmente pelo painel frontal e pelo firmware fornecido pelo fabricante. O OpenX6X00 muda essa perspectiva para os Xiegu X6100 e X6200. A versão 0.3.7 adiciona planos de banda para diferentes regiões da IARU, restrições por classe de licença nos Estados Unidos, uma interface reformulada para o Winlink e o modem experimental Mercury. Esses recursos se somam aos aplicativos de modos digitais, ao registro de contatos, ao controle pelo navegador e a outros programas executados diretamente no rádio.

Essa diferença tem impacto prático. Um notebook pode adicionar modos digitais e funções de rede a praticamente qualquer transceptor, mas também exige outra tela, mais cabos e mais um equipamento para alimentar e solucionar problemas. O OpenX6X00 integra muitas dessas funções ao ambiente computacional que já existe no rádio. Portanto, não se trata apenas de uma nova interface: o software permite reunir operação, registro de contatos e alguns recursos de rede em um único sistema.

A versão 0.3.7 marca mais um passo nessa mudança. Ela não adiciona um novo estágio de RF nem altera o firmware de banda base que controla as funções básicas do transceptor. Em vez disso, amplia a forma como a parte Linux do rádio interpreta as regras de operação, apresenta as comunicações digitais e protege os controles acessíveis pela web. As mudanças também mostram os desafios de manter um projeto de firmware aberto: os novos recursos precisam funcionar em dois rádios relacionados, respeitar diferenças entre os planos de operação de cada país e continuar seguros quando o software pode ser acessado pela rede local ou remotamente.

De interface alternativa a plataforma de software

O OpenX6X00 funciona na parte Linux dos X6100 e X6200 e é executado a partir de um cartão microSD. Os rádios mantêm um firmware de banda base separado para funções como DSP, RF, controle de potência e manipulador. O OpenX6X00 se comunica com essa parte, mas não a substitui. Essa separação permite que o projeto evolua a interface e os aplicativos enquanto utiliza o firmware existente para as funções fundamentais do transceptor.

Essa distinção é importante porque a expressão “firmware aberto” pode dar a entender que todas as partes do rádio foram substituídas ou podem ser modificadas livremente. Neste caso, o projeto controla uma camada de software significativa, mas a banda base continua sendo um componente separado fornecido pela Xiegu. O sistema operacional, os aplicativos, a interface de controle e as ferramentas web podem mudar independentemente do firmware que gerencia o hardware de rádio. Para o usuário, isso significa que um recurso disponível no OpenX6X00 ainda pode depender do que a banda base subjacente oferece.

A história do projeto também ajuda a entender seu alcance. O OpenX6X00 surgiu a partir da última versão aberta do firmware para o X6100, depois que o projeto original se tornou fechado. Seus responsáveis afirmam ter removido serviços que se comunicavam com sistemas externos e continuado o desenvolvimento de forma aberta. Desde então, o sistema passou a incluir, entre outros recursos, um painel de controle pelo navegador, uma visualização do DX Cluster, funções de log, programas para atividades ao ar livre e vários modos digitais. A nova versão amplia esse ambiente de software em vez de tratar cada função como um acessório independente.

O computador integrado muda a configuração de uma estação portátil. Quando um aplicativo de modo digital é executado no rádio, talvez não seja necessário conectar um computador para decodificar ou transmitir nos modos compatíveis. Se a mesma plataforma também oferecer um log e ferramentas de ativação, algumas tarefas poderão ser feitas sem alternar entre dispositivos. O controle pelo navegador acrescenta outra possibilidade: um celular, tablet ou computador conectado à rede local pode operar o rádio por meio de uma interface web. Juntos, esses recursos reduzem a dependência de um computador externo para muitas tarefas digitais e de rede.

Essa integração tem limites. Os controles físicos, a tela, os caminhos de áudio e as capacidades da banda base continuam determinando o que o software pode fazer. Um aplicativo Linux pode oferecer uma nova forma de operação, mas não elimina as limitações do hardware nem garante que todos os recursos funcionem da mesma maneira nos dois modelos. A diferença entre a camada de aplicativos e a banda base é especialmente relevante ao comparar recursos, investigar um problema ou decidir se vale a pena atualizar. Uma plataforma de software mais capaz amplia as possibilidades do rádio, mas o projeto de hardware continua definindo seus limites.

Planos de banda ajustados à região

A mudança mais visível da versão 0.3.7 talvez seja o sistema ampliado de planos de banda. As versões anteriores exibiam na faixa de plano de banda apenas o plano da Região 1 da IARU. A nova versão adiciona as Regiões 2 e 3, além dos planos dos Estados Unidos para as classes de licença Extra, Advanced, General e Technician. Com isso, a tela se torna mais útil para operadores cujas alocações diferem do plano originalmente compatível.

Um plano de banda é mais do que um conjunto de rótulos na tela. Ele ajuda os operadores a entender onde determinados tipos de emissão são apropriados ou permitidos e orienta as escolhas durante a sintonia. O novo sistema pode mostrar o plano selecionado na faixa correspondente, inclusive no painel do navegador. Ele também afeta recursos relacionados da interface, como a seleção de modo com base no plano e a indicação dos segmentos de CW. Nos planos dos Estados Unidos, as partes que não podem ser usadas pela classe de licença selecionada aparecem em cinza, com a indicação “out” quando aplicável.

A seleção automática usa as informações de localização disponíveis para escolher uma região da IARU. Primeiro, considera uma posição obtida por GPS; depois, o locator Maidenhead configurado; por fim, o país associado ao indicativo. Se nenhum desses dados estiver disponível, o rádio mantém a região selecionada anteriormente. Essa sequência faz sentido para um rádio portátil, que pode ser usado em locais diferentes, e também oferece uma alternativa para operadores sem GPS ou sem locator configurado.

A seleção automática não escolhe um plano dos Estados Unidos associado a uma classe de licença. Saber que o rádio está nos Estados Unidos não permite que o software determine os privilégios do operador. Um plano regional, por si só, não consegue fazer essa distinção, então os operadores norte-americanos precisam selecionar manualmente o país e a classe de licença. Essa é uma decisão sensata: a automação pode simplificar a configuração quando as informações necessárias estão disponíveis, mas não deve tentar adivinhar um dado regulatório que o sistema não pode inferir.

Em alguns casos, o plano regional também modifica a lista de bandas do rádio. Nas Regiões 2 e 3, as entradas de 160 m, 80 m, SSB em 40 m e 6 m podem adotar os limites da região na primeira inicialização após a atualização, desde que o operador não tenha editado essas entradas. Na Região 1, os limites existentes não são alterados. Essa diferença importa porque faixas fixas que funcionam em uma região talvez não correspondam às alocações ou às práticas operacionais de outra.

Para quem opera em atividades portáteis, esse recurso pode reduzir pequenas divergências na interface que ainda assim têm consequências práticas. Um rádio levado para outro país, configurado para uma região diferente ou usado de acordo com outro plano nacional deve mostrar informações apropriadas àquele contexto. A visualização do plano de banda não substitui o conhecimento das regras aplicáveis, e uma única configuração não consegue contemplar todas as variações nacionais. Ainda assim, ela deixa mais visível o contexto operacional selecionado e ajuda a alinhar a indicação de frequência a esse contexto.

O projeto informa que testou a visualização e as entradas da lista de bandas em uma versão para PC e em um X6100 de bancada, usando os planos das Regiões 2 e 3 e os planos US General e US Technician. Isso fornece uma referência útil sobre o comportamento da interface, mas não equivale a uma certificação regulatória formal nem a uma avaliação completa de todas as combinações possíveis de localização e licença. De acordo com as notas de lançamento, a seleção automática com base em uma posição GPS não foi testada em um rádio. É importante considerar essas ressalvas: os recursos regionais são práticos, mas o operador continua responsável por selecionar e respeitar as permissões corretas.

Winlink mais próximo de uma operação integrada ao rádio

O Winlink é uma das partes mais importantes da atualização porque conecta o radioamadorismo ao e-mail e às mensagens armazenadas e retransmitidas por redes de rádio. Em HF, ele pode ser útil quando não há acesso convencional à internet ou quando o operador quer trocar mensagens por meio de um gateway de rádio. O fluxo de trabalho do Winlink no OpenX6X00 usa ARDOP, um protocolo digital desenvolvido para comunicação de dados por rádio. A nova versão busca tornar o processo de conexão mais compreensível e facilitar o diagnóstico de problemas.

A interface atualizada adiciona um cartão “Before you connect”, que mostra como o Winlink vai utilizar o rádio. Outro cartão, dedicado à conexão, explica por que uma tentativa falhou e quais ações podem ajudar em seguida. Assim, o software não se limita a oferecer um botão de conexão: ele tenta deixar mais claras as condições da operação e os motivos de uma falha. Ao solucionar problemas em uma conexão HF, essas informações podem ser mais úteis do que uma mensagem genérica de erro, especialmente porque a configuração do rádio, os parâmetros do modem e a disponibilidade do gateway influenciam o resultado.

O comportamento da largura de banda do ARDOP também foi revisado. A página do rádio agora usa a maior largura de banda ARDOP para cada conexão. Na configuração descrita, o padrão é 500 Hz quando a lista de gateways solicita uma opção 2000MAX. As notas de lançamento também informam que uma senha digitada nas configurações do próprio aplicativo é mantida. Esses detalhes podem parecer pequenos, mas ajudam a determinar se uma ferramenta integrada será confiável durante uma operação real.

Outras mudanças afetam os controles e os logs enquanto um aplicativo digital está aberto. Nesse estado, o teclado fica indisponível, e os logs podem ser baixados juntos com as senhas ocultadas. As medidas atendem a duas necessidades distintas: evitar interações inadequadas enquanto um aplicativo controla o rádio e impedir a exposição desnecessária de informações confidenciais nos logs exportados. Um rádio capaz de se comunicar pela rede precisa tratar sua configuração e seus dados armazenados como parte do ambiente operacional.

A versão 0.3.7 também adiciona o Mercury como uma segunda opção experimental de modem para o Winlink. O Mercury está associado ao projeto HERMES e tem um requisito de compatibilidade específico: a estação remota precisa usar o Mercury 1.9.20 ou posterior. De acordo com a descrição do lançamento, o usuário seleciona o Mercury no Pat pela opção VARA HF. Os operadores devem conhecer esse detalhe antes de tentar se conectar. Como o Mercury é experimental nesta versão, sua integração deve ser vista como um recurso adicional em desenvolvimento, e não como uma garantia de compatibilidade com todos os gateways ou clientes Winlink.

Essa ressalva é importante nas redes de rádio. Um modem só é útil se a outra ponta puder trocar dados usando um protocolo e uma configuração compatíveis. Uma implementação local pode estar tecnicamente completa, mas ainda ter utilidade prática limitada se o restante da rede não tiver adotado o protocolo. Por isso, neste primeiro momento, o Mercury pode ser mais interessante para quem está experimentando, fazendo testes ou consegue coordenar a operação com estações compatíveis. Sua utilidade em maior escala dependerá da adoção fora do próprio rádio.

O desenvolvimento do Winlink também revela um desafio de projeto mais amplo. Um aplicativo executado no rádio precisa administrar decisões que, em um programa de computador, talvez aparecessem distribuídas em várias janelas: qual modem está ativo, qual largura de banda está sendo solicitada, se o rádio está pronto para transmitir e o que aconteceu depois de uma conexão malsucedida. Reunir esses elementos pode simplificar a estação, mas torna essencial apresentar as informações com clareza. Se a interface ocultar um estado importante, uma configuração compacta pode ser mais difícil de diagnosticar do que outra baseada em notebook.

Modos digitais e estação portátil

Os demais recursos do OpenX6X00 ajudam a contextualizar as mudanças no Winlink. O projeto oferece aplicativos executados no próprio rádio para modos como FT8, FT4, FT2, JS8, WSPR, PSK31, PSK63, Olivia, RTTY, SSTV, WeFax e Navtex com DSC somente para recepção. O nível exato de suporte varia de acordo com cada aplicativo e modo, mas a ideia geral é a mesma: o ambiente Linux do rádio executa programas que normalmente rodariam em um computador conectado. A versão 0.3.7 se apoia nessa base em vez de introduzir a operação digital do zero.

Isso pode mudar a montagem física de uma estação portátil. Um operador em campo talvez já leve um transceptor, uma bateria, uma antena e um celular ou tablet para consultar mapas e registrar contatos. Acrescentar um notebook para cada modo digital aumenta o peso e o consumo de energia, além de exigir mais cabos e configurações de software. Quando parte dessas tarefas é transferida para o rádio, a estação pode se tornar mais autônoma. Isso não torna todos os computadores desnecessários: uma tela maior, ferramentas de log conhecidas ou programas especializados ainda podem ser preferíveis. Mesmo assim, o rádio pode assumir mais tarefas essenciais diretamente.

Cada modo impõe exigências operacionais diferentes. O FT8 e os modos relacionados a sinais fracos dependem de temporização precisa, decodificação e transmissões sincronizadas. O WSPR costuma ser usado para observar a propagação por meio de beacons de baixa potência. O JS8 oferece mensagens digitadas e comunicações que podem usar retransmissores. O Winlink atende a outra finalidade e transporta mensagens por gateways. Reunir essas ferramentas no rádio pode facilitar a alternância entre experimentação, contatos e troca prática de mensagens, sem precisar reorganizar a estação em torno de um computador separado a cada vez.

A tela e os controles fazem parte da mesma experiência. Um waterfall pode representar os sinais de modo a facilitar a sintonia e a avaliação da atividade. A visualização do cluster pode ligar os spots à sintonia do rádio. O controle pelo navegador permite usar um dispositivo familiar como interface remota. O valor está na relação entre esses recursos: um spot pode orientar a escolha de frequência, um aplicativo digital pode controlar uma transmissão e um log pode registrar o contato no mesmo ambiente de software.

A integração também concentra a complexidade. Um aplicativo digital precisa de acesso confiável ao áudio, à frequência e ao controle de transmissão. Uma interface de navegador deve se comunicar com o rádio sem permitir que uma página não confiável use os controles de forma indevida. O log precisa preservar dados corretos dos contatos, enquanto os serviços de rede devem distinguir os usuários previstos de outros clientes. Cada função pode parecer simples isoladamente, mas as interações entre elas exigem projeto e testes cuidadosos.

A evolução do projeto mostra esse desafio. Versões anteriores adicionaram suporte ao X6200, controle remoto pelo navegador, Winlink em HF e outros recursos. Durante o desenvolvimento também surgiram defeitos no registro, no controle TCI, no PTT pelo navegador e em outras partes do sistema. Os responsáveis informam que uma revisão da versão 0.3.6 encontrou 14 defeitos, incluindo problemas no PTT pelo navegador, no configurador, no TCI e na interface web. A nova versão corrige esses problemas e mostra que desenvolver firmware aberto significa tanto adicionar recursos quanto corrigir as interações entre eles.

Segurança passa a fazer parte da operação de rádio

Um rádio com configurador web, controle remoto pelo navegador e serviços de rede tem um perfil de segurança diferente de um equipamento operado apenas por controles físicos. A versão 0.3.7 adiciona proteção contra DNS rebinding, um tipo de ataque em que um site malicioso pode fazer o navegador tratar um nome controlado pelo site como se apontasse para um dispositivo da rede local. Se o navegador conseguir acessar as páginas de configuração ou controle do rádio, um projeto vulnerável poderá expor ajustes ou permitir ações por meio da sessão do navegador do usuário.

O OpenX6X00 v0.3.7 restringe certas operações web aos nomes próprios do rádio, como seu nome de host local ou um nome configurado para ele. A restrição se aplica ao salvamento de alterações no configurador web e às páginas e conexões relacionadas, enquanto os programas TCI continuam podendo se conectar por qualquer nome. Essa separação atende a uma necessidade prática: as superfícies de controle pelo navegador e as interfaces de comunicação entre programas nem sempre precisam das mesmas regras de nomenclatura. Restringir operações web sensíveis a determinados nomes pode reduzir o risco de um site enganar o navegador e fazê-lo interagir com o rádio.

O trabalho de segurança desta versão faz parte de uma série de auditorias e revisões de código. O projeto informa que a análise da versão 0.3.6 encontrou 14 defeitos, corrigidos na versão 0.3.7. Auditorias independentes anteriores também levaram a ajustes no controle TCI, no tratamento de dados ADIF, na edição dos logs e no funcionamento das sessões de navegador. Esses problemas não são apenas cosméticos. Uma falha no controle de transmissão pode afetar a passagem correta entre transmissão e recepção. Um defeito no tratamento dos dados pode corromper logs ou deixar o sistema instável.

A atenção dada ao PTT pelo navegador é especialmente importante porque o controle remoto muda o significado do botão de transmissão. Um botão físico está diretamente associado ao operador e ao rádio. Um comando no navegador depende da conexão de rede e do estado do software. Se a conexão travar e depois voltar, a interface não deve transmitir inesperadamente com base em um comando antigo. As notas de lançamento informam que foi corrigido um defeito em que manter o PTT do navegador pressionado podia fazer o rádio transmitir novamente quando uma conexão interrompida fosse restabelecida. Esse é o tipo de situação-limite que uma interface bem projetada precisa tratar explicitamente.

A segurança também influencia como o acesso remoto é oferecido. O OpenX6X00 pode usar o Tailscale para operação remota, e a versão 0.3.7 adiciona suporte ao Tailscale Funnel, que permite acessar certas páginas do navegador de fora da rede local. O lançamento diferencia as páginas Panel e Screen de outros serviços, como o configurador, os programas TCI e os aplicativos Winlink. Essa distinção importa porque “acesso remoto” não representa uma permissão única: um painel de controle ao vivo, uma interface de configuração e um serviço de rede oferecem capacidades diferentes e envolvem riscos distintos.

O Funnel tem limites específicos. O navegador precisa ser pareado com o rádio antes de usar o link remoto. Depois, um navegador pareado em casa pode receber um link próprio para uso fora dela. O serviço público se limita às páginas Panel e Screen e aos sockets relacionados; é necessário usar um navegador que tenha sido pareado anteriormente em casa. Os outros serviços não ficam acessíveis pelo Funnel. O recurso foi testado com um substituto do daemon do Tailscale e em uma versão para PC, mas ainda não em um tailnet real com um rádio. Por isso, os responsáveis pedem comentários de usuários que testarem o recurso nesse ambiente.

Esse recurso vai além de um simples botão de conveniência. Publicar um serviço na internet muda quem pode tentar acessá-lo e qual tipo de autenticação é necessário. O OpenX6X00 separa o acesso do navegador remoto dos demais serviços do rádio e exige um pareamento anterior. O projeto também informa que o nome de host público ficará visível nos registros públicos de certificados. Operadores que não precisam controlar o rádio pelo navegador à distância podem deixar o Funnel desativado. Quem usar o recurso deve saber quais páginas se tornam acessíveis e quais continuam indisponíveis.

Limites de potência, manutenção e o que a versão 0.3.7 representa

O comportamento da potência de transmissão do X6200 é outra mudança importante para a operação. Na versão 0.3.7, a interface limita a potência selecionável a 8 W e a 5 W quando o rádio está funcionando com bateria. Um limite de software pode ser uma proteção útil, especialmente em uma estação portátil cuja alimentação varia, mas não deve ser confundido com uma declaração geral sobre a potência máxima do rádio. É um limite aplicado pelo controle deste firmware e pode influenciar a configuração conforme a fonte de alimentação.

A versão também corrige alguns comportamentos menores. O nível Moni padrão do X6100 passa a ser zero, assim como no X6200, mas um nível já configurado pelo operador é mantido. Quando um VFO é sintonizado além do limite de uma banda, o outro VFO continua na posição anterior. Também foram corrigidos defeitos relacionados ao controle pelo navegador, ao TCI, aos formulários do Wavelog e ao configurador. Cada ajuste contribui para uma operação mais previsível, mesmo sem acrescentar um novo recurso de destaque.

Quem já usa o OpenX6X00 pode atualizar diretamente pelo rádio. As notas de lançamento informam que um X6100 ou X6200 com uma instalação compatível v0.2.x ou v0.3.x pode receber a atualização pela função integrada. Novas imagens de cartão estão disponíveis para primeiras instalações e para rádios que não iniciam o suficiente para executar a atualização. Algumas imagens antigas precisam ser substituídas para incluir mudanças anteriores no bootloader ou no driver Wi-Fi. Essa necessidade depende do modelo e da versão instalada; portanto, nem todo usuário precisa regravar o cartão para instalar a v0.3.7.

A separação entre o pacote de atualização e a imagem do cartão é uma vantagem prática da arquitetura. Aplicativos e páginas web podem ser atualizados sem regravar a imagem completa do sistema quando o kernel, os drivers e os componentes de inicialização não mudam. O projeto informa que a v0.3.7 não exige uma nova imagem nos rádios que já utilizam uma imagem anterior compatível. As configurações e os logs continuam na partição de dados do cartão, embora seja recomendável fazer um backup antes de atualizar. Separar o sistema operacional das aplicações pode tornar a manutenção menos disruptiva, mas os usuários ainda precisam saber quando uma imagem completa é necessária.

A possibilidade de rollback também faz parte do processo de atualização. O rádio mantém a versão anterior disponível para retornar a ela automaticamente caso a nova instalação não consiga iniciar corretamente. Isso não elimina a importância de salvar as configurações e os logs, nem torna todas as atualizações isentas de risco. Ainda assim, oferece um mecanismo de recuperação importante em um dispositivo embarcado, no qual uma atualização malsucedida poderia exigir um procedimento mais complexo para regravar o cartão.

O projeto também reflete uma tendência mais ampla no radioamadorismo. Transceptores SDR incluem cada vez mais hardware computacional de uso geral, funções de rede e interfaces definidas por software. Isso permite acrescentar recursos depois que o rádio chega ao mercado, mas também faz da qualidade da manutenção do software parte do seu valor no dia a dia. A lógica dos planos de banda, a interoperabilidade dos modems, a segurança do navegador, a integridade dos logs e o controle de potência são questões de software que afetam a operação real. O desenvolvimento aberto permite que os usuários acompanhem essas mudanças e informem problemas. Ao mesmo tempo, exige que os responsáveis mantenham coerente um sistema cada vez maior.

Por isso, o OpenX6X00 v0.3.7 é mais do que uma lista de alterações. Os planos de banda regionais adaptam melhor a interface a operadores de diferentes partes do mundo. As mudanças no Winlink buscam tornar as conexões mais compreensíveis, enquanto o Mercury oferece uma possibilidade experimental para estações compatíveis. As correções de segurança e as revisões de código mostram que o controle remoto pelo navegador também afeta a confiabilidade operacional do rádio. Em conjunto, o lançamento transforma os Xiegu X6100 e X6200 em plataformas nas quais o firmware influencia como um transceptor é usado, conectado à rede e mantido.

Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.

This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.