Uma interface do reação básica para as fórmulas definidas no Lora Modem Designer's Guide da Semtech (AN1200.13), mostrando o tempo de antena para as taxas de dados usadas nos planos de frequência da rede de coisas (TTN) e mostrando as limitações que se aplicam à rede pública TTN.
Veja em ação em https://avbentem.github.io/airtime-calculator.
As próximas versões podem incluir:
Os planos de frequência dos quais as taxas de dados são mostradas são as da rede de coisas. Eles são baseados nos planos de frequência e nos parâmetros regionais de Lorawan v1.0.2rb e definidos em config.json.
Alguns planos de frequência têm taxas de dados muito diferentes para uplinks e downlinks; Para essas "regiões" distintas, são definidas neste aplicativo, como para US902 (uplink) e US902 DL (Downlink). Outros compartilham (a maioria) das taxas de dados, como o EU868.
Tanto os países quanto as especificações de Lorawan podem definir o ciclo de serviço máximo ou as limitações máximas de tempo de permanência: quando algum plano de frequência pode ser usado em vários países, diferentes países ainda podem impor limitações legais diferentes. E:
É importante ter em mente que as limitações do ciclo de trabalho descritas nas tabelas das especificações são limitações impostas por Lorawan, e não as limitações legais. Se você construir dispositivos comerciais e deseja que eles sejam certificados em Lorawan, eles precisam cumprir a especificação. Os dispositivos de desenvolvimento não precisam ser totalmente compatíveis com a especificação. Qualquer dispositivo (seja Lorawan ou não, gateway ou nó, comercial ou desenvolvimento) precisa estar em conformidade com as limitações legais que se aplicam em seu país.
[...]
O ciclo de trabalho imposto por Lorawan se aplica apenas a nós. Os gateways são tecnicamente apenas dispositivos Lora, não Lorawan, portanto a especificação de Lorawan não se aplica a eles. As limitações do ciclo de serviço regulatório geralmente se aplicam a qualquer transmissor.
Como para AS923:
O ciclo de trabalho máximo de 1% de Lorawan se aplica apenas a 923.20 e 923,40 MHz.
O tempo máximo de habitação de 400 ms pode não se candidatar à Austrália.
As especificações de Lorawan definem várias opções para o tamanho máximo da carga útil, como dependendo das configurações do tempo de permanência e com ou sem suporte para um possível encapsulamento repetidor.
Nas especificações iniciais, essas opções são bastante confusas, pois os valores máximos menores são listados quando não se aplicam tempos máximos de permanência. No entanto, os parâmetros regionais de Lorawan em fevereiro de 2020 RP002-1.0.1 afirmam que nenhum MacPayload pode ser maior que 230 bytes, independentemente das limitações de tempo de permanência, e nessa versão os números também foram ajustados.
Esta calculadora usa os tamanhos máximos de carga útil de RP002-1.0.1, que permitem um possível encapsulamento repetidor e não levam em consideração o máximo de tempo de permanência. Se o dispositivo nunca operará sob um repetidor, o tamanho máximo poderá ser um pouco maior. Se os tempos de permanência tiverem sido definidos, eles gerarão avisos na calculadora, independentemente do tamanho máximo da carga útil, permitindo que os usuários com quem esses tempos de permanência não se apliquem ainda vejam os tamanhos máximos de carga máxima correta (mais alta).
A alteração do tamanho da carga útil nem sempre afeta o número de símbolos que compõem a carga útil e o cabeçalho do pacote Lora, ou não para todas as taxas de dados. Por exemplo, isso é muito visível para tamanhos de carga útil do aplicativo de 12 versus 13 bytes. Este é o resultado esperado, causado pela modulação de rádio Lora, intercalação e correção de erros de avanço. O gráfico abaixo da grade visualiza isso.
Semtech's LoRa Modem Designer's Guide (AN1200.13) defines some more parameters, especially preamble length (to detect the signal), coding rate (CR, for forward error correction), header mode (to include a LoRa header with details such as coding rate, payload length and CRC), and low data rate optimisation mode (to avoid issues with drift of the crystal reference oscillator due to either temperature change or motion). Para Lorawan, eles não são configuráveis, portanto, não são expostos como entrada do usuário (exceto CR, se um valor não-defensor for definido através do URL).
Para Lorawan, o comprimento do preâmbulo é sempre 8, Cr é sempre 4/5, o cabeçalho do nível Lora é sempre incluído e o modo de otimização de taxas de dados baixa está ativo para SF11 e SF12 em 125 kHz.
O evento de cópia do navegador é mapeado da seguinte forma:
Se algum texto for selecionado, copie isso. Isso é tratado pelo navegador.
Caso contrário, quando uma dica de ferramenta estiver ativa, copie seu texto. Isso produz formatos de texto HTML e simples. Em um navegador de desktop, você precisará do teclado para copiar uma dica de ferramenta.
Ou então, copie os resultados. Isso suporta apenas HTML.
Para as quebras de linha na grade dos resultados, isso usa um formato muito específico para a conversão automática de HTML em marcação no discurso, como usado no fórum TTN: o discurso substitui <br> por n mas depois rejeita n nas células da tabela. Como uma solução alternativa, <br> é produzida como <br> , que é tratada como esperado no editor do discurso, mas precisa de alguma edição quando colado em outro lugar. Obviamente, o uso dos resultados estáticos não é muito útil de qualquer maneira.
Para text/plain nenhum URL é adicionado, pois o discurso prefere o conteúdo de texto simples, se isso for mais longo que o HTML.
Este aplicativo foi criado com URLs compartilháveis em mente; portanto, quase todas as entradas do usuário produzem um URL atualizado:
/<network>/<region>[/<parameters>] , EG /ttn/eu868 e /ttn/us902/6,14,cr48 .
<parameters> é uma lista separada por vírgula e define:
cr45 , cr46 , cr47 , cr48LinkAdrReq Os valores padrão não estão incluídos no segmento <parameters> ; Atualmente, isso se aplica a:
cr45 : conforme fixo para Lorawan Quando todos os parâmetros usam seus padrões, o segmento <parameters> e sua barra são excluídos.
Para servir esse aplicativo de página única das páginas do GitHub, é necessário alguns truques com um redirecionamento de JavaScript em uma página 404 personalizada. Infelizmente, alguns navegadores (como Brave) podem tentar ser úteis e mostrar uma opção como "Você quer verificar se uma versão salva está disponível na máquina Wayback?" mesmo ao executar adequadamente o redirecionamento esperado. Não está claro por que os 200 finais OK removem o banner para alguns sites no Brave, mas não nas páginas do Github.
Este projeto foi inicializado com o aplicativo Create React.
Para usar um pacote limitado para plotagem (removendo cerca de 690 kb da construção), enquanto usa as tipações do pacote completo, uma configuração de alias de paths é usada no tsconfig.json . No entanto, durante o teste ou construção, o Create React App remontaria ousadamente:
> react-scripts build
The following changes are being made to your tsconfig.json file:
- compilerOptions.paths must not be set (aliased imports are not supported)
...
TypeScript error in /src/components/result/Graph.tsx(1,20):
Could not find a declaration file for module 'plotly.js-basic-dist'
Para mitigar isso, alguns truques com extends são usados. Isso ainda mostrará a mesma mensagem para npm test e npm run build , e até formará o formato bastante o tsconfig.json , mas no final ele não tocará as extends e usará tsconfig-paths.json .
No diretório do projeto, execute:
npm install
Baixar todas as dependências. Você pode ignorar com segurança os avisos sobre a falta de dependências de pares.
npm start
Executa o aplicativo no modo de desenvolvimento. Abra http: // localhost: 3000 para visualizá -lo no navegador. A página será recarregada se você fizer edições. Você também verá erros de fiapos no console.
npm test
Inicia o corredor de teste no modo de relógio interativo. Consulte a documentação do aplicativo Create React sobre os testes de execução para obter detalhes.
npm test -- --coverage
Teste único executado com cobertura.
npm run lint , npm run lint:es , npm run lint:style ou npm run lint:pretty
Execute manualmente todos os linheiros e mais bonito, ou execute apenas aqueles para código, estilo de estilo ou arquivos restantes. Ao contrário do gancho de pré-compromisso (veja abaixo), isso não se limita a arquivos encenados.
npm run build
Executa os linheiros e (somente) se for bem -sucedido criar o aplicativo com feixes minimizados para produção na pasta build .
Para garantir que os URLs como /ttn/eu868/1,2 possam ser carregados sem primeiro carregar o arquivo nu / , veja, por exemplo, o arquivo Apache .htaccess .
Para construir para uma subpasta, defina "homepage": "/some/path/to/airtime-calculator" package.json . Isso não afetará o servidor de desenvolvimento, que sempre será carregado na pasta raiz. Para implantação na pasta raiz, defina -a como "/" ou não a defina. Veja também a documentação do aplicativo Create React sobre implantação.
Um gancho de pré-compromisso garante que erros de linha e erros de formatação não possam ser cometidos. Para permitir que regras mais bonitas substituam quaisquer regras de formatação que possam ser definidas por um linhador, é configurado para executar como um plug -in para Eslint e Stylelint e executar explicitamente os poucos tipos de arquivos que não são tratados por qualquer um deles.
Observe que o gancho de pré-compromisso usa encenação de fiapos, o que oculta temporariamente alterações não estudadas em arquivos parcialmente encenados. Isso pode fazer com que seu IDE mostre avisos sobre arquivos que foram alterados fora do IDE.
Cuidado com o SourCetree pode pular silenciosamente o gancho de pré-compromisso.
Ativar Stylelint em idiomas e estruturas | Folhas de estilo | Stylelint e, opcionalmente, desativar as inspeções padrão no editor | Inspeções | CSS . (Por exemplo, o WebStorm não gosta @import-normalize; no App.scss , mas o uso // noinspection CssInvalidAtRule já suprime essa inspeção específica neste código.)
As configurações mais bonitas no .prettierrc.yaml definem trailingComma: es5 . Depois de ser solicitado "Use o estilo de código baseado em lindos para este projeto?" Na Webstorm, isso produzirá estilo de codificação | Pontuação | Vírgula à direita: adicione quando multilina . Infelizmente, isso também se aplica aos parâmetros de função, que adicionam uma vírgula excessiva ao atingir o Código de Opção-Command-L para o Reformato (mas não para o comando de opção-Command-P for Reformat com mais bonito). Para evitar isso, defina manualmente a Webstorm para usar vírgula à direita: mantenha .
O editor configura .editorconfig Definir max_line_length , que é usado ao atingir a opção-command-l para o código de reforma, mas não quando usa o option-shift-command-p para reformato com mais bonito.