Date   

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


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

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
 
 


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


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


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


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: DRAWS Workstation (Turnkey version)

 

Aaron,

No.  The manufacturing samples for the case are still being developed.  Photos will not be available before the samples arrive.

Photos will be shared on the company blog when available.


On Thu, Nov 29, 2018 at 2:37 PM <aaron@...> wrote:
Does anyone have pictures of the DRAWS Workstation?
_._,_._,_

--


John D. Hays
Director

  


Re: DRAWS Workstation (Turnkey version)

Aaron Jones
 

Does anyone have pictures of the DRAWS Workstation?


Re: Show US Your DRAW Photos

Peter McC
 

UGH! Terrible site for mobile - in my iPad I get a pop up with the cancel button off the screen!

- Peter

On Nov 28, 2018, at 10:30 PM, Basil Gunn <@basil860> wrote:


I gave the wrong url for the Sunfounder displays that I've used.
These are the correct urls for the 7" & 10" LCD displays.

https://www.sunfounder.com/7-inch-hdmi-lcd.html
https://www.sunfounder.com/10-1-inch-hdmi-lcd.html

One more feature that I like is they run on 12V.
/Basil

Basil Gunn <@basil860> writes:

I just realized they made the same mistake on the DRAWS as they did on the UDRC series.
Not really a mistake if you use the superior SunFounder 7" monitor
(1024x600) which would have the HAT cables come out the top.
https://www.amazon.com/SunFounder-Inch-Monitor-HDMI-Raspberry/dp/B073GYBS93/ref=sr_1_4

I personally prefer the Sunfounder 10" display with 1280x800 resolution
that allows enough screen real estate to run a mail client or
Xastir. With the 10" screen the cables face the bottom but the RPi is
mounted at the top of the display with plenty of room for the cables.

The 7" & 10" Sunfounders come with a built in speaker, RPi mounting
pieces & an HDMI cable to mate with the RPi. I believe (could be wrong)
both sizes come with a touch screen option.

The 800x400 Smart-Pi display was good for my console winlink apps, mutt
with paclink-unix, but really didn't cut it for anything with a gui.

/Basil


The mini-din connectors are on the same side as they were on the UDRC. This means if you try to use one on the "Smarti-Pi" cases with the touchscreen and hinged base the cables will be in the way just like they are with the UDRC.

Oh well looks like I will have to remove the connectors like I did on the UDRC2
Or just buy a better video screen.

/Basil n7nix



Re: Powering the DRAWS

 

Either can be used. The leads go to a buck converter and give a better supply. Some of the wall wart USB power sources have voltage drop through their leads under load.


On Thu, Nov 29, 2018, 07:35 Lynn DeHart <kb3fn@... wrote:
I am new to this product, so excludes my “newbie” question. But is the DRAWS powered from the interface with the RPi or should I power with the included power leads? Tnx Lynn


Powering the DRAWS

 

I am new to this product, so excludes my “newbie” question. But is the DRAWS powered from the interface with the RPi or should I power with the included power leads? Tnx Lynn


Re: Show US Your DRAW Photos

Alexander <alexgish3rd@...>
 

Great idea. Please inform the group when available.
73's
A. Gish WB1GNL


Re: Show US Your DRAW Photos

 

I’m going to order some and will check them out.

Thanks,
Bryan K7UDR

On Nov 28, 2018, at 4:20 PM, Dave Wickert <dwickert@...> wrote:

Or maybe NWDR could have a bunch made and offer them as an accessory? Rather than each of us doing individual orders.
Just a thought.
 
73.
 
_-_-_ Dave, AE7TD
 
 
 
From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of Herb Weiner
Sent: Wednesday, November 28, 2018 12:10 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Show US Your DRAW Photos
 
Or, you could 3D Print these Pi Stand Extenders (or order them 3D Printed for you) from Thingiverse. These are perfect for the Smarti-Pi case with my UDRC, and they should work with DRAWS as well.
 
Herb


On Nov 28, 2018, at 11:51 AM, Robert Sears <kf7vop@...> wrote:
 
I just realized they made the same mistake on the DRAWS as they did on the UDRC series. 

The mini-din connectors are on the same side as they were on the UDRC. This means if you try to use one on the "Smarti-Pi" cases with the touchscreen and hinged base the cables will be in the way just like they are with the UDRC. 

Oh well looks like I will have to remove the connectors like I did on the UDRC2 

Robert/KF7VOP