Autor Tema: Proyecto para medir el valor eficaz verdadero (True RMS)  (Leído 8189 veces)

0 Usuarios y 3 Visitantes están viendo este tema.

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #45 en: 22 de Agosto de 2023, 23:09:02 »
Me acabo de llevar un chasco, estaba colocando los componentes que conforman el amplificador diferencial, cuando me acabo de dar cuenta que diseñe el PCB con el footprint del OP, pensando que tenía unas muestras de un tamaño determinado, cuando en realidad eran más grandes:



Ahora lo que tengo que hacer, es comprar del tamaño correcto y esperar a que lleguen.

Tal vez me anime adelantar, la parte del microcontrolador con el display.



Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #46 en: 23 de Agosto de 2023, 01:34:57 »
Bueno, pues toca esperar. No te imaginas la de veces que me ha pasado a mí algo parecido.

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #47 en: 23 de Agosto de 2023, 12:04:52 »
Bueno, pues toca esperar. No te imaginas la de veces que me ha pasado a mí algo parecido.

Eso me pasa por confianzudo, tenía que a ver revisado todo lo que tengo antes de enviar a fabricar el PCB.

Lo que suele pasar es que diseñas primero el PCB y cuando vas a comprar los elementos, no hay en existencias en los tamaños/disposición deseada.

Por eso es mejor tener primero todos los elementos primero antes de crear la placa, pero en este caso teniendo con anticipación los elementos he cometido un error de novato.
 :(

Lo bueno es que el proyecto es sólo un pasatiempo, así que no hay prisas.

Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #48 en: 31 de Agosto de 2023, 14:32:17 »
Así quedó con el microcontrolador y los transistores:



Y la tarea que administra al display, funciona correctamente:



Aproveché el hardware para hacer un video tutorial del manejo del display con el compilador XC32 y Harmony 3:

« Última modificación: 31 de Agosto de 2023, 15:40:39 por DominusDRR »
Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3610
    • Impresiones en 3D
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #49 en: 04 de Septiembre de 2023, 07:42:15 »
 <3 <3 <3 <3
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.


Desconectado Wasbfire

  • PIC10
  • *
  • Mensajes: 9
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #51 en: 10 de Septiembre de 2023, 19:38:11 »
He leido tu proyecto y me parecio increible la verdad, felicidades. Pero tengo una duda, este proyecto funciona solamente para frecuencias de la red electrica o tambien sirve para niveles de frecuencia mas altos, como por ejemplo 20kHz.

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #52 en: 10 de Septiembre de 2023, 19:42:20 »
He leido tu proyecto y me parecio increible la verdad, felicidades. Pero tengo una duda, este proyecto funciona solamente para frecuencias de la red electrica o tambien sirve para niveles de frecuencia mas altos, como por ejemplo 20kHz.

En teoría si, ya que el cálculo matemático del RMS no depende de la frecuencia.

Dependería de la velocidad de muestreo del conversor ADC.  Si puede tomar muestras mayores que 20 kHz, digamos 200 kSPS o más, el cálculo sería mucho más aproximado a la realidad.
Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #53 en: 10 de Septiembre de 2023, 19:45:29 »
He leido tu proyecto y me parecio increible la verdad, felicidades. Pero tengo una duda, este proyecto funciona solamente para frecuencias de la red electrica o tambien sirve para niveles de frecuencia mas altos, como por ejemplo 20kHz.

En teoría si, ya que el cálculo matemático del RMS no depende de la frecuencia.

Dependería de la velocidad de muestreo del conversor ADC.  Si puede tomar muestras mayores que 20 kHz, digamos 200 kSPS o más, el cálculo sería mucho más aproximado a la realidad.

Me olvidaba, también dependería del ancho de banda del amplificador operacional ocupado como acondicionador de la señal. (También debería ser mucho mayor que 20 kHz)
Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #54 en: 18 de Septiembre de 2023, 13:53:23 »
Hola.

Hasta comprar los elementos faltantes (debido a que importar poco, me sale muy caro, y esperar algunas semanas para comprarlos junto con otros que la empresa necesita), voy a crear la tarea que controla al buzzer, la cual servirá para advertir de un sobre o bajo voltaje.

También he decido, con el buzzer, realizar una tonada o música, cuando el dispositivo es energizado.

Ya he trabajado antes con el módulo comparador de salida, exactamente haciendo lo que he descrito, y funciona con un temporizador de 16 o 32 bits para realizar la comparación:



En la zona gráfica del MCC, hice un nuevo grupo denominado buzzer:



Dentro del cual he colocado el módulo OCMP1, que corresponde a la salida OC1:



Las características del buzzer son las siguientes:



Internet hay varios ejemplos de como generar música con una señal PWM

La frecuencia de las notas musicales, está en el rango aproximado desde 200 Hz a 3000 Hz.

Por lo tanto, para modificar, la frecuencia del PWM, se necesita modificar el registro del PRy del temporizador asociado:




Entonces, el valor a comparar, no es importante, pero como fuente de reloj, selecciono el temporizador 3, para no interferir con aquel que se va a usar con el módulo de captura de la señal cuadrada sincronizada con la sinusoidal:



Y creo una tarea con el nombre appBuzzer que se dedicará a generar la música inicial, y tonos de advertencia:



Tengo de un proyecto, con un microcontrolador PIC32MZ, estas definiciones para cada nota musical, donde cada una de ellas tiene como comentario, la frecuencia necesaria. Por ejemplo la nota musical c_ corresponde a 261Hz, y el valor a cargar en el PRy es 191570 para generar esa frecuencia.

Obviamente, para este microcontrolador, que trabaja a otra frecuencia, debo recalcular esos valores

Código: C
  1. #define mute 0
  2. #define c_      191570 //       261 Hz se puso guión bajo _ debido a que había confilctos con definiciones de aws o con freertos
  3. #define d_      170067 //       294
  4. #define e_      151974 //       329
  5. #define f   143265 //   349
  6. #define g   127876 //   391
  7. #define gS      120481 //       415
  8. #define a       113635 //       440
  9. #define aS      112359 //       445
  10. #define b       107295 //       466
  11. #define cH      95601  //       523
  12. #define cSH 90252  //   554
  13. #define dH      85178  //   587
  14. #define dSH 80385  //   622
  15. #define eH      75872  //       659
  16. #define fH      71632  //       698
  17. #define fSH 67567  //   740
  18. #define gH      63775  //       784
  19. #define gSH     60240  //       830
  20. #define aH      56817  //       880
  21.                
  22. #define cHH     23888   //      2093
  23. #define AB      26823   //      1864
  24. #define F6      35816   //      1396
  25. #define d7      21285   //      2349
  26. #define DE      20087   //      2489
  27. #define f7      17901   //      2793
  28. #define FG      16890   //      2960
  29. #define GA      15050   //      3322
  30. #define ABx 13407       //      3729
  31. #define CD      22551   //      2217
  32. #define E7      18960   //      2637
  33. #define g7      15943   //      3136

Mas tarde continúo con la explicación para generar la melodía inicial.



Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #55 en: 18 de Septiembre de 2023, 19:21:23 »
Continúo con respecto del PWM.

Según las definiciones anteriores, la frecuencia mínima es 261 Hz y la máxima es 3136 Hz, esto implicaría un periodo máximo de la señal PWM de 3.831 ms y mínimo de 318.88 microsegundos respectivamente.

Por lo tanto, el periodo del PWM debería ser mayor a esos 3.8 ms, por ejemplo el periodo podría ser 7ms.

Jugando con los parámetros del temporizador 3, con un escalamiento de 8, es decir con 6 Mhz, y con PR3 igual a 42000, conseguiría 7ms.

(42000/6MHz = 7 ms)



Ahora bien, si deseamos un periodo de 318.88 us, PR3 = f* T = 6MHz * 318.88 us = 1913.26, el cual es un valor que el PR3 puede poseer.

La ecuación para calcular el periodo de la señal PWM es:



Donde TPB es el periodo de la frecuencia del reloj del bus de periféricos, es decir 1/48MHz.

TMR Prescaler Value, es el valor del pre escalamiento que es 8, es decir que TPB * TMR Prescaler Value = 1/6MHz.

Con esto hice una tabla en Excel para conseguir los valores de PR2 para cada frecuencia auditiva:



Y lo pego en el archivo cabecera de la tarea appbuzzer: (obviamente sin decimales)



Una canción esta definida como una serie de notas musicales, y cada nota tiene un tiempo de duración.

Por lo que creo una estructura de datos de la siguiente manera:

Código: C
  1. typedef struct
  2. {
  3.     unsigned int FrecuenciaNota;
  4.     unsigned int Tiempo;
  5. }NotasMusicales;

Donde FrecuenciaNota es el valor del PR del temporizador, y Tiempo es la duración de la nota musical, por lo tanto creo un arreglo con 12 notas musicales así:

Código: C
  1. NotasMusicales      Musica[0x0C];

Esto lo creo en el archivo en C de la tarea del buzzer.



En el estado inicial de la tarea, lo que hago, es inicializar el arreglo 'musica' con los valores de PR3 y retardos para generar la música inicial



Recuerde que 1 ms está dado por:

Código: C
  1. #define _1ms 0x5DC0

También, en el estado inicial de la tarea (que la renombré) deshabilito todo lo relacionado con la configuración del PWM, de lo contrario, es psoible que el buzzer haga sonidos antes de empezar a ejecutarse la tarea, e inicio o arranco al temporizador 3:



Necesito un puntero, para ir obteneindo cada valor del arreglo denominado Musica, el cual será parte de la esctructura de datos de la tarea:



Y lo inicializo en la el código en C de la tarea:



También, necesito una variable para generar retardos asincrónicos, y la escribo en la estructura de datos:



Para cambiar el valor del PR3, creo una función así:

Código: C
  1. void actualizarFrecuenciaPWM(unsigned int frecuencia)
  2. {
  3.     TMR3_PeriodSet(frecuencia); //es similar a PR3 = frecuencia;
  4.     OCMP1_CompareSecondaryValueSet(frecuencia >> 1); // ancho de pulso en 50%
  5. }

Donde también intento que la relación de trabajo del PWM sea del % al escribir en el registro OC1RS, la mitad del valor de PR3.

En la inicialización de la tarea, capturo un valor del temporizador central o Core Timer, y genero la primera nota con el PWM mediante la función  actualizarFrecuenciaPWM



En el estado inicial, espero el tiempo que dura cada nota mediante un retardo asincrónico así:



Cuando el retardo ha finalizado, se hace lo siguiente:

Se captura un nuevo valor de temporizador central para el próximo retardo.

Incremento en 1, el puntero del arreglo denominado Musica.

Si el puntero está aún dentro del tamaño del arreglo musica, verifico que la siguiente sea mute o silencio, si es así, apago el PWM para generar un silencio.

Si no es mute actualizo el valor del PR3 con el valor de la siguiente nota.

Si el puntero es mayor que el tamaño del arreglo, la melodía ha finalizado , apago el PWM y salto a un estado denominado reposo, donde esperará la tarea hasta cuando se desee generar una señal acústica.

Esa señal acústica, será generada en un nuevo estado, pero eso será más adelante, por ahora sólo deseo crear esta parte del código.

Mañana, voy a probar con el hardware si este código funciona.


Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #56 en: 19 de Septiembre de 2023, 02:18:44 »
Jeje, lo que hace el aburrimiento mientras te llegan los componentes.
Por cierto, ¿por qué ocultas las notas de la canción?

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #57 en: 19 de Septiembre de 2023, 10:07:41 »
Por cierto, ¿por qué ocultas las notas de la canción?

Por copyright   :)

En realidad es el principio de una canción de una película muy famosa, similar a esta otra:



 Alguna vez quise convertir cualquier música a tonos con su frecuencia y duración, pero nunca supe como hacerlo.

En internet encuentras muchas melodías de canciones famosas para ser generadas con un PWM.
Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #58 en: 19 de Septiembre de 2023, 11:20:02 »
Descargue el nuevo código al hardware y este es el resultado:


Se puede apreciar que hay un tono no deseado antes de empezar la melodía.

Estaba asumiendo que se ejecuta algo de código antes de inicializar la tarea donde deshabilito el PWM, intenté varias cosas, por ejemplo poner en 1, el valor a comparar para que el ancho de pulso inicial sea pequeño, para que no genere ese ruido, así:



También intenté con un valor igual a cero, pero el resultado era el mismo.

Busqué donde se inicializa o activa el PWM, pensado que el código generado lo activaba antes de hora, pero no es así. Donde se activa el PWM es en donde yo escribí OCMP1_Enable



Así que se me ocurrió escribir una nota de silencio, en el código inicial, esto implica que el arreglo Musica, es ahora de 13 elementos:



Al hacer esto, la melodía sonó como debe ser.


Lo que sospecho es que la(s) función(es) que inicializan la(s) tarea(s) toman algo de tiempo, es decir, la primera vez si estaba colocando el primer tono correcto, pero hasta configurar todas las tareas y procesos, toma su tiempo, generando un sonido no deseado.

Agregando un silencio inicial, se evita el problema.

Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32

Desconectado DominusDRR

  • PIC24H
  • ******
  • Mensajes: 1937
    • Sicoy
Re:Proyecto para medir el valor eficaz verdadero (True RMS)
« Respuesta #59 en: 21 de Septiembre de 2023, 13:06:09 »
Estoy pensando en el diseño para calcular el valor RMS.

La primera idea básica conceptual, es que mediante la señal cuadrada que se generaría sincronizada con la red de 60Hz, sería útil para empezar y detener la adquisición de datos o muestras del ADC.

El inicio y detención, sería por el flanco de subida o positivo de dicha señal, así:




El problema es que no se cuantos ciclos de máquina tome el cálculo del valor RMS (se podría medir), como se puede apreciar en la imagen de arriba, finalizada la adquisición de datos, el CPU se concentraría en realizar ese cálculo.

No creo que tome mucho tiempo, pero sin embargo, tendría que esperar el otro ciclo de la señal senoidal para realizar una nueva adquisición de datos, tampoco pienso que afecte la precisión del cálculo, pero no me gusta la idea que pierda tiempo realizando ese proceso.

La segunda opción es que siempre este adquiriendo los datos del ADC.

Esto implicaría usar dos buffers o arreglos para almacenar la información.

En el primer ciclo, guardaría en el primer arreglo, luego la tarea que calcula el RMS, realizaría sus cálculos con ese array, pero en ese mismo ciclo, la información del ADC, se guardaría en el segundo array.

Luego al finalizar el segundo ciclo, el RMS se calculara con el segundo arreglo, y en el primero se almacenaría la información, algo así como esta imagen:




Hasta qui parece que funcionaría la idea de que siempre se esta adquiriendo información de la señal sinusoidal, sin embargo, es posible que las operaciones de cálculo del RMS, sean instrucciones atómicas, es decir no se pueden dividir en más subfunciones, y ejecutarlas toman algo de tiempo de tal manera, que por ejemplo si se está esperando el tiempo de adquisición de datos, ese tiempo sea más grande, debido a que no termina de ejecutarse alguna parte del cálculo RMS.

El tiempo de adquisición es de 1 us, el tiempo de conversión es aproximadamente de 14 us, y entre cada muestra, debe esperarse 100 us:



Anteriormente, propuse la utilización de modo polled es decir que espero a que una bandera finalice, para conocer si la conversión ADC está lista. Pero como menciono, el CPU podría estar ejecutando un proceso de cálculo RMS, y hasta que finalice y regrese a verificar esa bandera del ADC, el tiempo será mayor, y posiblemente, genere algún error de precisión.

También, yo ocupo retardos asincrónicos, los cuales no son precisos, y se ocupan en tareas no tan críticas, por ejemplo, en los displays, cada uno muestra información a una tasa de 1000 us  (1ms), pero si por algún momento fuera 1015 us, por decir algo, el usuario no va a notar eso.

Así que me veo obligado a usar interrupciones, tanto, para la finalización del la conversión del ADC y para la generación de 100 us.

De esa manera, pienso que se mejoraría la latencia producida del proceso de cálculo RMS



Tengo una idea algo difusa sobre MPLAB Harmony, XC32 con PIC32