Sensores a la nube basados ​​en Bluetooth, ¿opción de procesador?

Esta es una pregunta bastante amplia, pero tengo curiosidad por saber cómo la gente haría esto y qué partes usarían para hacer el trabajo pesado.

Imagina que tienes un módulo bluetooth, funciona bien y se puede reprogramar para que actúe como un dispositivo central sin demasiados problemas. Desea conectar los datos de sus dispositivos periféricos bluetooth a una red wifi. ¿Cómo haría usted para esto? ¿Elegiría una MCU wifi como una serie TI CC3200 o Freescale (NXP) KW y simplemente la conectaría directamente al módulo bluetooth? ¿O le gustaría un microcontrolador intermedio como un PIC32 para hacer parte del trabajo pesado y tener un módulo separado para WiFi también? ¿Cuál sería tu razón para cualquiera de los dos?

Editar: para ser más transparente, he notado algunos sistemas IoT que tienen un componente de puente bluetooth-wifi, que generalmente tienen un módulo wifi y bluetooth, luego un microcontrolador adicional en el medio. WunderBar es un buen ejemplo de esto. ¿Por qué se molestaría con un microcontrolador adicional si estuviera usando algo tan capaz como un CC3200?

Hay un montón de opciones y un montón de razones por las que cualquiera de ellas es buena. ¿Qué datos está enviando y cómo desea que la gente acceda a ellos? ¿Una página web? ¿Un protocolo personalizado?
Tenía curiosidad acerca de por qué wunderbar tiene un microcontrolador adicional entre módulos ya que estaba considerando hacer algo similar.
¿Qué te hace pensar que la Wunderbar puede actuar como un puente Bluetooth-WiFi? Ciertamente tiene BT y WiFi, pero no veo ninguna indicación de que los 'puente' juntos.
@brhans su propósito es leer múltiples sensores BLE conectados y subirlos a la web a través de wifi

Respuestas (2)

Personalmente, piratearía uno de los enrutadores baratos como el TP-Link TL-WR702N. Puede ejecutar OpenWRT y tiene una interfaz serial para comunicarse con su módulo Bluetooth. De esta forma, puede, por ejemplo, crear un script de Python que transmita los datos entre el módulo bluetooth y una computadora en la misma red que el enrutador a través de conectores TCP.

Todo está integrado, disponible desde muchos lugares, y esta popular solución cuenta con un amplio soporte y está documentada prácticamente en todas partes en la web. Muy poca electrónica desafortunadamente/afortunadamente (dependiendo de lo que quieras aprender o cuál sea tu campo).

Por supuesto, también puede hacer más o menos lo mismo con una Raspberry PI o similar usando Wifi y dongles bluetooth.

Basado en https://developer.relayr.io/documents/WunderBar/MM , está claro que no querían diseñar un módulo wifi desde cero, por lo que usaron un módulo wifi listo para usar, que maneja la mayor parte del wifi y tcp -ip sobrecarga, y está certificado por la FCC para uso modular. Reduce sus gastos generales de codificación y fabricación. Utilizan un chip ARM de la serie K de Freescale para el cifrado y la traducción de los datos del sensor sin procesar. El chip BLE nuevamente parece usarse para descargar cualquier operación de Bluetooth.

Si hubieran utilizado un Freescale KW en su lugar, tendría que ser capaz de cumplir con los requisitos estándar de WIFI, TCP-IP y SSL, así como con su propio código. Y tendrían que diseñar una placa, probablemente multicapa, con consideraciones de RF 802.11b/g/n, opciones de antena, blindaje. Entonces tendrían que probarlo con la FCC. Elimina los errores. Los costos probablemente excedan cualquier beneficio.

En cuanto a por qué no usaron algo como el KW30Z, un Kinetic con BLE IC, eso es solo una suposición, pero tal vez obtuvieron un mejor soporte o un firmware preconstruido para Nordic que lo que tendrían con Freescale. Parece ser casi el doble de lo que sería el KW30Z, que es solo 20 centavos más que el MK22FN512VDC12 existente, pero mirando las especificaciones, el microcontrolador K22 es de 120MHz con 128KB Sram y 512KB flash, mientras que un microcontrolador BLE Kinetis comparable es solo 50 MHz/20 KB/160 KB . Obviamente, necesitaban más energía del microcontrolador de la que habría permitido usar un solo IC. Entonces optaron por un IC más grande (y más caro) debido a las necesidades de procesamiento.