P252DMR and friends as possible future Pistar features

Suggest new features here
AD8DP
Posts: 19
Joined: Mon Sep 09, 2019 4:58 pm

P252DMR and friends as possible future Pistar features

Post by AD8DP » Fri May 15, 2020 10:39 pm

I wrote a new cross mode utility for the MMDVM_CM tools called P252DMR which does software transcoding between DMR(AMBE+2 2450x1150) and P25 phase 1(IMBE 4400x2800). For P25 It uses the open source imbe_vocoder developed by Pavel Yazev and can be found in the op25 repository for GNU Radio, among other places. For DMR it uses encoding functions that I wrote around the MD380 firmware image, based on the md380-emu example from the md380tools github repo. Because of this, it needs to be run on an ARM platform, which includes of course, the RPi. I am planning on pushing this and its DMR2P25 compliment to my fork of the MMDVM_CM repo, but after the current pull request for the DMR2YSF/YSF2DMR is all synced up. Meanwhile, I am hoping to hear from the (MMDVM_CM and Pistar) Andys in particular regarding their feelings about supporting these utilities in Pistar that utilize the open source imbe vocoder and md380 firmware based AMBE+2 vocoder.

Next on my list is to create a set of DSTAR2xxx uitities for MMDVM_CM, where xxx includes all the other modes (DMR/YSF/NXDN/P25) that will require only 1 USB AMBE3000 device connected to a Pistar RPi for the DSTAR vocoding. All the other modes will use the md380 vocoder and p25 the imbe vocoder. This will be a much cheaper alternative to the hi-dollar OpenSpot 3, especially for many folks that already own one of these USB AMBE devices. The OpenSpot 3 also does not do any P252xxx transcoding, since the AMBE3000 based hardware does not support the IMBE codec used by P25.

I am currently running P252DMR at "The BROniverse" which is a Detroit area multi-mode reflector network:
https://wa8bro.com/

DSTAR REF089C, REF/DCS/XRF625A, DMR TGIF TG31264, P25 TG31264, NXDN TG31264, and Peanut XRF625P can all be used to access this network. I am very pleased with the audio quality between all of these modes, especially the software transcoded P25 portal.

-Doug
Last edited by AD8DP on Sat May 16, 2020 5:03 pm, edited 1 time in total.

User avatar
MW0MWZ
Site Admin
Posts: 1074
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: P252DMR and friends as possible future Pistar features

Post by MW0MWZ » Sat May 16, 2020 9:35 am

Doug,

Of course I am very much interested in your work, the only potential fly in the ointment is that md380 based vocoder and the legalities around using it, it is not open source (that I know of), it *is* in the public domain, but that comes from reverse engineering and decrypting the closed source firmware bundles for the MD 380 radio.

So long as there is no legal reason why it cannot be included, I am all for it!
Andy

73 de MW0MWZ
http://pistar.uk

User avatar
MW0MWZ
Site Admin
Posts: 1074
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: P252DMR and friends as possible future Pistar features

Post by MW0MWZ » Sat May 16, 2020 9:38 am

Doug just thinking around this - would it be possible to make all of the code - with the md380 a user add-able piece - so everything is in place apart from that, and setting up the compiler/binaries in such a way that its not pulled into the finally binary, such that I can just have a button to pull it in if the end user decides that they accept the legal risk ?

Just thinking of ways to help you move forwards with this for all of us, and still take the legal high-ground :)
Andy

73 de MW0MWZ
http://pistar.uk

AD8DP
Posts: 19
Joined: Mon Sep 09, 2019 4:58 pm

Re: P252DMR and friends as possible future Pistar features

Post by AD8DP » Sat May 16, 2020 5:00 pm

Hi Andy,

I've been thinking about the same thing. Everything gets linked into a single, static executable 'P252DMR'. It would be no problem for me to host the executable (along with the others I mentioned as they become a reality) on github or on my own personal webserver, if necessary. Then you could create an option to pull it/them in with all of the required legal disclaimers, etc. You could of course build it yourself and post it somewhere as well, once it is on github.

Will it cause problems for the YSF2DMR/DMR2YSF pull request if I push this stuff up to my fork of MMDVM_CM now?

-Doug

User avatar
MW0MWZ
Site Admin
Posts: 1074
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: P252DMR and friends as possible future Pistar features

Post by MW0MWZ » Sun May 17, 2020 12:48 am

AD8DP wrote:
Sat May 16, 2020 5:00 pm
Hi Andy,

I've been thinking about the same thing. Everything gets linked into a single, static executable 'P252DMR'. It would be no problem for me to host the executable (along with the others I mentioned as they become a reality) on github or on my own personal webserver, if necessary. Then you could create an option to pull it/them in with all of the required legal disclaimers, etc. You could of course build it yourself and post it somewhere as well, once it is on github.

Will it cause problems for the YSF2DMR/DMR2YSF pull request if I push this stuff up to my fork of MMDVM_CM now?

-Doug
Doug, let me take these in reverse order...

I have not started on the config changes required for the DMR2YSF and YSF2{everything else} yet, so submit away...
Andy (CA6JAU) is going to have the same issue pulling in your changes if they include the md380 blob - that code is a potential issue for anyone - even GitHub.

There must be some way to build the project without having that blob in the middle (linking rather than embedding maybe ?) in short I am looking for a way to be able to provide pre-built binaries easily, while not hosting the blob myself (to avoid any potential legal issues).

Sure the chances are probably slim, but I'd rather 0 than slim.
Andy

73 de MW0MWZ
http://pistar.uk

AD8DP
Posts: 19
Joined: Mon Sep 09, 2019 4:58 pm

Re: P252DMR and friends as possible future Pistar features

Post by AD8DP » Mon May 18, 2020 3:27 am

I was planning on creating 'md380_vocoder' as a stand-alone C library for use with other projects like my DudeStar/DroidStar projects, the AMBE server in xlxd (ambed), etc. I'll work on that and see what I come up with.

User avatar
MW0MWZ
Site Admin
Posts: 1074
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: P252DMR and friends as possible future Pistar features

Post by MW0MWZ » Wed Jun 03, 2020 10:04 am

AD8DP wrote:
Mon May 18, 2020 3:27 am
I was planning on creating 'md380_vocoder' as a stand-alone C library for use with other projects like my DudeStar/DroidStar projects, the AMBE server in xlxd (ambed), etc. I'll work on that and see what I come up with.
Like I said - I love the idea, just for the sake of the legalities, it needs to be a separate thing - so that I can create images / updates etc etc that dont include it, but leave in a single click option to pull it in after the image is deployed.

So long as you can make that work - we can add it in easily enough.
Andy

73 de MW0MWZ
http://pistar.uk

AD8DP
Posts: 19
Joined: Mon Sep 09, 2019 4:58 pm

Re: P252DMR and friends as possible future Pistar features

Post by AD8DP » Sat Jun 06, 2020 5:51 am

I pushed P252DMR into my MMDVM_CM fork tonight, and added 2 new repos 'imbe_vocoder" and .md380_vocoder'. Here is how it works (this all being done on a Pi):

https://github.com/nostar/imbe_vocoder
make and make install will install this library 'libimbe_vocoder.a' and header file to /usr/local

https://github.com/nostar/md380_vocoder
The make command will download the firmware and ram images from a non github server and build the library. The library 'libmd380_vocoder.a' and header will be installed to /usr/local

https://github.com/nostar/MMDVM_CM
The P252DMR utility is not added to the top level makefile, so regular building of the other cross mode tools is not affected. This way your method of building pistar images should not be disturbed. Run make and make install from inside the P252DMR directory to create the executable.

The question I have is how to you envision your optional button to work? Do you want pistar to clone all of the software and build locally, or do you want to have a binary already built and hosted off site (for example on my server where I host the firmware) that can be downloaded to the pistar?

-Doug

W1MIT
Posts: 5
Joined: Thu Jun 07, 2018 1:50 pm

Re: P252DMR and friends as possible future Pistar features

Post by W1MIT » Wed Jun 10, 2020 4:25 am

Though I'm not a lawyer, I think Andy has a good point about the "legalities around using" the MD380 encoder. As an alternative to this, please consider using the AMBE decode and encode functions from the "Max" branch of OP25:

http://git.osmocom.org/op25/tree/op25/g ... /lib?h=max

With a little tweaking, these functions work fairly well on DMR. I use them every day.

73,
Dennis W1MIT

AD8DP
Posts: 19
Joined: Mon Sep 09, 2019 4:58 pm

Re: P252DMR and friends as possible future Pistar features

Post by AD8DP » Wed Jun 10, 2020 5:59 am

My dudestar software uses the open source AMBE vocoder from op25 as an option for software TX on all modes, which works marginal at best with only the best input audio conditions. Most of the time the audio sounds like Kermit the Frog. It is no where near acceptable for use in a cross mode transcoder. If you disagree you are of course more than welcome to implement it in your own fork of P252DMR and prove me wrong.

Leaving it up to the end user to decide is a fine idea and I would have expected nothing less.

Post Reply