Manufactura industrial
Internet industrial de las cosas | Materiales industriales | Mantenimiento y reparación de equipos | Programación industrial |
home  MfgRobots >> Manufactura industrial >  >> Manufacturing Technology >> Proceso de manufactura

XBee Walkie Talkie

Componentes y suministros

Goldilocks Analogue
Todavía como prototipo actualmente, pero la funcionalidad se puede recrear con MCP4822 DAC, amplificador de micrófono y amplificador de auriculares, junto con Arduino Uno.
× 1
MAX9744
× 1
MAX9814
× 1
MCP4921 DAC
× 1
Arduino UNO
× 1
Arduino Wireless Shield (Xbee)
× 1

Acerca de este proyecto

Estoy construyendo un clon avanzado de Arduino basado en el MCU AVR ATmega1284p con algunas características especiales que incluyen un DAC MCP4822 de 12 bits, amplificador de auriculares, memoria 2x SPI (SRAM, EEPROM) y una tarjeta SD. Hay muchas aplicaciones del mundo real para salidas analógicas, pero debido a que la plataforma Arduino no tiene capacidad DAC integrada, hay muy pocas aplicaciones publicadas para señales analógicas. Un Walkie Talkie es un ejemplo del uso de digital y analógico juntos para hacer un proyecto simple pero muy útil.

Analógico Ricitos de Oro - Prototipo 3

La funcionalidad real de Walkie Talkie es realmente solo unas pocas líneas de código, pero está construida sobre una base de entrada analógica (muestreo), salida analógica en el bus SPI al DAC MCP4822, rutinas de temporización de muestra y la plataforma de radio digital XBee. Empecemos desde arriba y luego profundicemos en las capas.

Radio XBee

Estoy usando radios XBee Pro S2B, configuradas para comunicarse punto a punto. Para el XBee Pro, debe haber una radio configurada como Coordinador y la otra como enrutador. Hay guías de configuración en Internet.

He configurado las radios para esperar el tiempo máximo entre caracteres antes de enviar un paquete, lo que implica que los paquetes se configurarán solo cuando estén llenos (84 bytes). Esto maximiza el rendimiento de la radio. El rendimiento bruto es de 250 kbit / s, pero la velocidad real de datos del usuario está limitada a unos 32 kbit / s. Esto tiene un impacto en la frecuencia de muestreo y, por lo tanto, en la calidad del habla que se puede transmitir.

Utilizando muestras de 8 bits, he descubierto que el muestreo de aproximadamente 3 kHz genera la mayor cantidad de datos que se pueden transmitir sin compresión. Dejo la compresión para otro proyecto.

Las radios XBee están configuradas en modo AT, que actúa como una tubería serial transparente entre los dos puntos finales. Esta es la forma más sencilla de conectar dos dispositivos mediante radio digital. Y me permitió hacer pruebas simples, usando cables, antes de preocuparme por si la plataforma de radio estaba funcionando o no.

Al observar el rastreo de un analizador lógico, podemos ver los paquetes de datos XBee que llegan a la línea (púrpura) Rx del puerto serie. Los paquetes de datos recibidos se almacenan en un búfer de anillo y se reproducen a una velocidad constante. He permitido hasta 255 bytes en el búfer de anillo de recepción, y esto será suficiente porque el tamaño del paquete XBee es de 84 bytes.

Las muestras que se van a transmitir al otro dispositivo se transmiten en la línea Tx (azul), más o menos en cada período de muestra, aunque se almacenan en búfer antes de la transmisión. La radio XBee almacena en búfer estos bytes por hasta 0xFF períodos entre símbolos (configuración) y solo transmite un paquete al otro extremo cuando tiene un paquete completo.

Frecuencia de muestreo

Al observar el presupuesto de bits para el enlace de transmisión, debemos calcular cuántos datos se pueden transmitir sin sobrecargar la plataforma de radio XBee y causar pérdida de muestra. Como no estamos comprimiendo abiertamente las muestras de voz, tenemos muestras de 8 bits por muestreo de 3000 Hz o 24 kbit / s para transmitir. Esto parece funcionar bastante bien. Probé el muestreo de 4 kHz, pero está demasiado cerca del máximo teórico y no funciona con demasiada eficacia.

Mirando el analizador lógico, podemos ver la llegada de un paquete de bytes que comienza con 0x7E y 0x7C en la línea Rx. Tanto el amplificador de micrófono como la salida DAC están polarizados alrededor de 0x7F (FF), por lo que podemos leer que los niveles de señal capturados y transmitidos aquí son muy bajos. La frecuencia de muestreo que se muestra es de 3000 Hz.

Procesamiento de muestras

He puesto un "ping" en una salida para capturar cuándo se está procesando la interrupción de muestreo (amarillo). Podemos ver que la cantidad de tiempo empleado en el procesamiento de la interrupción es muy pequeña para esta aplicación, en relación con el tiempo total disponible. Posiblemente se podría implementar algún tipo de compresión de datos.

Durante la interrupción del muestreo, hay dos actividades principales:generar una salida de audio, colocar una muestra en el DAC y luego leer el ADC para capturar una muestra de audio y transmitirla al búfer USART.

Esto lo hace la función audioCodec_dsp, que se llama desde el código en una interrupción del temporizador.

Estoy usando el AVR de 8 bits Timer0 para generar los intervalos de muestra regulares, activando una interrupción. Al usar una frecuencia MCU FCPU que es un múltiplo binario de las frecuencias de audio estándar, podemos generar tasas de muestreo de reproducción precisas usando solo el temporizador de 8 bits con un preescalador de reloj de 64. Para generar frecuencias de audio impares, como 44,100 Hz, el 16 bit Timer1 se puede utilizar para obtener suficiente precisión sin necesidad de un preescalador de reloj.

El ADC ATmega1284p está configurado en modo de ejecución libre y se reduce a 192 kHz. Si bien esto está cerca de la velocidad de adquisición máxima documentada para el ATmega ADC, todavía está dentro de la especificación para muestras de 8 bits.

Esta interrupción tarda 14 us en completarse y es muy corta en relación con los 333 us que tenemos para cada período de muestra. Esto nos da mucho tiempo para hacer otro procesamiento, como ejecutar una interfaz de usuario o procesar más audio.

Transacción SPI

En el último nivel de detalle, podemos ver la transacción SPI real para enviar la muestra entrante al DAC MCP4822.

Como he construido esta aplicación en el Goldilocks Analogue Prototype 2 que usa el bus SPI estándar, la transacción es normal. Mis últimos prototipos utilizan el modo SPI maestro en USART 1 del ATmega1284p, que acelera ligeramente la transacción SPI a través del almacenamiento en búfer doble y libera el bus SPI normal para lectura o escritura simultánea en la tarjeta SD o memoria SPI, para transmisión de audio. En la aplicación Walkie Talkie no hay necesidad de capturar el audio, por lo que no hay inconveniente en usar los prototipos más antiguos y el bus SPI normal.

Conclusión

Usando algunas herramientas preexistentes y algunas líneas de código, es posible construir rápidamente un walkie talkie encriptado digitalmente, capaz de comunicar voz (comprensible, pero no de alta calidad). Y no habrá ningún camionero de CB que esté escuchando las conversaciones familiares en el futuro.

Esta fue una prueba de agregar entrada de micrófono basada en el MAX9814 al Goldilocks Analogue. Revisaré el Prototype 3 y agregaré un circuito de amplificación de micrófono para admitir aplicaciones que necesiten entrada de audio, como este ejemplo de walkie talkie, o cambiadores de voz o sintetizadores de música de control vocal.

Dos prototipos Goldilocks Analogue con radios XBee y amplificadores de micrófono.

También estoy ejecutando los dispositivos ATmega1284p a la frecuencia aumentada de 24,576 MHz, por encima de la frecuencia estándar de 20 MHz. Esta frecuencia específica permite una reproducción muy precisa de muestras de audio desde 48 kHz hasta 4 kHz (o incluso hasta 1500 Hz). Los ciclos de reloj de MCU adicionales por período de muestra son muy bienvenidos cuando se trata de generar música sintetizada.

Codifique como de costumbre en Sourceforge AVR freeRTOS Además, una llamada a Shuyang en SeeedStudio, que es OPL, es increíble y es la fuente de muchos componentes y PCB.


Código

  • Código
  • Código
  • Código
Código C / C ++
 void audioCodec_dsp (uint16_t * ch_A, uint16_t * ch_B) {int16_t xn; uint8_t cn; / * ----- Audio Rx ----- * / / * Obtiene el siguiente carácter del búfer de anillo. * / if (ringBuffer_IsEmpty ((ringBuffer_t *) &(xSerialPort.xRxedChars))) {cn =0x80 ^ 0x55; // pone la señal anulada de la ley A en la salida. } else if (ringBuffer_GetCount (&(xSerialPort.xRxedChars))> (portSERIAL_BUFFER_RX>> 1)) // si el búfer está más de la mitad de su capacidad. {cn =ringBuffer_Pop ((ringBuffer_t *) &(xSerialPort.xRxedChars)); // saca dos muestras para ponerse al día, descarta la primera. cn =ringBuffer_Pop ((ringBuffer_t *) &(xSerialPort.xRxedChars)); } else {cn =ringBuffer_Pop ((ringBuffer_t *) &(xSerialPort.xRxedChars)); // extraer una muestra} alaw_expand1 (&cn, &xn); // expande la compresión A-Law * ch_A =* ch_B =(uint16_t) (xn + 0x7fff); // mover la señal a valores positivos, poner la señal en el canal A y B. / * ----- Audio Tx ----- * / AudioCodec_ADC (&mod7_value.u16); // la muestra es de 10 bits justificada a la izquierda. xn =mod7_value.u16 - 0x7fe0; // centra la muestra en 0 restando 1/2 rango de 10 bits. IIRFilter (&tx_filter, &xn); // filtrar el tren de muestras transmitido alaw_compress1 (&xn, &cn); // comprimir usando A-Law xSerialPutChar (&xSerialPort, cn); // transmitir la muestra} 
Código C / C ++
 ISR (TIMER0_COMPA_vect) __attribute__ ((hot, flatten)); ISR (TIMER0_COMPA_vect) {# si está definido (DEBUG_PING) // marca de inicio - comprobar el inicio de la interrupción - solo para depuración (trazo amarillo) PORTD | =_BV ( PORTD7); // Hacer ping a la línea IO. # Endif // Rutina de transferencia de datos del MCP4822 // mover los datos al MCP4822 - hecho primero por regularidad (jitter reducido). DAC_out (ch_A_ptr, ch_B_ptr); // Rutina de procesamiento de audio:realice cualquier procesamiento en la entrada que sea necesario:prepare la salida para la siguiente muestra. // Activa el controlador de audio global, que es una función de devolución de llamada, si está configurado. if (audioHandler! =NULL) audioHandler (ch_A_ptr, ch_B_ptr); # if definido (DEBUG_PING) // marca de fin - comprobar el final de la interrupción - solo para depuración (trazo amarillo) PORTD &=~ _BV (PORTD7); # endif} 
Código C / C ++
 void DAC_out (const uint16_t * ch_A, const uint16_t * ch_B) {DAC_command_t write; if (ch_A! =NULL) {write.value.u16 =(* ch_A)>> 4; write.value.u8 [1] | =CH_A_OUT; } else // ch_A es NULL así que apagamos el DAC {write.value.u8 [1] =CH_A_OFF; } SPI_PORT_SS_DAC &=~ SPI_BIT_SS_DAC; // Tire SS hacia abajo para seleccionar el DAC analógico Goldilocks. SPDR =write.value.u8 [1]; // Comienza la transmisión ch_A. while (! (SPSR &_BV (SPIF))); SPDR =write.value.u8 [0]; // Continuar la transmisión ch_A. if (ch_B! =NULL) // comenzamos a procesar ch_B mientras estamos haciendo la transmisión ch_A {write.value.u16 =(* ch_B)>> 4; write.value.u8 [1] | =CH_B_OUT; } else // ch_B es NULL, entonces apagamos el DAC {write.value.u8 [1] =CH_B_OFF; } while (! (SPSR &_BV (SPIF))); // verificamos que hayamos terminado ch_A. SPI_PORT_SS_DAC | =SPI_BIT_SS_DAC; // Eleve SS para anular la selección del DAC analógico Goldilocks y enganche el valor en el DAC. SPI_PORT_SS_DAC &=~ SPI_BIT_SS_DAC; // Tire SS hacia abajo para seleccionar el DAC analógico Goldilocks. SPDR =write.value.u8 [1]; // Comienza la transmisión ch_B. while (! (SPSR &_BV (SPIF))); SPDR =write.value.u8 [0]; // Continuar la transmisión ch_B. while (! (SPSR &_BV (SPIF))); // comprueba que hemos terminado ch_B. SPI_PORT_SS_DAC | =SPI_BIT_SS_DAC; // Eleve SS para anular la selección de Goldilocks Analogue DAC y enganche el valor en DAC.} 
AVRfreeRTOS en Sourceforge
Repositorio del puerto AVR de freeRTOS, incluidos los archivos de prueba DAC.h y Analogue utilizados en este proyecto. NO use el repositorio de github vinculado. Vaya a sourceforge para obtener el código más reciente. Https://sourceforge.net/projects/avrfreertos /https://github.com/feilipu/avrfreertos

Esquemas

No es absolutamente correcto, ya que está usando un DAC MCP4725 (I2C) y no un DAC MCP4822 (SPI), pero Fritzing no tenía la placa de arranque Adafruit correcta.

Además, se dibuja en una sola dirección ... (con la excepción de que Rx y Tx están interconectados).
Las placas XBee simplemente reemplazan los dos cables que conectan el Rx y el Tx. Cualquier aparato de radio que pueda transportar suficientes datos funcionaría. Esquemas para la salida DAC y el amplificador de auriculares.
Se agregará un amplificador de entrada de micrófono en el prototipo 4.

Proceso de manufactura

  1. Consideraciones para el mecanizado suizo de alta producción
  2. Guía para la creación de prototipos CNC
  3. Comprensión del proceso de fabricación del eje
  4. ¿Qué es la pasivación de acero inoxidable?
  5. Lectura de sensores analógicos con un pin GPIO
  6. Sensores analógicos en Raspberry Pi con un MCP3008
  7. Cómo generar una forma de onda de alta precisión utilizando un DAC y una PCB personalizada
  8. Controlador de riego IOT Win10 con sensores de humedad
  9. El valor de la medición analógica
  10. Dibuje cualquier cosa en su osciloscopio
  11. Cables blindados para circuitos de señal (parte 2)