Date   

Re: Where did the modulation go . . .

ab9ca@...
 

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


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?


73, dave

ab9ca/4



Re: Where did the modulation go . . .

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 7:30 PM, ab9ca@arrl.net wrote:
| 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 1 | ALT5 | TxD | 15 | 14 |

And we see that pin 7 is IN, not ALTO.

I don't know when these assignments might change. This command was issued after stopping dstarrepeaterd and ircddbgatewayd. These two daemons are started on bootup of the RPi.
Yeah, it appears as though you have something that’s setting Pin 7 to an IN pin instead of an ALT0.

How do we get pin 7 back to ALTO? It was likely there before I switched from wired to wireless. Prior to that event It was running and I was hearing the announcements.
I wouldn’t think it’s switching to wireless. It certainly wouldn’t switch the pin to an IN. It’s another daemon that’s starting that is bypassing the kernel and reassigning the pin.

Did you install ambeserver per chance? If I recall correctly, that’ll try to grab pin 7 as the reset pin. You can check by looking for the process with something like:

ps -ef | grep ambeserver

We can also try to shut down dstarrepeaterd for now to isolate things. You can keep it from starting by executing

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

Reboot after this and see if the output of gpio readall reflects that Pin 7 is in ALT0 mode.

--
Jeremy McDermond
nh6z@nh6z.net

73, dave
ab9ca/4


Re: Where did the modulation go . . .

ab9ca@...
 


Jeremy, first, thank you for your help on this. I think we are going to make some progress. 


Here is the command and output:


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


Here is the line of pin 7 by itself as the other stuff makes it difficult to read:

 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | ALT5 | TxD     | 15  | 14  |

And we see that pin 7 is IN, not ALTO.

I don't know when these assignments might change. This command was issued after stopping dstarrepeaterd and ircddbgatewayd. These two daemons are started on bootup of the RPi. 

How do we get pin 7 back to ALTO? It was likely there before I switched from wired to wireless. Prior to that event It was running and I was hearing the announcements.


73, dave
ab9ca/4


Re: UDRC-II holding PTT on during reboot

VK3IL
 

Thanks Jeremy for the explanation. I will leave my mitigation in then for now. The shutdown case shouldn't be an issue generally as I am configuring the RPi to be hardened against power switch off (this is a mobile application) using a read only SD card implemented with overlayfs. Hence I won't be using shutdown at all in practice. It's probably worth documenting this somewhere to warn people in other use cases.

Thanks,

David.


Re: Where did the modulation go . . .

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 1:40 PM, ab9ca@arrl.net wrote:



OK, you are speaking a language I do not understand. I don't know what BCM is nor where to find it.
BCM is short for Broadcom, the manufacturer of the System on a Chip used on the Raspberry Pi. The IC itself has pin numbers that are used in the Linux kernel and Raspberry Pi firmware to identify the pins.

I don't know what pinout.xyz is nor where to find it.
http://pinout.xyz is a cool site that shows you the pin assignments for a Raspberry Pi header.

Maybe if we use the 40 pin header we can both recognize which pin we are talking about?
The numbers in parenthesis are the 40-pin header numbers.

While this command is running I see the following on these pins of the 40 pin header:

pin 3 - a DC voltage of about 3.4v, no waveform
pin 5 - a DC voltage of about 3.4v, no waveform
These look correct. The I2C should idle high.

pin 7 - nothing, no DC nor waveform
This is worrisome. This should be a 25MHz square wave. But as I said, it will *only* turn on if the mixer is set up correctly.

pin 12 - apprx 3.4v rectangular wave at approx 3 MHz
This is about right. Your playback is 32bits/sample * 48kHz * 2 samples = 3.072 MHz.

pin 35 - rectangular wave approx 3.4v approx 48 kHz
This matches your sample rate, so this is correct.

pin 38 - nothing
This is correct. You’re not recording, you’re playing back.

pin 40 - a pulse width modulated 3.4 v rectangular waveform
This is your playback data.

This command should cause the RPi to generate a 1000 Hz tone and send it to din 6. It does not do so.

Should there not be the master clock on pin 7?
Yes, but only if the kernel thinks there’s a valid playback path. Your mixer settings look correct, though.

What is the output of

sudo gpio readall

It should look something like:

+-----+-----+---------+------+---+---Pi 2---+---+------+---------+-----+-----+
| 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 | 1 | ALT0 | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | ALT0 | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 1 | ALT0 | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | OUT | 1 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | OUT | 0 | 15 || 16 | 1 | OUT | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 1 | 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 | 1 | 31 || 32 | 0 | OUT | 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 2---+---+------+---------+-----+-----+

I’m mainly interested in the state of Pin 7 in here to make sure the “Mode” is set to “ALT0”.

I don;t think the I2C is used by this script so I can understand no activity on pins 2 and 3.
You’ll see a burst of activity at the start of the transfer when the kernel sets up the chip, but it’ll go quiet after that.

The following is for education more than anything else; not only for you but for others on the list as well. Each of the pins on the 40-pin header has multiple functions it can serve. They can all pretty much be GPIO inputs or outputs, but there are also multiple “ALT” modes that the pins can be put in as well. These “ALT” modes are hooked to hardware on the System on a Chip (SoC) that provide specialized interfaces like I2C, I2S, SPI, Serial, etc. http://pinout.xyz will show you these alternate modes if you click on a pin on the header. For example, if you click on Pin 7, which is BCM4, you’ll see that ALT0 is GPCLK0, which is the first General Purpose Clock on the Raspberry Pi. ALT1 is for a secondary memory interface, and ALT5 is a pin for the JTAG test interface.

These pin functions are set up in two ways by NWDR. First, there is a chunk of firmware on the I2C ID flash on the UDRC itself. This tells the firmware how to set up the pins and their functions. Once the kernel is booted, the kernel will “claim” the pins and set them up for the various devices on the system. Again, there is a piece of the firmware on the ID flash on the UDRC that tells the kernel that there is additional hardware on the Raspberry Pi. This is the RPi “HAT” specification that’s detailed at https://github.com/raspberrypi/hats. NWDR tries to fully comply with the spec as much as possible.

There are issues, though, when it comes to using the wiringPi library. This library, instead of using kernel interfaces to control the GPIO pins, writes directly to the memory registers in the SoC. At first it used to do this directly through /dev/mem which is a huge security hole. The RPi folks, though, wrote a special driver that presents a device called /dev/gpiomem that is a little less dangerous. The problem is that this will “yank the rug” out from under the kernel if you’re not careful. The kernel isn’t notified that the wiringPi has changed the function of pins and breaks things. The kernel won’t let you use these pins through its normal interfaces because something else has already claimed them.


What next?
Lets make sure that your MCLK isn’t getting borked somehow. dstarrepeater uses wiringPi and can screw that up if it’s set up incorrectly. After that we’re more looking at mixer settings to make sure that the DACs are on.

73, dave

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


Re: UDRC-II holding PTT on during reboot

Jeremy McDermond <mcdermj@...>
 

On Nov 28, 2016, at 2:53 PM, VK3IL <david@vk3il.net> wrote:

UDRC-I is quite different on PTT. It has a single PTT line (also on GPIO 12), but does not have any buffer transistor. In UDRC-II, there are 2 separate PTT lines buffered with transistors on GPIO 12 and GPIO 23.

That has made me wonder though if the on chip pull-up on this line has been left active in UDRC-II (which would have been necessary in UDRC-I) ? This would trigger the symptoms I am seeing due to the inverting action of the transistor buffer, The pull-up state transcends power down and so would explain the behaviour I suspect.
The pull-up/down resistors on the chip are only active when the pin is in input mode. The firmware on the UDRC tries to set up the pin so that you don’t get this behavior, but unfortunately I haven’t been able to make it work out correctly. This is a problem that we are aware of and it’s on my long list of things to do to try to find a workaround for folks. Unfortunately part of this is hardware based because the Broadcom chip itself has defaults that don’t come up quite right. I wish I could give you a better answer.

Regards,

David.
--
Jeremy McDermond
nh6z@nh6z.net


Re: Where did the modulation go . . .

ab9ca@...
 

Thank you Stuart!


With your input I pulled off the text, saved it to a file, changed owner & group, and made it executable. That left only to correct 'plughw' error on approx line 246.


It seems to run now:


pi@compass:~ $ ./measure_deviate.sh.2 -f 1000 -c din6 -l 180

Using tone: 1000 (wave file name: 1000hzsin.wav) for duration 180 & connector: din6 using gpio: 23


=== Found existing wav file: 1000hzsin.wav and tone length is not default 30 seconds.

May want to delete existing wavefile 1000hzsin.wav to create a different tone duration


If using devcal from Svxlink make sure devcal line has -f1000

Using PTT GPIO 23 with tone of 1000 Hz

Playing WAVE '1000hzsin.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

Hardware PCM card 0 'udrc' device 0 subdevice 0

Its setup is:

  stream       : PLAYBACK

  access       : RW_INTERLEAVED

  format       : S32_LE

  subformat    : STD

  channels     : 2

  rate         : 48000

  exact rate   : 48000 (48000/1)

  msbits       : 32

  buffer_size  : 24000

  period_size  : 6000

  period_time  : 125000

  tstamp_mode  : NONE

  period_step  : 1

  avail_min    : 6000

  period_event : 0

  start_threshold  : 24000

  stop_threshold   : 24000

  silence_threshold: 0

  silence_size : 0

  boundary     : 1572864000

  appl_ptr     : 0

  hw_ptr       : 0

##################################################+| MAX^C

Aborted by signal Interrupt...

##########################                        +| MAX

** carrier off from trapped CTRL-C




Now, if only we could figure out why my UDRC quit running . . . 

I still hear nothing but the right port does key.

73, dave
ab9ca/4


Re: Where did the modulation go . . .

Stuart Longland VK4MSL
 

On 29/11/16 08:58, ab9ca@arrl.net wrote:
OK, I did the 'wget':
pi@compass:~ $ wget
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh
Yeah, have a close look at the link. In fact, rename the file to have
.html on the end and open it. Then please have a look at my earlier reply.

--2016-11-28 22:50:24--
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

Length: unspecified [text/html]
^^^^^^

Bourne Shell doesn't understand this.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.


Re: Where did the modulation go . . .

 

Look inside downloaded files before trying to executing them, e.g. more measure_deviate.sh


On Mon, Nov 28, 2016 at 3:00 PM, John D. Hays <john@...> wrote:

On Mon, Nov 28, 2016 at 2:58 PM, John D Hays - K7VE <john@...> wrote:
If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

 

On Mon, Nov 28, 2016 at 2:58 PM, John D Hays - K7VE <john@...> wrote:
If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

 

If you goto https://github.com/nwdigitalradio/n7nix/tree/master/deviation
You will see a link to the script, but it shows you a view of it (HTML page), you will see a 'raw' button that gives you actual contents of the script (no HTML).
The wget I provided will get you the contents.

On Mon, Nov 28, 2016 at 2:49 PM, <ab9ca@...> wrote:


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

ab9ca@...
 

OK, I did the 'wget':


pi@compass:~ $ wget https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

--2016-11-28 22:50:24--  https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

Resolving github.com (github.com)... 192.30.253.113

Connecting to github.com (github.com)|192.30.253.113|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: ‘measure_deviate.sh.1’


measure_deviate.sh.1        [  <=>                            ]  98.18K   272KB/s   in 0.4s   


2016-11-28 22:50:30 (272 KB/s) - ‘measure_deviate.sh.1’ saved [100539]



And it says it got it. 

I make that executable and run it:

pi@compass:~ $ sudo chmod +x ./measure_deviate.sh.1

pi@compass:~ $ ./measure_deviate.sh.1 -f 1000 -c din6 -l 180
./measure_deviate.sh.1: line 5: syntax error near unexpected token `newline'
./measure_deviate.sh.1: line 5: `<!DOCTYPE html>'

Something still not quite right.

73, dave
ab9ca/4


Re: Where did the modulation go . . .

Stuart Longland VK4MSL
 

On 29/11/16 08:49, ab9ca@arrl.net wrote:
So . . . the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation
That is a link to the directory listing.

That is very plainly labeled as 'measure_deviate.sh' is in fact not
measure_deviate.sh?
Yep, it is 'measure_deviate.sh', it links to the source code listing of
that file. It is *NOT* the raw file, but a pretty-printed version for
viewing in a web browser.

The link for this is
https://github.com/nwdigitalradio/n7nix/blob/master/deviation/measure_deviate.sh

If you have a look, you'll see what I mean. Now, up the top of the
source code listing, you'll see a button labelled "Raw", *that* link is
the one you feed to curl/wget/whatever.

If you click it, it'll take you to here:
https://raw.githubusercontent.com/nwdigitalradio/n7nix/master/deviation/measure_deviate.sh

Note the lack of formatting and pretty printing.

No wonder I am lost . . . .

Seems that if it is labeled as such it should be that . . .
Blame Github. It's their UI. Unfortunately this is not under anyone's
control but theirs.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.


Re: UDRC-II holding PTT on during reboot

VK3IL
 

UDRC-I is quite different on PTT. It has a single PTT line (also on GPIO 12), but does not have any buffer transistor. In UDRC-II, there are 2 separate PTT lines buffered with transistors on GPIO 12 and GPIO 23.

That has made me wonder though if the on chip pull-up on this line has been left active in UDRC-II (which would have been necessary in UDRC-I) ? This would trigger the symptoms I am seeing due to the inverting action of the transistor buffer, The pull-up state transcends power down and so would explain the behaviour I suspect.

Regards,

David.


Re: Where did the modulation go . . .

ab9ca@...
 


So . . .  the link at the top of this page:

https://github.com/nwdigitalradio/n7nix/tree/master/deviation


That is very plainly labeled as 'measure_deviate.sh' is in fact not measure_deviate.sh? 

No wonder I am lost . . . . 

Seems that if it is labeled as such it should be that . . . 

If it is info should it not be labeled as info?

And if it is a 'go to this page to download' should it not be labeled as that?


I'll see if I can figure out what in world you guys are talking about.


73, dave

ab9ca/4




Re: Where did the modulation go . . .

 

On Mon, Nov 28, 2016 at 1:59 PM, Basil Gunn <basil@...> wrote:
On Mon, 28 Nov 2016 13:40:30 -0800
ab9ca@... wrote:

>
> The new tone generation script does not work. I get the following:
>
> pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180
>
> ./measure_deviate.sh: line 5: syntax error near unexpected token
> `newline'
>
> ./measure_deviate.sh: line 5: `<!DOCTYPE html>'

You are not running the script. There is no `<!DOCTYPE html>' in the
script.

git clone https://github.com/nwdigitalradio/n7nix
cd n7nix/deviation/
./measure_deviate.sh -f 1000 -c din6 -l 180






--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
   


Re: Where did the modulation go . . .

Basil Gunn
 

On Mon, 28 Nov 2016 13:40:30 -0800
ab9ca@arrl.net wrote:


The new tone generation script does not work. I get the following:

pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180

./measure_deviate.sh: line 5: syntax error near unexpected token
`newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'
You are not running the script. There is no `<!DOCTYPE html>' in the
script.

git clone https://github.com/nwdigitalradio/n7nix
cd n7nix/deviation/
./measure_deviate.sh -f 1000 -c din6 -l 180


Re: Where did the modulation go . . .

Stuart Longland VK4MSL
 

On 29/11/16 07:40, ab9ca@arrl.net wrote:
pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180

./measure_deviate.sh: line 5: syntax error near unexpected token `newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'
You've downloaded a HTML file and you're trying to execute it as if it
were a shell script. As the script in question lacks the initial #!
characters to tell the shell what program is supposed to execute the
script, it tries to "execute" the HTML directly.

HTML is not valid Bourne shell syntax.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.


Re: Where did the modulation go . . .

ab9ca@...
 


OK, you are speaking a language I do not understand. I don't know what BCM is nor where to find it. I don't know what pinout.xyz is nor where to find it. Maybe if we use the 40 pin header we can both recognize which pin we are talking about?


So far as I know there is nothing else running on the RPi.  But I can no longer recall how to display what is running. Years ago I ran Linux full time. But have forgotten much of it. 


The new tone generation script does not work. I get the following:

..........................

pi@compass:~ $ ./measure_deviate.sh -f 1000 -c din6 -l 180

./measure_deviate.sh: line 5: syntax error near unexpected token `newline'

./measure_deviate.sh: line 5: `<!DOCTYPE html>'

..........................................

However I still have the old script that does work, AFAIK. I renamed it 'generate_tone.sh'. The following command should generate 1000 cycle tone for 3 min:

................................. 
pi@compass:~ $ ./generate_tone.sh 1000 10
Found existing wav file: 1000hzsin.wav
If using devcal from Svxlink make sure devcal line has -f1000
Using PTT GPIO 23 with tone of 1000 Hz
Playing WAVE '1000hzsin.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
Hardware PCM card 0 'udrc' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 24000
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 1572864000
  appl_ptr     : 0
  hw_ptr       : 0
##################################################+| MAX^C
...............................................

While this command is running I see the following on these pins of the 40 pin header:

pin 3 - a DC voltage of about 3.4v, no waveform
pin 5 - a DC voltage of about 3.4v, no waveform
pin 7 - nothing, no DC nor waveform
pin 12 - apprx 3.4v rectangular wave at approx 3 MHz

pin 35 - rectangular wave approx 3.4v approx 48 kHz

pin 38 -  nothing

pin 40 - a pulse width modulated 3.4 v rectangular waveform


This command should cause the RPi to generate a 1000 Hz tone and send it to din 6. It does not do so. 

Should there not be the master clock on pin 7? 


I don;t think the I2C is used by this script so I can understand no activity on pins 2 and 3.


What next?


73, dave

ab9ca/4



Re: UDRC-II holding PTT on during reboot

Paul Johnson
 

Interesting. I did a reboot on both my RPi 2 and RPi 3, both with
UDRC-I, and I did not see the PTT line activity you are describing.
Something different about the UDRC-II ???

Paul VE7DHM

On Sun, 2016-11-27 at 15:30 -0800, VK3IL wrote:
Hi,

I'm making good progress getting a mobile APRS
tracker/digipeater/iGate going using RPi 3 and UDRC-II with 2 radios.
I have hit a minor problem that I'd like to solve if possible. I find
that when I reboot the pi, that the GPIO12 PTT line is activated and
remains activated through the reboot process until I get Direwolf
running again. This can leave a carrier on air for a significant
length of time which is not ideal. I assume this is something to do
with the way the GPIO states default on a reboot. At present, I've
used "gpio -g mode 12 out; gpio -g write 12 0" early in the boot
sequence to minimise the time it's on, but not sure how to fix
properly. This problem also exists if I do a shutdown and I have to
power off the radio to stop the carrier which is obviously a concern.
Reboot and shutdown should be infrequent, but I'd obviously rather not
have a carrier on air by accident.


73

David


VK3IL

4861 - 4880 of 5976