Date   
Re: Thumb DV Software

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

If one stops to think about it, this is much more common than people may realize.

Look at your computer.  If it's not an Apple, Chromebook, or Microsoft Surface, you probably are running an Operating System and Applications that were not developed by the manufacturer.  If you have an issue with the software, the remedy is usually to contact the support network for the software, rather than the hardware manufacturer.

There are at least 4 different suppliers of software that use the ThumbDV.  Each of them have their own development and support cycle.  NW Digital Radio provides them basic integration information and in some cases contributes code (e.g. enhancements to AMBEserver), but the applications themselves remain under the umbrella of the various development companies or teams.

Incidentally, the manufacturers of similar products to the ThumbDV also use third party software.  One notable manufacturer also has their own application, in addition to 3rd parties, which has been in 'beta' for years at a time. 

On Tue, Mar 1, 2016 at 2:42 AM, e.maletta@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Interesting concept, manufacturer not related to software. Love that model!!


Don't get me wrong the product works however from a software support perspective I would caution users that this product is lacking.

_

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  

Re: Thumb DV Software

mikezingman@...
 

As a software developer I got EXACTLY what I wanted from the DV3000 and the ThumbDV.  They provide a  hardware platform  from which I can base my code.  I was well aware that the software from NWD was beta, and it makes no difference to me.

Now, users of my software are told up front, before they are even allowed to download it, that it is in development.  The contract between the developer and the user is simple: I will give you code with the understanding that it may be incomplete and has bugs.  You understand it is incomplete and will agree to use it and report  back issues you find.  Simple.  If that contract is not acceptable, then nothing is lost.

The DV3000/ThumbDV is far from the only product like this.  Every single board computer I  own is a work in progress.  The hardware is solid (usually) but the software is always a work in progress.  From device drivers to Linux to applications, it is a moving target.  

This is what I like to do.  It may not be your cup of tea.  For me any product in this space that does NOT evolve and improve is a dead product.  Why bother?  If I wanted an appliance I would buy it from ICOM/Kenwood/Yaesu.


MIke


Raspberry Pi 3?

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Bryan, John, all...

Any interest in the Raspberry Pi 3?

I'm guessing not, as from your previous descriptions the UDRX wasn't processor-bound.

Nice that they put Wi-Fi and Bluetooth onboard, but pity they didn't provide an antenna connector for applications like yours where it will be in a metal cabinet.

Any potential benefit from the 64-bit processor (even though your base OS, Raspberian will continue to be 32-bit)?

Mostly I'm curious if you plan to stick with the plan to use the Raspberry Pi 2 even though the Raspberry Pi 3 is out, same price, same form factor, same I/O?

Looking forward to the BBQ or demo of a nearly-shipping UDRX-440 at MicroHAMS Digital Conference in a few weeks.


Thanks,

Steve N8GNJ

Re: Raspberry Pi 3?

Jeremy McDermond <mcdermj@...>
 

On Mar 2, 2016, at 7:46 PM, Steve Stroh N8GNJ steve.n8gnj@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:


Bryan, John, all...

Any interest in the Raspberry Pi 3?
We’re interested. I have three on order.

I'm guessing not, as from your previous descriptions the UDRX wasn't processor-bound.

Nice that they put Wi-Fi and Bluetooth onboard, but pity they didn't provide an antenna connector for applications like yours where it will be in a metal cabinet.
There actually is a set of solder pads on the bottom side of the board to solder in a connector. That being said, it’s not really “manufacturable” for us to be soldering those things on by hand.

Any potential benefit from the 64-bit processor (even though your base OS, Raspberian will continue to be 32-bit)?
It’s not necessarily the 64-bit that interests me, especially seeming as Rasbian will continue to be 32-bit for the time being. Compass could become more ambitious and I could build 64-bit packages, but I don’t see a lot of advantage in that vs. the time and effort it would take for me to maintain it.

The real difference here is that the RPi 3 is a Cortex-A53 based processor while the RPi2 is a Cortex-A7. Of particular interest is that the NEON SIMD execution units on the Cortex-A53 is twice as wide as on the Cortex-A7. Since SIMD can help out a lot with DSP tasks, that potentially make the RPi 3 much better at what we’re trying to do. Or, as the Raspberry Pi Foundation folks are saying “We chose the processor not because it was 64-bit, but because it was such a better 32-bit processor."

Mostly I'm curious if you plan to stick with the plan to use the Raspberry Pi 2 even though the Raspberry Pi 3 is out, same price, same form factor, same I/O?
It depends on what comes out in our testing. Since some folks are going to be worried about power consumption, if the RPi 3 takes significantly more juice than the RPi 2, we’ll consider staying with the older board. We also have to make sure we can completely turn off the WiFi and Bluetooth transceivers so that we don’t run into RFI issues with those being inside the same box as our 440MHz RF gear. If these tests turn out favorably, we’ll probably ship with RPi 3. If not, all the current testing has being going on RPi 2, and we’ll ship with what we know.

Looking forward to the BBQ or demo of a nearly-shipping UDRX-440 at MicroHAMS Digital Conference in a few weeks.
Hopefully I’ve answered some of your questions.

Thanks,

Steve N8GNJ
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

Re: Raspberry Pi 3?

grahamc64@...
 

Hi Bryan, John and all,

Will the DV3000 work with the Raspberry Pi 3?

Regards

Graham
G7LMF

Re: Raspberry Pi 3?

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

We don't have one for testing yet, but there shouldn't be a reason why it wouldn't. I'd start with the PI 2 configuration.

On Mar 5, 2016 6:17 PM, "grahamc64@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

Hi Bryan, John and all,


Will the DV3000 work with the Raspberry Pi 3?

Regards

Graham
G7LMF

Re: Raspberry Pi 3?

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

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.

 

73,

John G8BPQ

 


From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: 05 March 2016 21:01
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?

 

 

Hi Bryan, John and all,

 

Will the DV3000 work with the Raspberry Pi 3?

 

Regards

 

Graham

G7LMF

dmr for nwdigital

K6ST Barry Bettman <k6st@...>
 

Has anyone been able to run DMR on the nwdigital?

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


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



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

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

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: 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?

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?

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?

"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?

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 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?

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@...