BrandMeister EA ®📟🎙

https://github.com/LadyHwesta/ham-net-tracker

Hola a todos, Me complace anunciar que, gracias a Jonathan, toda la funcionalidad de trunking DMR en la que he estado trabajando durante los últimos 3 años ya se ha incorporado por completo a MMDVM-Host, MMDVM, MMDVM-IQ y DMRGateway, y está disponible para su uso. Ahora puede experimentar con la tecnología DMR trunking utilizando repetidores MMDVM y equipos combinadores de RF convencionales, o, de forma más sencilla y económica, utilizando el nuevo módem MMDVM-Multi para transmitir y recibir múltiples canales DMR, incluido el canal de control para la estación trunking, con una sola radio I/Q de la lista de dispositivos SDR compatibles con MMDVM-Multi. La nueva funcionalidad requiere el uso de un programa Linux con una interfaz gráfica de usuario, también basado en el código DMR de Jonathan, llamado DMRTC (controlador de trunking DMR), que se puede encontrar en un repositorio de Github en: https://github.com/qradiolink/dmrtc/ o en el espejo (principal) de Codeberg: https://codeberg.org/qradiolink/dmrtc Hasta el momento, el programa se ha probado principalmente con radios Hytera que tienen habilitada la funcionalidad DMR de nivel 3. He creado una página de documentación que describe la instalación y configuración de una estación base troncalizada DMR basada en MMDVM-Multi. Puede encontrarla en esta dirección: https://qradiolink.org/docs/MMDVM/dmr-trunking.html También se ha desarrollado un nuevo protocolo de red para admitir la troncalización DMR, en colaboración con Artem DL5ABM del equipo Brandmeister. Este protocolo, denominado "Homebrew DMR Trunking Protocol", solo está implementado por la red Brandmeister, mediante el conector "DMRTC link". El protocolo admite la indicación automática de presencia de sitio, el aprovisionamiento automático de grupos de conversación desde la red central y otras funciones, aunque es posible que no todas estén implementadas todavía. Si desea implementarlo en su red o contribuir con modificaciones, puede descargar una descripción en esta dirección: https://qradiolink.org/Homebrew_DMR_trunking_protocol_v0.6.pdf Este proyecto aún está en desarrollo, con muchas funciones por añadir y errores que corregir, por supuesto. Si detecta algún error en la documentación, por favor, avíseme. Atentamente, Adrian YO8RZZ

Hola a todos Me complace anunciar que MMDVM-Multi ya está disponible en mi GitHub. Antes de continuar, quiero aclarar que este programa es principalmente obra de Adrian YO8RZZ; yo solo le añadí algunas partes para adaptarlo mejor al estilo MMDVM. La idea del MMDVM-Multi es muy sencilla. Utilizando un único dispositivo basado en I/Q, como un SXceiver o un LimeSDR, puedes conectarte a varias instancias de MMDVM-IQ para crear un punto de acceso multicanal que admita hasta siete canales MMDVM-IQ. Así, podrías asignar uno a D-Star, otro a DMR, otro a System Fusion, etc. O bien, un canal para D-Star y DMR, otro para System Fusion y otro para P25/NXDN. La combinación la decides tú. Solo es cuestión de un pequeño paso para llevar el concepto más allá. El proyecto DVM cuenta con un sistema de trunking P25 fase 1 en funcionamiento que requiere al menos dos tarjetas de punto de acceso MMDVM full-duplex para operar, y sería ideal poder integrarlas en un sistema MMDVM-Multi para que funcionen con un solo componente de hardware de RF, que podría funcionar junto con una o dos instancias de MMDVM-IQ. También disponen de un sistema de trunking DMR en funcionamiento, independiente de la implementación de trunking DMR en el MMDVM. Asimismo, están trabajando en trunking NXDN y P25 fase 2. Lo único que se necesita es que alguien desarrolle un conector para integrar el proyecto DVM en el MMDVM-Multi. ¡Pero aún hay más! El SXceiver se creó originalmente para usarse con TETRA, por lo que tiene sentido integrarlo también en el MMDVM-Multi, de modo que se podría tener un punto de acceso funcionando con varios modos DV (y FM) diferentes, todos en canales distintos pero adyacentes. La única desventaja es que la potencia de salida se reduce según la cantidad de canales diferentes que se utilicen. Amplificar un sistema MMDVM-Multi requerirá amplificadores altamente lineales, probablemente de clase A, para evitar la intermodulación entre los canales de transmisión. Probablemente sea factible amplificar hasta el nivel de decenas de milivatios utilizando componentes comerciales. También quisiera agradecer la contribución de Shawn Chain, en particular por la actualización de MMDVM-IQ. Jonathan G4KLX https://codeberg.org/qradiolink/SVXBridge

La diferencia de calidad de audio entre una app y un equipo de radio de CO1CB

https://drc.radioid.net Una nueva solución para controlar tu radio Comjot. Incluye soporte PoC. Aún en fase beta, pero muy funcional. Este software fue diseñado para el dispositivo CJ1.

https://z3dmr.com/

Ahora que tenemos MMDVM-IQ funcionando y con novedades aún más interesantes por venir, necesitamos hablar sobre los puntos de acceso basados ​​en SX1255. En el mundo de MMDVM HotSpot, contamos con varios diseños diferentes y moderadamente incompatibles, los cuales deben tenerse en cuenta en el código fuente de MMDVM_HS. Incluso en el ámbito de los módems MMDVM, teníamos diseños de hardware bastante distintos que debían ser compatibles. ¿A quién se le ocurrió que una placa STM32F1 funcionando a 72 MHz era una buena opción de diseño? Aun así, la admitimos. Actualmente, existen algunas implementaciones diferentes del SX1255 que están en desarrollo o ya están disponibles, por lo que brindar soporte para las implementaciones ligeramente diferentes (a través de SoapySDR) no representa un gran problema. Cada una requiere un cambio relativamente pequeño en MMDVM-IQ, y lo mismo ocurrirá con otros sistemas basados ​​en I/Q como TETRA. Me gustaría pedirles a quienes diseñen futuros sistemas basados ​​en SX1255 que no reinventen la rueda y creen otra implementación ligeramente incompatible, porque puedo garantizar que en algún momento en el futuro la gente del mundo de MMDVM dirá que no, y se quedarán con un hardware sin soporte para MMDVM convencional. Este mensaje NO se aplica a SXceiver, MuCell, Z32IT ni a los próximos diseños que aparecerán. Ustedes tienen la ventaja de ser los primeros y pueden innovar a su antojo. Sería ideal contar con pines GPIO de Raspberry Pi estandarizados para las placas SX1255, de modo que quienes desarrollen futuras placas SX1255 puedan utilizarlos y garantizar la compatibilidad con SoapySDR mediante un controlador genérico que, estoy seguro, alguien creará. En el futuro, si alguien creara una placa SX1255 con alguna característica nueva e impresionante, me interesaría brindarle soporte. No quiero frenar la experimentación, pero tampoco quiero dar soporte a muchas placas SX1255 muy similares que solo se diferencien en el uso de sus pines GPIO. Si alguien crea un nuevo diseño basado en I/Q que no utilice el SX1255, entonces lo anterior NO aplica. Me interesaría mucho si lo hicieras y probablemente estaría muy dispuesto a brindarle soporte. No quiero ser negativo, pero quiero frenar la proliferación de placas SX1255 genéricas con hardware incompatible. Jonathan G4KLX