Date   
Re: HELP....can't get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater!

Bryan Hoyer <bhhoyer@...>
 

Well that depends on how much of an idiot you are.

Sorry, couldn’t resist.

There are clear beginner instructions on the pi website on how to copy an image to an sdcard. We will also offer pre-programmed sdcards.

Bryan K7UDR

On Mar 13, 2016, at 12:07 PM, grahamc64@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Hi Bryan,


Thanks for the ray of light at the end of the tunnel.

Will the instructions released with the image for the UDRC be "idiot proof" for me?

Regards

Graham
G7LMF


Re: HELP....can't get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater! [1 Attachment]

grahamc64@...
 

Hi Bryan,

Thanks for the ray of light at the end of the tunnel.

Will the instructions released with the image for the UDRC be "idiot proof" for me?

Regards

Graham
G7LMF

Re: HELP....can't get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater! [1 Attachment]

Bryan Hoyer <bhhoyer@...>
 

Hi Graham,

hang in there for a few weeks.

The soon to be released UDRC includes a pre-built image with support for the PiDV.

Bryan K7UDR


On Mar 13, 2016, at 10:18 AM, grahamc64@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:


Hi All,


I am now at the end of my tether with trying to get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater!


I am a total novice as far as linux is concerned so all I really want is a total idiots guide (me being the total idiot) with step by step instructions of what I meed to install, where and how I download the packages, how and into what directories I need to install them and how to get it all working at the end!


I have tried following the really good companion guide from AmateurLogic but as it states it "isn't intended to be a complete UNIX manual" which is, what I guess, I really need.


I have tried following other suggestions but I am really not getting anywhere.


PLEASE, PLEASE, PLEASE does anyone have a complete guide for someone like me.


Hopefully awaiting a reply from my saviour


Graham




G7LMF




HELP....can't get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater!

grahamc64@...
 

Hi All,


I am now at the end of my tether with trying to get my DV3000 connected to my RPi board to run ircddbgateway and dummyrepeater!


I am a total novice as far as linux is concerned so all I really want is a total idiots guide (me being the total idiot) with step by step instructions of what I meed to install, where and how I download the packages, how and into what directories I need to install them and how to get it all working at the end!


I have tried following the really good companion guide from AmateurLogic but as it states it "isn't intended to be a complete UNIX manual" which is, what I guess, I really need.


I have tried following other suggestions but I am really not getting anywhere.


PLEASE, PLEASE, PLEASE does anyone have a complete guide for someone like me.


Hopefully awaiting a reply from my saviour


Graham

G7LMF


Re: dmr for nwdigital

beaupeppybrandypip@...
 


Hello Barry

I've also got DMR running with the ThumbDV now on the software I'm doing (slowly but surely).

DMR uses rate 33 mode on the AMBE-3000 chip. Exactly the same audio quality as Fusion DN (half rate voice mode), same AMBE rate mode/format.

Not helpful for you at the moment I know, but at least you know we are out here slowly working on creating software for the ThumbDV for encode and decode of any and all possible AMBE digital voice protocols (I've so far got DStar, Fusion and DMR running).

Cath

Re: Raspberry Pi 3?

Jeremy McDermond <mcdermj@...>
 

On Mar 10, 2016, at 4:39 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

The problem is that on the Pi3 the GPU clock frequency can vary, unless it
is locked to 250 MHz, then reducing performance.
Alright. Thanks for being patient and helping me understand the problem, John. I figured there was something I was missing.

The unfortunate thing is that it appears as though they’re doing the frequency scaling in the firmware, so the Linux kernel is not aware of it and won’t be able to correct for the clock changes in the UART driver. It’s also too bad that Broadcom threw this in the “aux” stuff. Apparently they added that module as an afterthought at the end (it also has the other two SPI busses in it) and the hardware isn’t really well thought out. It would certainly be more useful if it were on a clock mux like the rest of the clocks.

Apparently there is another tradeoff, though. If you set force_turbo=1, you’ll cause the GPU core to max clock rate and it will only reduce it in the event of low voltage or thermal issues. This should allow you to have full speed on the GPU along with a functional Mini-UART. The issue here is going to be power consumption and heat. I’ll be checking some of this out when I get hardware to do so.

I think the “official party line” from NWDR is that you should use the device tree overlay to disable bluetooth and restore the AMBA UART to the PiDv.

There is a load of stuff about this on the PI forums.
That’s part of why I didn’t see it. I’m not a big fan of web forums because they’re really a “pull” content system where I have to check different forums by hand, rather than an e-mail list that’s “push” in that it shows up in my central e-mail box. They do have an RSS/Atom feed, though, so I put it in my RSS reader so that I’ll hopefully stay better up to date with this stuff. I’m on one of the RPi kernel wonk’s list but I didn’t see anything about that there yet. I’ll be watching both for possible solutions and will let people know if there ends up being one.

73, John
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

Re: Raspberry Pi 3?

"John Wiseman" <john.wiseman@...>
 

The problem is that on the Pi3 the GPU clock frequency can vary, unless it
is locked to 250 MHz, then reducing performance.

There is a load of stuff about this on the PI forums.

73, John


________________________________________
From: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...]
Sent: 10 March 2016 12:23
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?

 

On Mar 10, 2016, at 1:04 AM, 'John Wiseman' john.wiseman@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Jeremy,

I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower.
I’m not sure where you’re getting this from. The Mini-UART is clocked off of
the “core” clock. The GPU is default off of this PLL. The firmware sets this
speed to 250MHz on the RPi 2, and, presumably, 450MHz on the RPi 3. There’s
a divider on the Mini-UART to produce whatever speed you want.

I fully understand that the AMBA UART is being used for bluetooth and the
Mini-UART is being used for the serial pins on the header now. My point is
that you can simulate this change by merely using the device overlay on a
RPi 2. It’s the same peripheral.


I only peripherally understand what you’re trying to say about the clocks.
The RPi 1/2 define the “core” PLL as fixed to 250MHz. It won’t change during
operation AFAIK. So that’s not a concern.

I think what you’re trying to point out is that 250MHz is around 40% slower
than 450MHz. That’s fine but the of_serial driver pays attention to the
device tree to figure out what speed its clock is at and sets up its
dividers accordingly. Check out in bcm2708_common.dtsi around line 205 where
it sets its clock. This refers to the clock definition around line 359. This
is where the UART device gets its frequency to figure out what its divisor
has to be. There’s a “fixed factor” clock in there that multiplies clk_core
by two because the ns16550’s divisor is multiplied by 16, where the
Mini-UART is divided by 8 (see
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Periphera
ls.pdf on Page 11 and some discussion of this fact at
http://comments.gmane.org/gmane.linux.drivers.devicetree/134707). This is a
correction for that fact. If one were to change the clock-frequency setting
of clk_core, the UART will do the right thing. This doesn’t even require a
kernel recompile.

You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.
Or by accurately telling the device what frequency its clock is at. If worst
comes to worst, it’s should be a one-liner device tree overlay. The
of_serial driver supports a clock-frequency setting that will force it to
use whatever we tell it.

But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.
I’ll know for sure tomorrow, but I’m pretty sure you can have your cake and
eat it too.


73,
John

Jeremy McDermond (NH6Z)
nh6z@...

Re: Raspberry Pi 3?

Jeremy McDermond <mcdermj@...>
 

On Mar 10, 2016, at 1:04 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Jeremy,

I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower.
I’m not sure where you’re getting this from. The Mini-UART is clocked off of the “core” clock. The GPU is default off of this PLL. The firmware sets this speed to 250MHz on the RPi 2, and, presumably, 450MHz on the RPi 3. There’s a divider on the Mini-UART to produce whatever speed you want.

I fully understand that the AMBA UART is being used for bluetooth and the Mini-UART is being used for the serial pins on the header now. My point is that you can simulate this change by merely using the device overlay on a RPi 2. It’s the same peripheral.

I only peripherally understand what you’re trying to say about the clocks. The RPi 1/2 define the “core” PLL as fixed to 250MHz. It won’t change during operation AFAIK. So that’s not a concern.

I think what you’re trying to point out is that 250MHz is around 40% slower than 450MHz. That’s fine but the of_serial driver pays attention to the device tree to figure out what speed its clock is at and sets up its dividers accordingly. Check out in bcm2708_common.dtsi around line 205 where it sets its clock. This refers to the clock definition around line 359. This is where the UART device gets its frequency to figure out what its divisor has to be. There’s a “fixed factor” clock in there that multiplies clk_core by two because the ns16550’s divisor is multiplied by 16, where the Mini-UART is divided by 8 (see https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf on Page 11 and some discussion of this fact at http://comments.gmane.org/gmane.linux.drivers.devicetree/134707). This is a correction for that fact. If one were to change the clock-frequency setting of clk_core, the UART will do the right thing. This doesn’t even require a kernel recompile.

You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.
Or by accurately telling the device what frequency its clock is at. If worst comes to worst, it’s should be a one-liner device tree overlay. The of_serial driver supports a clock-frequency setting that will force it to use whatever we tell it.

But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.
I’ll know for sure tomorrow, but I’m pretty sure you can have your cake and eat it too.


73,
John

Jeremy McDermond (NH6Z)
nh6z@...

Re: Raspberry Pi 3?

"John Wiseman" <john.wiseman@...>
 

Jeremy,


I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower. You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.


But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.


73,
John


________________________________________
From: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...]
Sent: 09 March 2016 22:01
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?


 


On Mar 6, 2016, at 10:32 AM, 'John Wiseman' john.wiseman@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:



There have been some significant changes to the serial port (ttyAMA0 is
now used for Bluetooth, and the new ttyS0’s speed depends on the GPU clock),
so probably not without some work.


I just got a chance to check this out today after clearing some other stuff
from my plate. I don’t yet have an RPi 3 (They should arrive on Friday and
I’ll give another report based on that), but you can access the Mini-UART on
the RPi 2 by using a device tree overlay. Add:


dtoverlay=uart1


to your /boot/config.txt and you’ll end up with a /dev/ttyS0 that are on the
same pins as /dev/ttyAMA0. Pins BCM14 and BCM15 have both UARTs available on
them.


I did this and hooked up a PiDV to the RPI 2 and ran AMBEserver -i
/dev/ttyS0. I then used Buster to listen to a reflector. No audio dropouts
and everything seems to work fine.


The issues I’ve been seeing around using the Mini-UART are all surrounding
using it as a console, not as a peripheral after boot-time. There are issues
with the clocks being gated correctly and such. The firmware does some
initial setup, and if you’re not careful you can gate the wrong clocks and
really mess up the system. We’re watching the clock code rather closely
because we are using one of the general purpose clocks on the RPi in the
soon-to-be-released UDRC.


But the upshot of this all is that the PiDV should work okay on the RPi 3. I
will post a definitive answer when I get a RPi 3 for testing.


73,

John G8BPQ

--

Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...m

Re: Raspberry Pi 3?

kellykeeton@...
 

show how much I looked into this.. in that case things look much better, but I didn't actually use the chip dummy repeater loads now and no errors with the test script. 

Re: Raspberry Pi 3?

"John D. Hays" <john@...>
 

Need to find the right serial device for those pins on the pi 3

On Wed, Mar 9, 2016 at 3:56 PM, kellykeeton@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

my testing is not definitive I quickly tried to put it back on the GPIO


... one yes it needs more power 2.5a to boot and I gave it 3a with the DV3000 GPIO

python AMBEtest3.py

d 8 N 1 False False False 0 a9 Reset 6100010033

hangs there... shows no writing etc...no product ID


...

when trying to load dummyrepeater "AMBEserver -i /dev/AMA0" crashes with unable to write to serial


Posted by: kellykeeton@...




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  

Re: Raspberry Pi 3?

mcdermj@...
 

The device name has changed.  You'll need to change it in both of them:

python AMBEtest3.py -s /dev/ttyS0

or

AMBEserver -i /dev/ttyS0

--
Jeremy McDermond (NH6Z)
nh6z@...

Re: Raspberry Pi 3?

kellykeeton@...
 

Jeremy if you want to play with a rpi3 hit me up offline and I can enable your RDP/SSH into mine to play around with. has a GPIO DV3000 on it right now.

Re: Raspberry Pi 3?

kellykeeton@...
 

my testing is not definitive I quickly tried to put it back on the GPIO

... one yes it needs more power 2.5a to boot and I gave it 3a with the DV3000 GPIO

python AMBEtest3.py

d 8 N 1 False False False 0 a9 Reset 6100010033

hangs there... shows no writing etc...no product ID


...

when trying to load dummyrepeater "AMBEserver -i /dev/AMA0" crashes with unable to write to serial

Re: Raspberry Pi 3?

Jeremy McDermond <mcdermj@...>
 

On Mar 6, 2016, at 10:32 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:


There have been some significant changes to the serial port (ttyAMA0 is now used for Bluetooth, and the new ttyS0’s speed depends on the GPU clock), so probably not without some work.
I just got a chance to check this out today after clearing some other stuff from my plate. I don’t yet have an RPi 3 (They should arrive on Friday and I’ll give another report based on that), but you can access the Mini-UART on the RPi 2 by using a device tree overlay. Add:

dtoverlay=uart1

to your /boot/config.txt and you’ll end up with a /dev/ttyS0 that are on the same pins as /dev/ttyAMA0. Pins BCM14 and BCM15 have both UARTs available on them.

I did this and hooked up a PiDV to the RPI 2 and ran AMBEserver -i /dev/ttyS0. I then used Buster to listen to a reflector. No audio dropouts and everything seems to work fine.

The issues I’ve been seeing around using the Mini-UART are all surrounding using it as a console, not as a peripheral after boot-time. There are issues with the clocks being gated correctly and such. The firmware does some initial setup, and if you’re not careful you can gate the wrong clocks and really mess up the system. We’re watching the clock code rather closely because we are using one of the general purpose clocks on the RPi in the soon-to-be-released UDRC.

But the upshot of this all is that the PiDV should work okay on the RPi 3. I will post a definitive answer when I get a RPi 3 for testing.

73,

John G8BPQ
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

Re: dmr for nwdigital

mikezingman@...
 

Barry,

The app runs on OSX and Linux (x86 or ARM) at this time.  On the PC I use the internal sound hardware with a headset.  On the Pi I have used an external sound fob (CM108) for sound (the Pi has no sound input!).  

On the Pi I have done both GUI based PTT (like the video) as well as VOX.  The Vox was cool because I used a HT mic with a ptt button.  Because the PTT gated the audio from the mic, I never had to worry about ambient noise triggering the transmit mode.  I just push the button and talk.  Just like a radio, ha.

The app can use either the DV3000 or the ThumbDV in direct serial mode or via the ambe server if you wanted.  I do often use AMBE server because I test on many devices and it is good to have a server when ever I need it.

If you wanted to look at some doc:


NOTE:  This repo is for the DMR to Allstar gateway, but it uses the same components as the dongle mode with a GUI.

There is no magic to building on Windows, just have not spent any time porting it.

Also if you are on Allstar, node 2100 is up and running the DMR gateway.

Mike

DMRDongle 480

"Gianfranco Venezia" <i0inu@...>
 

Greetings to all the newsgroups

And ' possible to have the DMRDongle480 program to do the tests ?????????

 

tanks

Re: dmr for nwdigital

K6ST Barry Bettman <k6st@...>
 

Thanks Mike.  I have a DVthumb and want to run DMR on it.

On Tue, Mar 8, 2016 at 11:25 AM, mikezingman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Barry,


If you are asking about the DV3000 or the ThumbDV, then yes I have done this.  I am in the middle of working on an application that allows one to use the DV3000/ThumbDV just like the DummyRepeater mode works for DStar.  I have been using it for a while and it works very well on both TX and RX.  This is part code is an outgrowth of a project to create a gateway between DMR and ALLStar/Asterisk and that project is nearing its completion.  Once I get a chance, I will open source the code and others can build on my efforts.

A bad youtube video:

DMRDongle480
DMRDongle480
Test with the DMRDongle GUI
Preview by Yahoo

 



The quality was not up to what I wanted so I never released it, but I am tied up with some family things at the moment and this will have to do.  I will do a better one at some point. 

Mike N4IRR



Re: dmr for nwdigital

mikezingman@...
 

Barry,

If you are asking about the DV3000 or the ThumbDV, then yes I have done this.  I am in the middle of working on an application that allows one to use the DV3000/ThumbDV just like the DummyRepeater mode works for DStar.  I have been using it for a while and it works very well on both TX and RX.  This is part code is an outgrowth of a project to create a gateway between DMR and ALLStar/Asterisk and that project is nearing its completion.  Once I get a chance, I will open source the code and others can build on my efforts.

A bad youtube video:

DMRDongle480

 



The quality was not up to what I wanted so I never released it, but I am tied up with some family things at the moment and this will have to do.  I will do a better one at some point. 

Mike N4IRR


dmr for nwdigital

K6ST Barry Bettman <k6st@...>
 

Has anyone been able to run DMR on the nwdigital?