OP25 Setting up op25 to stream to broadcastify

[KA1RBI]

Thanks for the update, Max. Any ETA on that fix ?

I've been looking into this a bit. The way that dstar works is different from p25/ysf/dmr in that dstar uses gmsk. There is a gmsk demod block in native gnuradio, but I'm dissatisfied with its performance as it apparently doesn't handle frequency offsets at all gracefully. If there is any frequency drift (due to, say, ppm error in the rtl sdr) it will stop working due to that lack of frequency synchronization.

The OP25 demod block in any case needs to be enhanced to add gmsk as a valid filter type. I guess the sequence of steps might be roughly to add dstar initially using the gr native gmsk block and then fix the other issues. It's less than ideal...

73

Max

 

[KA1RBI]

Thanks for the update, Max. Any ETA on that fix ?

I've pushed an update to the 'max' branch of the osmocom repo that hopefully should address this. To enable dstar for a channel (multi_rx.py must be used), specify "gmsk" for filter_type and "fsk4" for demod_type...

Please let me know how it goes...

Max

 

[boatbod]

I've pushed an update to the 'max' branch of the osmocom repo that hopefully should address this. To enable dstar for a channel (multi_rx.py must be used), specify "gmsk" for filter_type and "fsk4" for demod_type...

Please let me know how it goes...

Max

I've merged Max's change to p25_demodulator.py into the boatbod fork.

 

[ve2vag]

Thanks to both of you, I'll test this and will post back results

 

[ve2vag]

I've tested D-Star decoding and it works. Wondering if there are arguments or parameters I could try to optimize the audio quality. Will have to check thru code to see if I can find something. Anyhow, the D-Star protocol audio quality is not very good to begin with, compared to DMR or Fusion.
Here is what I have for now in my json file:
{
"demod_type": "fsk4",
"destination": "udp://127.0.0.1:23458",
"excess_bw": 0.2,
"filter_type": "gmsk",
"frequency": 144950000,
"if_rate": 24000,
"name": "dstar",
"symbol_rate": 4800
},

Thanks for everything !

 

[KA1RBI]

Wondering if there are arguments or parameters I could try to optimize the audio quality.

Everything that is known about the dstar codec comes as a result of reverse engineering, as its details haven't been published, afaik. We can thank the anonymous authors of original DSD and others (**not** dsdplus) for what we do have. The question isn't so much why it sounds as bad as it may sound, but that it sounds as good as it does given the lack of documentation. ARRL must take some of the blame for this as well, for promulgating and allowing a closed standard to be used in ham radio.

If anyone has any technical documentation on "ambe version 1" (if that's even a correct designation) please forward the same to the OP25 project...

Max

p.s. I'm assuming here of course that you've tuned the station properly - you can enable the "datascope" and "symbol" plots to get a confirmation of this.............

 

[ve2vag]

Max,

I sincerely hope that you did not perceive my post as a criticism of either your work, or anything related to the OP25 project, because it wasn't meant to be this. Since english is not my native language, I may have not used proper phrasing, and I'm sorry if it was perceived as that. I'm grateful for all the work of those involved in the project.

I was aware of the closed standard situation for D-Star. And as an amateur radio licensee who possess D-Star (Icom ID-800H and IC-91AD), Fusion (Yaesu FTM-100) and DMR (Radioddity GD-77, and Motorola XPR-6350) radios, my comment about the audio quality was made by experimenting and using myself radios with these protocols, and not just by judging anything "by ear" related to the project.

And I must admit: I have played a little bit with the datascope and symbol plots, but maybe there is place for improvement in that part over here. I'l have to check that again. I'm a newbie in regards of everything RPI and Linux related, and I'm learning with experimenting, trials and (many...) errors. Will report back when time permits to fine tune on my part.

And again, thanks for all of your work and all of those involved in the project. 73s

 

[KA1RBI]

Max,

I sincerely hope that you did not perceive my post as a criticism of either your work, or anything related to the OP25 project

Not in the slightest - much appreciate all honest feedback, both good and not so good.

73

Max

 

[james18211]

Thank you for the guide you've posted here.

I've been able to get things working, but I'm running into an issue where after a (seemingly) random period of time, from a day to over a week, I'm getting continuous buffer overruns from Darkice resulting in the streams being interrupted. Restarting the streams resolves the issue, but they're down until I manually do it.

As an interim fix I have cron restarting the streams hourly, but that's obviously not a great solution.

Any suggestions would be most appreciated.

I can find next to nothing online about this issue, especially with Darkice.

Setup:

2x RTL-SDRs streaming OP25 va Darkice. Raspberry Pi 3 B+, up to date Raspbian

From syslog:
AlsaDspSource :: Buffer overrun!

 

[Spitfire8520]

Thank you for the guide you've posted here.

I've been able to get things working, but I'm running into an issue where after a (seemingly) random period of time, from a day to over a week, I'm getting continuous buffer overruns from Darkice resulting in the streams being interrupted. Restarting the streams resolves the issue, but they're down until I manually do it.

As an interim fix I have cron restarting the streams hourly, but that's obviously not a great solution.

Any suggestions would be most appreciated.

I can find next to nothing online about this issue, especially with Darkice.

Setup:

2x RTL-SDRs streaming OP25 va Darkice. Raspberry Pi 3 B+, up to date Raspbian

From syslog:
AlsaDspSource :: Buffer overrun!

I am curious about this as well as I have run into the same issue on a near identical setup (1x RTL-SDR) twice in the past 3 days. I am guessing that the latest outage it is related to Feeds down again?. It seems to hint at Darkice not handling server side outages very gracefully and gets stuck in a "Buffer overrun" loop.

 

[boatbod]

I've seen something similar with my two streams. Usually simply rebooting the host or restarting Darkice fixes the problem.

 

[hagensieker]

My feed never really goes down but I stop getting audio. I set a crontab up to reboot the Pi once a day and no problems since.

 

[boatbod]

My feed never really goes down but I stop getting audio. I set a crontab up to reboot the Pi once a day and no problems since.

The pi3 seems more prone to op25 ceasing to make audio. I've long suspected it's some sort of race condition or i/o block but never been able to pin it down. That was the main reason I personally moved away from using a pi3 to host one of my feeds. Now they both run very happily on a single Intel NUC7.

 

[squirrel]

I have used this guide to successfully setup streaming on a Raspberry pi. With information like this available it makes it way easy. I was hoping to monitor the stream locally and was wondering if there is a way to setup the loopback to darkice and also have it output the audio to the speaker jack?

 

[simpilo]

I have used this guide to successfully setup streaming on a Raspberry pi. With information like this available it makes it way easy. I was hoping to monitor the stream locally and was wondering if there is a way to setup the loopback to darkice and also have it output the audio to the speaker jack?

Use a player that can stream from your local network and enter in the host machine IP and TCP port. the port used to stream outbound to Broadcastify. I recommend VLC. It won't interrupt your connection to Broadcastify. Bitrate will be the same. Computers and the internet are very robust and smart.

 

[squirrel]

I am using the same config for darkice as on page one of this post so the port is 80. I have tried to use VLC to connect using 192.168.1.188:80 but it never connects. Any idea what I am missing?

 

[simpilo]

I am using the same config for darkice as on page one of this post so the port is 80. I have tried to use VLC to connect using 192.168.1.188:80 but it never connects. Any idea what I am missing?

Its a TCP port. http://192.168.1.188:80

That the correct way. Since its a Icecast method Broadcastify uses you really need

http://192.168.1.188:80/<your mount point shown in your Broadcastify Tech settings>

without the brackets.

Just the IP and Port isn't enough. That only works for UDP. We're not using UDP.

 

[boatbod]

I have used this guide to successfully setup streaming on a Raspberry pi. With information like this available it makes it way easy. I was hoping to monitor the stream locally and was wondering if there is a way to setup the loopback to darkice and also have it output the audio to the speaker jack?

Yes, this absolutely is possible and just requires the correct setup in asound.conf. The advantage over trying to monitor your own stream via broadcastify is far less delay (it's instantaneous).

rx.py needs to output to "mout0" device
darkice.cfg needs to receive from "loop0" device

# output device
pcm.loopout0 {
  type dmix
  ipc_key 328211
  slave.pcm "hw:Loopback,0,0"
}

# input device
pcm.loopin0 {
  type dsnoop
  ipc_key 686592
  slave.pcm "hw:Loopback,1,0"
}

# duplex plug device
pcm.loop0 {
  type plug
  slave {
    pcm {
      type asym
      playback.pcm "loopout0"
      capture.pcm "loopin0"
    }
  }
}

pcm.mout0 {
  type plug
  slave.pcm mdev0
  route_policy "duplicate"
}

pcm.mdev0 {
        type multi

        slaves.a.pcm "hw:Loopback,0,0"
        slaves.a.channels 2
        slaves.b.pcm "hw:0,0"
        slaves.b.channels 2

        bindings.0.slave a
        bindings.0.channel 0
        bindings.1.slave a
        bindings.1.channel 1
        bindings.2.slave b
        bindings.2.channel 0
        bindings.3.slave b
        bindings.3.channel 1
}

 

[squirrel]

Spectacular! That did the trick.

Thanks!

 

[kb9mwr]

Everything that is known about the dstar codec comes as a result of reverse engineering, as its details haven't been published, afaik. We can thank the anonymous authors of original DSD and others (**not** dsdplus) for what we do have. <snip>

Originally dsd only supported d-star using a dongle as the author had no published details to work off of. I think the original dsd author was gone (thanks to dsd plus) by the time dstar support was added (3 yrs later) by others in the community see:

https://forums.radioreference.com/v...tware/215282-decoding-d-star-any-success.html

There was also this tip from user "groovy"

If anybody wants to continue the research / work, I suggest you look at the osmocom GMR code that Sylvain Munaut worked on. Those phones use a similar codec - I believe with longer frames for the satellite latency. Initially he used the mbelib code, enhanced it for things like tone support, but he later rewrote the synthesis code completely. See OsmocomGMR for his presentations and source code.

Unless other developers take this on, DVSI releases specs, or you switch to a hardware-based decoder like the thumbDV, I don't see the dstar voice quality improving in the short term.

From:
https://forums.radioreference.com/v...dio-quality-d-star-dsd1-70-a.html#post2412739

Anyway, now I too am able to decode d-star with op25, where as I was having problems before. Thanks Max!

I do believe if we could snag the brains and talent those folks in the link, it could be improved to sound better ?

PS. I did manage to transmit P25 using op25 connected to a GM300 radio. That was cool too.