OFF topic... (or not)
Re: OFF topic... (or not)
Yes. I know someone in the FreeDMR team
Its definitely something they would consider.
Its definitely something they would consider.
Re: OFF topic... (or not)
The OpenRTX team works on the MD-380 , MD-UV380 modifications
Currently, there is a version of MMDVM / MMDVMHost that supports the M17 protocol
https://github.com/g4klx/MMDVMHost/tree/M17_AX25_FM
There are transition tools from DMR2M17 available
https://github.com/nostar/MMDVM_CM
and we are currently using these solutions but this causes not really using M17 to RF and this is rather the goal so we need HT radios etc. to use M17 natively.
In a similar way, it may not be used by radio NXDN, P25, etc., because the same tools available for switching the DMR network to NXDN and P25, but it is good but it would be good to use such modes on RF
73 Waldek
Currently, there is a version of MMDVM / MMDVMHost that supports the M17 protocol
https://github.com/g4klx/MMDVMHost/tree/M17_AX25_FM
There are transition tools from DMR2M17 available
https://github.com/nostar/MMDVM_CM
and we are currently using these solutions but this causes not really using M17 to RF and this is rather the goal so we need HT radios etc. to use M17 natively.
In a similar way, it may not be used by radio NXDN, P25, etc., because the same tools available for switching the DMR network to NXDN and P25, but it is good but it would be good to use such modes on RF
73 Waldek
Re: OFF topic... (or not)
OK.SP2ONG wrote: ↑Sat Apr 24, 2021 10:30 amThe OpenRTX team works on the MD-380 , MD-UV380 modifications
Currently, there is a version of MMDVM / MMDVMHost that supports the M17 protocol
https://github.com/g4klx/MMDVMHost/tree/M17_AX25_FM
There are transition tools from DMR2M17 available
https://github.com/nostar/MMDVM_CM
and we are currently using these solutions but this causes not really using M17 to RF and this is rather the goal so we need HT radios etc. to use M17 natively.
In a similar way, it may not be used by radio NXDN, P25, etc., because the same tools available for switching the DMR network to NXDN and P25, but it is good but it would be good to use such modes on RF
73 Waldek
I was told the MD380 needed hardware modification
They must have found a solution to modifying the hardware
If OpenRTX got that working on the MD380 they will know how to do it on the other radios
No need for anyone else to take time to do this. Its just duplication of effort.
Why dont they support the modes like YSF and P25 etc which also use AMBE ?
AM would also be fun. I'd like that... Retro modes
Actually AM Tx is already possible. But I don't think AM reception is possible. But perhaps it may be possible to receive AM
Re: OFF topic... (or not)
Yes, but maybe it would be possible to find a solution without harwdare modification, because with the modification it will still be a barrier for many people. Solution without modification + appropriate firmware there is a chance that the M17 will have a chance to find its place among DV hamradio communication because otherwise it will end up only in a small group but maybe I'm wrong .
Re: OFF topic... (or not)
Roger,
If there is not enough space for CODEC2 in OpenGD77, then it can do LITE OpenGD77 versions where, for example, there will be only one ENGLISH language, or would it be possible to recover the memory on CODEC2? or give up some of them to have the OpenGD77 DMR AMBE / Codec2 firmware.
Everyone can run their local FreeDMR server and it's a difficult task see the description available:
https://github.com/hacknix/FreeDMR/wiki
FreeDMR we can run on RPI v4 or VPS computer
On such a server you can try DMR Codec2 and give it access to others. You can also connect this server later via OpenBridge protocol to another FreeDMR server.
I am not an expert on the DMR protocol, but if only the voice data will be instead of AMBE in CODEC2, then by appointing on FreeDRM servers that Talk Group 88 is an International group for calls on DMR Codec2 and Talk Group 888 is a local group for calls on DMR Cocdec2, you can use the current one FreeDMR servers are DMR Codec2 connectivity.
What's more interesting, when using DMR Codec2, the transition to the M17 network will be the same as from DMR to NXDN or YSF narrow, i.e. you will not need to transcode voice, only transcode METData
It would be an interesting experience if we could have OpenGD77 DMR Ambe / Codec2.
73 Waldek
If there is not enough space for CODEC2 in OpenGD77, then it can do LITE OpenGD77 versions where, for example, there will be only one ENGLISH language, or would it be possible to recover the memory on CODEC2? or give up some of them to have the OpenGD77 DMR AMBE / Codec2 firmware.
Everyone can run their local FreeDMR server and it's a difficult task see the description available:
https://github.com/hacknix/FreeDMR/wiki
FreeDMR we can run on RPI v4 or VPS computer
On such a server you can try DMR Codec2 and give it access to others. You can also connect this server later via OpenBridge protocol to another FreeDMR server.
I am not an expert on the DMR protocol, but if only the voice data will be instead of AMBE in CODEC2, then by appointing on FreeDRM servers that Talk Group 88 is an International group for calls on DMR Codec2 and Talk Group 888 is a local group for calls on DMR Cocdec2, you can use the current one FreeDMR servers are DMR Codec2 connectivity.
What's more interesting, when using DMR Codec2, the transition to the M17 network will be the same as from DMR to NXDN or YSF narrow, i.e. you will not need to transcode voice, only transcode METData
It would be an interesting experience if we could have OpenGD77 DMR Ambe / Codec2.
73 Waldek
Re: OFF topic... (or not)
Thats external flash memory, not CPU program memory
All these radios have 512k MCU ROM
Lower 16k is the bootloader
Top 4k is some encryption keys, and if you remove it the bootloaer won't let the radio boot
Official binary sections included for ambe are 172k and 15k = 187k
So space for the firmware is only 305k
Unfortunately because the MCU rom memory map has to be fragmented, by the official firmware blocks, the compiler does not correctly report the remaining space
If you look at the build output you will see this
Code: Select all
PROGRAM_FLASH: 476 KB 494 KB 96.36%
However I don't think it is accurately reporting the free program space memory, as this value does not decrease very much when new code is added.
I think possibly there is 50 - 100k available, but I don't have a way to determine the amount of program memory which is available.