Where did the modulation go . . .


ab9ca@...
 

Interesting that something has changed. I set up those memories several years ago off some reference that I found online. I did not make up those settings. And so long as we had internet at the rptr site they worked FB. Used them often. Set up several other radios in the area the same way, and those also worked FB. But now it is required that the call be removed and we have 7 spaces with and E or an I . . . . 


Thanks to both you and Dan for the info.


73 de dave

ab9ca/4



 

Your UR should be 7 spaces and an E, not call sign and E and the same for status but using I. 

These are radio configuration issues not dstarrepeater or ircddbgatewayd problems. 

Please visit a D-STAR primer site to understand how the the various fields should be set. 

On Dec 7, 2016 19:15, <ab9ca@...> wrote:

They are both turned ON in ircddbgatewayconfig.


When I try an ECHO test I get this in the ircddb log:


M: 2016-12-08 02:58:55: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:58:56: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102

M: 2016-12-08 02:58:59: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:59:02: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102


KI4SAZ is the call of the local rptr and the hotspot. 

I have a port forward set up in the router for port 40000 for G2 routing. Is that the port that is needed?

When I first set it up I used my personal call and got the same results. 

I get nothing back when I try STATUS and no audio playback from the ECHO command. 

But the basic hotspot seems to be working thru the rptr. I can link and unlink, talk and hear via the rptr with the hotspot providing the internet connectivity. We have lost the internet at the tower. One too many lightning strikes on the tower. Apparently that nice copper phone line provides a good ground. 

73 de dave
ab9ca/4


Dan Porter (AI2M)
 

You need to put the following in the radio's Your Call field:
_______E (7 spaces before the E)
_______I (7 spaces before the I)
for echo and info respectively. 

Dan, AI2M

On Dec 7, 2016, at 10:15 PM, ab9ca@... wrote:

They are both turned ON in ircddbgatewayconfig.


When I try an ECHO test I get this in the ircddb log:


M: 2016-12-08 02:58:55: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:58:56: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102

M: 2016-12-08 02:58:59: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:59:02: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102


KI4SAZ is the call of the local rptr and the hotspot. 

I have a port forward set up in the router for port 40000 for G2 routing. Is that the port that is needed?

When I first set it up I used my personal call and got the same results. 

I get nothing back when I try STATUS and no audio playback from the ECHO command. 

But the basic hotspot seems to be working thru the rptr. I can link and unlink, talk and hear via the rptr with the hotspot providing the internet connectivity. We have lost the internet at the tower. One too many lightning strikes on the tower. Apparently that nice copper phone line provides a good ground. 

73 de dave
ab9ca/4


ab9ca@...
 

They are both turned ON in ircddbgatewayconfig.


When I try an ECHO test I get this in the ircddb log:


M: 2016-12-08 02:58:55: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:58:56: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102

M: 2016-12-08 02:58:59: AB9CA    is trying to G2 route to callsign KI4SAZ E

M: 2016-12-08 02:59:02: USER: AB9CA    KI4SAZ C KI4SAZ G 70.196.133.102


KI4SAZ is the call of the local rptr and the hotspot. 

I have a port forward set up in the router for port 40000 for G2 routing. Is that the port that is needed?

When I first set it up I used my personal call and got the same results. 

I get nothing back when I try STATUS and no audio playback from the ECHO command. 

But the basic hotspot seems to be working thru the rptr. I can link and unlink, talk and hear via the rptr with the hotspot providing the internet connectivity. We have lost the internet at the tower. One too many lightning strikes on the tower. Apparently that nice copper phone line provides a good ground. 

73 de dave
ab9ca/4


 

If they are turned on, they should work.  Watch the log for an error

tail -f /var/log/opendv/ircddbgatewayd.log



On Wed, Dec 7, 2016 at 11:12 AM, <ab9ca@...> wrote:

OK, seem to have nearly all of it working now. 

Can link and unlink, can talk and hear on the reflectors once linked. 


But I can't get the ECHO test nor the STATUS inquiry to work. I would really like to have these available. What is needed to get these working? Both are turned on the ircddbgatewayconfig.


73 de dave

ab9ca/4





--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 

OK, seem to have nearly all of it working now. 

Can link and unlink, can talk and hear on the reflectors once linked. 


But I can't get the ECHO test nor the STATUS inquiry to work. I would really like to have these available. What is needed to get these working? Both are turned on the ircddbgatewayconfig.


73 de dave

ab9ca/4



 



On Tue, Dec 6, 2016 at 3:06 PM, <ab9ca@...> wrote:

Some further progress made.


Got it decoding the TX from the HT to the dstarrepeater log:



Congratulations
 

M: 2016-12-06 22:52:45: Radio header decoded - My: AB9CA   /DAVE  Your: CQCQCQ    Rpt1: DIRECT    Rpt2: DIRECT    Flags: 00 00 00

M: 2016-12-06 22:52:45: Received a non-repeater packet, ignoring

M: 2016-12-06 22:52:45: Current DC offset: -0.005470

M: 2016-12-06 22:52:45: AMBE for AB9CA     Frames: 0.5s, Silence: 4.3%, BER: 0.0%

M: 2016-12-06 22:52:46: Transmitting to - My: AB9CA  C/      Your: AB9CA     Rpt1: AB9CA  C  Rpt2: AB9CA  C  Flags: 01 00 00

M: 2016-12-06 22:55:05: Network header received - My: 2M0JLS  /5100  Your: CQCQCQ    Rpt1: AB9CA  G  Rpt2: AB9CA  C  Flags: 00 00 00

M: 2016-12-06 22:55:05: Transmitting to - My: 2M0JLS  /5100  Your: CQCQCQ    Rpt1: AB9CA  G  Rpt2: AB9CA  C  Flags: 00 00 00

M: 2016-12-06 22:55:05: Stats for 2M0JLS    Frames: 0.7s, Loss: 0.0%, Packets: 0/34


And got it to connect to a reflector via the setup in ircddbgatewayconfig. It connects at startup OK.

Good

 
Can't get any commands through it from the HT. Can't get it to link, unlink, echo, or report status via command from the HT. I am assuming the echo and status work with the UDRC?

See below  -- these commands are a function of the ircddbgateway software, not the UDRC.  The UDRC is just like any other modem one would use.
 
Did RX some audio from the reflector. 

Had to set up the port forwarding manually, the script did not work with this Belkin router. 

See if the router has a UPNP option for the script to work, but manual is probably better as long as you have a fixed LAN address.
 

So . . . what is the likely cause of not being able to get commands through from the HT? That part was working before I ran into the roadblock that killed the TX audio. 

And is it normal to see this line:
M: 2016-12-06 22:52:45: Received a non-repeater packet, ignoring

in the dstarrepeater log? 

And is it normal to see the RPTR1 and RPTR2 shown as 'DIRECT' even when this is not what is programmed into the HT RPTR1 and RPTR2 slots.

This probably your problem.  Are you using DR Mode (modern D-STAR radios), with mode set for DUPLEX with an offset of 0.00 Mhz.? 

If the radio is not set to DUPLEX, it will not set the right bit for repeating and that is what forces DIRECT for RPT1 and RPT2.
 

73 de dave
ab9ca/4



--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 

Some further progress made.


Got it decoding the TX from the HT to the dstarrepeater log:


M: 2016-12-06 22:52:45: Radio header decoded - My: AB9CA   /DAVE  Your: CQCQCQ    Rpt1: DIRECT    Rpt2: DIRECT    Flags: 00 00 00

M: 2016-12-06 22:52:45: Received a non-repeater packet, ignoring

M: 2016-12-06 22:52:45: Current DC offset: -0.005470

M: 2016-12-06 22:52:45: AMBE for AB9CA     Frames: 0.5s, Silence: 4.3%, BER: 0.0%

M: 2016-12-06 22:52:46: Transmitting to - My: AB9CA  C/      Your: AB9CA     Rpt1: AB9CA  C  Rpt2: AB9CA  C  Flags: 01 00 00

M: 2016-12-06 22:55:05: Network header received - My: 2M0JLS  /5100  Your: CQCQCQ    Rpt1: AB9CA  G  Rpt2: AB9CA  C  Flags: 00 00 00

M: 2016-12-06 22:55:05: Transmitting to - My: 2M0JLS  /5100  Your: CQCQCQ    Rpt1: AB9CA  G  Rpt2: AB9CA  C  Flags: 00 00 00

M: 2016-12-06 22:55:05: Stats for 2M0JLS    Frames: 0.7s, Loss: 0.0%, Packets: 0/34


And got it to connect to a reflector via the setup in ircddbgatewayconfig. It connects at startup OK.

Can't get any commands through it from the HT. Can't get it to link, unlink, echo, or report status via command from the HT. I am assuming the echo and status work with the UDRC?

Did RX some audio from the reflector. 

Had to set up the port forwarding manually, the script did not work with this Belkin router. 

So . . . what is the likely cause of not being able to get commands through from the HT? That part was working before I ran into the roadblock that killed the TX audio. 

And is it normal to see this line:
M: 2016-12-06 22:52:45: Received a non-repeater packet, ignoring

in the dstarrepeater log? 

And is it normal to see the RPTR1 and RPTR2 shown as 'DIRECT' even when this is not what is programmed into the HT RPTR1 and RPTR2 slots.

73 de dave
ab9ca/4


 

actually TX is always on the same pin for 1200 or 9600, it's the receive that must hit the right pin.

The control that you need to play with in alsamixer is:

ADC Level (It is usually pretty forgiving)




On Mon, Dec 5, 2016 at 4:05 PM, <ab9ca@...> wrote:

Yes, it must be in order for any audio to TX. I tested at both 1200 and 9600 baud. Works only at 9600. 


73 de dave

ab9ca/4





--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 

Yes, it must be in order for any audio to TX. I tested at both 1200 and 9600 baud. Works only at 9600. 


73 de dave

ab9ca/4



 

Is the radio set for 9600 baud packet 

FT-7900R Operating Manual - Yaesu pages 10-11



On Mon, Dec 5, 2016 at 2:46 PM, <ab9ca@...> wrote:

Some progress to report. 


I don't have a microSD card reader so cannot go all the way back to square 1 right now. 


But in the process of running through the steps, I went in to edit /boot/config.txt and found that these two lines had been added to the end of the file:


#enable_uart=1

#dtoverlay=w1-gpio


I added the # on the line.


The only item not commented out in that file is this line:


# Enable audio (loads snd_bcm2835)

# dtparam=audio=on

force_turbo=1



Once those two lines were commented out and the RPi rebooted TX audio came alive again. I can hear the messages playing.


Unfortunately I have no audio detect. I can key the HT, see the RX indicator light up on the FT-7900, hear it RX audio, but nothing prints in the dstarrepeater@1.log. 


I have switched the RX invert option in dstarrepeaterconfig. Checked that alsamixer was not muted. Adjusted the level of PCM on alsamixer to mid range. What else? 


Here is the result of the 'sudo gpio readall' command:


pi@compass:~ $ sudo gpio readall

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |

 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |

 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |

 |   4 |   7 | GPIO. 7 | ALT0 | 0 |  7 || 8  | 0 | IN   | TxD     | 15  | 14  |

 |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |

 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1   | 18  |

 |  27 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |

 |  22 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 0 | OUT  | GPIO. 4 | 4   | 23  |

 |     |     |    3.3v |      |   | 17 || 18 | 0 | OUT  | GPIO. 5 | 5   | 24  |

 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |

 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 1 | IN   | GPIO. 6 | 6   | 25  |

 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |

 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |

 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |

 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |

 |   6 |  22 | GPIO.22 |  OUT | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |

 |  13 |  23 | GPIO.23 |  OUT | 1 | 33 || 34 |   |      | 0v      |     |     |

 |  19 |  24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |

 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28  | 20  |

 |     |     |      0v |      |   | 39 || 40 | 0 | ALT0 | GPIO.29 | 29  | 21  |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

pi@compass:~ $ 

pi@compass:~ $ 

pi@compass:~ $ 



Does this look right or do I still have some pins of the 40 pin header still messed up?

73 de dave
ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 

Some progress to report. 


I don't have a microSD card reader so cannot go all the way back to square 1 right now. 


But in the process of running through the steps, I went in to edit /boot/config.txt and found that these two lines had been added to the end of the file:


#enable_uart=1

#dtoverlay=w1-gpio


I added the # on the line.


The only item not commented out in that file is this line:


# Enable audio (loads snd_bcm2835)

# dtparam=audio=on

force_turbo=1



Once those two lines were commented out and the RPi rebooted TX audio came alive again. I can hear the messages playing.


Unfortunately I have no audio detect. I can key the HT, see the RX indicator light up on the FT-7900, hear it RX audio, but nothing prints in the dstarrepeater@1.log. 


I have switched the RX invert option in dstarrepeaterconfig. Checked that alsamixer was not muted. Adjusted the level of PCM on alsamixer to mid range. What else? 


Here is the result of the 'sudo gpio readall' command:


pi@compass:~ $ sudo gpio readall

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |

 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |

 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |

 |   4 |   7 | GPIO. 7 | ALT0 | 0 |  7 || 8  | 0 | IN   | TxD     | 15  | 14  |

 |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |

 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1   | 18  |

 |  27 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |

 |  22 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 0 | OUT  | GPIO. 4 | 4   | 23  |

 |     |     |    3.3v |      |   | 17 || 18 | 0 | OUT  | GPIO. 5 | 5   | 24  |

 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |

 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 1 | IN   | GPIO. 6 | 6   | 25  |

 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |

 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |

 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |

 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |

 |   6 |  22 | GPIO.22 |  OUT | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |

 |  13 |  23 | GPIO.23 |  OUT | 1 | 33 || 34 |   |      | 0v      |     |     |

 |  19 |  24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |

 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28  | 20  |

 |     |     |      0v |      |   | 39 || 40 | 0 | ALT0 | GPIO.29 | 29  | 21  |

 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+

 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |

 +-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+

pi@compass:~ $ 

pi@compass:~ $ 

pi@compass:~ $ 



Does this look right or do I still have some pins of the 40 pin header still messed up?

73 de dave
ab9ca/4




 

If you are setting up a hotspot -- follow the directions here https://nw-digital-radio.groups.io/g/udrc/wiki/UDRC%E2%84%A2-For-Simplex-Hotspots-and-Converted-Analog-Repeaters#Install-Compass-Linux


Follow the instructions, including the installation of Compass Linux, step by step and exactly -- (except only install the applications listed for dstarrepeater and ircddbgateway, not direwolf or xastir, etc.)

On Mon, Dec 5, 2016 at 11:36 AM, <ab9ca@...> wrote:


John,

 > The wired/wireless is not at all related to whether dstarrepeaterd is
 > working.

I do not doubt that whatever connection exists between logging onto 
the wireless and killing the UDRC is tenuous, but, rest assured, there 
is a connection. That is what happened. There is definitely a 
connection in there somewhere. It may be inadvertent, perhaps some 
script seizes pin 7 although it does not need to. But there is a 
connection.

Fine on the restart, but . . . .

What do I need to do to delete or supersede the image now on the RPi? 
As I mentioned in a previous post, I picked this up after another 
fellow had done all of the early work. So I don't know what he did. 
And I don't know how to undo it. I don't know which files are stored 
where nor how they were created. How do I wipe the slate clean?

I tried downloading a new copy of dstarrepeaterd. But all it did was 
come back and tell me I already had the latest version.

The rig is a Yaesu FT-7900 for the hotspot.

73 de dave
ab9ca/4





--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Ian
 

Dave,

I can sympathize with you as I had similar problem in that my URDC11 was working fine a few days ago when I last fired it up. On starting it on Friday I found that it wasn't transmitting audio; after spending some time ( days ) trying to troubleshoot the problem I bit the bullet and downloaded the latest version of CompassLinux, followed the instructions on the Wiki and, after one or two changes I am back up and running.

Whilst this will not get to the bottom of your problem, it would relieve the frustration, you would have a working system again and time to troubleshoot if you wished.

Grab the latest image from < http://archive.compasslinux.org/images/wilderness/ >, the ones I used are 3rd and 4th from the bottom, unzip then DD the image to a fresh SD card.

Troubleshooting something other than a " vanilla " install is always difficult.

Regards,

Ian..


ab9ca@...
 


John,

 > The wired/wireless is not at all related to whether dstarrepeaterd is
 > working.

I do not doubt that whatever connection exists between logging onto 
the wireless and killing the UDRC is tenuous, but, rest assured, there 
is a connection. That is what happened. There is definitely a 
connection in there somewhere. It may be inadvertent, perhaps some 
script seizes pin 7 although it does not need to. But there is a 
connection.

Fine on the restart, but . . . .

What do I need to do to delete or supersede the image now on the RPi? 
As I mentioned in a previous post, I picked this up after another 
fellow had done all of the early work. So I don't know what he did. 
And I don't know how to undo it. I don't know which files are stored 
where nor how they were created. How do I wipe the slate clean?

I tried downloading a new copy of dstarrepeaterd. But all it did was 
come back and tell me I already had the latest version.

The rig is a Yaesu FT-7900 for the hotspot.

73 de dave
ab9ca/4



 

Dave,

I would suggest building a new image and following the steps on the Wiki to get to a known state.

What are you hooking to (DR-1X, Radio for Hotspot)?

On Mon, Dec 5, 2016 at 9:58 AM, <ab9ca@...> wrote:

Still needing some help on this one. 


Sent a note the other day to that effect and have heard nothing.


How about some helpl?


Sorry about that.
 

I have unmasked dstarrepeaterd and reenabled it. It starts but I still have the issue of pin 7. It is still showing as IN and not ALTO. What do I need to do to get this thing working?


See above
 

I guess you do not believe me when I tell you what happened. Let me repeat it once again. This is what happened and you need to start from here in troubleshooting this issue. 


We believe you, but we are not there and cannot see what else may have affected your installation.
 

I had the UDRC running. It was playing the canned messages and I could see on the ircddbgatewayd tail that I was connecting to the reflectors. But in the process of trying to get the port forwarding set up on the router I ended up losing wired internet. So I logged onto the wireless. Somehow this caused me to lose pin 7 of the GPIO. Maybe it was the logging on process? Or maybe something else. Once I logged onto the wireless it has not worked since.  Dunno if it matters but the wired was still connected to the RPi. The wired cat5 connection was still active but no internet access. It could go as far as the router but no further. I had typo'ed the addresses of the LAN and WAN sides of the router and they were set to the same network subset. But the wireless side still worked. 


The wired/wireless is not at all related to whether dstarrepeaterd is working.
 

So what script in the wireless logging-on process would steal GPIO pin 7? And, if dstarrepeaterd needs pin 7, why does does it not steal it back? Or, why, at the very least do I not get a resource conflict error message from the OS? 


I don't know.
 

Is there not some way to interrogate the OS and have it tell whom has claimed pin 7? 


Perhaps Jeremy knows. 

If all of the above fails then what do I need to do to start over? Wipe the slate clean. I'm not opposed to doing that if that is what is needed to get this thing working. But I need to know how to go about that process. 


See above.  Do not make any other changes until it is working from the instructions in the Wiki, then only make 1 change at a time, test, and roll back if something breaks.
 

Still looking for some help . . . .


dave

ab9ca/4


_

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


ab9ca@...
 

Still needing some help on this one. 


Sent a note the other day to that effect and have heard nothing.


How about some helpl?


I have unmasked dstarrepeaterd and reenabled it. It starts but I still have the issue of pin 7. It is still showing as IN and not ALTO. What do I need to do to get this thing working?


I guess you do not believe me when I tell you what happened. Let me repeat it once again. This is what happened and you need to start from here in troubleshooting this issue. 


I had the UDRC running. It was playing the canned messages and I could see on the ircddbgatewayd tail that I was connecting to the reflectors. But in the process of trying to get the port forwarding set up on the router I ended up losing wired internet. So I logged onto the wireless. Somehow this caused me to lose pin 7 of the GPIO. Maybe it was the logging on process? Or maybe something else. Once I logged onto the wireless it has not worked since.  Dunno if it matters but the wired was still connected to the RPi. The wired cat5 connection was still active but no internet access. It could go as far as the router but no further. I had typo'ed the addresses of the LAN and WAN sides of the router and they were set to the same network subset. But the wireless side still worked. 


So what script in the wireless logging-on process would steal GPIO pin 7? And, if dstarrepeaterd needs pin 7, why does does it not steal it back? Or, why, at the very least do I not get a resource conflict error message from the OS? 


Is there not some way to interrogate the OS and have it tell whom has claimed pin 7? 


If all of the above fails then what do I need to do to start over? Wipe the slate clean. I'm not opposed to doing that if that is what is needed to get this thing working. But I need to know how to go about that process. 


Still looking for some help . . . .


dave

ab9ca/4



ab9ca@...
 


No activity on the for a couple of days. Anyone else have any ideas I can try to cure this, or is it time to go back to square one, wipe the slate clean, and start over? How would I do that?


That may sound like a strange request, how to start over, but this is a team project and another fellow did all of the early work on this before I picked it up. I don't know what he did in the early stages.


73 de dave

ab9ca/4



ab9ca@...
 

On Mon, Nov 28, 2016 at 10:37 pm, Jeremy McDermond wrote:

Did you install any new packages when you switched the networking to wireless?

No, the dstar and irc daemons were running at the time. There was no internet access as the wired was not working. I decided to try to give it access by clicking on the wireless icon in the upper right. It was ID'ing at that point in time. I clicked on the icon, gave it the password and it logged onto the wireless connection. At that point it had connectivity but it lost audio and has not worked since. No decode, no encode. 


I get 96 lines of stuff with the 'systemctl status' command:


pi@compass:~ $ systemctl status

● compass

    State: running

     Jobs: 0 queued

   Failed: 0 units

    Since: Thu 1970-01-01 00:00:03 UTC; 46 years 10 months ago

   CGroup: /

           ├─1 /sbin/init

           ├─system.slice

           │ ├─avahi-daemon.service

           │ │ ├─476 avahi-daemon: running [compass.local

           │ │ └─500 avahi-daemon: chroot helpe

           │ ├─dbus.service

           │ │ └─477 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

           │ ├─cron.service

           │ │ └─468 /usr/sbin/cron -f

           │ ├─lighttpd.service

           │ │ ├─680 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

           │ │ ├─690 /usr/bin/php-cgi

           │ │ ├─693 /usr/bin/php-cgi

           │ │ ├─694 /usr/bin/php-cgi

           │ │ ├─695 /usr/bin/php-cgi

           │ │ └─696 /usr/bin/php-cgi

           │ ├─dhcpcd.service

           │ │ └─478 /sbin/dhcpcd -q -b

           │ ├─lightdm.service

           │ │ ├─613 /usr/sbin/lightdm

           │ │ └─683 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

           │ ├─hciuart.service

           │ │ └─758 /usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -

           │ ├─system-serial\x2dgetty.slice

           │ │ └─serial-getty@...

           │ │   └─616 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102

           │ ├─systemd-journald.service

           │ │ └─134 /lib/systemd/systemd-journald

           │ ├─minissdpd.service

           │ │ └─663 /usr/sbin/minissdpd -i 0.0.0.0

           │ ├─udisks2.service

           │ │ └─930 /usr/lib/udisks2/udisksd --no-debug

           │ ├─vsftpd.service

           │ │ └─585 /usr/sbin/vsftpd /etc/vsftpd.conf

           │ ├─ssh.service

           │ │ └─562 /usr/sbin/sshd -D

           │ ├─systemd-logind.service

           │ │ └─469 /lib/systemd/systemd-logind

           │ ├─ircddbgatewayd.service

           │ │ └─559 /usr/sbin/ircddbgatewayd

           │ ├─systemd-udevd.service

           │ │ └─136 /lib/systemd/systemd-udevd

           │ ├─polkitd.service

           │ │ └─917 /usr/lib/policykit-1/polkitd --no-debug

           │ ├─system-ifup.slice

           │ │ └─ifup@...

           │ │   └─437 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan1.pid -i wlan1 -D nl80211,wext -c /etc/wpa_supplicant/wpa_suppl

           │ ├─rsyslog.service

           │ │ └─552 /usr/sbin/rsyslogd -n

           │ ├─triggerhappy.service

           │ │ └─499 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/run/thd.pid

           │ ├─ntp.service

           │ │ └─654 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:111

           │ └─bluetooth.service

           │   └─765 /usr/lib/bluetooth/bluetoothd

           └─user.slice

             └─user-1000.slice

               ├─user@...

               │ ├─713 /lib/systemd/systemd --user

               │ └─716 (sd-pam)  

               ├─session-c1.scope

               │ ├─ 705 lightdm --session-child 13 16

               │ ├─ 719 /usr/bin/lxsession -s LXDE-pi -e LXDE

               │ ├─ 745 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager

               │ ├─ 748 /usr/bin/dbus-launch --exit-with-session x-session-manager

               │ ├─ 749 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

               │ ├─ 774 /usr/lib/gvfs/gvfsd

               │ ├─ 800 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes

               │ ├─ 903 openbox --config-file /home/pi/.config/openbox/lxde-pi-rc.xml

               │ ├─ 905 lxpolkit

               │ ├─ 908 lxpanel --profile LXDE-pi

               │ ├─ 909 pcmanfm --desktop --profile LXDE-pi

               │ ├─ 916 /usr/bin/ssh-agent -s

               │ ├─ 927 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

               │ ├─ 943 /usr/lib/gvfs/gvfs-goa-volume-monitor

               │ ├─ 947 /usr/lib/gvfs/gvfs-mtp-volume-monitor

               │ ├─ 951 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor

               │ ├─ 955 /usr/lib/gvfs/gvfs-afc-volume-monitor

               │ ├─ 963 /usr/lib/gvfs/gvfsd-trash --spawner :1.1 /org/gtk/gvfs/exec_spaw/0

               │ ├─ 972 /usr/lib/menu-cache/menu-cached /tmp/.menu-cached-:0-pi

               │ ├─ 986 /usr/bin/x-www-browser

               │ ├─ 992 /usr/lib/gvfs/gvfsd-metadata

               │ ├─1014 lxterminal

               │ ├─1015 gnome-pty-helper

               │ ├─1016 /bin/bash

               │ ├─1422 systemctl status

               │ └─1423 pager

               └─session-c2.scope

                 ├─615 /bin/login -f   

                 └─796 -bash

pi@compass:~ $ 






Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 10:06 PM, ab9ca@arrl.net wrote:

OK, it looks like ambeserver is running.



I tried to kill it but it would not die. It kept changing its PID.
So I did the:



sudo systemctl disable dstarrepeaterd@1
sudo systemctl mask dstarrepeaterd@1



and then rebooted.



Then ran the following:



pi@compass:~ $ sudo systemctl status dstarrepeaterd@1 ircddbgatewayd
● dstarrepeaterd@1.service
Loaded: masked (/dev/null)
Active: inactive (dead)

Nov 29 05:45:54 compass systemd[1]: Stopped dstarrepeaterd@1.service.

● ircddbgatewayd.service - D-STAR Gateway Daemon
Loaded: loaded (/lib/systemd/system/ircddbgatewayd.service; enabled)
Active: inactive (dead) since Tue 2016-11-29 05:45:54 UTC; 1min 11s ago
Process: 560 ExecStart=/usr/sbin/ircddbgatewayd (code=killed, signal=TERM)
Main PID: 560 (code=killed, signal=TERM)

Nov 29 05:43:25 compass systemd[1]: Started D-STAR Gateway Daemon.
Nov 29 05:45:54 compass systemd[1]: Stopping D-STAR Gateway Daemon...
Nov 29 05:45:54 compass systemd[1]: Stopped D-STAR Gateway Daemon.
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $ sudo gpio readall
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | ALT0 | 1 | 3 || 4 | | | 5V | | |
| 3 | 9 | SCL.1 | ALT0 | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 1 | ALT5 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT5 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | ALT0 | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | OUT | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | OUT | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | OUT | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | ALT0 | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | ALT0 | 0 | 21 || 22 | 1 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | OUT | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | OUT | 0 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | OUT | 1 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | ALT0 | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | ALT0 | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+---Pi 3---+---+------+---------+-----+-----+
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $
pi@compass:~ $ ps -ef | grep ambeserver
pi 1102 1033 0 05:47 pts/0 00:00:00 grep --color=auto ambeserver

This is just your grep command in the line above. ambeserver isn’t running.

Looks like pin 7 is still an IN pin and ambeserver is still running, if I'm reading this right.



The ambeserver must be being started somewhere in the boot sequence. How do I find out where? Would the log show this?
Something that you have installed is grabbing pin 7 on boot. It’s not dstarrepeaterd because we’ve told it not to start on boot. It’s difficult for me to debug over email. If you do a:

systemctl status

it’ll show you the daemons that systemd have started. That being said, there could be a startup script somewhere that’s snagging the pin. Did you install any new packages when you switched the networking to wireless?

73, dave

ab9ca/4
--
Jeremy McDermond
nh6z@nh6z.net