Date   
NWDR's take on Raspberry Pi 3 Model A+? #pi3a+

Steve Stroh
 

I'm curious about NWDR's take on the Raspberry Pi 3 Model A+ that was
recently announced.

I'm curious if the form factor (lower profile) of the 3 A+ is
compatible with DRAWS?

Would the 512K of RAM on the 3 A+ (vs the 1 GB of RAM on the 3 B+) be
a significant factor in not being able to use DRAWS to its full
potential?

Thanks,

Steve N8GNJ

--
Steve Stroh (personal / general): stevestroh@...

Re: NWDR's take on Raspberry Pi 3 Model A+? #pi3a+

 
Edited

 

On Fri, Nov 30, 2018 at 1:47 PM Steve Stroh <steve.stroh@...> wrote:
I'm curious about NWDR's take on the Raspberry Pi 3 Model A+ that was
recently announced.

I'm curious if the form factor (lower profile) of the 3 A+ is
compatible with DRAWS?
 
The 40 pin GPIO is supposed to be pin compatible, so the DRAWS Hat should be able to plug into it.  We have no plans internally to use the 3A+ and they aren't available for testing so we won't be able to give a definitive answer.  I am sure someone will give it a try and can share their experience with the community.   
 

Would the 512K of RAM on the 3 A+ (vs the 1 GB of RAM on the 3 B+) be
a significant factor in not being able to use DRAWS to its full
potential?
 
The driver requirements are not significant, so the real question is "Will your application run in 512MB along with the OS and supporting applications?"

What is probably more significant is the connectivity issues, only one USB port, no RJ-45 LAN port, etc.  By the time one adds an adapter like https://www.amazon.com/gp/product/B072Q25TCD -- the cost savings are gone.  

Also, it's shorter form factor is not going to mate well with the DRAWS custom case, so someone would need to manufacture or provide a 3-D print for it.

 

Thanks,

Steve N8GNJ

--


John D. Hays
Edmonds, WA
K7VE
 
   
 

Re: NWDR's take on Raspberry Pi 3 Model A+? #pi3a+

 

https://www.youtube.com/watch?v=dL8gxaSK-zk

Re: NWDR's take on Raspberry Pi 3 Model A+?

Daniel Corwin
 

I personally don’t use the built on Ethernet. I’ve found in multiple setups (different network switches and Ethernet cables both shielded and not) where it caused more RFi.  My APRS iGate I’ve got home brewed right now uses WiFi with minimal rfi from an Apple 2.1a iPad charger. 

On Fri, Nov 30, 2018 at 5:32 PM John D Hays - K7VE <john@...> wrote:


On Fri, Nov 30, 2018 at 1:47 PM Steve Stroh <steve.stroh@...> wrote:
I'm curious about NWDR's take on the Raspberry Pi 3 Model A+ that was
recently announced.

I'm curious if the form factor (lower profile) of the 3 A+ is
compatible with DRAWS?

The 40 pin GPIO is supposed to be pin compatible, so the DRAWS Hat should be able to plug into it.  We have no plans internally to use the 3A+ and they aren't available for testing so we want be able to give a definitive answer.  I am sure someone will give it a try and can share their experience with the community.   

 

Would the 512K of RAM on the 3 A+ (vs the 1 GB of RAM on the 3 B+) be
a significant factor in not being able to use DRAWS to its full
potential?

The driver requirements are not significant, so the real question is "Will your application run in 512K along with the OS and supporting applications?"

What is probably more significant is the connectivity issues, only one USB port, no RJ-45 LAN port, etc.  By the time one adds an adapter like https://www.amazon.com/gp/product/B072Q25TCD -- the cost savings are gone.  

Also, it's shorter form factor is not going to mate well with the DRAWS custom case, so someone would need to manufacture or provide a 3-D print for it.

 

Thanks,

Steve N8GNJ

--


John D. Hays
Edmonds, WA
K7VE

   

Re: Show US Your DRAW Photos

Annaliese McDermond
 

If you’d like to see what some of the NWDR developers are working on with their boards, I have written a quick page on my current DRAWS project, a combination 2m APRS digipeater and 70cm digital mode repeater using mmdvm-udrc. Hardware build information and pictures are up there right now, and I’ll be posting config snippets to share as I finish the rest of the process with setup. https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS™-Based-Digipeater-and-Repeater

For those of you wanting to use virtual sound cards with the DRAWS/UDRC, know that that functionality is critical to my project, so I’m trying to find the bugs and make that a viable option. There are no guarantees of success here, but I’ll be posting results as I find them out.

I’m happy to answer questions as I can, but please understand that I have a day job, and am not retired like the majority of Ham operators :). That means that my “Amateur Time Units” (Thanks Bill) are limited, and sometimes I’d rather spend them working on a solution for problems than responding to questions here.

I’m happy to hear that people are passionate and enjoying their DRAWS™ boards. It’s one of the things that makes my work with NWDR worthwhile.

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

Bring back the UDRC, alongside the DRAWS?

Chris - KC9AD
 
Edited

Given the sold-out popularity of both the UDRC and the DRAWS, and given the functionality and cost differences between the two, is there any possibility that NWDR would consider producing both products and offering two separate SKUs? The reason I ask is that I am one of those many non-APRS people. I love fldigi and direwolf but both of them run beautifully on the lower-cost UDRC-Pi combo; the extra DRAWS features do not help me. I would like to buy another UDRC or two if they would ever become available again. Thanks for the great products guys.

BTW, I use the Pi's Ethernet port all day every day to run my UDRC-Pi remotely, from across the room. Saves on keyboard, mouse, and display clutter. I also use it for a packet interface. So far, no RFI that I can detect.

BTW, BTW, I am not very technical, so I depend on the more technical members of the community to produce near-turnkey software images for me. And that sharing of software and expertise has made the UDRC-Pi very popular around here.

Thanks also to the NWDR community. 73.

Chris Doutre KC9AD

Re: Bring back the UDRC, alongside the DRAWS?

 

I second this thought. I don't need GPS accuracy or a real time clock. I am very happy with the functionality of the UDRC 1.

Bob AF9W

Re: MMDVM & UDRC

Dan Porter (AI2M)
 

Hi Rich,

Did you eventually manage to get it working? 
I was thinking of trying again with my UDRC.

73, Dan - AI2M

On Jul 6, 2018, at 3:05 PM, Rich KR4PI <rich.schnieders@...> wrote:

Thanks John, that helped but there were still a few errors along the way:

g++ -g -O3 -Wall -std=c++0x -pthread -c -o Biquad.o Biquad.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDMR.o CalDMR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarRX.o CalDStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarTX.o CalDStarTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalNXDN.o CalNXDN.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalP25.o CalP25.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CWIdTX.o CWIdTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMORX.o DMRDMORX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMOTX.o DMRDMOTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarRX.o DStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarTX.o DStarTX.cpp
DStarTX.cpp: In member function ‘void CDStarTX::txHeader(const uint8_t*, uint8_t*) const’:
DStarTX.cpp:382:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
       if (d & 0x08U)
       ^~
DStarTX.cpp:384:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
         i++;
         ^
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIR.o FIR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIRInterpolator.o FIRInterpolator.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IO.o IO.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IOUDRC.o IOUDRC.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVM.o MMDVM.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNRX.o NXDNRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNTX.o NXDNTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25RX.o P25RX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25TX.o P25TX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o POCSAGTX.o POCSAGTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SampleRB.o SampleRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialController.o SerialController.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialPort.o SerialPort.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialRB.o SerialRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SoundCardReaderWriter.o SoundCardReaderWriter.cpp
SoundCardReaderWriter.cpp: In member function ‘virtual void CSoundCardWriter::entry()’:
SoundCardReaderWriter.cpp:479:85: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
 le ((ret = ::snd_pcm_writei(m_handle, m_samples + offset, nSamples - offset)) != (nSamples - offset)) {
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFRX.o YSFRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFTX.o YSFTX.cpp
g++ Biquad.o CalDMR.o CalDStarRX.o CalDStarTX.o CalNXDN.o CalP25.o CWIdTX.o DMRDMORX.o DMRDMOTX.o DMRSlotType.o DStarRX.o DStarTX.o FIR.o FIRInterpolator.o IO.o IOUDRC.o MMDVM.o NXDNRX.o NXDNTX.o P25RX.o P25TX.o POCSAGTX.o SampleRB.o SerialController.o SerialPort.o SerialRB.o SoundCardReaderWriter.o Thread.o Utils.o YSFRX.o YSFTX.o -g -lpthread -lasound -lwiringPi -o MMDVM

it did complete the compile. When I attempt ./MMDVM is receive the following:

Link does not exist: /dev/pts/1 <> ttyMMDVM0
Error creating symlink from /dev/pts/1 to ttyMMDVM0
Unable to open serial port on vpty: ttyMMDVM0

I am assuming this indicates that it is not properly configured for the UDRC.  That is what I will be exploring next.

Thanks for the help
Rich, KR4PI
 
 

Compass udrc kernel panic

Bernard Pidoux
 

Hi Annaliese,

Let me introduce myself first. I have been maintaining ham radio application under Linux for two decades, linfbb and FPAC. I am also contributing occasionally to Linux net modules AX25 and rose. I have a couple of raspberry pi with UDRC II hats running compass distro with Direwolf APRS and at the same time AX25 packet radio network applications. Everything is running flawlessly with last updates.
I recently experienced kernel panics with compass Linux distro with kernel 4.14.79-v7+ as soon as opening a Chromium window.
Kernel panic does not occur if I rmmod all snd and udrc modules before activating Chromium.
After removing all sound and udrc module, modprobe udrc does not reload all needed modules for aplay - l to find udrc card.
I attach one of the photo I took from screen while kernel panic. It shows a null pointer related to bcm2835.
When investigating kernel panic I noticed a few dmesg messages:
sdhost-bcm2835 3f202000.mmc could not get clk, deferring probe.
udrc: loading out-of-tree module taints kernel.
snd-udrc soc:sound: ASoC: CODEC DAI tlv320aic32x4-hifi not registered -will retry
snd-udrc soc:sound: snd_soc_register_card() failed: -517
If you need I can send you more details and screen pictures.

Regards,

Dr Bernard Pidoux
F6BVP

Re: MMDVM & UDRC

Geoffrey Merck
 

Hi,

I am waiting for my DRAWS to be delivered as I plan to address this issue.

73
Geoffrey F4FXL / KC3FRA

Le jeu. 6 déc. 2018 à 13:51, Dan Porter (AI2M) <groups@...> a écrit :
Hi Rich,

Did you eventually manage to get it working? 
I was thinking of trying again with my UDRC.

73, Dan - AI2M

On Jul 6, 2018, at 3:05 PM, Rich KR4PI <rich.schnieders@...> wrote:

Thanks John, that helped but there were still a few errors along the way:

g++ -g -O3 -Wall -std=c++0x -pthread -c -o Biquad.o Biquad.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDMR.o CalDMR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarRX.o CalDStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarTX.o CalDStarTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalNXDN.o CalNXDN.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalP25.o CalP25.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CWIdTX.o CWIdTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMORX.o DMRDMORX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMOTX.o DMRDMOTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarRX.o DStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarTX.o DStarTX.cpp
DStarTX.cpp: In member function ‘void CDStarTX::txHeader(const uint8_t*, uint8_t*) const’:
DStarTX.cpp:382:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
       if (d & 0x08U)
       ^~
DStarTX.cpp:384:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
         i++;
         ^
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIR.o FIR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIRInterpolator.o FIRInterpolator.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IO.o IO.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IOUDRC.o IOUDRC.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVM.o MMDVM.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNRX.o NXDNRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNTX.o NXDNTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25RX.o P25RX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25TX.o P25TX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o POCSAGTX.o POCSAGTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SampleRB.o SampleRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialController.o SerialController.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialPort.o SerialPort.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialRB.o SerialRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SoundCardReaderWriter.o SoundCardReaderWriter.cpp
SoundCardReaderWriter.cpp: In member function ‘virtual void CSoundCardWriter::entry()’:
SoundCardReaderWriter.cpp:479:85: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
 le ((ret = ::snd_pcm_writei(m_handle, m_samples + offset, nSamples - offset)) != (nSamples - offset)) {
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFRX.o YSFRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFTX.o YSFTX.cpp
g++ Biquad.o CalDMR.o CalDStarRX.o CalDStarTX.o CalNXDN.o CalP25.o CWIdTX.o DMRDMORX.o DMRDMOTX.o DMRSlotType.o DStarRX.o DStarTX.o FIR.o FIRInterpolator.o IO.o IOUDRC.o MMDVM.o NXDNRX.o NXDNTX.o P25RX.o P25TX.o POCSAGTX.o SampleRB.o SerialController.o SerialPort.o SerialRB.o SoundCardReaderWriter.o Thread.o Utils.o YSFRX.o YSFTX.o -g -lpthread -lasound -lwiringPi -o MMDVM

it did complete the compile. When I attempt ./MMDVM is receive the following:

Link does not exist: /dev/pts/1 <> ttyMMDVM0
Error creating symlink from /dev/pts/1 to ttyMMDVM0
Unable to open serial port on vpty: ttyMMDVM0

I am assuming this indicates that it is not properly configured for the UDRC.  That is what I will be exploring next.

Thanks for the help
Rich, KR4PI
 
 

Re: Compass udrc kernel panic

Basil Gunn
 

Hi Bernard,

Understand that compass is raspbian is Debian. Please ssh into your
target machine & cut & paste text rather than attaching screen shots,
then you can show us more information from the panic.

The kernel panic from your screen shot is from kernel file:
net/ax25/ax25_addr.c in routine ax25cmp() which compares two ax25
addresses one of which is null.

It looks to me like this is occurring when FPAC is binding to device
rose0 but it's difficult to parse the screen shot you attached.

Anna might comment on the messages coming out of soc:sound. Eventually
the tlv320aic code registers with i2s

snd-udrc soc:sound: tlv320aic32x4-hifi <-> 3f203000.i2s mapping ok

From the information you have supplied I believe this is a Rose ax.25
problem and not a compass/udrc codec problem.

/Basil

Bernard Pidoux <bernard.f6bvp@...> writes:

Hi Annaliese,

Let me introduce myself first. I have been maintaining ham radio
application under Linux for two decades, linfbb and FPAC. I am also
contributing occasionally to Linux net modules AX25 and rose. I have a
couple of raspberry pi with UDRC II hats running compass distro with
Direwolf APRS and at the same time AX25 packet radio network
applications. Everything is running flawlessly with last updates.

I recently experienced kernel panics with compass Linux distro with
kernel 4.14.79-v7+ as soon as opening a Chromium window. Kernel panic
does not occur if I rmmod all snd and udrc modules before activating
Chromium. After removing all sound and udrc module, modprobe udrc
does not reload all needed modules for aplay - l to find udrc card. I
attach one of the photo I took from screen while kernel panic. It
shows a null pointer related to bcm2835. When investigating kernel
panic I noticed a few dmesg messages: sdhost-bcm2835 3f202000.mmc
could not get clk, deferring probe. udrc: loading out-of-tree module
taints kernel. snd-udrc soc:sound: ASoC: CODEC DAI tlv320aic32x4-hifi
not registered -will retry snd-udrc soc:sound: snd_soc_register_card()
failed: -517 If you need I can send you more details and screen
pictures.

Regards,

Dr Bernard Pidoux
F6BVP

Re: Compass udrc kernel panic

Annaliese McDermond
 

On Dec 6, 2018, at 9:48 AM, Basil Gunn <@basil860> wrote:


Anna might comment on the messages coming out of soc:sound. Eventually
the tlv320aic code registers with i2s

snd-udrc soc:sound: tlv320aic32x4-hifi <-> 3f203000.i2s mapping ok
Indeed the mapping fails a few times before it succeeds. This is because of driver dependency ordering. Many times the tlv320aic32x4 driver doesn’t look quickly enough for the other pieces of the sound driver. This is why the framework retries, because module dependencies aren’t always the greatest in Linux.

Bernard Pidoux <bernard.f6bvp@...> writes:

Hi Annaliese,

I recently experienced kernel panics with compass Linux distro with
kernel 4.14.79-v7+ as soon as opening a Chromium window. Kernel panic
does not occur if I rmmod all snd and udrc modules before activating
Chromium. After removing all sound and udrc module, modprobe udrc
does not reload all needed modules for aplay - l to find udrc card. I
attach one of the photo I took from screen while kernel panic. It
shows a null pointer related to bcm2835.
There’s no relation really to BCM2835. The BCM2835 is the Broadcom System on a Chip part number of the SoC on the Raspberry Pi. The Oops message is telling you that it’s running on a Raspberry Pi. It has no real relation to the cause of the panic.

When investigating kernel
panic I noticed a few dmesg messages:
sdhost-bcm2835 3f202000.mmc could not get clk, deferring probe.
This is the Raspberry Pi’s MMC interface on the MMC. It’s just commenting that whatever clock it’s running isn’t ready yet, and it’ll load the driver later. This is a normal condition on the Pi during boot.

udrc: loading out-of-tree module taints kernel.
This just means that we compiled the udrc kernel module “out of tree” instead of “in tree.” That means we don’t have the full Linux kernel source, just the necessary headers. It’s not a part of the kernel itself. This is a normal condition.


snd-udrc soc:sound: ASoC: CODEC DAI tlv320aic32x4-hifi not registered -will retry
snd-udrc soc:sound: snd_soc_register_card() failed: -517
See above.

If you need I can send you more details and screen
pictures.
I think Basil has a sound analysis here that you’re seeing a panic in the ax25 stack somewhere. I’d have to investigate what the changes to the ax25 stack were between kernel versions and try to bisect it.

If you’d like to know my offhand guess as to what’s happening, I’d guess that Chromium is trying to do a broadcast to all interfaces for some reason. Once you load the ax25 stack, the packet modem becomes a network interface. This broadcast packet is probably triggering a bug in the ax25 stack due to it having some sort of freaky address (or more accurately no address) by the time it gets there. But this is just a wild guess from hearing the symptoms.

Other than the fact it’s saying that the tlv320aic32x4 driver is loaded at the time of panic, there’s nothing here that really points to the udrc; just to the ax25 stack. You might want to poke at the kernel ax25 folks and they may be able to illuminate more. Or Basil grubs around in that chunk of the kernel more than I and may have some knowledge to illuminate the situation.


Regards,

Dr Bernard Pidoux
F6BVP


--
Annaliese McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

Re: MMDVM & UDRC

Annaliese McDermond
 

Dan --

Because I’m trying to get my repeater up and running again, and would like to use MMDVM-UDRC to do so, I’ve been doing some work on getting MMDVM-UDRC to work. My code is in the nwdigitalradio github account at:

https://github.com/nwdigitalradio/MMDVM-UDRC

You’re welcome to play with it with the understanding that it’s development code, may not work at all. I’m getting close to having things possibly working acceptably.


An issue you’ll have to deal with is that mmdvm-udrc expects a 24000 sample rate. The UDRC hardware doesn’t support this and if you try to use hw:CARD=udrc,DEV=0 it will fail complaining on not being able to send sample rate. You might try using plughw:CARD=udrc,DEV=0 instead. I’m using a custom asound.conf to support it.

More as I get things worked out.

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

On Dec 6, 2018, at 4:51 AM, Dan Porter (AI2M) <groups@...> wrote:

Hi Rich,

Did you eventually manage to get it working?
I was thinking of trying again with my UDRC.

73, Dan - AI2M

On Jul 6, 2018, at 3:05 PM, Rich KR4PI <@KR4PI> wrote:

Thanks John, that helped but there were still a few errors along the way:

g++ -g -O3 -Wall -std=c++0x -pthread -c -o Biquad.o Biquad.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDMR.o CalDMR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarRX.o CalDStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarTX.o CalDStarTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalNXDN.o CalNXDN.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalP25.o CalP25.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CWIdTX.o CWIdTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMORX.o DMRDMORX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMOTX.o DMRDMOTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarRX.o DStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarTX.o DStarTX.cpp
DStarTX.cpp: In member function ‘void CDStarTX::txHeader(const uint8_t*, uint8_t*) const’:
DStarTX.cpp:382:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (d & 0x08U)
^~
DStarTX.cpp:384:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
i++;
^
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIR.o FIR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIRInterpolator.o FIRInterpolator.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IO.o IO.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IOUDRC.o IOUDRC.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVM.o MMDVM.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNRX.o NXDNRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNTX.o NXDNTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25RX.o P25RX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25TX.o P25TX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o POCSAGTX.o POCSAGTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SampleRB.o SampleRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialController.o SerialController.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialPort.o SerialPort.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialRB.o SerialRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SoundCardReaderWriter.o SoundCardReaderWriter.cpp
SoundCardReaderWriter.cpp: In member function ‘virtual void CSoundCardWriter::entry()’:
SoundCardReaderWriter.cpp:479:85: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
le ((ret = ::snd_pcm_writei(m_handle, m_samples + offset, nSamples - offset)) != (nSamples - offset)) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFRX.o YSFRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFTX.o YSFTX.cpp
g++ Biquad.o CalDMR.o CalDStarRX.o CalDStarTX.o CalNXDN.o CalP25.o CWIdTX.o DMRDMORX.o DMRDMOTX.o DMRSlotType.o DStarRX.o DStarTX.o FIR.o FIRInterpolator.o IO.o IOUDRC.o MMDVM.o NXDNRX.o NXDNTX.o P25RX.o P25TX.o POCSAGTX.o SampleRB.o SerialController.o SerialPort.o SerialRB.o SoundCardReaderWriter.o Thread.o Utils.o YSFRX.o YSFTX.o -g -lpthread -lasound -lwiringPi -o MMDVM

it did complete the compile. When I attempt ./MMDVM is receive the following:

Link does not exist: /dev/pts/1 <> ttyMMDVM0
Error creating symlink from /dev/pts/1 to ttyMMDVM0
Unable to open serial port on vpty: ttyMMDVM0

I am assuming this indicates that it is not properly configured for the UDRC. That is what I will be exploring next.

Thanks for the help
Rich, KR4PI

Re: MMDVM & UDRC

Jonathan Naylor
 

Hi Annaliese

There are a set of filter coefficients for 48 kHz sample rate in a branch of the MMDVM firmware. I’ll look into slotting those in and altering the other variables.

Ideally I’d recalculate them in MATLAB as floating point but my license for it ran out. Octave can probably do it though. Even rescaling from Q15 format will probably give enough precision.

It’s bizarre seeing Linux kernel AX25 being mentioned. I wrote that stuff 23 years ago and last looked at it 20 years ago. I’m not sure I could add anything to that discussion these days.

Jonathan G4KLX 




On Friday, December 7, 2018, 06:01, Annaliese McDermond <nh6z@...> wrote:

Dan --

Because I’m trying to get my repeater up and running again, and would like to use MMDVM-UDRC to do so, I’ve been doing some work on getting MMDVM-UDRC to work.  My code is in the nwdigitalradio github account at:

https://github.com/nwdigitalradio/MMDVM-UDRC

You’re welcome to play with it with the understanding that it’s development code, may not work at all.  I’m getting close to having things possibly working acceptably.


An issue you’ll have to deal with is that mmdvm-udrc expects a 24000 sample rate.  The UDRC hardware doesn’t support this and if you try to use hw:CARD=udrc,DEV=0 it will fail complaining on not being able to send sample rate.  You might try using plughw:CARD=udrc,DEV=0 instead.  I’m using a custom asound.conf to support it.

More as I get things worked out.

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



> On Dec 6, 2018, at 4:51 AM, Dan Porter (AI2M) <groups@...> wrote:
>
> Hi Rich,
>
> Did you eventually manage to get it working?
> I was thinking of trying again with my UDRC.
>
> 73, Dan - AI2M
>
>> On Jul 6, 2018, at 3:05 PM, Rich KR4PI <rich.schnieders@...> wrote:
>>
>> Thanks John, that helped but there were still a few errors along the way:
>>
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o Biquad.o Biquad.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDMR.o CalDMR.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarRX.o CalDStarRX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarTX.o CalDStarTX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalNXDN.o CalNXDN.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalP25.o CalP25.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o CWIdTX.o CWIdTX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMORX.o DMRDMORX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMOTX.o DMRDMOTX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarRX.o DStarRX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarTX.o DStarTX.cpp
>> DStarTX.cpp: In member function ‘void CDStarTX::txHeader(const uint8_t*, uint8_t*) const’:
>> DStarTX.cpp:382:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
>>        if (d & 0x08U)
>>        ^~
>> DStarTX.cpp:384:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
>>          i++;
>>          ^
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIR.o FIR.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIRInterpolator.o FIRInterpolator.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o IO.o IO.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o IOUDRC.o IOUDRC.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVM.o MMDVM.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNRX.o NXDNRX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNTX.o NXDNTX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25RX.o P25RX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25TX.o P25TX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o POCSAGTX.o POCSAGTX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o SampleRB.o SampleRB.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialController.o SerialController.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialPort.o SerialPort.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialRB.o SerialRB.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o SoundCardReaderWriter.o SoundCardReaderWriter.cpp
>> SoundCardReaderWriter.cpp: In member function ‘virtual void CSoundCardWriter::entry()’:
>> SoundCardReaderWriter.cpp:479:85: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
>>  le ((ret = ::snd_pcm_writei(m_handle, m_samples + offset, nSamples - offset)) != (nSamples - offset)) {
>>      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFRX.o YSFRX.cpp
>> g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFTX.o YSFTX.cpp
>> g++ Biquad.o CalDMR.o CalDStarRX.o CalDStarTX.o CalNXDN.o CalP25.o CWIdTX.o DMRDMORX.o DMRDMOTX.o DMRSlotType.o DStarRX.o DStarTX.o FIR.o FIRInterpolator.o IO.o IOUDRC.o MMDVM.o NXDNRX.o NXDNTX.o P25RX.o P25TX.o POCSAGTX.o SampleRB.o SerialController.o SerialPort.o SerialRB.o SoundCardReaderWriter.o Thread.o Utils.o YSFRX.o YSFTX.o -g -lpthread -lasound -lwiringPi -o MMDVM
>>
>> it did complete the compile. When I attempt ./MMDVM is receive the following:
>>
>> Link does not exist: /dev/pts/1 <> ttyMMDVM0
>> Error creating symlink from /dev/pts/1 to ttyMMDVM0
>> Unable to open serial port on vpty: ttyMMDVM0
>>
>> I am assuming this indicates that it is not properly configured for the UDRC.  That is what I will be exploring next.
>>
>> Thanks for the help
>> Rich, KR4PI
>>
>>
>
>






Re: MMDVM & UDRC

Annaliese McDermond
 

On Dec 7, 2018, at 12:14 AM, Jonathan Naylor via Groups.Io <naylorjs=yahoo.com@groups.io> wrote:

Hi Annaliese

There are a set of filter coefficients for 48 kHz sample rate in a branch of the MMDVM firmware. I’ll look into slotting those in and altering the other variables.

Ideally I’d recalculate them in MATLAB as floating point but my license for it ran out. Octave can probably do it though. Even rescaling from Q15 format will probably give enough precision.
If you have some matlab code, I have a Matlab 2015b license on my Mac that I could spit out the coefficients for you. I’m mildly familiar with the process because I’ve done it for filter coefficients in the OpenHPSDR FPGA code that I was playing with.


It’s bizarre seeing Linux kernel AX25 being mentioned. I wrote that stuff 23 years ago and last looked at it 20 years ago. I’m not sure I could add anything to that discussion these days.

Jonathan G4KLX
--
Annaliese McDermond (NH6Z)
nh6z@...

Re: MMDVM & UDRC

Dan Porter (AI2M)
 

Hi Anna,

Thanks for the info. I’m definitely interested in following your progress.

Dan - AI2M

On Dec 7, 2018, at 1:01 AM, Annaliese McDermond <nh6z@...> wrote:

Dan --

Because I’m trying to get my repeater up and running again, and would like to use MMDVM-UDRC to do so, I’ve been doing some work on getting MMDVM-UDRC to work.  My code is in the nwdigitalradio github account at:

https://github.com/nwdigitalradio/MMDVM-UDRC

You’re welcome to play with it with the understanding that it’s development code, may not work at all.  I’m getting close to having things possibly working acceptably.


An issue you’ll have to deal with is that mmdvm-udrc expects a 24000 sample rate. The UDRC hardware doesn’t support this and if you try to use hw:CARD=udrc,DEV=0 it will fail complaining on not being able to send sample rate.  You might try using plughw:CARD=udrc,DEV=0 instead.  I’m using a custom asound.conf to support it.

More as I get things worked out.

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



On Dec 6, 2018, at 4:51 AM, Dan Porter (AI2M) <groups@...> wrote:

Hi Rich,

Did you eventually manage to get it working? 
I was thinking of trying again with my UDRC.

73, Dan - AI2M

On Jul 6, 2018, at 3:05 PM, Rich KR4PI <rich.schnieders@...> wrote:

Thanks John, that helped but there were still a few errors along the way:

g++ -g -O3 -Wall -std=c++0x -pthread -c -o Biquad.o Biquad.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDMR.o CalDMR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarRX.o CalDStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalDStarTX.o CalDStarTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalNXDN.o CalNXDN.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CalP25.o CalP25.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o CWIdTX.o CWIdTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMORX.o DMRDMORX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRDMOTX.o DMRDMOTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarRX.o DStarRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DStarTX.o DStarTX.cpp
DStarTX.cpp: In member function ‘void CDStarTX::txHeader(const uint8_t*, uint8_t*) const’:
DStarTX.cpp:382:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
      if (d & 0x08U)
      ^~
DStarTX.cpp:384:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
        i++;
        ^
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIR.o FIR.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o FIRInterpolator.o FIRInterpolator.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IO.o IO.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o IOUDRC.o IOUDRC.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVM.o MMDVM.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNRX.o NXDNRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o NXDNTX.o NXDNTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25RX.o P25RX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P25TX.o P25TX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o POCSAGTX.o POCSAGTX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SampleRB.o SampleRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialController.o SerialController.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialPort.o SerialPort.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SerialRB.o SerialRB.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o SoundCardReaderWriter.o SoundCardReaderWriter.cpp
SoundCardReaderWriter.cpp: In member function ‘virtual void CSoundCardWriter::entry()’:
SoundCardReaderWriter.cpp:479:85: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
le ((ret = ::snd_pcm_writei(m_handle, m_samples + offset, nSamples - offset)) != (nSamples - offset)) {
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFRX.o YSFRX.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFTX.o YSFTX.cpp
g++ Biquad.o CalDMR.o CalDStarRX.o CalDStarTX.o CalNXDN.o CalP25.o CWIdTX.o DMRDMORX.o DMRDMOTX.o DMRSlotType.o DStarRX.o DStarTX.o FIR.o FIRInterpolator.o IO.o IOUDRC.o MMDVM.o NXDNRX.o NXDNTX.o P25RX.o P25TX.o POCSAGTX.o SampleRB.o SerialController.o SerialPort.o SerialRB.o SoundCardReaderWriter.o Thread.o Utils.o YSFRX.o YSFTX.o -g -lpthread -lasound -lwiringPi -o MMDVM

it did complete the compile. When I attempt ./MMDVM is receive the following:

Link does not exist: /dev/pts/1 <> ttyMMDVM0
Error creating symlink from /dev/pts/1 to ttyMMDVM0
Unable to open serial port on vpty: ttyMMDVM0

I am assuming this indicates that it is not properly configured for the UDRC.  That is what I will be exploring next.

Thanks for the help
Rich, KR4PI










Re: Compass udrc kernel panic

Curt, WE7U
 

On Thu, 6 Dec 2018, Annaliese McDermond wrote:

If you?d like to know my offhand guess as to what?s happening, I?d guess that Chromium is trying to do a broadcast to all interfaces for some reason. Once you load the ax25 stack, the packet modem becomes a network interface. This broadcast packet is probably triggering a bug in the ax25 stack due to it having some sort of freaky address (or more accurately no address) by the time it gets there. But this is just a wild guess from hearing the symptoms.
Check Samba as well if it's loaded and running. It's a known contributor to "talk to all interfaces" problems.

--
Curt, WE7U. http://we7u.wetnet.net
U.S. Weather Alerts: Firenet.aprs2.net, port 14580, filter "t/n e/WE7U-WX"
Coordinate Converter (Android): http://www.sarguydigital.com

Re: Bring back the UDRC, alongside the DRAWS?

 

Making 2 products causes inventory issues and makes both more expensive.

After we launched the ThumbDV we still get a couple of requests per year for the PiDV but the economics don’t work out.

We spent a lot of time deciding on the GPS. With the UDRC one could add a USB GPS but that wouldn’t give you PPS, which is arguably not a necessity for Ham Radio but is pretty cool. DRAWS is also a 4 layer Board with additional features; ADC, serial port, and Expansion connector, which increases Ir’s cost.

We even did a survey and found that a majority of responders preferred the on board GPS.

By Comparison the popular Signal Link USB with Cable is $129.95 and has only 1 Radio Port and no GPS.

The best way to save Money is to do a group buy:

5% for 5 units 10% for 10. You can mix DRAWs and ThumbDV in the order.

Use coupons:

club5

club10

Re: Compass udrc kernel panic

f6bvp
 

I would like to thank all who sent a reply to my kernel panic message.

Basil Gunn contributed a lot in analyzing the screen dump :
" The kernel panic from your screen shot is from kernel file:
net/ax25/ax25_addr.c in routine ax25cmp() which compares two ax25
addresses one of which is null." he wrote.
His message reminded me an old bug I found in february 2016 in rose
ax.25 packet radio protocole, when ax25cmp has a NULL argument,
triggering a kernel panic.
https://marc.info/?l=linux-netdev&m=146866282201792&w=2
https://marc.info/?l=linux-hams&m=147118203413414&w=2
Thus I patched the offending function and everything turned back to
excellent behavior.
I guess that Annaliese analysis is correct in that association of
Chromium and rose unraveled the old bug, during tasks swap (?).
I now have to convince netdev authority to accept the simple patch.
A couple of years ago it did not. However now that kernel panic occurs
systematically when opening Chromium the patch can be more easily accepted.

https://marc.info/?l=linux-netdev&m=145633324325000&w=2
https://marc.info/?l=linux-netdev&m=145643820631007&w=2
https://marc.info/?l=linux-netdev&m=145704258127811&w=2
https://marc.info/?l=linux-hams&m=147118203413414&w=2

If not, I am thinking of adopting dkms for rose module to be
automatically re installed each time kernel updates. A package with dkms
rose module could be built, turning around "official" kernel distro.

Thanks again to you all.

Bernard

Le 07/12/2018 à 15:35, Curt, WE7U a écrit :
On Thu, 6 Dec 2018, Annaliese McDermond wrote:

If you?d like to know my offhand guess as to what?s happening, I?d
guess that Chromium is trying to do a broadcast to all interfaces for
some reason.  Once you load the ax25 stack, the packet modem becomes a
network interface.  This broadcast packet is probably triggering a bug
in the ax25 stack due to it having some sort of freaky address (or
more accurately no address) by the time it gets there.  But this is
just a wild guess from hearing the symptoms.
Check Samba as well if it's loaded and running. It's a known contributor
to "talk to all interfaces" problems.

Re: Bring back the UDRC, alongside the DRAWS?

ve7fmn
 

OK, so then it begs the question, two actually...
I had a custom cable made to interface between the UDRC-2 and my KX3. Will that cable work with my new to me DRAWS?
Can the DRAWS replace a signalink USB in additional to all of the other cool things it does?
PS, mine arrived day before yesterday, thank you, and I was thoroughly spanked by Canada customs and Canada Post (not thank you).

-----Original Message-----
From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of Bryan Hoyer
Sent: Friday, December 7, 2018 8:01 AM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?


Making 2 products causes inventory issues and makes both more expensive.

After we launched the ThumbDV we still get a couple of requests per year for the PiDV but the economics don’t work out.

We spent a lot of time deciding on the GPS. With the UDRC one could add a USB GPS but that wouldn’t give you PPS, which is arguably not a necessity for Ham Radio but is pretty cool. DRAWS is also a 4 layer Board with additional features; ADC, serial port, and Expansion connector, which increases Ir’s cost.

We even did a survey and found that a majority of responders preferred the on board GPS.

By Comparison the popular Signal Link USB with Cable is $129.95 and has only 1 Radio Port and no GPS.

The best way to save Money is to do a group buy:

5% for 5 units 10% for 10. You can mix DRAWs and ThumbDV in the order.

Use coupons:

club5

club10