Do exemplo LoRa de 6 km a uma FUOTA confiável: alcance, airtime e Delta OTA em um pomar de tangerinas

Os valores de alcance e os tempos de FUOTA deste artigo não substituem medições de laboratório ou de campo. Todas as hipóteses devem ser recalculadas depois de definir o modelo real do dispositivo, a antena, o plano regional de frequências e as condições do canal.

Resumo

À primeira vista, o problema parece simples: um nó sensor baseado em LoRa consegue enviar dados de um pomar de tangerinas até um gateway? Quando o produto chega ao campo, surge uma pergunta mais difícil: como distribuir centenas de quilobytes de firmware de forma confiável pela mesma conexão?

Este estudo começa com o exemplo aproximado de 6 km para SF9/125 kHz apresentado no resumo técnico da Semtech. Ele explica por que esse número não pode ser transferido diretamente para um pomar denso e analisa a troca entre alcance e velocidade de dados criada por spreading factor (SF) e bandwidth (BW). Também explica por que um link budget não significa somar as potências de saída de dois dispositivos: é preciso avaliar em conjunto o transmissor ativo, a sensibilidade do outro receptor, os ganhos das antenas e as perdas ambientais. Depois, escolhe-se um pomar de tangerinas entre vários ambientes agrícolas e discute-se a altura das antenas. Por fim, propõe-se Delta OTA em vez de uma imagem completa, atualizações em várias etapas e seleção de rotas delta no servidor.

O resultado principal é direto: o sucesso da FUOTA não depende apenas de encontrar o maior alcance. Capacidade downlink confiável, airtime total, duty cycle, perda de pacotes, posição do gateway, verificação do bootloader e orquestração da atualização precisam ser projetados em conjunto.

1. Por que o exemplo aproximado de 6 km da Semtech não é um alcance real no pomar

O resumo técnico LoRa da Semtech apresenta um exemplo de aproximadamente 6 km para SF9/125 kHz. O mesmo documento informa que esses valores dependem do terreno (Semtech, LoRa and LoRaWAN: A Technical Overview). Os 6 km são uma referência para uma configuração de modulação específica e condições idealizadas de área aberta; não são uma garantia de alcance bidirecional confiável em um pomar de tangerinas.

Os principais motivos são:

1. A propagação em linha de visada em terreno aberto não é igual à propagação NLOS entre fileiras de árvores.
2. Uma antena de sensor próxima ao solo é diferente da antena elevada do gateway usada em um teste de catálogo.
3. O alcance do fabricante depende de um SF/BW, tamanho de pacote, antena e potência específicos.
4. O alcance utilizável deve incluir a direção mais fraca do link bidirecional e a taxa de sucesso de pacotes desejada.
5. Umidade, chuva, irrigação, densidade da folhagem e orientação das fileiras mudam durante a estação.

Estudos de campo em pomares de tangerina e outros pomares analisaram como folhas, galhos, troncos, geometria das fileiras e altura das antenas afetam a perda de propagação (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). Portanto, a tabela de 6 km da Semtech pode ser uma hipótese inicial para medições de campo, mas nunca o resultado.

A pergunta central muda de acordo com isso:

Em que link margin, taxa de sucesso de pacotes e airtime FUOTA a referência de 6 km em área aberta da Semtech se transforma dentro de um pomar denso?

2. Como SF e BW alteram o alcance?

Na camada física LoRa, o spreading factor determina quanto os dados são espalhados pelos símbolos chirp. O resumo da Semtech explica que, entre SF7 e SF12, um SF maior melhora a sensibilidade do receptor, mas reduz o bit rate e a velocidade de transferência (Semtech, LoRa and LoRaWAN: A Technical Overview).

A relação pode ser resumida assim:

Tabela numérica de SF/BW e alcance para um pomar de tangerinas

A tabela a seguir é uma estimativa de planejamento de engenharia para um pomar de citros com cerca de 2,5–4 m de altura, vegetação densa, irrigada e presente durante todo o ano. As células usam o formato alcance (m) / bit rate PHY bruto (kbit/s); em um projeto confiável, deve-se considerar o limite inferior do intervalo. O cenário de cálculo pressupõe E22-900M22S/SX1262, 868 MHz, CR 4/5, ganho de antena de 0 dBi, 2 dB de perdas de cabo e conectores, 10 dB de margem adicional para fading e segurança e uma antena que não esteja enterrada (informações do fabricante do E22-900M22S).

O bit rate PHY vem da relação R_b = SF × (BW / 2^SF) × 4/5 e não representa o throughput real da aplicação. Cabeçalhos LoRaWAN, duty cycle, espera, retransmissões, metadados de fragmentação e perda de pacotes reduzem ainda mais a velocidade útil. Os alcances são estimativas de planejamento baseadas nas hipóteses de RF indicadas, não medições de campo nem valores garantidos para um pomar de tangerinas. As colunas SF5–SF6 e BW250/BW500 são comparações de LoRa bruto; combinações fora dos data rates padrão de LoRaWAN EU868 devem ser verificadas contra os parâmetros regionais.

Os parâmetros regionais LoRaWAN definem planos de canais, data rates permitidos, limites de potência e restrições regionais. Por isso, uma tabela SF/BW precisa ser verificada contra os parâmetros da região e da banda em uso (LoRa Alliance RP002 Regional Parameters; consulte as publicações do Technical Committee da LoRa Alliance para a lista atualizada).

Por que ADR é importante?

LoRaWAN Adaptive Data Rate (ADR) permite que o network server ajuste o data rate e a potência de transmissão de um dispositivo conforme a qualidade do link. A Semtech descreve o objetivo como preservar o link margin necessário usando um data rate maior para reduzir o airtime e o consumo de capacidade da rede (Semtech, Understanding LoRa Adaptive Data Rate).

Para FUOTA, a consequência é clara: um dispositivo só deve passar para SF12 quando realmente precisar. Se o link for confiável em SF9 ou SF8, o SF menor pode reduzir o tempo da atualização.

3. Link budget: as potências dos dois dispositivos não são somadas

As potências de saída do Dragino e do E22 não podem ser simplesmente somadas em um único cálculo. Cada direção RF precisa ser calculada separadamente:

potência recebida =
potência de saída do transmissor ativo
+ ganho da antena transmissora
+ ganho da antena receptora
− perdas de cabos e conectores
− perda de propagação
− perdas ambientais de folhagem, troncos, solo e outros elementos

Para E22 → Dragino, usam-se a potência de saída do E22 e a sensibilidade do receptor Dragino. Para Dragino → E22, usam-se a potência do Dragino e a sensibilidade do E22. O alcance bidirecional utilizável é determinado pela direção mais fraca. Como a sensibilidade varia com SF, BW, coding rate e as condições de medição, um único número de “alcance do dispositivo” é tecnicamente incompleto. O resumo técnico LoRa da Semtech explica a relação entre os parâmetros de modulação, a sensibilidade e o bit rate.

Para os cálculos de campo deste artigo, não assuma um valor nominal em dBm antes de definir os modelos exatos do Dragino e do E22, o tipo de antena, a potência conduzida e as permissões regionais. Datasheets não substituem medições de campo.

4. Por que tratar o tipo de cultivo como um problema RF separado?

A mesma configuração de rádio não produz o mesmo resultado em todos os ambientes agrícolas. Folhas, galhos, troncos, umidade do solo, geometria das fileiras e chuva podem afetar espalhamento, absorção e fading por múltiplos caminhos. Há estudos sobre por que a linha de visada costuma não existir em pomares e por que a folhagem altera a perda de propagação (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

Por isso, consideramos primeiro estes cultivos como cenários candidatos:

• milho,
• beterraba-sacarina,
• tomate,
• batata,
• melancia,
• pimentão,
• cebola seca,
• uva,
• maçã,
• tangerina.

Esta não é uma classificação da produção mundial. É um conjunto de cenários de engenharia que combina necessidades dos sensores, sensibilidade à irrigação/EC, valor econômico e dificuldade RF. Para cada cultivo, criamos primeiro uma tabela de alcance–bit rate para combinações SF/BW e depois uma tabela de airtime FUOTA para as mesmas combinações. São estimativas iniciais para orientar um plano de testes, não garantias de campo.

5. Por que um pomar de tangerinas?

Entre esses candidatos, um pomar de tangerinas é um bom teste de estresse:

• as árvores são perenes e têm folhagem densa,
• folhas e galhos podem ocupar o caminho RF durante boa parte do ano,
• os nós costumam ser instalados perto do solo ou do tronco,
• várias fileiras podem ficar entre o gateway e o nó,
• a propagação ao longo de uma fileira não é igual à propagação entre fileiras.

A existência de estudos RF em pomares cítricos que consideram simultaneamente posição do nó, altura da antena, profundidade da vegetação e distância mostra que a posição da antena não pode ser explicada apenas pela distância em metros (citrus orchard RF deployment study). Experimentos de posicionamento de sensores em áreas cítricas também relataram diferentes níveis de sinal recebido com diferentes alturas de antena e cobertura das árvores (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

A pergunta crítica já não é “Quantos quilômetros o LoRa alcança?”, mas:

Cada sensor do pomar consegue se conectar com link margin suficiente, e o mesmo downlink consegue completar uma transferência longa de firmware?

6. Altura da antena: 1 metro, 5 metros e 50 centímetros

Colocar o gateway a 1 metro

Um mastro de aproximadamente 1 metro pode deixar a antena dentro da camada inferior de troncos e folhagem. Fileiras, galhos e folhas entram diretamente no caminho de propagação. Ver a outra antena não significa que a zona de Fresnel esteja livre; reflexões do solo e fileiras ainda podem dominar.

Colocar o gateway a 5 metros

Uma altura de aproximadamente 5 metros pode aproximar a antena do gateway das copas de muitas árvores ou colocá-la acima delas. Isso não cria automaticamente linha de visada em todo o pomar, mas pode reduzir obstáculos do lado do gateway, perdas relacionadas ao solo e o efeito das copas no caminho horizontal. Medições em pomares mostram que o efeito da folhagem depende de as antenas estarem próximas ao solo ou à copa (orchard foliage path-loss study).

Um mastro de 5 metros, portanto, não é um “multiplicador de alcance”. O benefício deve ser medido junto com:

• o gateway na borda, no centro ou no fim de uma fileira,
• a antena paralela ou perpendicular às fileiras,
• ganho da antena e padrão de radiação vertical,
• perda do cabo coaxial e dos conectores,
• inclinação do terreno e reflexões do solo.

Colocar as duas antenas a 50 centímetros

A atração dos 50 cm é manter a antena abaixo da folhagem superior e usar o corredor entre os troncos. Mas “não atravessa folhas” não significa “existe linha de visada”. Nessa altura:

• troncos e galhos baixos podem ser obstáculos diretos,
• reflexões do solo e perdas em solo úmido podem aumentar,
• um link entre fileiras pode ser significativamente pior que um link ao longo da fileira.

O cenário de 50 cm deve ser medido na mesma rota dos cenários de 1 m e 5 m; não deve ser tratado como melhoria teórica de alcance. Em muitos pomares, uma hipótese razoável é orientar a antena do sensor para o corredor da fileira, elevar a antena do gateway acima das copas e adicionar um segundo gateway se necessário. É uma hipótese de projeto derivada da dependência de altura e orientação observada em estudos RF de pomares; precisa ser validada no campo.

7. Um link de telemetria não é um link FUOTA

O fato de um sensor enviar regularmente um pequeno pacote de medição não significa que consiga baixar uma imagem de firmware de 1 MB pela mesma rede. Telemetria normalmente é um uplink esparso; FUOTA é uma operação longa, principalmente downlink, que precisa retransmitir fragmentos perdidos.

Dispositivos LoRaWAN Class A abrem duas janelas curtas de recepção depois de um uplink. Dispositivos Class C mantêm o receptor disponível por mais tempo enquanto não transmitem, tornando útil uma operação temporária em Class C para uma grande transferência downlink (LoRaWAN Specification).

FUOTA não é um único comando “enviar pacote de firmware”. Os blocos da LoRa Alliance separam as responsabilidades:

• TS004 Fragmented Data Block Transport: fragmentação de dados grandes e gerenciamento da sessão (TS004-2.0.0).
• TS005 Remote Multicast Setup: programação de multicast temporário e janelas de distribuição Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: gerenciamento de versões de firmware e hardware, reboot e imagens de atualização (TS006-1.0.0).
• TS007 Multi Package Access: comunicação dos pacotes e FPorts do dispositivo para transportar vários comandos com menos downlinks (TS007-1.0.0).

Usar esses padrões em conjunto exige desenvolvimento adicional e validação HIL, independentemente do alcance RF.

8. O custo de uma imagem completa de firmware de 1 MB

Um cálculo aproximado do limite inferior para um firmware completo de 1 MB é:

número de bits a transferir / bit rate teórico

Com 1 MB e 5,47 kbit/s, apenas o tempo de transferência PHY é de aproximadamente 25,5 minutos. Aplicando 10% de uso do canal como hipótese de cenário, o limite inferior teórico passa para aproximadamente 4,25 horas. Isso exclui cabeçalhos LoRaWAN, metadados dos fragmentos TS004, paridade/redundância, perda de pacotes, retries e configuração da sessão Class C. A legislação regional e os limites de uso do canal precisam ser verificados para a banda e o país (RP002 Regional Parameters).

Por isso, escolher configurações FUOTA apenas pelo “maior alcance” pode ser um objetivo errado. A melhor configuração minimiza o airtime total mantendo um link margin confiável.

9. Delta OTA: transportar a diferença, não todo o firmware

Com Delta OTA, o servidor envia a diferença entre a imagem base informada pelo dispositivo e a imagem alvo. O dispositivo aplica o patch para reconstruir o firmware alvo:

firmware base no dispositivo
        +
delta patch
        ↓
firmware alvo
        ↓
verificação SHA-256 e assinatura
        ↓
MCUboot test boot e confirmação de saúde

O projeto open source detools é um exemplo de abordagem delta para sistemas embarcados: documenta a aplicação em streaming de patches sequenciais e a aplicação incremental em C para dispositivos com memória limitada (detools README). No projeto Agronode, o fluxo de criação e aplicação delta é definido com SHA base, SHA alvo, tamanho da imagem e layout MCUboot (documentação Agronode Delta OTA, código de aplicação delta).

As medições atuais do projeto relatam deltas entre releases consecutivas de aproximadamente 15–53 KB contra uma imagem completa de aproximadamente 944 KB (documentação Delta OTA do projeto). Essa medida é específica dessas releases; a mesma proporção não deve ser esperada para todo par de versões.

Usando o mesmo valor PHY aproximado de 5,47 kbit/s:

Isso não é uma duração FUOTA real, mas uma comparação de tamanho. Fragmentação, paridade, retries e gerenciamento da sessão adicionam tempo.

10. Dispositivos muito antigos podem ser atualizados com pequenos passos Delta?

Sim, se existir uma cadeia delta adequada:

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

Cada seta é uma sessão FUOTA separada e uma barreira de segurança separada. O servidor só deve iniciar o patch seguinte depois de o dispositivo:

1. concluir a sessão de fragmentação,
2. verificar o SHA base,
3. criar a imagem alvo e verificar o SHA alvo,
4. passar pelo test boot do MCUboot,
5. confirmar o novo firmware com uma verificação de saúde,
6. informar a nova versão e a identidade da imagem.

O fluxo test–confirm–revert do MCUboot pode retornar à imagem anterior funcional no boot seguinte quando uma imagem nova falha; é um padrão fundamental para reduzir o risco de brick em atualizações remotas (documentação de design do MCUboot, assinatura de imagens e ferramentas MCUboot).

A desvantagem de uma cadeia de várias etapas é que configuração da sessão, airtime, energia, reboot e risco de falha se repetem em cada etapa. Se cada hop tiver probabilidade independente de sucesso de 98%, a probabilidade de completar dez hops sem retries é aproximadamente 0,98^10 = 81,7%. Isso não é uma previsão de sucesso em campo; é um modelo de como o número de hops multiplica o risco.

11. O modelo correto é um grafo delta, não uma lista de arquivos delta

Guardar apenas releases adjacentes é um modelo simples:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

Em produção, é melhor guardar imagens completas e vários tipos de delta juntos:

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

Política recomendada de artifacts:

• Armazenar uma imagem completa e assinada para cada release.
• Manter deltas sequenciais N→N+1 como artifacts imutáveis e duradouros.
• Gerar deltas diretos das versões base realmente presentes no campo para a release mais recente.
• Manter deltas bridge de versões LTS/checkpoint selecionadas para a release mais recente.
• Armazenar com cada delta os metadados de SHA base, SHA alvo, placa, revisão de hardware, variante e geometria das partições.
• Nunca excluir imagens completas; elas continuam sendo a fonte canônica para gerar deltas, fazer perícia e recuperar dispositivos.

No Agronode, o script de artifacts existente mostra a geração de deltas diretos a partir das versões base de campo (ensure_field_deltas.py). A política atual do backend procura uma correspondência direta base–alvo; também é necessário um graph/path planner para planejar automaticamente A→B→C quando A→B e B→C existem (ota_policy.py).

O servidor pode escolher a rota com esta função de custo:

custo da rota =
bytes totais dos patches
+ airtime estimado
+ custo de sessão/reboot por hop
+ risco de perda de pacotes e falha
+ energia do dispositivo e custo de manutenção

Uma primeira política prática é usar um patch direto quando existir e tiver tamanho razoável. Se for grande demais, tentar uma rota checkpoint com no máximo 2–3 hops controlados. A imagem completa deve ser mantida como caminho de recuperação, bootstrap ou transporte alternativo, não como “último recurso” automático por LoRa.

12. Barreiras de segurança necessárias para Delta OTA

Delta OTA não elimina os controles de segurança; torna ainda mais importante a identidade exata da imagem base.

Para cada patch, verifique pelo menos:

• o SHA-256 do firmware base informado pelo dispositivo,
• o SHA-256 base esperado pelo patch,
• a placa e a revisão de hardware,
• a geometria de partições/slots,
• o SHA-256 do firmware alvo,
• a assinatura MCUboot e a chave de assinatura permitida,
• se a versão alvo cumpre a política de downgrade.

O MCUboot verifica a integridade e a assinatura da imagem e pode fornecer rollback quando um test boot não é confirmado permanentemente (documentação oficial do MCUboot). O código de aplicação delta deve rejeitar incompatibilidades de base e layout antes de criar a imagem alvo (aplicação delta do Agronode).

Para dispositivos muito antigos, também é preciso definir uma versão bootstrap FUOTA. Se o firmware anterior não tiver cliente de fragmentação, código delta-apply ou o suporte de bootloader necessário, o dispositivo não pode entrar diretamente na cadeia delta. Primeiro, atualize-o por BLE, Wi-Fi, rede celular ou uma imagem completa controlada.

13. Um roteiro viável para este projeto

Etapa 1 — Fixar as hipóteses RF

• Confirmar os modelos exatos do Dragino e do E22.
• Selecionar a região e o plano de frequências.
• Medir a potência conduzida ou verificá-la no datasheet.
• Registrar ganho de antena, perda do cabo e polarização.
• Medir na mesma rota do pomar os cenários de 50 cm, 1 m e gateway a 5 m.

Etapa 2 — Criar um mapa de conectividade de campo

• Registrar RSSI e SNR em cada ponto de medição.
• Medir a taxa de sucesso dos pacotes e a dependência da direção.
• Comparar condições secas, irrigadas, chuvosas e com diferentes densidades de folhagem.
• Medir uma rota ao longo das fileiras e outra transversal.
• Definir separadamente o link margin mínimo necessário para FUOTA.

Etapa 3 — Completar o transporte FUOTA LoRaWAN

• Implementar a sessão de fragmentação TS004.
• Implementar com TS005 o ciclo de vida temporário Class C/multicast.
• Conectar o gerenciamento de versão de firmware/reboot do TS006 e o package discovery do TS007.
• Testar perda de fragmentos, retries, interrupções e reinicialização do gateway.
• Não prometer sucesso Delta FUOTA de ponta a ponta sobre LoRa antes de concluir esta etapa.

Etapa 4 — Adicionar artifacts delta e gerenciamento de rotas

• Armazenar cada release completa assinada como artifact canônico.
• Gerar deltas adjacentes e deltas diretos das bases ativas em campo para a release mais recente.
• Manter os metadados delta imutáveis com SHA base/alvo e identidade do hardware.
• Implementar no servidor a seleção de patches diretos e rotas multi-hop limitadas.
• Após cada hop, aguardar sinais de versão, SHA, saúde do boot e saúde da aplicação.

Etapa 5 — Definir a métrica de sucesso FUOTA

Sucesso não deve significar apenas “todos os pacotes chegaram”. Relate em conjunto:

• bytes do patch e airtime total,
• taxa de perda de fragmentos e número de retries,
• tempo de conclusão da atualização,
• consumo de energia,
• taxa de sucesso do test boot,
• taxa de confirmação permanente,
• taxa de rollback,
• sucesso por hop e total quando vários hops forem necessários.

Conclusão

O problema LoRa em um pomar de tangerinas não é apenas “Quantos quilômetros conseguimos cobrir?”. SF e BW criam uma troca entre alcance e bit rate; a folhagem altera o link teórico nas condições de campo; altura da antena e orientação das fileiras mudam o resultado; e FUOTA exige uma capacidade downlink muito diferente da necessária para pequenos pacotes de telemetria.

Por isso, a referência de 6 km da Semtech e a distância de atualização confiável em um pomar denso não descrevem a mesma métrica. A arquitetura correta combina link budget RF medido, altura adequada do gateway, transporte FUOTA padrão TS004/TS005, barreiras de segurança MCUboot e um grafo de artifacts Delta OTA.

Quando Delta OTA reduz uma imagem completa de 1 MB a patches de aproximadamente 15–53 KB, pode reduzir drasticamente o airtime FUOTA. Mas o algoritmo delta sozinho não transforma essa vantagem em um produto confiável. O servidor precisa conhecer o SHA base exato do dispositivo, escolher uma rota direta ou multi-hop limitada, verificar cada hop e conservar a imagem completa como fonte de recuperação.

Em resumo, o objetivo não é o maior alcance, mas um sistema LoRaWAN capaz de realizar uma atualização de firmware mensurável, repetível e reversível em um pomar de tangerinas.

Fontes

Padrões e documentos técnicos de fabricantes

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

Estudos de propagação RF agrícola

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling