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

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

Estudo técnico para construir um dispositivo de Tarot físico, confiável e evolutivo, comparando NFC, visão computacional, mesas sensorizadas e soluções híbridas.

Posted August 29, 2026. Markdown. Tags: pesquisa, esp32, nfc, tarot, hardware, inteligencia-artificial, iot.

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:

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:

  1. Captura física: obter card_id, orientação, ordem e posição.
  2. Validação determinística: rejeitar carta duplicada indevida, slot inexistente, contagem errada e tag não vinculada.
  3. Conhecimento local: nomes, significados, spreads e histórico.
  4. Interpretação opcional: enviar fatos validados ao backend e à LLM.
  5. 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:

Limitações:

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 é:

  1. uma antena fisicamente delimitada por slot;
  2. habilitar apenas um campo RF por vez;
  3. percorrer os slots em varredura rápida;
  4. usar SPI com chip select, enables/power switches ou front-end com seleção de antena;
  5. calibrar cada antena já montada no gabinete final;
  6. 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:

  1. QR ou Data Matrix: fácil de gerar e decodificar, porém visualmente intrusivo se grande; pequeno exige foco e iluminação.
  2. 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).
  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.
  4. 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:

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:

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:

Leitor e tags por fase

Distribuição de periféricos

Uma configuração plausível de produto:

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 é:

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

Módulos do firmware

O firmware pode continuar simples, mas deve separar responsabilidades:

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:

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:

  1. gerar dinamicamente enum com os slot_id daquela leitura;
  2. exigir todos os slots e additionalProperties: false;
  3. não aceitar card_id retornado pela IA como fonte de verdade; o backend o reinsere a partir da leitura;
  4. validar tamanho, idioma e ausência de novos slots;
  5. limitar tentativas e usar fallback determinístico se o provedor falhar;
  6. guardar provider, model, prompt_version, catálogo e parâmetros usados;
  7. 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:

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:

  1. fatos do deck e nomes;
  2. significados de fonte histórica;
  3. adaptação editorial original em PT-BR;
  4. 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.

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:

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

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:

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:

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:

Medidas recomendadas

  1. 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.
  2. 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.
  3. NVS Encryption e Flash Encryption: proteger credenciais em repouso; usar chaves por dispositivo.
  4. Secure Boot v2: executar somente firmware assinado.
  5. OTA HTTPS assinada: duas partições, autoteste e rollback; anti-rollback depois de um processo de release maduro.
  6. Rate limit e cotas: impedir que um token roubado gere custo ilimitado de LLM/TTS.
  7. Validação de entrada: tamanho máximo de pergunta, schema de spread, IDs permitidos e número exato de cartas.
  8. 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:

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:

  1. dispositivo consulta manifesto autenticado;
  2. confere modelo de hardware, canal e versão;
  3. baixa por HTTPS a imagem assinada na partição inativa;
  4. verifica assinatura/hash;
  5. reinicia na nova imagem em estado pending verify;
  6. testa NVS, display, leitor, storage e conectividade básica;
  7. 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:

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:

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

  1. protoboard para verificar componentes;
  2. placa perfurada ou interposer com conectores confiáveis;
  3. mockup de espuma/MDF para testar gestos e dimensões;
  4. protótipo de gabinete impresso;
  5. PCB de engenharia com pontos de teste;
  6. revisão de RF, alimentação, ESD e térmica;
  7. pequeno lote montado e teste de uso;
  8. 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:

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

Princípios:

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:

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:

Critérios de aceite do MVP

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:

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

Fase 1: MVP offline

Fase 2: backend

Fase 3: LLM

Fase 4: interface final

Fase 5: áudio

Fase 6: PCB de engenharia

Fase 7: gabinete

Fase 8: produto final

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

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

View the original Markdown file

Ideas | What changed | RSS | About | Text version

Pablo Murad <pablomurad@pm.me>