Dispositivo físico de Tarot com ESP32, NFC, câmera e inteligência artificial

Este relatório estuda como transformar cartas reais em uma experiência eletrônica sem reduzir o Tarot a um aplicativo. O foco é identificar cartas, posição, ordem e orientação, funcionar sem internet e, quando desejado, enviar uma tiragem já determinada pelo hardware para um backend que acrescente interpretação por inteligência artificial. Não há firmware neste documento: primeiro se escolhe uma arquitetura que valha a pena construir.

Resumo executivo

A arquitetura recomendada para o primeiro protótipo é ESP32-S3 com PSRAM, um único leitor NFC, tags NTAG213 nas 78 cartas, display IPS de 3,5 a 4 polegadas e um encoder com botão. As cartas são aproximadas uma a uma. O aparelho registra a sequência, permite confirmar normal ou invertida e mantém catálogo, spreads e significados resumidos localmente. Um backend simples em FastAPI e SQLite recebe somente a tiragem validada e chama uma LLM ou um servidor local. É a solução com melhor relação entre confiabilidade, custo, velocidade de aprendizado e preservação do ritual.

Para a bancada, um módulo PN532 continua conveniente por preço, documentação comunitária e bibliotecas. Para uma placa destinada a produto, entretanto, ele não deve ser adotado sem reavaliação: a própria NXP o classifica como Not Recommended for New Designs e recomenda PN7160. O MFRC522 está em fim de vida e também não é indicado para projeto novo. Entre alternativas atuais, PN7160 simplifica a integração por NCI, enquanto ST25R200 oferece mais controle de RF, suporte a NFC-A/B/V e duas antenas single-ended, mas exige engenharia de antena e software mais especializada (NXP PN532, NXP PN7160, NXP MFRC522, ST ST25R200).

Uma única tag NFC identifica a carta, mas não revela sua rotação de 180 graus. Duas tags na mesma carta também não resolvem isso sem localização espacial: o leitor verá o mesmo conjunto de UIDs nas duas orientações. No MVP, a solução correta é confirmação explícita por botão/encoder. Na versão física premium, a solução mais robusta é um berço com duas zonas de leitura e uma tag colocada assimetricamente perto do topo da carta; a zona que detectar a tag determina a orientação. Uma câmera com AprilTag ou ArUco também resolve carta e orientação, mas adiciona iluminação, enquadramento, oclusão, processamento e impacto visual.

Uma mesa de Cruz Celta com dez leitores é viável, porém não é um bom primeiro passo. Leitores e antenas próximos se acoplam e detunam; a localização exige uma antena por posição; os campos devem ser ativados em sequência; e a eletrônica, o gabinete e a calibração ficam caros. Anticolisão permite enumerar tags no mesmo campo, mas não diz em qual espaço físico cada uma está. Hall, capacitivo e óptico detectam presença, não identidade, a menos que sejam combinados com outra tecnologia.

O ESP32-S3 com 8 MB de PSRAM e ao menos 16 MB de flash continua sendo a melhor escolha: tem Wi-Fi, Bluetooth LE, 512 KB de SRAM interna, 45 GPIOs, USB, câmera/LCD, I2S e suporte maduro no ESP-IDF. O ESP32-P4 é muito mais forte em HMI e visão, mas não possui Wi-Fi nem Bluetooth integrados e normalmente precisa de um segundo SoC; seu datasheet atual ainda é preliminar. Ele só faz sentido numa versão premium realmente dependente de câmera, MIPI e tela grande (ESP32-S3, ESP32-P4, ESP32-P4 e conectividade).

O dispositivo deve permanecer útil sem internet. Identificação, spreads, significados curtos, histórico e uma leitura determinística baseada no catálogo cabem no armazenamento local. A nuvem acrescenta síntese narrativa, perguntas e TTS, mas não escolhe nem altera cartas. Chaves de OpenAI, Anthropic ou Gemini ficam exclusivamente no backend. O retorno da LLM deve obedecer a JSON Schema, ser validado semanticamente e referenciar somente os slot_id aceitos pelo backend.

Metodologia e critérios

A pesquisa foi concluída em 29 de agosto de 2026. Foram priorizados datasheets e páginas oficiais da Espressif, NXP, STMicroelectronics, Analog Devices e TDK; documentação oficial de ESP-IDF, LVGL, APIs de IA e bibliotecas; legislação brasileira e britânica; repositórios originais; e projetos documentados por seus autores. Fóruns, Hackaday, Reddit e vídeos foram usados apenas para encontrar experiências e ideias, nunca para substituir especificações do fabricante.

As conclusões usam três rótulos:

Confirmado: consta em documentação, datasheet, código ou status oficial.
Estimativa: preço, tempo, alcance ou custo de fabricação que varia com fornecedor e construção.
Inferência de engenharia: conclusão derivada de características confirmadas, mas que precisa de protótipo e medição.

Os critérios de decisão foram confiabilidade de identificação, preservação da experiência física, complexidade, custo, disponibilidade em 2026, manutenção, privacidade, evolução para produto e risco de ficar preso a hardware antigo.

Conceito do dispositivo

O objeto deve agir como um instrumento de captura e interpretação, não como o responsável pelo sorteio. A pessoa embaralha e escolhe cartas reais. O aparelho apenas confirma o que já aconteceu fisicamente, organiza a tiragem e apresenta informações.

O sistema completo tem cinco responsabilidades separadas:

Captura física: obter card_id, orientação, ordem e posição.
Validação determinística: rejeitar carta duplicada indevida, slot inexistente, contagem errada e tag não vinculada.
Conhecimento local: nomes, significados, spreads e histórico.
Interpretação opcional: enviar fatos validados ao backend e à LLM.
Apresentação: tela, áudio e interface web sem impedir o modo offline.

Essa separação impede que uma falha de internet, uma troca de provedor ou uma resposta criativa da IA transforme o aparelho em um peso de papel.

Arquiteturas possíveis

A. Cartas com RFID/NFC de 13,56 MHz

Cada carta recebe uma etiqueta passiva ultrafina. O leitor energiza a tag por indução e lê seu identificador ou uma pequena mensagem NDEF. NTAG213 é suficiente: oferece UID de 7 bytes, 144 bytes de área útil, NFC Forum Type 2, anticolisão e versões de IC com 75 µm para integração ultrafina. A NXP informa alcance de até 100 mm em condições favoráveis, mas ressalva que ele depende do campo e da geometria das antenas. Em uma mesa real, com módulos pequenos, laminado, madeira e ruído, deve-se projetar para aproximação de poucos centímetros, não prometer 10 cm (NTAG213/215/216).

Vantagens:

identificação rápida e determinística;
tag invisível sob adesivo ou nova laminação;
não depende da ilustração, idioma ou iluminação;
custo por carta baixo em lote;
leitura e catálogo podem ser totalmente offline.

Limitações:

uma antena não informa a orientação de uma tag simétrica;
metal, display, bateria e outras antenas alteram sintonia e alcance;
várias cartas no mesmo campo podem ser enumeradas por anticolisão, mas a posição espacial continua desconhecida;
sobrepor tags ou encostar cartas pode diminuir o acoplamento;
tags modificam fisicamente um baralho comercial e podem ser percebidas ao tato se forem mal instaladas.

NTAG, MIFARE e o que realmente é necessário

O projeto precisa de um identificador estável e, opcionalmente, poucos bytes de metadados. Não precisa da autenticação e dos setores de MIFARE Classic. Para este uso, NTAG213 é mais simples e interoperável. O UID não é segredo e pode ser clonado; isso é aceitável porque não se trata de controle de acesso. A identidade canônica deve ficar numa tabela de vínculo local, não depender de texto gravado na tag.

Gravar somente um identificador próprio assinado em NDEF permite substituir leitores e conferir integridade, mas não torna a tag anticópia. Para um produto comercial que precise reconhecer apenas decks oficiais, seria necessário avaliar tags com assinatura criptográfica/originality signature e um modelo de ameaça real. Não vale acrescentar essa complexidade ao MVP.

Leitores em 2026

Leitor	Status e protocolos	Interface	Uso recomendado	Limitação principal
MFRC522	EOL/NRND; ISO 14443A, MIFARE e NTAG	SPI	Somente experimento muito barato já existente	Hardware antigo, protocolo limitado e clones de qualidade variável
PN532	NRND; 13,56 MHz, vários modos NFC	I2C, SPI ou UART em módulos	Bancada e MVP rápido	Não escolher automaticamente para uma PCB nova
PN7160	Ativo; NFC Forum, NCI 2.0, tags 1 a 5	I2C ou SPI	Produto novo quando simplicidade NCI importa	Controlador mais complexo que um leitor UID básico
ST25R200	Ativo; NFC-A/B/V, T1T–T5T, duas antenas single-ended	SPI	PCB de produto, duas zonas de orientação, bom controle de RF	Exige projeto de antena, matching e biblioteca RFAL
ST25R3916B	Ativo; A/B/F/V, P2P e recursos avançados de RF	SPI	Mesa ou ambiente ruidoso que justifique AFE sofisticado	Mais caro e complexo que o necessário no MVP
ST25R300	Ativo; leitor universal de até 2,2 W	SPI	Produto premium, antena pequena ou ambiente muito ruidoso	Excesso de potência, custo e complexidade para primeira versão

O PN7160 tem datasheet rev. 4.2 de julho de 2026 e firmware integrado, reduzindo trabalho no host. O ST25R200 está em produção, tem programa de longevidade, medição I/Q e opção de duas antenas independentes, o que o torna especialmente interessante para um berço topo/base numa futura PCB. O ST25R300 deve ser visto como solução especializada, não como substituto automático do PN532 (PN7160, ST25R200, ST25R3916B, ST25R300).

Ler muitas tags e usar muitos leitores

O NTAG21x implementa anticolisão e pode selecionar individualmente mais de uma tag no campo. Isso não significa que um módulo barato lerá 78 cartas empilhadas, nem que saberá em qual slot cada tag está. Bobinas muito próximas também se acoplam, alterando indutância, fator Q e sintonia.

Para uma mesa multiposição, a estratégia correta é:

uma antena fisicamente delimitada por slot;
habilitar apenas um campo RF por vez;
percorrer os slots em varredura rápida;
usar SPI com chip select, enables/power switches ou front-end com seleção de antena;
calibrar cada antena já montada no gabinete final;
impedir que uma carta alcance duas zonas ao mesmo tempo por geometria física.

Multiplexar somente I2C ou SPI não resolve a interferência do campo. Desligar ou colocar os outros leitores em power-down é parte do projeto. Uma PCB de dez posições também deve reservar distância e blindagem sem colocar folha metálica diretamente atrás das antenas.

Viabilidade das 78 cartas

Confirmado: 78 UIDs cabem com enorme folga no ESP32, e NTAG213 possui memória muito além do necessário. Estimativa: etiquetas genéricas em lote custam aproximadamente US$ 0,15 a US$ 0,60 cada; varejo de marca pode ultrapassar US$ 2 por unidade. A Adafruit vendia uma etiqueta NTAG213 por US$ 2,95 em agosto de 2026, ilustrando a diferença entre varejo e compra em lote (Adafruit NTAG213).

Assim, um deck custa aproximadamente US$ 12–47 em tags genéricas antes de frete e impostos, ou muito mais no varejo. Tecnicamente é fácil; o trabalho real é instalar 78 tags sem criar espessura desigual, registrar o vínculo sem erro e proteger a impressão.

B. Cartas reconhecidas por câmera

Há quatro níveis de dificuldade:

QR ou Data Matrix: fácil de gerar e decodificar, porém visualmente intrusivo se grande; pequeno exige foco e iluminação.
AprilTag ou ArUco: marcadores fiduciais foram feitos para detecção robusta, fornecem cantos e orientação e reconhecem várias cartas no quadro. AprilTag 3 recomenda tagStandard41h12 para a maioria dos casos (AprilTag 3).
Marcador discreto, UV ou infravermelho: preserva a arte, mas requer tinta, iluminação, filtros e testes de impressão; não é uma solução pronta.
Reconhecimento da ilustração: visualmente ideal, porém depende do deck, de direitos sobre imagens, dataset, reflexo, oclusão e um modelo treinado. Deve rodar em servidor ou processador mais forte, não ser a primeira tarefa TinyML do produto.

Método visual	Identidade	Orientação	Várias cartas	Robustez prática	Impacto estético
QR Code	Sim	Sim, pelos cantos	Possível	Boa com código grande e contraste	Alto a médio
Data Matrix	Sim	Sim	Possível	Boa em área pequena, depende do decoder	Médio
AprilTag/ArUco	Sim	Excelente	Excelente	Melhor opção de engenharia para marcadores	Alto se não for incorporado à moldura
Marcador UV/IR	Sim	Sim	Possível	Não confirmada sem protótipo óptico	Baixo a olho nu
Arte completa	Sim	Inferida pela pose	Possível	Variável; deck, luz e oclusão importam	Nenhum

O driver oficial esp32-camera suporta ESP32, S2 e S3 e sensores como OV2640, OV3660 e OV5640. OV2640 chega a 1600×1200 e gera JPEG; OV5640 chega a 2592×1944 e o driver atual inclui autofocus quando o módulo possui lente compatível (driver oficial). Em agosto de 2026, a linha oficial ESP-VISION concentra pipelines QR/AprilTag mais sofisticados sobretudo em ESP32-P4 e ESP32-S31. Portanto, AprilTag no S3 é possível por código customizado, mas não deve ser tratado como um recurso pronto e barato igual a ler NFC.

Comparação de placas e sensores de câmera

Plataforma	Pontos fortes	Limitações para este projeto
ESP32-CAM + OV2640	Muito barata e amplamente conhecida	ESP32 original, poucos GPIOs livres, projeto de alimentação e USB menos elegante; ruim como base de produto novo
ESP32-S3-EYE	8 MB PSRAM, câmera 2 MP, LCD, microfone e IMU em kit oficial	Placa de avaliação com formato e conexões pouco adequados ao gabinete final
ESP32-S3 + OV2640	Econômico, JPEG em hardware do sensor, suficiente para marcadores grandes	Foco fixo e menor margem para marcadores discretos
ESP32-S3 + OV5640 AF	Mais resolução e autofocus disponível em módulos compatíveis	Mais banda, memória, latência, consumo e ajustes ópticos
ESP32-P4-EYE	ISP, MIPI CSI, aceleradores de imagem e muita PSRAM	Sem rádio integrado; custo e software maiores; exagero para MVP NFC

A câmera superior montada sobre a mesa reconhece várias cartas e orientação de uma vez, mas altera o ritual e exige distância fixa. Uma câmera no próprio dispositivo reconhecendo uma carta por vez é mais simples, embora ainda inferior ao NFC em privacidade, latência e iluminação.

C. Mesa ou tabuleiro com posições predeterminadas

Uma mesa converte cada papel do spread em um slot físico. Ela pode ficar muito bonita e elimina a seleção manual de posição, mas torna cada novo spread um problema de layout.

Sensor por posição	Detecta presença	Detecta carta	Detecta orientação	Avaliação
NFC/RFID	Sim	Sim	Só com duas zonas ou marcador assimétrico	Melhor tecnologia única, porém cara em muitos slots
Hall + ímã	Sim	Não, salvo codificação magnética complexa	Pode, com dois ímãs/sensores	Barato para presença; ímãs tornam cartas perceptíveis
Capacitivo	Sim	Não	Não	Útil como gatilho para acordar leitor/câmera
Fotointerruptor/reflexivo	Sim	Não	Possível com impressão codificada	Luz ambiente, poeira e acabamento exigem cuidado
Câmera superior	Sim	Sim	Sim	Flexível para vários layouts; depende de visão e enquadramento
NFC + presença capacitiva	Sim	Sim	Não por si só	Permite ligar RF somente quando necessário

Uma mesa fixa de Cruz Celta requer dez posições e, provavelmente, dez antenas. Ela não acomoda bem todos os spreads. Uma alternativa melhor para versão premium é uma superfície modular com cinco a sete zonas e o spread mostrado no display, ou uma câmera superior que aceite coordenadas configuráveis.

D. Tarot totalmente eletrônico

ESP32, touchscreen e cartas sorteadas por software formam a arquitetura mais simples e confiável do ponto de vista eletrônico. Ela resolve identidade, orientação e spread sem sensores. Também perde o objeto principal: baralho, embaralhamento, textura e escolha física.

É útil como modo de demonstração, acessibilidade, viagem ou teste de interface, mas não deve ser a proposta central. Se houver sorteio eletrônico, use gerador aleatório apropriado e registre o algoritmo; nunca peça à LLM que escolha a carta.

E. Sistema híbrido

O híbrido correto não é usar todas as tecnologias simultaneamente. É combinar cartas reais, captura determinística, tela discreta, conhecimento offline e IA opcional. NFC sequencial é o núcleo mais racional; visão pode ser adicionada apenas se a detecção automática de orientação ou de várias cartas justificar a complexidade.

Comparação RFID × câmera × outras opções

Arquitetura	Custo	Complexidade	Precisão	Experiência física	Escalabilidade
Um leitor NFC sequencial	Baixo	Baixa	Muito alta para identidade; orientação manual	Excelente	Excelente por software
NFC com berço de duas zonas	Médio	Média	Muito alta para identidade e orientação	Excelente	Boa; um fluxo por vez
Mesa com vários leitores	Alto	Alta	Alta depois de calibração	Excelente, porém layout rígido	Baixa para novos spreads físicos
Câmera + AprilTag/ArUco	Médio	Alta	Alta sob luz e enquadramento controlados	Boa, marcador visível	Alta para layouts e número de cartas
Câmera + arte da carta	Médio a alto	Muito alta	Incerta sem dataset e testes por deck	Excelente	Baixa entre decks; alta no servidor depois de treinada
Touchscreen	Baixo a médio	Baixa	Determinística	Baixa	Muito alta
Híbrido NFC + display + backend	Médio	Média	Muito alta	Excelente	Excelente

Identificação das 78 cartas e modelo de dados

O catálogo canônico deve ser independente de tag, tradução e edição gráfica. Um padrão simples e legível:

Maiores: major_00 a major_21;
Paus: minor_wands_ace, minor_wands_02 … minor_wands_10, minor_wands_page, minor_wands_knight, minor_wands_queen, minor_wands_king;
Copas: prefixo minor_cups_;
Espadas: prefixo minor_swords_;
Ouros: prefixo minor_pentacles_.

Não use apenas números 0–77 no banco. Eles são compactos no firmware, mas opacos em logs e migrações. O firmware pode manter internamente um índice uint8_t, enquanto JSON e API usam card_id legível.

Catálogo de cartas

{
  "schema_version": "1.0",
  "deck_system": "rider_waite_smith",
  "cards": [
    {
      "card_id": "major_00",
      "arcana": "major",
      "number": 0,
      "suit": null,
      "rank": null,
      "names": {
        "pt-BR": "O Louco",
        "en": "The Fool"
      },
      "meanings": {
        "upright": {
          "keywords": ["começo", "liberdade", "espontaneidade"],
          "short": "Abertura para um caminho ainda não definido."
        },
        "reversed": {
          "keywords": ["imprudência", "hesitação", "dispersão"],
          "short": "Pede atenção ao risco ou ao medo de começar."
        }
      },
      "correspondences": {
        "element": "air",
        "astrology": null,
        "numerology": 0
      },
      "sources": ["waite_pictorial_key_1910"],
      "content_license": "public-domain-source-plus-original-adaptation"
    }
  ]
}

Correspondências esotéricas variam entre RWS, Marseille, Thoth e escolas contemporâneas. Campos ausentes devem ser null, não inventados. O texto em português deve ser uma redação própria baseada em fontes licenciadas, com proveniência por campo ou registro.

Vínculo entre tag e carta

{
  "binding_version": 3,
  "deck_id": "deck_pablo_001",
  "bindings": [
    {
      "tag_uid": "04A1B2C3D4E5F6",
      "card_id": "major_00",
      "bound_at": "2026-09-12T19:30:00Z",
      "active": true
    }
  ]
}

O UID deve ser normalizado em hexadecimal maiúsculo e validado pelo tamanho. Não é necessário enviar UIDs para a LLM nem guardá-los no histórico remoto.

Registro completo de uma leitura

{
  "schema_version": "1.0",
  "reading_id": "01995a9b-53f4-7ea0-b88a-9f3ac85a4031",
  "device_id": "tarot-s3-001",
  "deck_id": "deck_pablo_001",
  "spread": {
    "spread_id": "past_present_future",
    "version": 2
  },
  "created_at": "2026-09-12T19:42:15Z",
  "question": "Que aspecto desta decisão merece mais atenção?",
  "privacy_mode": "local",
  "cards": [
    {
      "slot_id": "past",
      "capture_order": 1,
      "card_id": "major_00",
      "orientation": "upright",
      "capture_method": "nfc",
      "confidence": 1.0,
      "captured_at": "2026-09-12T19:41:02Z"
    },
    {
      "slot_id": "present",
      "capture_order": 2,
      "card_id": "minor_swords_02",
      "orientation": "reversed",
      "capture_method": "nfc_manual_orientation",
      "confidence": 1.0,
      "captured_at": "2026-09-12T19:41:18Z"
    }
  ],
  "status": "captured",
  "firmware_version": "0.3.0"
}

confidence significa confiança da captura, não da interpretação. Para NFC, identidade vale 1,0 quando o UID está vinculado; uma orientação confirmada pelo usuário também é determinística e deve ser registrada como método manual, sem fingir que foi detectada pelo sensor.

Como detectar carta normal ou invertida

Técnica	Robustez	Custo	Veredito
Botão/encoder após a leitura	Alta, depende do usuário	Quase zero	Recomendado no MVP
Uma tag central	Nenhuma para orientação	Baixo	Identifica apenas a carta
Duas tags sem localização espacial	Nenhuma: o conjunto não muda ao girar	Dobro por carta	Não usar
Uma tag assimétrica + duas zonas de antena	Alta com berço mecânico	Médio	Melhor solução NFC premium
Tag assimétrica + leitor móvel/gesto	Baixa; gesto difícil de padronizar	Baixo	Evitar
AprilTag/ArUco	Alta com imagem boa	Médio	Melhor solução visual
Reconhecimento da arte	Variável	Alto em desenvolvimento	Pesquisa futura
Acelerômetro em cada carta	Tecnicamente possível	Proibitivo, espesso e exige energia	Sem sentido para 78 cartas
Ímãs/codificação física	Média	Trabalho manual e cartas perceptíveis	Só para baralho próprio experimental

No berço de duas zonas, coloca-se uma única tag perto do topo de cada carta. O cartão repousa sempre na mesma moldura. Se a antena superior lê a tag, a carta está em uma orientação; se a inferior lê, está na outra. As duas antenas nunca transmitem simultaneamente. Essa solução ainda precisa de protótipo de RF com diferentes espessuras, mas preserva o baralho melhor que duas tags e não depende de câmera.

Spreads configuráveis

Não existe uma única disposição universal para todos os nomes. Cruz Celta, relacionamento e decisão possuem variações de escola. O arquivo deve versionar papéis e coordenadas, e a tela deve mostrar ao usuário qual convenção está ativa.

Spreads úteis para a primeira biblioteca:

uma carta: foco do dia ou reflexão;
três cartas: passado, presente e futuro;
três cartas: situação, obstáculo e conselho;
três cartas: mente, corpo e espírito;
cinco cartas em cruz: situação, desafio, base, possibilidade e síntese;
ferradura de sete cartas;
decisão: opção A, consequência A, opção B, consequência B e conselho;
relacionamento: pessoa A, pessoa B, dinâmica, força, tensão e caminho;
Cruz Celta de dez cartas, com convenção documentada.

Exemplo de `spread.json`

{
  "$schema": "https://tarot.local/schemas/spread-1.0.json",
  "spread_id": "past_present_future",
  "version": 2,
  "names": {
    "pt-BR": "Passado, presente e futuro",
    "en": "Past, Present and Future"
  },
  "card_count": 3,
  "allow_reversed": true,
  "capture_mode": "sequential",
  "slots": [
    {
      "slot_id": "past",
      "order": 1,
      "label": {"pt-BR": "Passado"},
      "layout": {"x": 0.18, "y": 0.5, "rotation_deg": 0}
    },
    {
      "slot_id": "present",
      "order": 2,
      "label": {"pt-BR": "Presente"},
      "layout": {"x": 0.5, "y": 0.5, "rotation_deg": 0}
    },
    {
      "slot_id": "future",
      "order": 3,
      "label": {"pt-BR": "Futuro"},
      "layout": {"x": 0.82, "y": 0.5, "rotation_deg": 0}
    }
  ]
}

Coordenadas normalizadas de 0 a 1 permitem desenhar o spread em telas diferentes. O firmware valida schema, versão, IDs únicos, contagem e limites antes de substituir a versão anterior. Atualizações devem ser assinadas ou chegar pelo backend autenticado, e a última configuração válida permanece como rollback.

Hardware recomendado

Comparação dos SoCs

SoC	CPU e memória interna	Rádio	Câmera, tela e áudio	Adequação
ESP32 original	Até dois Xtensa LX6; cerca de 520 KB SRAM conforme variante	Wi-Fi 4, Bluetooth Classic/LE	I2S e periféricos, mas plataforma mais antiga	Só reaproveitamento; não iniciar produto novo sem motivo
ESP32-C3	RISC-V single-core 160 MHz; 400 KB SRAM	Wi-Fi 4, BLE 5	I2S; sem controlador paralelo de câmera dedicado	Leitor NFC sem interface pesada
ESP32-C6	RISC-V 160 MHz; 512 KB SRAM	Wi-Fi 6 2,4 GHz, BLE 5, 802.15.4	Bom IoT, não orientado a visão/HMI	Não traz vantagem decisiva ao Tarot
ESP32-S3	Dual-core Xtensa LX7 240 MHz; 512 KB SRAM; módulos com PSRAM	Wi-Fi 4, BLE 5	LCD/câmera, USB, I2S, SD/MMC, instruções vetoriais	Melhor equilíbrio
ESP32-P4	RISC-V dual-core 400 MHz + LP core; 768 KB L2; 16/32 MB PSRAM em pacote	Nenhum rádio integrado	MIPI CSI/DSI, ISP, JPEG, H.264, PPA, I2S, USB HS	Premium de visão e HMI, com SoC de rádio auxiliar

Os dados de C3, C6, S3 e P4 vêm das páginas e datasheets da Espressif (C3, C6, S3, P4). O datasheet atual do P4 é v0.7, classificado como preliminar; ele está disponível em kits, mas ainda implica maior risco de revisão e cadeia de fornecimento que o S3.

Escolha clara

Use ESP32-S3-WROOM com 8 MB de PSRAM e 16 MB de flash, ou variante superior disponível. No protótipo, uma DevKitC-1 N16R8/N32R16 ou placa integrada de fornecedor conhecido reduz o tempo de bancada. Confirme o sufixo exato no datasheet e no anúncio: muitos vendedores anunciam "S3" sem PSRAM.

Razões:

PSRAM dá margem para LVGL, fontes, buffers de áudio e eventual câmera;
dois núcleos permitem separar UI e I/O/rede sem prometer tempo real rígido;
USB nativo facilita produção, diagnóstico e recuperação;
há suporte oficial maduro em ESP-IDF, Arduino core, câmera, esp_lcd, I2S, HTTPS e OTA;
Wi-Fi já está no mesmo módulo, ao contrário do P4.

Leitor e tags por fase

Bancada/MVP: módulo PN532 de fornecedor confiável, em SPI. SPI tende a ser mais previsível que clones em I2C e deixa claro o controle do barramento. O objetivo é validar baralho, fluxo e alcance, não congelar a BOM.
Protótipo de produto: placa de avaliação PN7160, CLRC663 plus ou ST25R200. Avaliar alcance com a antena real e comparar complexidade de integração.
PCB final: ST25R200 se as duas antenas e o controle de RF forem úteis; PN7160 se NCI e firmware integrado reduzirem risco. CLRC663 plus é outra opção ativa com ISO 14443/15693 e SPI/I2C/UART (CLRC663 plus).
Tags: NTAG213, uma por carta, compradas inicialmente em amostra de 10 a 20 do mesmo lote. Testar antes de adquirir 78 ou 156 unidades.

Distribuição de periféricos

Uma configuração plausível de produto:

SPI compartilhado com chip select separado para NFC e microSD;
interface adequada do display conforme a placa: SPI para 320×240, QSPI/I80/RGB para maior resolução;
I2C para touch, RTC opcional, fuel gauge e sensores;
I2S/PDM para áudio;
GPIO separado para enable/reset do leitor, encoder, botões, backlight e interrupções;
USB-C para alimentação e serviço;
partição A/B para OTA e partições separadas para NVS e LittleFS.

Não se deve escolher os pinos antes de selecionar módulo, display e leitor exatos. GPIOs de boot, flash/PSRAM e USB possuem restrições específicas da variante; o esquema final deve ser revisado contra o datasheet e o hardware design guide.

Software recomendado

ESP-IDF, Arduino, PlatformIO ou Rust

Opção	Vantagem	Limitação	Decisão
Arduino Framework	Começo rápido e muitas bibliotecas maker	Configuração, segurança e integração de componentes complexos ficam menos explícitas	Bom para prova elétrica do leitor
ESP-IDF	Framework oficial, componentes versionados, FreeRTOS, TLS, OTA, segurança, `esp_lcd`, câmera, áudio e diagnóstico	Curva inicial maior e C/C++ mais detalhado	Escolha para o firmware que evoluirá
Arduino como componente do ESP-IDF	Reaproveita biblioteca Arduino mantendo `menuconfig` e infraestrutura IDF	Mistura ecossistemas e versões; requer disciplina	Ponte aceitável para uma biblioteca NFC específica
PlatformIO	Ambiente/build conveniente para Arduino e IDF	Não é framework por si; versões da plataforma podem atrasar o upstream	Ferramenta opcional, não decisão arquitetural
Rust para ESP32	Segurança de memória e ecossistema interessante	Menos exemplos e integração pronta em câmera, LVGL, NFC e áudio	Não escolher neste projeto inicial

A Espressif documenta o ESP-IDF como framework oficial e permite usar Arduino como componente, inclusive com o Component Manager (ESP-IDF, Arduino como componente). A recomendação pragmática é:

testar PN532 e tags com um pequeno programa Arduino ou exemplo IDF;
iniciar o produto em ESP-IDF estável, com C++ somente onde trouxer organização clara;
incorporar uma biblioteca Arduino apenas se ela for decisiva e estiver testada na versão do core compatível;
fixar versões de ESP-IDF e componentes no repositório.

Módulos do firmware

O firmware pode continuar simples, mas deve separar responsabilidades:

reader_service: estados do NFC/câmera e eventos de captura;
deck_registry: vínculo UID → card_id;
spread_engine: slots, ordem e validação;
catalog: nomes e significados locais;
reading_store: histórico e fila de sincronização;
ui: telas e entrada do encoder/touch;
network: Wi-Fi, TLS, API e sincronização;
audio: download, buffer, decodificação e I2S;
update: manifesto, download, verificação e rollback;
device_security: identidade, NVS protegida e políticas.

Uma fila de eventos evita que leitura NFC bloqueie renderização ou rede. Estados explícitos ajudam a impedir leituras duplicadas:

BOOT → READY → SELECT_SPREAD → WAIT_CARD
     → CONFIRM_ORIENTATION → SLOT_SAVED
     → WAIT_CARD ... → REVIEW → INTERPRET
     → PRESENT_RESULT → READY

O mesmo UID lido repetidamente deve ser ignorado até sair do campo por um intervalo configurável. A tela e um som curto confirmam uma captura, sem transformar o ritual em um caixa de supermercado.

Arquitetura do ESP32

Armazenamento local

Tecnologia	Conteúdo recomendado	Motivo
NVS	Wi-Fi, ID do dispositivo, preferências, versão ativa, contadores pequenos	Chave-valor, atualizações atômicas, wear leveling e suporte a criptografia
LittleFS	`cards.json`, `spreads/*.json`, traduções, temas e pequenas filas	Arquivos pequenos atualizáveis e organização simples
microSD/FAT	Áudio, imagens, exportação e histórico extenso	Capacidade e remoção fáceis; não é necessária no MVP básico
SPIFFS	Apenas projeto legado	LittleFS é a escolha mais adequada para um projeto novo baseado em arquivos

A documentação da Espressif posiciona NVS para configurações que não mudam frequentemente e alerta que ela não é adequada a logs grandes e frequentes; ESP-IDF possui suporte de partição a LittleFS, FAT e SPIFFS (considerações de filesystem, tabelas de partição).

Um catálogo textual das 78 cartas e dezenas de spreads cabe facilmente na flash. Não se deve adicionar microSD só porque há um slot disponível: ela cria conector, cartão, corrupção por remoção e mais estados de erro. Adicione quando áudio e exportação realmente justificarem.

Partições conceituais

Uma imagem de produção com 16 MB pode reservar:

bootloader e tabela;
NVS e nvs_keys;
otadata;
duas partições de aplicação A/B;
LittleFS para catálogo/configuração;
coredump pequeno e controlado, sem dados pessoais em produção.

Os tamanhos só devem ser fechados depois de compilar firmware com LVGL, codecs e idiomas. OTA A/B exige espaço para duas imagens completas.

Tempo e relógio

Histórico precisa de UTC confiável. Com internet/LAN, use SNTP e grave ISO 8601. Sem rede, o ESP32 perde precisão e data após falta de energia; um RTC com bateria é opcional para produto offline. Nunca trate o timestamp como prova criptográfica.

Backend recomendado

Comparação

Stack	Pontos fortes	Custo de complexidade	Veredito
Python + FastAPI + Pydantic	JSON Schema/OpenAPI, validação, ecossistema de LLM/TTS e prototipagem rápida	Ambiente Python e concorrência devem ser administrados	Recomendado
Node.js + Fastify	Familiaridade, JSON Schema nativo e ótimo I/O	Mais escolhas de validação/ORM e ecossistema de IA dividido	Excelente alternativa se Node for preferência dominante
Rust + Axum	Desempenho, binário único, controle	Mais tempo para integrações, modelos e painel	Desnecessário no primeiro backend

FastAPI gera OpenAPI/JSON Schema a partir de modelos Pydantic e valida estruturas aninhadas, exatamente o problema central do projeto (recursos oficiais). Não há carga que justifique otimização prematura: uma leitura produz poucos quilobytes e uma chamada lenta de IA.

Banco de dados

SQLite é suficiente para o MVP, para um dispositivo ou pequena família de dispositivos e para o servidor local. Ele entrega um arquivo único, transações e backup simples. Use WAL se houver painel e gravações simultâneas, chaves estrangeiras e migrações versionadas.

Migre para PostgreSQL quando houver múltiplos usuários, várias instalações, sincronização complexa, relatórios concorrentes, políticas de retenção ou serviço comercial. MongoDB não traz vantagem para um modelo que tem leituras, slots, dispositivos e relações claras. O JSON original pode ser preservado em uma coluna, sem abandonar tabelas relacionais.

Endpoints conceituais

GET  /v1/cards?deck_system=rider_waite_smith
GET  /v1/spreads
GET  /v1/spreads/{spread_id}
POST /v1/readings
GET  /v1/readings/{reading_id}
POST /v1/readings/{reading_id}/interpretations
POST /v1/readings/{reading_id}/tts
GET  /v1/device/config
POST /v1/device/sync

POST /v1/readings valida e persiste a captura antes de qualquer LLM. A interpretação é um recurso filho da leitura, não um corpo que pode substituir cartas. Uma chave idempotente evita duplicação se o ESP32 repetir o POST após timeout.

Tabelas mínimas

devices(id, name, public_key, firmware_version, last_seen_at)
decks(id, deck_system, content_version, created_at)
tag_bindings(deck_id, tag_uid, card_id, active)
spreads(id, version, definition_json, active)
readings(id, device_id, deck_id, spread_id, question, privacy_mode, created_at)
reading_cards(reading_id, slot_id, capture_order, card_id, orientation, capture_method)
interpretations(id, reading_id, provider, model, prompt_version, output_json, created_at)
notes(id, reading_id, text, created_at)

Pergunta, interpretação e nota podem conter informação íntima. Devem ter retenção configurável, exportação e exclusão. Logs técnicos não devem copiar o corpo completo.

Integração com LLM

Regra de autoridade

O fluxo precisa ser unidirecional:

sensores → leitura validada e imutável → contexto do catálogo → LLM → texto derivado

A LLM não recebe ferramenta para sortear, trocar ou gravar cartas. O backend monta uma estrutura congelada com reading_id, spread, slots e trechos do catálogo. Se a IA mencionar carta ou slot não presente, o resultado é rejeitado.

Provedores e execução local

Caminho	Vantagem	Limitação	Uso
OpenAI	Structured Outputs, boa qualidade multilíngue e ecossistema	Dados saem da rede; custo e dependência	Nuvem opcional
Anthropic	Texto longo e interpretação narrativa forte	API e política próprias; validar saída	Nuvem opcional
Gemini	Structured Output e modelos de diferentes custos	Suporta subconjunto de JSON Schema	Nuvem opcional
Ollama	Instalação local simples e API conhecida	Desempenho depende do computador e do modelo	Melhor primeiro modo privado
llama.cpp	Controle fino e implantação leve/CPU	Operação manual e limites do modelo	Servidor local compacto
vLLM	Alto throughput em GPU	Exagero para poucas leituras	Serviço com muitos usuários

Não existe um "melhor modelo de Tarot" verificável. Escolha por testes cegos em português brasileiro, fidelidade ao contexto, consistência de schema, latência e custo. Crie um conjunto de 30 a 50 tiragens fixas, incluindo cartas invertidas e spreads longos, e compare respostas sem permitir que o modelo veja a avaliação anterior.

Structured Output e validação

OpenAI e Gemini documentam saída estruturada por JSON Schema, mas a própria documentação do Gemini lembra que JSON sintaticamente válido não garante valores semanticamente corretos. Portanto, a aplicação deve validar os dois níveis (OpenAI Structured Outputs, Gemini Structured Output).

Modelo de resposta:

{
  "schema_version": "1.0",
  "reading_id": "01995a9b-53f4-7ea0-b88a-9f3ac85a4031",
  "summary": "A tiragem aponta uma transição que pede decisão consciente.",
  "slots": [
    {
      "slot_id": "past",
      "interpretation": "O início espontâneo ainda influencia a situação.",
      "evidence_keywords": ["começo", "espontaneidade"]
    }
  ],
  "synthesis": "...",
  "reflection_questions": ["O que ainda está sendo adiado?"],
  "advice": "Use a leitura como reflexão, não como substituto de decisão profissional.",
  "safety_note": null
}

Boas práticas:

gerar dinamicamente enum com os slot_id daquela leitura;
exigir todos os slots e additionalProperties: false;
não aceitar card_id retornado pela IA como fonte de verdade; o backend o reinsere a partir da leitura;
validar tamanho, idioma e ausência de novos slots;
limitar tentativas e usar fallback determinístico se o provedor falhar;
guardar provider, model, prompt_version, catálogo e parâmetros usados;
apresentar o texto como interpretação simbólica, nunca diagnóstico, previsão garantida ou ordem médica, jurídica ou financeira.

Contexto controlado

Em vez de despejar um livro inteiro no prompt, o backend envia para cada carta:

papel do slot;
orientação;
significado correspondente do catálogo;
símbolos e palavras-chave licenciados;
pergunta, somente se a pessoa autorizou;
regras editoriais e de segurança.

Isso é uma forma pequena e determinística de RAG. Vetores e banco vetorial são desnecessários para 78 registros conhecidos. Um lookup por card_id é mais auditável.

Tarot e base de conhecimento

Banco próprio ou interpretação direta

Use banco próprio + LLM. A interpretação direta confia em conhecimento de treinamento cuja fonte, escola e licença são desconhecidas. O catálogo próprio traz consistência, offline, tradução controlada, rastreabilidade e testes.

Separe quatro camadas:

fatos do deck e nomes;
significados de fonte histórica;
adaptação editorial original em PT-BR;
síntese gerada para uma leitura específica.

Cada registro deve incluir source_id, licença, autor da adaptação, versão e data. Não copie descrições de sites contemporâneos sem licença.

Direitos autorais: RWS, Marseille e Thoth

Isto é análise de risco, não parecer jurídico. O país de publicação, morte do autor, edição usada, tradução, fotografia e contrato podem mudar a conclusão.

Rider-Waite-Smith original: Pamela Colman Smith morreu em 1951. A Lei 9.610/1998 estabelece no Brasil, em regra, vida do autor mais 70 anos contados de 1º de janeiro do ano seguinte. Assim, por inferência jurídica simples, a arte original de 1909/1910 entrou em domínio público patrimonial no Brasil em 1º de janeiro de 2022. Nos EUA, o Copyright Office informa que, em 2026, obras publicadas antes de 1931 estão em domínio público. Wikimedia Commons reúne arquivos RWS marcados como domínio público (Lei 9.610, art. 41, U.S. Copyright Office Circular 15A, RWS no Commons).
Textos de Waite: edições históricas de The Pictorial Key to the Tarot podem estar em domínio público; o Project Gutenberg declara a edição digital relacionada como domínio público nos EUA. A digitalização e o texto do projeto possuem termos próprios que devem ser observados (Project Gutenberg).
Marseille: gravuras históricas antigas podem estar em domínio público, mas "Tarot de Marseille" não identifica uma única imagem. Use acervo que declare licença/PD para o arquivo específico. Restaurações, colorizações, fotografias e edições modernas podem ter direitos.
Thoth: não trate a arte como livre. Frieda Harris morreu em 1962; pelo prazo brasileiro geral, a proteção patrimonial só expiraria ao fim de 2032, com entrada em domínio público em 2033, salvo particularidades. Publicações atuais atribuem direitos a organizações e editoras. Para produto, obtenha licença ou use apenas conhecimento original cuidadosamente produzido, sem reproduzir arte/texto protegido (Oxford Academic, U.S. Games: permissões de imagem).

Mesmo quando a obra-base é pública, não copie uma recoloração moderna, scan de origem incerta, tradução recente, logotipo ou embalagem de editora. Mantenha uma pasta de evidências com URL, captura da licença, autor, data de acesso e hash do arquivo.

UI e display

Comparação de tecnologias

Tecnologia	Pontos fortes	Problemas	Uso indicado
OLED pequeno	Preto profundo, contraste, módulo barato	Pouco espaço, risco de retenção/burn-in, texto longo ruim	Status no MVP mínimo
IPS LCD	Disponível em muitos tamanhos, cor, toque e boa legibilidade	Backlight consome continuamente; preto não é absoluto	Melhor equilíbrio de 3,5 a 4,3 pol.
AMOLED	Preto real e acabamento visual excelente	Preço, fornecimento, drivers, burn-in e integração	Premium depois de validar fornecedor
E-paper	Aparência de papel e consumo quase zero na imagem estática	Refresh lento, ghosting e animação limitada	Versão contemplativa sem vídeo/animação
Display redondo	Objeto visual marcante	Texto e spreads desperdiçam área; disponibilidade/pinout	Elemento secundário, não tela principal

Tamanho recomendado:

2,8 pol. 320×240: suficiente para nome, slot e significado curto;
3,5 pol. 320×480 ou 480×320: melhor MVP com encoder;
4 a 4,3 pol. 480×480 ou 800×480: melhor protótipo premium e leitura de parágrafos;
5 pol.: confortável, mas exige mais gabinete, largura de banda e energia;
7 pol.: começa a parecer tablet e desloca o foco das cartas.

Uma placa integrada como Waveshare ESP32-S3-Touch-LCD-4.3C, com S3, PSRAM, flash, touch e codec de áudio, pode acelerar a validação da interface. Ela não deve determinar a PCB final e precisa ser comprada somente depois de revisar BSP, pinos e licença dos exemplos (documentação da placa).

Bibliotecas gráficas

LVGL: escolha principal para widgets, estilos, animação moderada, internacionalização e touch. É open source e roda em microcontroladores; a Espressif mantém esp_lvgl_port, que integra LVGL a esp_lcd, touch, botões e encoder (LVGL, esp_lvgl_port).
esp_lcd: camada oficial de baixo nível do ESP-IDF, com APIs comuns para SPI, I80, RGB, QSPI e outros barramentos. É a base preferida da PCB de produto (guia LCD).
TFT_eSPI: ótimo para protótipos Arduino e displays SPI conhecidos. A configuração tradicional de controlador e pinos fica na biblioteca, o que pode complicar builds reproduzíveis se não for gerenciada por projeto (TFT_eSPI).
LovyanGFX: biblioteca eficiente para Arduino/ESP-IDF e muitos displays, útil quando uma placa já possui configuração suportada (LovyanGFX).

Para produto, prefira esp_lcd + esp_lvgl_port + LVGL, versões fixadas e um BSP próprio da placa. TFT_eSPI e LovyanGFX são atalhos válidos, não requisitos.

Direção visual

"Místico" não precisa significar lua roxa, partículas e fonte ilegível. Uma interface editorial pode usar:

fundo carvão, marfim quente e um único acento cobre/dourado;
tipografia serifada legível nos títulos e sans-serif nos controles;
margens amplas e movimento lento apenas para confirmar transições;
ilustração da carta pequena, se a licença permitir;
ícone claro para orientação;
progresso 2 de 3 e nome do papel do slot;
brilho baixo e modo noturno real;
nenhum gradiente RGB pulsante durante a leitura.

Teste fontes com todos os acentos de português. Faça subset de glifos para reduzir flash, mas mantenha caracteres necessários a nomes e traduções.

Áudio e voz

Caminho de reprodução

backend TTS → arquivo/stream autenticado → buffer no ESP32
→ decoder MP3/Opus/WAV → PCM → I2S → amplificador classe D → alto-falante

O MAX98357A permanece em produção, recebe I2S sem MCLK e entrega até 3,2 W em 4 Ω a 5 V nas condições do datasheet. Módulos prontos são a opção maker mais simples. Para uma PCB nova, avalie a geração MAX98360A, também em produção (MAX98357A, MAX98360A).

Escolha um alto-falante de 4 ou 8 Ω, 2–3 W, com câmara acústica real. Um bom gabinete e controle de ganho importam mais que potência nominal. Posicione microfone e speaker para reduzir realimentação.

Formatos

Formato	Banda/armazenamento	CPU	Uso
WAV PCM	Alto	Muito baixo	Sons curtos e fallback offline
MP3	Médio	Moderado	Melhor primeira opção para TTS por ampla interoperabilidade
Opus	Muito baixo com boa voz	Moderado	Streaming e conversa depois de medir decoder

O componente oficial esp_audio_codec suporta decodificação MP3, Opus, WAV e outros formatos no S3 (ESP Audio Codec). Para o MVP com voz, gere MP3 mono no backend, faça download completo ou streaming com buffer e toque após validar tamanho e tipo. Opus é atraente para baixa latência, mas não precisa ser o primeiro formato.

Microfone

INMP441 e ICS-43434 aparecem em muitos tutoriais e módulos, porém seus status oficiais são NRND/EOL. Eles servem para bancada se já disponíveis, não para congelar uma nova PCB (INMP441, ICS-43434).

Para novo projeto, avalie:

TDK T5848, I2S de 24 bits e linha atual;
TDK T5837, PDM, status de produção, 68 dBA SNR;
outros MEMS ativos, confirmados no distribuidor e no fabricante quando a PCB for fechada.

O ESP32-S3 possui modos I2S/PDM e exemplos oficiais de captura de microfone (I2S no S3, T5837, T5848).

Perguntas de voz exigem também wake button, cancelamento de eco ou half-duplex, transcrição e consentimento. Comece com pressionar para falar depois que a leitura termina. Não deixe o microfone sempre transmitindo.

TTS cloud e local

TTS pode vir do mesmo provedor de IA ou de serviço separado. No modo privado, Piper é uma opção local atual: o projeto mantido OHF-Voice/piper1-gpl possui servidor HTTP e vozes pt_BR; cada modelo de voz tem licença própria e precisa de conferência (Piper, vozes). O ESP32 apenas toca o resultado, não executa síntese neural.

Segurança

Modelo de ameaça simples

Proteja contra:

extração de token do firmware perdido/roubado;
backend falso na mesma rede;
firmware OTA malicioso;
repetição de uma requisição capturada;
abuso do endpoint de LLM/TTS;
vazamento de perguntas e interpretações em logs;
arquivo de spread malformado ou adulterado;
chave de provedor gravada no ESP32.

Medidas recomendadas

HTTPS com validação de servidor: bundle de CA ou pinning de chave pública/certificado no modo LAN. Nunca aceite qualquer certificado em produção.
Identidade por dispositivo: token aleatório de escopo limitado ou, preferivelmente na versão de produto, chave assimétrica/cliente mTLS. O backend pode revogar um aparelho sem trocar credenciais dos demais.
NVS Encryption e Flash Encryption: proteger credenciais em repouso; usar chaves por dispositivo.
Secure Boot v2: executar somente firmware assinado.
OTA HTTPS assinada: duas partições, autoteste e rollback; anti-rollback depois de um processo de release maduro.
Rate limit e cotas: impedir que um token roubado gere custo ilimitado de LLM/TTS.
Validação de entrada: tamanho máximo de pergunta, schema de spread, IDs permitidos e número exato de cartas.
Privacidade por padrão: corpo de leitura fora de logs, crash reports e analytics.

ESP-IDF recomenda Secure Boot junto com Flash Encryption, oferece ESP HTTPS OTA e permite marcar a nova imagem como válida somente após diagnóstico; caso contrário, o bootloader pode reverter (visão de segurança S3, Flash Encryption, OTA e rollback). Esses recursos queimam eFuses e limitam recuperação: habilite em placas de teste, documente chaves e só então passe a release.

Protocolo de requisição

Além de TLS, uma chamada pode levar:

Authorization: Device <token>;
X-Request-Id UUID idempotente;
timestamp e nonce;
hash do corpo em assinatura HMAC, se usar segredo simétrico;
firmware_version e schema_version.

O backend rejeita timestamp muito antigo, nonce repetido, dispositivo revogado e firmware abaixo de uma versão mínima quando houver vulnerabilidade conhecida.

Atualização OTA

O fluxo seguro:

dispositivo consulta manifesto autenticado;
confere modelo de hardware, canal e versão;
baixa por HTTPS a imagem assinada na partição inativa;
verifica assinatura/hash;
reinicia na nova imagem em estado pending verify;
testa NVS, display, leitor, storage e conectividade básica;
marca válida; se travar ou falhar, rollback automático.

Arduino OTA é conveniente em laboratório, mas a versão de produto deve usar ESP-IDF HTTPS OTA com assinatura e controle de rollout. Faça 1%, 10%, 50%, 100% da frota e permita pausar. Atualizações de catálogo e spreads são dados versionados, menores e independentes do firmware; também precisam de assinatura e rollback.

Funcionamento offline

Função	Sem internet e sem servidor LAN	Com servidor local	Com cloud
Identificar cartas e orientação manual	Sim	Sim	Sim
Exibir nome, papel e significado curto	Sim	Sim	Sim
Validar spread	Sim	Sim	Sim
Histórico local	Sim	Sim	Sim
Interpretação determinística do catálogo	Sim	Sim	Sim
Síntese longa por LLM	Não no ESP32	Sim, Ollama/llama.cpp	Sim
TTS neural	Não no ESP32	Sim, Piper/modelo local	Sim
Perguntas adicionais	Limitadas a menus	Sim	Sim

O fallback offline pode concatenar conteúdo editorial por slot e uma síntese curta baseada em regras, sem fingir ser LLM. Exemplo: título do spread, papel, carta/orientação, significado curto e duas perguntas de reflexão pré-escritas. Essa resposta é previsível, instantânea e auditável.

Fila de sincronização:

leitura recebe UUID local;
fica pending_sync se o usuário habilitou histórico remoto;
reenvio usa o mesmo ID e chave idempotente;
ao obter confirmação, muda para synced;
exclusão local pode gerar tombstone se o servidor precisar apagar cópia.

Alimentação

Recomendação

Use USB-C de 5 V como alimentação principal. O aparelho ficará sobre uma mesa, e bateria adicionaria carregador, proteção, combustível, envelhecimento, certificação, risco térmico e suporte. Um cabo de tecido e uma fonte de boa qualidade podem fazer parte da estética.

Na PCB, USB-C não significa apenas soldar um conector: implemente corretamente resistores CC para sink, proteção ESD, fusível/limitador, reguladores, plano de retorno e corrente do backlight/áudio. Uma placa dev já resolve isso para o protótipo.

Se portabilidade for requisito real

Bateria	Vantagem	Limitação
LiPo pouch	Fina e fácil de integrar	Perfuração/inchaço, proteção mecânica e carregamento cuidadoso
18650 protegida	Disponível e substituível	Grande, suporte mecânico e qualidade variável de células
LiFePO4	Química mais estável e muitos ciclos	Tensão e carregador específicos; menor densidade

Use célula certificada, BMS/proteção, carregador com power-path, termistor e fuel gauge. Não carregue célula dentro de caixa de madeira sem análise térmica. Deep sleep ajuda quando a tela e o leitor estão desligados, mas um produto de mesa com display aceso consome muito mais no backlight e no Wi-Fi que o MCU em repouso. Meça o conjunto, não estime autonomia apenas pelo datasheet do ESP32.

Hardware físico e acabamento

Uma construção com aparência comercial pode combinar:

casca externa de madeira fresada ou impressa com acabamento fosco;
chassi interno impresso em 3D para alinhamento e manutenção;
janela de vidro/acrílico óptico sobre display;
superfície fina não metálica sobre a antena NFC;
PCB própria e cabos FFC/JST internos, sem Dupont;
encoder metálico, um botão de retorno e nenhum teclado desnecessário;
alto-falante em câmara fechada com tecido acústico;
luz indireta quente, não LEDs RGB aparentes;
parafusos acessíveis por baixo e peças substituíveis.

Metal perto da bobina NFC muda o campo; se houver alumínio, abra uma janela RF e valide com ferrite apropriada e projeto de antena. Madeira também varia em espessura e umidade. A antena deve ser sintonizada no conjunto final, não só na bancada.

Processo físico recomendado

protoboard para verificar componentes;
placa perfurada ou interposer com conectores confiáveis;
mockup de espuma/MDF para testar gestos e dimensões;
protótipo de gabinete impresso;
PCB de engenharia com pontos de teste;
revisão de RF, alimentação, ESD e térmica;
pequeno lote montado e teste de uso;
acabamento de produto.

Mesa e tabuleiro de Tarot

Arquitetura eletrônica possível

Uma versão de seis zonas pode usar um front-end ST25R e um multiplexador de bobinas. A ST publicou em 2025 uma nota específica para multiplexar seis antenas, incluindo parasitas e sequência de comutação. Isso confirma viabilidade, mas também mostra que não se trata de um simples multiplexador I2C (ST AN6121).

ESP32-S3 ─SPI─ ST25R reader ─ RF switch/matching ─ antenna 1
                                      ├────────── antenna 2
                                      ├────────── antenna 3
                                      ├────────── antenna 4
                                      ├────────── antenna 5
                                      └────────── antenna 6

Cada caminho precisa de componentes de matching, perdas medidas, tempo de assentamento e calibração. Um TCA9548A pode resolver endereços I2C de módulos, mas não resolve acoplamento entre campos RF.

Limite de layout

Uma Cruz Celta tem carta cruzando outra no centro. Duas tags sobrepostas podem ter leitura instável, e duas antenas sob a mesma área não separam bem as cartas. A mesa deve mudar o gesto, por exemplo, registrar a carta "cruzada" sequencialmente antes de colocá-la, ou usar câmera. Esse detalhe sozinho justifica não iniciar pela mesa completa.

Alternativa modular

Uma bandeja de três zonas que desliza ou se combina em módulos é mais útil que uma tábua rígida de dez. Ainda assim, conectores e calibração entre módulos precisam de identificação. Para spreads grandes, o display pode orientar captura sequencial e as cartas ficam livres sobre a mesa.

Experiência do usuário

Fluxo recomendado:

tocar no encoder para acordar;
escolher o spread; o último aparece primeiro;
ler uma instrução curta e deixar a tela escurecer;
embaralhar e dispor as cartas reais;
aproximar a carta do slot indicado;
aparelho mostra nome, papel e pergunta Normal ou invertida?;
girar o encoder se necessário e confirmar;
repetir, com som tátil discreto e progresso;
revisar miniaturas/lista sem interpretação;
escolher Leitura local, Interpretar com servidor ou Somente salvar;
receber síntese; áudio começa apenas se solicitado;
adicionar nota ou encerrar; a tela volta a um estado calmo.

Princípios:

tecnologia não compete com as cartas;
nenhuma captura ocorre silenciosamente;
é fácil desfazer a última carta;
Wi-Fi e IA não aparecem durante o embaralhamento;
não use cronômetro ou gamificação;
fale interpretação indisponível, leitura salva em vez de erro técnico;
ofereça modo sem cartas invertidas por deck/spread;
não force pergunta pessoal para iniciar.

Histórico e interface web opcional

O histórico deve guardar data, spread e sua versão, deck, cartas, orientação, pergunta opcional, interpretação, notas, provedor/modelo e versão do conteúdo. Não sobrescreva a captura quando uma interpretação for refeita; crie outra versão derivada.

Uma interface tarot.local na LAN ou domínio HTTPS pode oferecer:

busca e exportação do histórico;
exclusão e política de retenção;
vinculação e diagnóstico das 78 tags;
edição/validação de spreads;
atualização de catálogo e idioma;
escolha de cloud/local e modelo;
status, logs técnicos reduzidos e OTA;
backup criptografado.

O dispositivo continua capaz de capturar e ler significados básicos sem o painel. tarot.local via mDNS é conveniente, mas HTTPS local exige certificado confiável ou pinning no aparelho. Não exponha a interface doméstica diretamente à internet; use VPN, proxy autenticado ou acesso somente LAN.

Privacidade

Ofereça três modos visíveis:

Modo	Destino da pergunta e leitura	Garantia prática
Offline	Somente o aparelho	Sem IA; histórico pode ser local
Privado/LAN	Backend local + Ollama/llama.cpp/Piper	Nenhum conteúdo precisa sair da rede
Cloud	Backend próprio + provedor escolhido	Dados saem para o provedor conforme contrato/política

Antes do primeiro uso cloud, explique quais campos são enviados, provedor, retenção e como apagar. Permita enviar a tiragem sem a pergunta. Não use o conteúdo para analytics, treinamento próprio ou telemetria. Criptografe backups que contenham perguntas.

BOM e custos estimados

Premissas

Valores são faixas de varejo/pequeno lote observadas ou estimadas em agosto de 2026, sem frete, imposto, montagem, ferramenta e certificação. A conversão usa US$ 1 = R$ 5,2005, taxa informativa do Banco Central em 28 de agosto de 2026 (Conversor BCB). O preço brasileiro real pode ficar 25–100% acima da conversão por impostos, frete, margem e disponibilidade.

A ESP32-S3-DevKitC-1 aparecia por cerca de US$ 15–17 em distribuidores oficiais, enquanto displays e placas integradas variam muito. NTAG213 de marca no varejo custava US$ 2,95 por unidade ou US$ 2,36 em 100+, valor que faria 78 tags custarem US$ 184. Inlays genéricos em lote podem ser muito mais baratos, mas essa economia é estimativa até testar amostra e fornecedor (Mouser DevKitC, Adafruit NTAG213).

Nível 1: MVP sequencial

Item	Quantidade	USD estimado	BRL direto
ESP32-S3 DevKit com PSRAM	1	US$ 15–25	R$ 78–130
Módulo PN532 de boa procedência	1	US$ 12–25	R$ 62–130
NTAG213 fino, lote/amostra	78 + reserva	US$ 20–70	R$ 104–364
IPS 3,5 pol. e driver/touch opcional	1	US$ 18–40	R$ 94–208
Encoder, botão, buzzer e LED discreto	conjunto	US$ 5–12	R$ 26–62
Fonte USB-C e cabo	1	US$ 10–18	R$ 52–94
Placa de protótipo, conectores e cabos	conjunto	US$ 10–25	R$ 52–130
Gabinete impresso/MDF de protótipo	1	US$ 20–60	R$ 104–312
Total aproximado		US$ 110–275	R$ 572–1.430

Esse nível não inclui câmera, bateria, microfone, speaker nem PCB própria. Um OLED já disponível pode reduzir custo, mas não valida a experiência final de leitura.

Nível 2: intermediário integrado

Item	Quantidade	USD estimado	BRL direto
Placa S3 com PSRAM ou módulo + carrier	1	US$ 20–40	R$ 104–208
Kit PN7160/ST25R200 para avaliação	1	US$ 30–90	R$ 156–468
NTAG213 + reserva e gabarito	lote	US$ 20–70	R$ 104–364
IPS touch 4–4,3 pol.	1	US$ 35–80	R$ 182–416
MAX98357A/98360, speaker e acústica	conjunto	US$ 12–30	R$ 62–156
Microfone MEMS atual em breakout	1	US$ 5–18	R$ 26–94
microSD, conector e cartão	conjunto	US$ 8–18	R$ 42–94
Encoder, botões, iluminação e ESD	conjunto	US$ 10–25	R$ 52–130
PCB em pequeno lote e montagem parcial	lote	US$ 45–130	R$ 234–676
Gabinete refinado	1	US$ 60–180	R$ 312–936
Fonte, cabos e ferragens	conjunto	US$ 15–30	R$ 78–156
Total aproximado		US$ 260–710	R$ 1.352–3.692

Nível 3: premium de pequeno lote

Item	Quantidade	USD estimado	BRL direto
S3 customizado ou kit P4 + SoC de rádio	1	US$ 60–140	R$ 312–728
NFC atual, duas zonas, matching e ferrite	conjunto	US$ 60–180	R$ 312–936
Tags testadas e aplicação profissional	lote	US$ 30–100	R$ 156–520
IPS/AMOLED touch premium 4–5 pol.	1	US$ 70–170	R$ 364–884
Áudio completo e microfone atual	conjunto	US$ 30–80	R$ 156–416
Câmera e óptica, se realmente usada	1	US$ 20–70	R$ 104–364
PCB customizada, protótipos e montagem	lote	US$ 120–400	R$ 624–2.080
Gabinete madeira/alumínio/acrílico	1	US$ 180–600	R$ 936–3.120
Fonte, ESD, ferragens e conectores	conjunto	US$ 25–70	R$ 130–364
Gabaritos e montagem de pequeno lote	conjunto	US$ 100–350	R$ 520–1.820
Total aproximado		US$ 700–2.160	R$ 3.640–11.233

Uma mesa de 6–10 zonas pode acrescentar US$ 300–1.200 em antenas, front-ends/switches, PCB grande, calibração e gabinete. Certificação, desenvolvimento, moldes, perdas e mão de obra não aparecem nessas tabelas. Elas são orçamento de prototipagem, não custo unitário de produto em escala.

Projetos existentes e lições reutilizáveis

Não foi encontrado um produto aberto, recente e comprovado que una 78 cartas reais, orientação automática, spreads configuráveis, ESP32, backend e LLM exatamente como proposto. Há protótipos e projetos adjacentes valiosos:

Projeto	O que fez	Lição e ressalva
Nano ESP32 NFC Tarot Reader	Proposta de agosto de 2026 com Nano ESP32, PN532, OLED e 78 cartas	Confirma que catálogo cabe localmente; ainda era discussão, não produto validado
Tarot Tutor – MIT/Fab Academy	Tags nas cartas, MFRC522 e display	Mostra trabalho manual de gravar/vincular tags; usa hardware hoje antigo e não prova mesa multizona
RFID/NFC Tarot Reading Table	Ideia de 2015 para dez cartas, display e SD	A pergunta já antecipava o problema; não oferece implementação validada
RFID Poker Board – UIUC	Projeto 2026 de mesa com ESP32-S3, cartas tagueadas, posições e JSON	Precedente mais próximo para matriz/round-robin; o design mistura afirmações de ISO15693 com PN532/MFRC522 de modo suspeito e metas não comprovadas. Serve como alerta para validar protocolo e RF antes da PCB (documento)
Skull of Fate SAO	Carta eletrônica com NFC dinâmico, LEDs e sensores	Inspiração de objeto e interação, mas cada carta contém eletrônica, inviável para 78 no objetivo atual
Fortune Teller's Crystal Ball	ESP32, toque capacitivo e cartas num puzzle	Capacitivo é bom para presença/ritual, não identidade
pico_eink_tarot	Tarot eletrônico com e-paper e aleatoriedade física/ruído	Referência de display contemplativo; não reconhece baralho real
Zaparoo ESP32	Lê tokens NFC para acionar mídia, com suporte maker	Padrões de cadastro, feedback e leitura sequencial podem ser estudados; não copiar arquitetura/versões sem auditoria
AprilTag 3	Detector C de marcadores, múltiplos IDs e pose	Base madura para protótipo visual no servidor/P4
ESP32 QR Code Demo	Demonstra QR com ESP32-S3-EYE	Prova de QR no S3; desempenho de mesa com muitas cartas ainda precisa de benchmark

O padrão recorrente é revelador: protótipos de uma carta são fáceis; os problemas de produto estão em RF multizona, acabamento, orientação, fluxo e manutenção do conteúdo.

Componentes atuais: lista curta de decisão

Componente	Fabricante/status em 2026	Vantagens	Desvantagens e disponibilidade
ESP32-S3-WROOM/DevKitC	Espressif, ativo	Rádio, PSRAM em variantes, câmera/LCD/USB/I2S, ecossistema amplo	Confirmar PSRAM/flash e pinout exatos
ESP32-P4	Espressif, disponível, datasheet preliminar v0.7	Visão e HMI muito superiores	Sem rádio, mais caro e maior risco de revisão
NTAG213	NXP, ativo	Fino, UID 7 bytes, 144 B e anticolisão	Preço e qualidade do inlay variam; amostra obrigatória
ST25TN01K	ST, ativo	Alternativa Type 2 com UID e anticolisão	Ecossistema maker menor (produto)
PN532	NXP, NRND	Módulos e bibliotecas abundantes	Não usar como escolha automática de nova PCB
MFRC522	NXP, EOL/NRND	Muito barato	Evitar em projeto novo
PN7160	NXP, ativo	Firmware NCI, I2C/SPI, tags NFC 1–5	Integração NCI e antena ainda exigem engenharia
CLRC663 plus	NXP, ativo	A/B/V e múltiplas interfaces	Front-end de nível mais baixo que PN7160
ST25R200	ST, ativo	A/B/V, boa RF, duas antenas, longevidade	RFAL/matching e PCB mais especializados
OV2640	OmniVision, amplamente suportado pelo driver ESP	Barato, JPEG, 2 MP	Foco fixo e qualidade limitada
OV5640 AF	OmniVision, suportado pelo driver ESP	5 MP e autofocus em módulos compatíveis	Mais banda, RAM, lente e ajuste
MAX98357A	Analog Devices, produção	Módulos I2S simples	Geração antiga; comparar MAX98360 na PCB
T5837/T5848	TDK, produção	Microfones PDM/I2S atuais	São SMD; breakout pode ser menos comum
INMP441/ICS-43434	TDK, NRND/EOL	Módulos baratos ainda disponíveis	Não congelar em novo produto

Possíveis problemas

Risco	Nível	Consequência	Mitigação
Alcance NFC muda com carta e gabinete	Médio	Falhas intermitentes	Testar 10+ tags, materiais e tolerâncias; sintonizar no gabinete final
Tags empilhadas/colisão	Alto na mesa	Carta ausente ou UID instável	Uma zona por vez, geometria física e teste de carga do campo
Interferência entre leitores	Alto na mesa	Detuning e leituras cruzadas	RF sequencial, power-down, matching por antena e medição com protótipo
Orientação automática por NFC	Alto	Upright/reversed errado	Manual no MVP; duas zonas assimétricas no premium
Marcador visual pequeno	Médio/alto	Falso negativo	Câmera fixa, luz difusa, margem, tamanho mínimo medido
Reconhecimento da arte	Alto	Erro entre decks/cartas parecidas	Não incluir no MVP; servidor e dataset por deck, com confiança/fallback
Reflexo e oclusão da câmera	Alto	Cartas não detectadas	Acabamento fosco, iluminação controlada e revisão na tela
Wi-Fi/LAN indisponível	Médio	Sem LLM/TTS	Modo offline completo e fila de sincronização
Latência/custo da LLM	Médio	Ritual interrompido	Mostrar leitura local imediatamente, timeout, cache de TTS e cotas
LLM inventa carta ou certeza	Alto	Interpretação enganosa	Captura imutável, schema dinâmico, validação semântica e disclaimer
Vazamento de pergunta pessoal	Alto	Dano de privacidade	Modos visíveis, minimização, logs sem corpo, servidor local e exclusão
Direitos autorais de arte/texto	Alto	Remoção, licença ou litígio	Evidência por ativo, RWS histórico verificado, texto próprio, evitar Thoth sem licença
Hardware NRND/EOL	Médio	Redesign e fornecimento	PN532 só na bancada; validar PN7160/ST25R200 antes da PCB
Áudio com ruído/realimentação	Médio	Voz desagradável	Fonte limpa, layout I2S/amp, câmara, half-duplex e teste acústico
OTA defeituosa	Alto	Aparelho inutilizado	Imagem assinada, A/B, autoteste, rollback e rollout gradual
Corrupção/flash wear	Médio	Histórico perdido	NVS para config, LittleFS para dados, transações, backup e escrita agrupada
Bateria aquece/envelhece	Médio/alto	Segurança e suporte	USB-C no produto inicial; célula certificada e projeto específico depois
Interface domina o ritual	Médio	Produto vira app com cartas	Tela escurecida, poucos passos e estudo com usuários
Manutenção de spreads/conteúdo	Médio	Leituras inconsistentes	Versões, schema, assinatura, rollback e fontes registradas
Custo do lote explode	Alto	Produto inviável	protótipo RF/mecânico primeiro, três cotações e BOM alternativa por peça

MVP recomendado

Arquitetura escolhida

ESP32-S3 com PSRAM + PN532 em SPI + uma NTAG213 por carta + IPS 3,5 pol. + encoder + USB-C.

Sem câmera, bateria, microfone, mesa multiposição ou touch obrigatório. Orientação confirmada no encoder. O aparelho mantém catálogo e spreads em LittleFS, preferências em NVS e histórico local compacto. Um backend FastAPI/SQLite é adicionado depois que a captura funcionar.

Por que esta escolha vence:

identifica 78 cartas com precisão e sem luz;
preserva qualquer ilustração;
produz valor antes da IA;
permite testar se a experiência de aproximar cartas é natural;
falhas são fáceis de diagnosticar;
o PN532 pode ser trocado por leitor atual sem mudar o modelo de dados;
todo spread novo é configuração, não novo hardware.

Critérios de aceite do MVP

78 cartas vinculadas e lidas corretamente em 100 ciclos de teste cada;
leitura típica em menos de 500 ms após posicionamento, medida no conjunto real;
zero duplicação ao manter carta no campo por 10 segundos;
desfazer e substituir a última carta;
spreads de 1, 3 e 10 cartas sem recompilar;
funcionamento offline após desligar roteador;
histórico sobrevive a 100 ciclos de energia;
nenhum UID ou segredo aparece em logs normais;
gabinete temporário já define claramente a zona de leitura.

Se o gesto de confirmar orientação incomodar mais de 20% dos testes de uso, prototipe duas alternativas antes de seguir: duas tags distintas nas extremidades com zona estreita que lê apenas a extremidade apresentada, ou uma tag assimétrica com duas antenas espaciais. Duas tags dobram custo e precisam de teste de colisão/espessura; duas antenas são mais elegantes e muito mais exigentes em RF.

Versão premium recomendada

A versão premium ainda deve preservar captura sequencial, mas trocar o "tap" por um berço de leitura:

ESP32-S3 em PCB própria;
ST25R200 ou equivalente atual;
duas antenas alternadas, uma em cada extremidade do berço;
uma NTAG213 assimétrica por carta;
IPS/AMOLED touch de 4–4,3 pol.;
encoder físico mantido como controle principal;
speaker, MAX98360 e microfone atual com push-to-talk;
armazenamento local e áudio/TTS;
gabinete de madeira com chassi interno e área RF não metálica;
backend local/cloud selecionável.

Essa arquitetura detecta orientação automaticamente sem fotografar a mesa e sem modificar cada carta com duas tags. A ST25R200 pode conectar duas antenas single-ended, mas matching, chaveamento e alcance precisam ser comprovados na PCB; essa capacidade não transforma o RF em detalhe trivial.

Uma variante premium de mesa com câmera superior e AprilTag só deve nascer se testes mostrarem demanda real por captura simultânea. Nesse caso, ESP32-P4 + C6, iluminação difusa e câmera adequada formam uma base melhor que forçar o S3 a processar uma mesa inteira.

Roadmap

Fase 0: prova dos riscos principais

comprar S3, PN532 e 10 NTAG213 de 2–3 geometrias;
medir leitura com papel, sleeve, laminação, 2–8 mm de madeira/acrílico;
testar cartas isoladas, empilhadas e duas próximas;
provar display e encoder;
Critério de saída: escolher tag, zona e materiais sem desenhar PCB.

Fase 1: MVP offline

cadastrar 78 tags;
implementar catálogo, 1 carta, dois spreads de 3 e Cruz Celta;
orientação manual, desfazer e histórico;
gabinete funcional simples;
Critério de saída: dez pessoas completam leitura sem ajuda técnica.

Fase 2: backend

FastAPI, Pydantic e SQLite;
autenticação por dispositivo, idempotência e sync;
painel mínimo de histórico e configuração;
Critério de saída: perda de rede não perde nem duplica leitura.

Fase 3: LLM

catálogo com proveniência e JSON Schema;
integração local Ollama primeiro e um provedor cloud;
suíte fixa de avaliações em PT-BR;
Critério de saída: zero alteração de cartas/slots em testes e fallback confiável.

Fase 4: interface final

LVGL, direção editorial, acessibilidade e idiomas;
estudar 3,5 versus 4,3 pol.;
medir FPS, memória, temperatura e boot;
Critério de saída: UI sem travar captura ou rede.

Fase 5: áudio

I2S, speaker, MP3 e Piper/cloud TTS;
push-to-talk experimental;
Critério de saída: voz inteligível, sem ruído e com privacidade clara.

Fase 6: PCB de engenharia

migrar PN532 para PN7160/ST25R200 após comparação;
ESD, fonte, USB-C, test points e OTA A/B;
protótipo do berço de duas antenas;
Critério de saída: três placas montadas passam testes elétricos e RF.

Fase 7: gabinete

madeira/acrílico/impressão, câmara acústica e acesso de serviço;
gabarito para aplicar tags;
testes térmicos, queda leve, desgaste e limpeza;
Critério de saída: pequeno lote consistente, sem fios ou placas aparentes.

Fase 8: produto final

Secure Boot, Flash/NVS Encryption e OTA assinada;
provisionamento individual e recuperação;
licenças, manual, privacidade, descarte e suporte;
certificações e pré-compliance de rádio/EMC conforme mercado;
Critério de saída: piloto limitado antes de qualquer fabricação maior.

Diagrama final da arquitetura

flowchart LR
    C[Cartas reais com NTAG213] --> R[Zona NFC sequencial]
    R --> E[ESP32-S3 com PSRAM]
    U[Encoder, botão e display LVGL] <--> E
    E --> V[Validador de spread e orientação]
    V --> L[Catálogo e spreads no LittleFS]
    V --> H[Histórico e fila offline]
    V -->|JSON imutável por HTTPS| B[FastAPI + Pydantic]
    B --> D[(SQLite)]
    B --> K[Contexto do catálogo]
    K --> M{Modo escolhido}
    M --> O[Ollama ou llama.cpp na LAN]
    M --> P[Provedor cloud]
    O --> J[Saída JSON Schema validada]
    P --> J
    J --> B
    B -->|Texto e áudio autenticados| E
    T[Piper ou TTS cloud] --> B
    E --> A[I2S + amplificador + speaker]

Fluxo de confiança

UID da tag
  → tabela local UID/card_id
  → slot e orientação confirmados
  → validação contra spread.json
  → leitura persistida e imutável
  → contexto recuperado por card_id
  → LLM produz somente interpretação
  → schema + validação semântica
  → apresentação

Recomendações práticas

Compre somente dez tags primeiro. Diâmetro/retângulo da antena importa mais que a memória.
Use PN532 apenas para aprender e validar UX. Abra uma tarefa explícita de migração antes da PCB.
Não automatize orientação no primeiro mês. Meça se a confirmação manual é realmente um problema.
Não faça mesa de Cruz Celta antes do leitor único atingir confiabilidade. A sobreposição central é um risco próprio.
Comece offline. Se nomes, spreads e histórico dependem do backend, a arquitetura está errada.
Catalogue fontes e licenças antes de escrever 78 textos. Conteúdo copiado é dívida jurídica e editorial.
Teste IA com tiragens fixas. "Parece bonito" não mede fidelidade nem segurança.
Mantenha API de captura independente do provedor. Trocar OpenAI por Ollama não pode alterar o firmware.
Use USB-C e elimine bateria. Reabra a decisão somente após um caso de uso portátil real.
Construa um mockup de gabinete cedo. Gesto, antena, tela e acústica dependem da geometria física.

Conclusão

O projeto é tecnicamente viável e não exige uma arquitetura extravagante. Setenta e oito tags NFC, um ESP32-S3 e um leitor sequencial resolvem a parte mais importante: registrar com precisão cartas reais escolhidas por uma pessoa. O desafio não é armazenar o Tarot nem chamar uma LLM; é manter a experiência natural, reconhecer orientação honestamente, evitar hardware obsoleto na PCB e fazer RF, segurança, conteúdo e gabinete funcionarem juntos.

O primeiro protótipo deve usar ESP32-S3 + PN532 + NTAG213 + display IPS + encoder, com orientação manual, funcionamento offline e nenhum áudio/câmera. O PN532 é ferramenta de prototipagem, não compromisso de produto. Depois que o fluxo estiver validado, uma versão premium com ST25R200 e berço de duas antenas pode automatizar a orientação sem abandonar as cartas. Câmera/AprilTag e ESP32-P4 ficam como ramo separado para uma mesa de captura simultânea, caso a demanda compense sua complexidade.

Essa progressão mantém a tecnologia no lugar certo: invisível o bastante para sustentar cartas, ritual e interpretação, mas determinística o bastante para não deixar a inteligência artificial inventar o que aconteceu.

Fontes consultadas

Espressif e software embarcado

NFC, RFID e visão

UI, áudio, backend e IA

Tarot, direitos e referências de projeto

Nota sobre atualidade

Pesquisa concluída em 29 de agosto de 2026. Status de componentes, preços, APIs de IA, licenças e disponibilidade mudam. Confirme datasheets, lifecycle, estoque, termos de uso e legislação aplicável antes de fechar uma PCB, adquirir um lote ou comercializar conteúdo.