开云体育

I'm seeing an odd problem, but it might be difficult to describe. I have a Raspberry Pi Zero running the latest software and DireWolf 1.4.E. But it has also done this with version 1.3. I am running

As far as it concerns permissions, everything seems to be fine. Something else is grabbing your serial port as soon as direwolf exits. After stopping direwolf, try: $ lsof | grep PTT and $ lsof | grep

Hi David, thanks for your reply. I've been exploring the sudo issue for a few days now and here's what I've found. - Works perfectly on the default pi user on Rpi. This is because pi is set up for

Hello all, I've been using DireWolf for quite some time now and I'm really happy with it. The decoding performance is amazing and the program is pretty stable. Uptime without restart at all before the

As for GPIO access, the running user needs to be apart of the "gpio" group. Quick example is: -- b. Add this new user into the following unix groups: - "audio" (allow users to access the soundcard) -

Thanks for the reply, here is the results: kd9dcs@bluetracker:/dev $ ls -al /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Feb 27 15:26 /dev/ttyUSB0 as an added bonus here is the udev rule I wrote to

OK lets see the permissions of ttyUSB0 $ ls -al /dev/ttyUSB0 [direwolf_packet] wrote:

This is exactly what I did (with it's own callsign). I guess I was hoping that DireWolf would add itself into the list where it wouldn't repeat that exact same packet for the 30 seconds. (Can't think

Hi Arnold, I had the same issue on my digipeater (still in test on a CHIP).I got a solution with this filter : FILTER 0 0 ! b/F1EVM You need to change F1EVM by the callsign of the digipeater. Best

Hope you don't mind if I join in with this Tim as I'm watching this with interest. I have similar problems trying to get GPIO PTT and DCD working with the correct permissions. Despite being able to

John, I have run into a similar error. What I found was that the Raspberry Pi processor couldn't keep up with the audio demands at the higher USB speeds. This resulted in dropped USB packets that

I'm always game for learning more, thanks for diving in with some help. Here are the results of the commands: kd9dcs@bluetracker:~ $ who kd9dcs :0 2017-02-26 17:51 (:0) kd9dcs pts/0 2017-02-27 05:34

Hello Tim, This is a permission problem and not a direwolf exiting problem. give us the output of the below commands: $ who $ groups $ ls -al /dev/PTT 73 de SV1LJJ [direwolf_packet] wrote:

Good morning guys, Tim (Kd9DBG) with the high school telemetry car project, Here is my current question... How does one "cleanly" shutdown Direwolf? Here is the behavior after launching direwolf on a

Attached is an example. I have another receiver and another computer running DireWolf as well. The receiver only has a small HT antenna so it can only hear what comes out of this digipeater. I thought

My digipeater is hearing its own transmissions, and because it is sending with a path of WIDE1-1, and will digipeat WIDE1-1, it digipeats itself. So how do I make it so it knows it already sent its

IGFILTER works on V1.4 Windows 7 , don't, like i said , V1.4 linux on Ubuntu 14.4

Thanks for the info. I'd like to see if I can get it to work with a Project Fi data-only sim card, which costs a penny per megabyte, with no ongoing monthly charge. It's cheap enough to try it for a

I am currently using APRX to convert DPRS from D-STAR radios to APRS and forward it to APRSIS. Specifically, a program called D-RATS parses the position data from D-STAR radios and presents it to TCP

I am experimenting with setting up a "two-way" IGate on a Raspberry Pi 3 running Jessie. The Direwolf version is the current one, downloaded form GitHub. I keep getting the error show in the subject