Preço de amostra, não preço por volume.
Solicitar uma amostra86 × 54 × 3.2 mm, 30 g, 20-24 h de gravação. Protocolo Bluetooth aberto, código de referência incluído.
Entregamos o protocolo Bluetooth completo junto com um conjunto de código de referência. Você escreve a camada de transcrição, armazenamento e recuperação do jeito que o seu negócio precisa e envia as gravações direto para a sua própria base de conhecimento. O nosso trabalho é captar o som com fidelidade.
O dispositivo tem iniciar e parar, e mais nada. O áudio volta por Bluetooth; como é transcrito, onde é armazenado e em qual base de conhecimento entra é decidido pelo seu código.
As gravações vão do cartão para o celular por Bluetooth LE a cerca de 30 KB/s, então uma gravação de uma hora chega em cerca de 4 minutos. Nosso app de referência para Android mostra cada etapa funcionando em hardware real, para que a sua equipe comece de um código que funciona, e não de um documento de protocolo.
2 minutos em um celular real: conectar, baixar com velocidade ao vivo, retomar após uma queda, fala para texto, reprodução e exclusão.
A mesma demonstração em formato de celular.
Medido em um celular Android 9 com uma amostra CB08, firmware V1.0.0. A velocidade no seu celular e firmware poderá variar.
O código-fonte completo do Android (Java puro, sem bibliotecas de terceiros) e o documento do protocolo BLE são fornecidos com os pedidos de amostra.
O documento do protocolo e o código-fonte do Android acompanham o pedido de amostra. ODM, white-label e implantação on-premise são cotados à parte.
Serviço principal GATT 0xAE20, escrita em 0xAE21, notificação em 0xAE22. O conjunto de comandos, a transferência de arquivos e a autoverificação estão no documento do protocolo que acompanha o pedido de amostra.
Enviar, ingerir, buscar, perguntar: quatro endpoints e pronto. Ou leve apenas o hardware e o protocolo e aponte a transcrição para o seu próprio ASR.
A camada de recepção e transcrição pode rodar inteiramente dentro da sua própria sala de servidores, de modo que o áudio nunca sai da sua rede. Reuniões, consultas e aulas costumam exigir isso.
Tudo abaixo foi medido em unidades que já enviamos, não copiado da folha de dados de um fornecedor. Onde as nossas medições discordam da documentação do fornecedor do chip, dizemos isso e informamos o número que de fato observamos. Seus engenheiros podem conferir cada linha em um dispositivo real assim que tiverem a amostra em mãos.
Um serviço primário, uma característica de escrita, duas características de notificação. Respostas, áudio e dados de arquivo compartilham o 0xAE22; os eventos de tecla e de estado de gravação ficam isolados no 0xAE23, para que os dois fluxos não corrompam os quadros parciais um do outro.
| UUID | Propriedade | Uso |
|---|---|---|
| 0xAE20 | Primary Service | Serviço principal |
| 0xAE21 | WRITE_WITHOUT_RESPONSE | App → dispositivo |
| 0xAE22 | NOTIFY | Respostas, áudio, lista de arquivos, dados de arquivo |
| 0xAE23 | NOTIFY | Eventos de tecla, estado de gravação |
Os comandos são pares TYPE-CMD. A tabela completa, incluindo streaming em tempo real e download segmentado, está no documento do protocolo que acompanha o pedido de amostra; estes são os que uma integração precisa primeiro.
| TYPE-CMD | Nome | Parâmetros / resposta |
|---|---|---|
| 0-0 | Sincronizar hora | ano 2B LE + mês/dia/hora/min/seg, 1B cada |
| 0-1 / 0-2 | Obter / responder armazenamento | remain 4B LE + total 4B LE. A unidade é 1 KB, e não os blocos de 8 KB que o documento do fornecedor indica |
| 0-3 / 0-4 | Obter / responder bateria | 1B, 0–100; 110 significa carregando |
| 0-10 / 0-11 | Obter / responder firmware | 6B ASCII, p. ex. V1.0.0 |
| 2-0 / 2-1 | Obter / responder lista de arquivos | count 4B BE + N×28B entradas; pode abranger várias notificações |
| 2-2 | Solicitar download | offset 4B LE + nome do arquivo 24B — deve ser uma única escrita GATT de 36 bytes |
| 2-3 / 2-4 / 2-5 | Início / dados / fim | código de fim 0=ok, 1=não encontrado, 2=offset grande demais, 3=outro |
| 2-8 / 2-13 | Excluir um / confirmação | mesmo endereçamento de 2-2, extensão restaurada. Confirmação 1B, 0=ok |
| 1-0 / 1-1 / 1-2 | Tempo real iniciar / áudio / parar | o dispositivo envia o nome do arquivo e, depois, pacotes OPUS fixos de 40 bytes |
Seis coisas que nos custaram tempo de verdade para descobrir. Publicamos porque um integrador que esbarra nelas sem aviso vai achar que o hardware está com defeito.
O dispositivo armazena internamente OPUS a cerca de 16 kbps. Pedir um .wav só faz com que ele decodifique esse áudio já com perdas para PCM de 256 kbps: sem ganho de qualidade e com cerca de 16× mais bytes. No app de referência para Android, uma gravação de uma hora (cerca de 7.2 MB em OPUS) chega ao celular em cerca de 4 minutos, medido a 30.7 KB/s.
Tanto o fluxo em tempo real quanto os arquivos retirados do dispositivo são pacotes OPUS fixos de 40 bytes, sem contêiner. É preciso envolvê-los em Ogg antes de salvar. O CRC-32 do Ogg não é refletido e não tem XOR final: não é o do zlib. Se errar, você produz um arquivo que parece Ogg e que todo player recusa em silêncio. Vetor de teste: oggCrc("123456789") == 0x89A1897F.
A solicitação de download 2-2 tem 36 bytes e deve sair como uma única escrita GATT. No Android, uma escrita é MTU−3, e o MTU padrão de 23 permite apenas 20 bytes: o nome do arquivo é truncado e o dispositivo responde “arquivo não encontrado”. Exija que requestMtu(≥39) tenha sucesso e falhe de forma explícita; um fallback de melhor esforço só produz um erro confuso.
A documentação do fornecedor diz que o 0-2 retorna blocos de 8 KB. Ele retorna unidades de 1 KB. Tratá-las como 8 KB infla a capacidade oito vezes; tratá-las como bytes a reduz em 1024. Nenhum dos dois gera erro: você simplesmente exibe um número absurdo. Uma unidade verificada informa 28.8 de 29.1 GB utilizáveis.
O campo de 4 bytes em cada entrada de 28 bytes da lista é a duração, não a hora. A única fonte de hora é o próprio nome do arquivo: note20260830-014512 ou call20260830-014512. Faça o parse, ordene da mais recente para a mais antiga e use o prefixo para distinguir gravações ambiente de chamadas.
A Apple o bloqueia em todos os navegadores do iOS, inclusive o Chrome, porque o Chrome no iOS é WebKit por baixo. É uma restrição do sistema operacional, sem solução alternativa. Um app para iPhone precisa usar o CoreBluetooth nativo.
O microfone de condução óssea costuma ser mal interpretado, inclusive por quem já manuseou o dispositivo. Ele não capta o crânio de quem o usa. Fica encostado na parte de trás do celular e capta a vibração do fone de ouvido, porque um microfone de ar não consegue ouvir a outra ponta de uma chamada que não está no viva-voz.
A consequência é o que há de mais útil neste hardware. No modo chamada, o microfone de ar é, na prática, o falante próximo e o microfone de vibração é o interlocutor remoto: as duas vozes são separadas fisicamente, antes de qualquer software rodar. Transcreva cada canal e atribua os trechos pela diferença de energia e você obtém uma atribuição quase perfeita, sem nenhum modelo de impressão de voz. As gravações mono recorrem ao diarization_enabled, que só se aplica a mono e adivinha a partir das características da voz.
Oito endpoints. Ou leve apenas o hardware e o protocolo, aponte a transcrição para o seu próprio ASR e nunca nos chame em tempo de execução.
| Endpoint | Finalidade |
|---|---|
| POST /rec/v1/upload | Enviar um arquivo de áudio |
| POST /rec/v1/ingest | Enviar para transcrição |
| GET /rec/v1/item/{id} | Transcrição, resumo, itens de ação |
| POST /rec/v1/ask | Fazer uma pergunta sobre uma gravação |
| GET /rec/v1/list | Listar gravações |
| POST /rec/v1/item/{id}/speakers | Renomear falantes: apenas renderiza de novo, sem retranscrever, sem custo extra |
| POST /rec/v1/retranscribe/{id} | Reexecutar com outro mecanismo de ASR |
| POST /rec/t/{key}/search | Endpoint de plugin para assistente de voz; sempre retorna HTTP 200 com uma frase falável |
A camada de recepção e transcrição roda inteiramente dentro da sua rede, sem que nenhum áudio saia dela. Não é exigente: é uma caixa pequena sem ventoinha, não um servidor com GPU.
| Item | Requisito |
|---|---|
| CPU | Intel N97 / N100 / N150. Diferença de até 10% entre eles; não vale a pena se preocupar |
| RAM | 8 GB. Pico medido de 797 MB: 16 GB é desperdício |
| Disco | 268 MB de modelos, mais os dados do cliente |
| Vazão | Cerca de 4× o tempo real: 27 segundos de áudio transcritos em 6.5 segundos |
Todos os componentes estão liberados para redistribuição comercial. O GeoNames exige atribuição no seu rodapé; os demais, não.
| Componente | Licença |
|---|---|
| sherpa-onnx (ASR), RapidOCR | Apache-2.0 |
| cndoc, anydoc, pdf-inspector, pdfplumber | MIT |
| pypdfium2 | BSD-3 |
| Banco de dados de lugares GeoNames | CC BY 4.0: atribuição obrigatória no rodapé |
Não. O documento do protocolo Bluetooth e o código-fonte do app de referência para Android acompanham o pedido de amostra. Você pode apontar a transcrição para o seu próprio ASR, para um serviço de terceiros ou para uma instância on-premise, e nunca chamar os nossos servidores em tempo de execução.
Sim. A camada de recepção e transcrição roda no seu próprio servidor, e nenhum áudio passa por nós. Uma caixa Intel N97 ou N100 com 8 GB de RAM transcreve a cerca de 4× o tempo real, o que basta para reuniões, consultas e aulas.
No modo chamada, sim, e sem modelo de impressão de voz: o microfone de ar e o de condução óssea captam fisicamente as duas partes em canais separados. As gravações ambiente em mono recorrem à diarização algorítmica, que é menos confiável.
1.000 unidades é o típico. É negociável abaixo disso no ferramental existente com a nossa embalagem. O prazo mais curto de amostra em uma unidade de estoque é de 72 horas.
O iOS precisa de um app nativo com CoreBluetooth, porque a Apple bloqueia o Web Bluetooth em todos os navegadores do iOS. O protocolo é o mesmo; só muda a API de transporte. Podemos desenvolver o app ou entregar o protocolo à sua equipe.
Sim, em vídeo. Temos uma demonstração de 2 minutos do nosso app de referência para Android rodando em um celular real com o gravador. Uma gravação de uma hora chega ao celular em cerca de 4 minutos (3 min 49 s medidos a 30.7 KB/s). O código-fonte do Android e o documento do protocolo BLE acompanham o pedido de amostra.
Todos os números acima foram medidos, e cada afirmação pode ser verificada em uma unidade real. A referência completa do protocolo, incluindo streaming em tempo real, download segmentado e a tabela completa de notas de campo, está no documento do protocolo que acompanha o pedido de amostra.
Não. O documento do protocolo Bluetooth e o código-fonte do app de referência para Android acompanham o pedido de amostra. Você pode apontar a transcrição para o seu próprio ASR, para um serviço de terceiros ou para uma instância on-premise, e nunca chamar os nossos servidores em tempo de execução.
Sim. A camada de recepção e transcrição roda no seu próprio servidor, e nenhum áudio passa por nós. Uma caixa Intel N97 ou N100 com 8 GB de RAM transcreve a cerca de 4× o tempo real, o que basta para reuniões, consultas e aulas.
No modo chamada, sim, e sem modelo de impressão de voz: o microfone de ar e o de condução óssea captam fisicamente as duas partes em canais separados. As gravações ambiente em mono recorrem à diarização algorítmica, que é menos confiável.
1.000 unidades é o típico. É negociável abaixo disso no ferramental existente com a nossa embalagem. O prazo mais curto de amostra em uma unidade de estoque é de 72 horas.
O iOS precisa de um app nativo com CoreBluetooth, porque a Apple bloqueia o Web Bluetooth em todos os navegadores do iOS. O protocolo é o mesmo; só muda a API de transporte. Podemos desenvolver o app ou entregar o protocolo à sua equipe.
Sim, em vídeo. Temos uma demonstração de 2 minutos do nosso app de referência para Android rodando em um celular real com o gravador. Uma gravação de uma hora chega ao celular em cerca de 4 minutos (3 min 49 s medidos a 30.7 KB/s). O código-fonte do Android e o documento do protocolo BLE acompanham o pedido de amostra.
25 horas de gravação contínua e 15 dias em espera, com uma bateria de 400mAh carregada por conector USB magnético.
Dois microfones omnidirecionais mais um microfone de condução óssea, que se mantém limpo em uma sala de reunião, um consultório ou uma sala de aula.
86 × 54 × 3.2 mm, a área de um cartão bancário, com cerca de 28 gramas em um corpo de alumínio monobloco usado com capa de couro. Uma tela monocromática de 0.42 polegada mostra hora, bateria e estado da gravação.
Cor da carcaça e caracteres em serigrafia, material da capa e logotipo em relevo, estrutura da embalagem e o conjunto completo de impressão, manual e etiquetas de conformidade no idioma local. No software, a tela de inicialização e os textos da interface, um app com a sua marca ou o seu próprio app que fale o protocolo, os mecanismos de transcrição e de resumo que você indicar e uma base de conhecimento privada e um backend on-premise.
Conte-nos o caso de uso, o mercado-alvo e o volume esperado, e voltaremos com preços e um plano de personalização. As amostras podem ser enviadas; a documentação do protocolo Bluetooth pode ir antes para os seus engenheiros.
PINGOOD TECHNOLOGY CO. LIMITED (operando como AI HW Stack) é uma ODM/OEM de hardware com IA sediada em Shenzhen. Entregamos a stack completa (design industrial e ferramental, placa principal, firmware Android, o pipeline de ASR + LLM + TTS, o app companheiro e o backend na nuvem) em um único pedido.
Tecnologia em que nos baseamos: Android TV, Azure AI Speech, OpenAI speech-to-text, Alibaba Model Studio, Cloudflare Workers.
Publicado em 2026-09-01 · · Contato: kristy@aihwstack.com
