Date   
Re: Bring back the UDRC, alongside the DRAWS?

ve7fmn@...
 

It was W7TUT that made the cable.

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

I have not made any cables. You probably got yours from Art Miller or Robert Sears. I think it is safe to assume that if the cable worked on your UDRC it is going to work on the DRAWS. Most of us are using standard cables with mini 6 pin DINs on both ends. Your radio doesn't have that connector so a cable had to be made for it. The mini 6 pin DIN is a pretty standard connector with the pins the same from radio to radio. If NWDR made a change to its connectors they would not be compatible with many radios. My DRAWS board came with two standard, off the shelf, cables. They are not doing anything special.

Budd Churchward
WB7FHC

-----Original Message-----
From: ve7fmn@...
Sent: Friday, December 07, 2018 8:36 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

It’s the one Mr. Churchward made. I do not have a schematic. One end goes into the UDRC2 the other into a TRRS connector as used by KX3.


-----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 5:28 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

Yes, the custom cable will work. You may have to change the alsamixer
settings to get the correct audio input as DRAWS has an analog mixer in the
front end to select Audio or Discriminator. Seeing as HF rigs don’t have
discriminator you need to set alsamixer ti IN_2 instead of the default IN_1
as on the UDRC.

Send me your cable spec and I’ll check it. I have a KX3 Online with DRAWS in
my shack.

Yes DRAWS can replace a SignalLink. Now I’m not bashing the SignalLink but
the transformer coupled audio prevents doing 9600 FSK on the High End and
4800 GMSK on the Loe end.

On Dec 7, 2018, at 9:03 AM, ve7fmn@... wrote:

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




Re: Bring back the UDRC, alongside the DRAWS?

ve7fmn@...
 

Sorry for the false accusation Budd 😊
I was so taken by your helpful videos, really, that you name popped into my mind.
The cable was actually made by a ham who is listed as a resource in the UDRC-2 discussion. I followed the links and a cable showed up at my mail box. Too easy.
And thank you for taking time to make the you tube videos. Please make another showing how we can implement the onboard soundcard instead of a signalink or nomic (neither of which I have had roaring success with) with our KX3s to do those modes that use a soundcard to advantage.
Thank you again.
Fred VE7FMN

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

I have not made any cables. You probably got yours from Art Miller or Robert Sears. I think it is safe to assume that if the cable worked on your UDRC it is going to work on the DRAWS. Most of us are using standard cables with mini 6 pin DINs on both ends. Your radio doesn't have that connector so a cable had to be made for it. The mini 6 pin DIN is a pretty standard connector with the pins the same from radio to radio. If NWDR made a change to its connectors they would not be compatible with many radios. My DRAWS board came with two standard, off the shelf, cables. They are not doing anything special.

Budd Churchward
WB7FHC

-----Original Message-----
From: ve7fmn@...
Sent: Friday, December 07, 2018 8:36 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

It’s the one Mr. Churchward made. I do not have a schematic. One end goes into the UDRC2 the other into a TRRS connector as used by KX3.


-----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 5:28 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

Yes, the custom cable will work. You may have to change the alsamixer
settings to get the correct audio input as DRAWS has an analog mixer in the
front end to select Audio or Discriminator. Seeing as HF rigs don’t have
discriminator you need to set alsamixer ti IN_2 instead of the default IN_1
as on the UDRC.

Send me your cable spec and I’ll check it. I have a KX3 Online with DRAWS in
my shack.

Yes DRAWS can replace a SignalLink. Now I’m not bashing the SignalLink but
the transformer coupled audio prevents doing 9600 FSK on the High End and
4800 GMSK on the Loe end.

On Dec 7, 2018, at 9:03 AM, ve7fmn@... wrote:

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




Re: Bring back the UDRC, alongside the DRAWS?

Budd Churchward
 

I have not made any cables. You probably got yours from Art Miller or Robert Sears. I think it is safe to assume that if the cable worked on your UDRC it is going to work on the DRAWS. Most of us are using standard cables with mini 6 pin DINs on both ends. Your radio doesn't have that connector so a cable had to be made for it. The mini 6 pin DIN is a pretty standard connector with the pins the same from radio to radio. If NWDR made a change to its connectors they would not be compatible with many radios. My DRAWS board came with two standard, off the shelf, cables. They are not doing anything special.

Budd Churchward
WB7FHC

-----Original Message-----
From: ve7fmn@...
Sent: Friday, December 07, 2018 8:36 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

It’s the one Mr. Churchward made. I do not have a schematic. One end goes into the UDRC2 the other into a TRRS connector as used by KX3.


-----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 5:28 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

Yes, the custom cable will work. You may have to change the alsamixer settings to get the correct audio input as DRAWS has an analog mixer in the front end to select Audio or Discriminator. Seeing as HF rigs don’t have discriminator you need to set alsamixer ti IN_2 instead of the default IN_1 as on the UDRC.

Send me your cable spec and I’ll check it. I have a KX3 Online with DRAWS in my shack.

Yes DRAWS can replace a SignalLink. Now I’m not bashing the SignalLink but the transformer coupled audio prevents doing 9600 FSK on the High End and 4800 GMSK on the Loe end.

On Dec 7, 2018, at 9:03 AM, ve7fmn@... wrote:

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




Re: Bring back the UDRC, alongside the DRAWS?

ve7fmn@...
 

It’s the one Mr. Churchward made. I do not have a schematic. One end goes into the UDRC2 the other into a TRRS connector as used by KX3.

-----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 5:28 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Bring back the UDRC, alongside the DRAWS?

Yes, the custom cable will work. You may have to change the alsamixer settings to get the correct audio input as DRAWS has an analog mixer in the front end to select Audio or Discriminator. Seeing as HF rigs don’t have discriminator you need to set alsamixer ti IN_2 instead of the default IN_1 as on the UDRC.

Send me your cable spec and I’ll check it. I have a KX3 Online with DRAWS in my shack.

Yes DRAWS can replace a SignalLink. Now I’m not bashing the SignalLink but the transformer coupled audio prevents doing 9600 FSK on the High End and 4800 GMSK on the Loe end.

On Dec 7, 2018, at 9:03 AM, ve7fmn@... wrote:

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




Re: Bring back the UDRC, alongside the DRAWS?

 

Yes, the custom cable will work. You may have to change the alsamixer settings to get the correct audio input as DRAWS has an analog mixer in the front end to select Audio or Discriminator. Seeing as HF rigs don’t have discriminator you need to set alsamixer ti IN_2 instead of the default IN_1 as on the UDRC.

Send me your cable spec and I’ll check it. I have a KX3 Online with DRAWS in my shack.

Yes DRAWS can replace a SignalLink. Now I’m not bashing the SignalLink but the transformer coupled audio prevents doing 9600 FSK on the High End and 4800 GMSK on the Loe end.

On Dec 7, 2018, at 9:03 AM, ve7fmn@... wrote:

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




Re: Compass udrc kernel panic

Basil Gunn
 

Curt, WE7U <curt.we7u@...> writes:

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.
When I bring up an AX.25 machine I always install iptables & block the
following 3 addresses on both ax0 & ax1 interfaces. I noticed these
addresses being broadcast/multicast while looking at a traffic spy of my
RF interfaces.

iptables -A OUTPUT -o ax0 -d 224.0.0.22 -p igmp -j DROP
iptables -A OUTPUT -o ax0 -d 224.0.0.251 -p udp -m udp --dport 5353 -j DROP
iptables -A OUTPUT -o ax0 -d 239.255.255.250 -p udp -m udp -j DROP

iptables -A OUTPUT -o ax1 -d 224.0.0.22 -p igmp -j DROP
iptables -A OUTPUT -o ax1 -d 224.0.0.251 -p udp -m udp --dport 5353 -j DROP
iptables -A OUTPUT -o ax1 -d 239.255.255.250 -p udp -m udp -j DROP

224.0.0.22 is used for IGMPv3 (multicast) protocol
224.0.0.251 is Bonjour/mDNS request coming out of the Avahi daemon
239.255.255.250 is Simple Service Discovery Protocol (SSDP) for uPNP
detection

I agree with Curt that Samba & dropbox will broadcast on all
network addresses but you can fix both of these with proper
configuration of the app.

/Basil

Re: Bring back the UDRC, alongside the DRAWS?

rdelowrey@...
 

Bryan

I purchased one of your ThumbDV's several months back. What is the best software to use with this product? Thanks!

Richard DeLowrey KN4JWK

Sent from Rick's IPad

On Dec 7, 2018, at 11:00 AM, Bryan Hoyer <@K7UDR> wrote:


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: Bring back the UDRC, alongside the DRAWS?

Steve Stroh
 

Disclaimer: Although I know the individuals of NW Digital Radio
personally, the following are my personal comments - not vetted,
approved, or even discussed with anyone at NWDR. I've followed this
"next generation packet radio" space pretty closely for a lot of years
now. Thus I think I have some perspective.

I applaud NW Digital Radio for evolving the UDRC into the UDRC II, the
DRAWS board, and eventually the packaged DRAWS. It's HARD to evolve a
product, for the reasons we're seeing in this thread. It's DAMN HARD
to evolve a product as a small, shoestring company.

My perception (perhaps they've actually said this - don't remember) is
that NWDR kind of stumbled into this market. Recall that the UDRC was
originally intended to create a controller for the Yaesu DR-1X
repeater to add D-STAR capability to it. Quite apart from that
"science project", it turns out, the UDRC met a need in Amateur Radio
for a well thought out "sound card modem" interface for the Raspberry
Pi.

It's notable that the UDRC used the normal communications methods for
Raspberry Pi that other interface boards (HATs) do, rather than the
much easier method of connecting sound card modems via USB. USB is
really nice, easy, simple, cheap... when it works, but sometimes it
doesn't, especially for very cheap consumer devices like sound cards.

It's also notable that the UDRC and its successors were (eventually)
supported under the native Raspberry Pi Linux (Rasperian) and it (most
relevant to me) is capable of 9600 bps FSK operation, which most sound
card modems are not. As NWDR went along with UDRC, they collected a
list of "wants" and "don't wants" for the product, and when it came
time for another production run, they chose to do the hard thing and
evolve the design with the long term goal of making it an "appliance".
That's tough, but it's worth doing.

In their market research leading to the final spec of DRAWS, they
ASKED their customer base if they wanted DRAWS to incorporate a GPS
receiver as standard and named an approximate price. Most of the
respondents said that they were willing to pay a small premium to have
GPS as a standard feature. It will be very, very interesting to see
what the software authors can do when they can assume the presence of
a GPS, including a stable time base. It was kind of an either / or
decision for them; again they can't afford to support and stock
different versions of the same product.

I agree with NWDR's vision - to make a turnkey, packaged DRAWS
available via normal Amateur Radio retail channels, to finally
displace the now very tired legacy TNCs that are still being sold
(much as I love them). It's going to take QUITE an effort to get DRAWS
out into the real world of Amateur Radio as opposed to reaching and
supporting us early adopters who found NWDR largely because we were
looking for such a product and largely self-support (such as these
lists).

Despite appearances :-) NWDR is a very small operation - they can't
afford to support multiple versions of the same product. Thus, they
have to FOCUS.

Godspeed Bryan, Basil, Anna, John, and Dennis! Can't wait to see
what's next from you folks!


Thanks,

Steve Stroh N8GNJ

PS - I also applaud NWDRs secondary, stealth mission - to get Amateur
Radio back into an experimental, "advance the state of the radio art"
mode by embedding a relatively inexpensive open source hardware
platform and most importantly, Linux. This is exactly the kind of
platform that Amateur Radio needs to be perceived as relevant to those
who we need to attract if Amateur Radio will continue beyond the
current generation.

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

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

Re: Compass udrc kernel panic

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

 

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

Curt Mills, 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: 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: 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

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
 

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