Keyboard Shortcuts
Likes
- Direwolf
- Messages
Search
|
Components to get full TNC?
Would anyone be able to tell me what software (Compass Linux on a Raspberry Pi) would be used with direwolfs KISS TNC port ability to get full TNC command emulation? IE: So I can just connect minicom or telnet to the port and issue commands like I do with a hardware TNC2 on my Kenwood HT & D710ga?
I saw this once in a forum.. something like pilinbpq or something stood up the full TNC, but I am having trouble finding it. Anyone using direwolf with othersoftware to get a full TNC2? Nick |
|
Re: Bluetooth SPP w/ APRSDroid
On 09/03/2017 19:42, mike_ph4@... [direwolf_packet] wrote:
I've managed to get a very crude hack working to connect APRSDroid and Direwolf on a Pi Zero W. Pi Zero W has built-in WiFi and Bluetooth. Paired my Nexus 7 with the Pi Zero W. Make the Pi discoverable:| $ sudo hciconfig hci0 piscan Then search and pair from the Nexus. | Configure APRSDroid to use connection protocol - Bluetooth TNC. Connection configuration - client mode. Bluetooth channel 22. On the Pi, I use socat to connect the Bluetooth rfcomm0 device that gets created on connection to the kiss tnc service in Direwolf (tcp port 8001). Start direwolf in one terminal window. In another terminal, start the rfcomm service which spawns socat to connect to the kiss tnc in Direwolf: $ sudo rfcomm watch /dev/rfcomm0 22 socat -d -d tcp4:127.0.0.1:8001 /dev/rfcomm0 Now try and send some beacons from APRSDroid. You should see incoming connections in the rfcomm terminal window, then a "Connected to KISS client" message in Direwolf followed by a beacon. TX appears to work, I'll see if I can verify RX when I get time... 73 Nick. |
|
Re: Raspberry Pi Zero VERY long transmit delay
David Ranch
开云体育Hello Arnold, ? Yes, or connect up the HDMI display with a USB keyboard. --David KI6ZHD |
|
Re: Raspberry Pi Zero VERY long transmit delay
David, "When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running? ?" How would I know??? ?I suppose I could connect to the serial port for a terminal. ?Would that give you the answer? Arnold From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Sunday, March 12, 2017 8:32:20 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running?? --David |
|
Re: Raspberry Pi Zero VERY long transmit delay
David Ranch
开云体育Hey Arnold,
When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running?? --David |
|
Re: Raspberry Pi Zero VERY long transmit delay
Somehow I missed putting this in the email. ?It IS in the DireWolf configuration. ADEVICE plughw:1,0
I DO have PulseAudio removed. ?I don't think it is included in the latest Raspberry Pi Jessie OS, but I went through the steps anyway. Off the wall thought, it is possible that without any Ethernet device in the Pi Zero that something is looking for it, and kills things? ?That seems to be a common thread in my troubleshooting. ?If I have some sort of Ethernet or WiFi connected or not, nothing fails. ?When I don't have something, then I get this failure. ?However, there are other changes going on, so I haven't convinced myself about this. ?I just thought I'd toss that wild thought out. Running the "Top Command" in another window is an issue in itself. ?I'm trying to run this without any external connection to anything. ?If I do have this connected, then only about 20% of the processor time is used, but I have no idea when I start having issues. Arnold KQ6DI From: "wb2osz@... [direwolf_packet]" <direwolf_packet@...> To: "direwolf packet" Sent: Sunday, March 12, 2017 3:33:36 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay Usually you would have something like "ADEVICE?plughw:1,0" when running on the Raspberry Pi. ?I don't see ADEVICE in there which would result in using the "default" device. Did you make sure that PulseAudio was removed? ?In my experience PulseAudio never worked right on the RPi and my recommendation is to remove it. ? (Note: ?It is fine on larger x86 based systems.) ?? ?Currently section 1.3. The other thing I would try is running the "top" command in another window? ?What is using a significant amount of CPU time? ?How much idle time is left over? |
|
Re: Raspberry Pi Zero VERY long transmit delay
Usually you would have something like "ADEVICE?plughw:1,0" when running on the Raspberry Pi. ?I don't see ADEVICE in there which would result in using the "default" device. Did you make sure that PulseAudio was removed? ?In my experience PulseAudio never worked right on the RPi and my recommendation is to remove it. ? (Note: ?It is fine on larger x86 based systems.) ?? ?Currently section 1.3. The other thing I would try is running the "top" command in another window? ?What is using a significant amount of CPU time? ?How much idle time is left over? |
|
Re: Raspberry Pi Zero VERY long transmit delay
David, I should have provided you with the DireWolf configuration. ?The following is the configuration I have for this Zero. ?Anything not included is commented out. ?These are the only active parameters. Arnold KQ6DI
MODEM 1200
# Beacon for Pi Zero # Send Telemetry #This should only digipeat WIDE1-1 #Digipeat parameters & filter to desired stations From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Saturday, March 11, 2017 3:44:27 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
|
|
Re: Raspberry Pi Zero VERY long transmit delay
David, Correct, I am not using any Linux AX.25 Stack. ?I am also not including any HamLib support in the DireWolf build. The Hub I am using (that works) could have an external supply, but it wasn't included and wasn't specified, so I don't have one there. I don't have any?PERSISTANCE or TXDELAY parameters set, I'm just using the default. The odd part here is the transmitter keys up with no audio, so the channel is or should be clear. ?Even if it was hearing itself, no audio out of the sound card doesn't have much modulation for Persistance to wait for. If you provide more details on what you would like for Telemetry, I'd be glad to try. ?I'm just not sure what I should set, and how... ?Other telemetry is not an issue for me, just don't know what goes here. I did find another USB hub (not powered) and a micro to mini USB adapter that should permit it to work in the Zero. ?Since the long delay isn't always present, I like to run one test long enough that I have a positive result (yes or no) for each configuration. At least I have a configuration that works now, even if it isn't ideal. ?So we'll figure it out. Arnold KQ6D From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Saturday, March 11, 2017 3:44:27 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
|
|
Re: Raspberry Pi Zero VERY long transmit delay
David Ranch
开云体育Hello Arnold, There have been random reports about these delays and I've seen it too.? I didn't correlate it to being related to having a USB hub in front of the sound device but that's weird.? In the Direwolf docs, it's actually recommended to directly attach the USB sound card to avoid USB hub arbitration issues but Raspbian has changed a *LOT* in the last two years. With your testing, does your USB hub support external power supplies?? I've found this is almost always required when you either have a Wifi dongle or multiple devices connected to it.? I highly highly doubt that these delays are coming from the Rpi hardware, the USB sound hardware, or even the OS.? They have to be coming from Direwolf itself.? I believe you're doing all your packet work within Direwolf itself and not using the Linux AX.25 stack right?? Looking into this a little (guessing really), I wonder if this comes from say the PERSISTANCE or TXDELAY parameters: -- 6. Persistence The P and SlotTime parameters are used to implement true p-persistent CSMA. This works as follows: Whenever the host queues data for transmission, the TNC begins monitoring the carrier detect signal from the modem. It waits indefinitely for this signal to go inactive. When the channel clears, the TNC generates a random number between 0 and 1. [2] If this number is less than or equal to the parameter p, the TNC keys the transmitter, waits .01 * TXDELAY seconds, and transmits all queued frames. The TNC then unkeys the transmitter and goes back to the idle state. If the random number is greater than p, the TNC delays .01 * SlotTime seconds and repeats the procedure beginning with the sampling of the carrier detect signal. (If the carrier detect signal has gone active in the meantime, the TNC again waits for it to clear before continuing). Note that p = 1 means "transmit as soon as the channel clears"; in this case the p-persistence algorithm degenerates into the 1-persistent CSMA generally used by conventional AX.25 TNCs. -- The real next step would be to add telemetry to your logs with detailed timestamps to see when the radio is getting keyed up vs. when audio is started, etc.? Looking at the direwolf code: ?? - in the audio.c file, there is the audio_flush routine which has various commented out debug lines that could be enabled (remove the # characters) ?? - in the ptt.c file, there is the much nicer "ptt_debug_level" variable and if you set this to 1 or 2 and recompile, you'll get more details You might try fiddling around with some of these items, recompile Direwolf, and see what you get in the logs.?? Let us know what you find! --David KI6ZHD |
|
Re: Raspberry Pi Zero VERY long transmit delay - more
So I put the micro USB hub #2992 back in Without the WiFi USB thing, and my problem went away. ?However that USB Hub does have an ethernet port, although nothing is attached... ?Just the Sound USB thing. The Sound device is Syba. ?I know it's not recommended to run on a hub, but that's the only way this works??? I don't think I have any more micro-USB hubs or anything else, so I've run out of things to try. ?At least I'm narrowing it down. Arnold KQ6DI From: "kq6di@... [direwolf_packet]" To: "direwolf packet" Sent: Saturday, March 11, 2017 10:52:57 AM Subject: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay I asked this question before and didn't get any answer, so now I've done more testing and have a major clue. I have a Raspberry Pi Zero running DireWolf that has a very long transmit delay. ?First, I do have all of the Pi OS updated to the latest and greatest. ?It has done this with BOTH DireWolf versions 1.3 AND 1.4. What I see (and hear on the radio) is the transmitter is turned on with total silence transmitted for up to 8 seconds or so, then the packet burst and the transmitter gets turned off. ?Sometimes there is no delay, and quite often it is 5 seconds or more. I had no problems when my sound USB device AND a wireless Ethernet were plugged into a USB Hub w/ Ethernet Hub. When I removed that hub and all internet access, my problems begin again. ?I now have the sound device plugged into the Pi Zero through a 4" micro USB to USB adapter cable. ?Then the problem begins. I have tried other USB sound devices with the same results. I'm going to try putting the USB hub back in without the wireless USB device and see what happens, but it has a wired Ethernet port on it (but nothing plugged into that port). Any hints on why the Pi Zero seems to need the USB hub w/ internet to function properly with DireWolf? Since the Pi Zero in stand-alone digipeater configuration only requires 80 mA from my 12V supply (Yes, regulated down), this is perfect for the battery & solar portable digipeater... ?if it worked. Thanks, Arnold KQ6DI-4 |
|
Raspberry Pi Zero VERY long transmit delay
I asked this question before and didn't get any answer, so now I've done more testing and have a major clue. I have a Raspberry Pi Zero running DireWolf that has a very long transmit delay. ?First, I do have all of the Pi OS updated to the latest and greatest. ?It has done this with BOTH DireWolf versions 1.3 AND 1.4. What I see (and hear on the radio) is the transmitter is turned on with total silence transmitted for up to 8 seconds or so, then the packet burst and the transmitter gets turned off. ?Sometimes there is no delay, and quite often it is 5 seconds or more. I had no problems when my sound USB device AND a wireless Ethernet were plugged into a USB Hub w/ Ethernet Hub. When I removed that hub and all internet access, my problems begin again. ?I now have the sound device plugged into the Pi Zero through a 4" micro USB to USB adapter cable. ?Then the problem begins. I have tried other USB sound devices with the same results. I'm going to try putting the USB hub back in without the wireless USB device and see what happens, but it has a wired Ethernet port on it (but nothing plugged into that port). Any hints on why the Pi Zero seems to need the USB hub w/ internet to function properly with DireWolf? Since the Pi Zero in stand-alone digipeater configuration only requires 80 mA from my 12V supply (Yes, regulated down), this is perfect for the battery & solar portable digipeater... ?if it worked. Thanks, Arnold KQ6DI-4 |
|
Re: dw 1.3: "gps must be configured to use tbeacon"
David Ranch
开云体育Hello Shimniok (no call given), ? I assume you've configured a Tracker beacon (tbeacon) in your direwolf.conf and also configured the use of your GPS using either the GPSNEMA or GPSD keywords.
Looking at the older Direwolf 1.2 Raspberry-Pi-APRS-Tracker.pdf documentation, this GPS support is via gpsd method ONLY.? Unfortunately, it seems the TBEACON there assumes that things just work vs. modern version of Direwolf requires that you specify which GPS method you want to use (GPSNEMA - aka direct serial support or GPSD via the daemon) in the direwolf.conf file.? This is obviously a change in behavior from a configuration point of view but I don' think this is a big deal.
Please update your direwolf.conf to reflect how you want to use your GPS and let us know how it goes. --David KI6ZHD |
|
dw 1.3: "gps must be configured to use tbeacon"
I'm running into a TBEACON error on RPi / direwolf 1.3.?I searched github issues, googled, and searched yahoo groups -- to no avail. I figured I'd ask if anyone's seen this... On RPi 2, newly dist-upgraded Debian Jessie, using a USB GPS and gpsd set up as instructed,?direwolf 1.3 (rebuilt for gpsd as instructed)?issues this error upon startup: Config file, line 58: GPS must be configured to use TBEACON But on direwolf-1.2 -- using the very same config file -- no such error and, in fact, the older version happily beacons the gps-provided position as instructed by the TBEACON statement. Q: Is anyone else running direwolf 1.3 on a Raspberry Pi? Are you seeing the same error or not? I haven't dug into the source code to any great extent yet, but the code generating this error message doesn't exist in 1.2. I've eliminated gpsd as the problem -- direwolf 1.2 works fine along with?cgps -s?and gpsmon commands.
|
|
Re: Audio input device 0 error: Input/output error
David Ranch
开云体育Hello John, If things are working for an hour or so and then things start to break down, I would begin to suspect: ?? - RFI from your radio getting back into the soundcard and/or Rpi and confusing/corrupting it ????? - Try disconnecting the PTT line from the radio and make it a purely RX setup.? See if that makes your Direwolf setup run longer.? Say all day, etc. ????? - If this helps, make sure you have the audio lines using decoupling caps, the polarity of the lines are correct, wrap ferrite chokes on both sides of all audio cables.? More turns per side, the better (within reason) ?? - Do you have any other software running that is trying to use the soundcard:? mixers, pavucontrol, etc? ?? - You might have a poor/weak power supply for the Rpi.? You should ideally be running a 5.1volt (not 5.0 but 5.1V) 2A or better supply.? ???? ?? - You might have a marginal hardware be it the sound device or Rpi.? Could be say heat could be building up and making it fault (do you see other OS errors in /var/log/syslog?)? What kind of airflow does the Rpi have through it's case? Ps.? I see that you're using Audio device 0 here meaning that you disabled or swapped the built-in sound device to be "audio device 1".? I generally leave the built-in soundcard in place and set as the default audio device.? I then let the USB sound device for packet to be device 1.? This seems to avoid misconfiguration issues, etc. --David KI6ZHD On 03/08/2017 07:37 AM, John Spoonhower
jpspoonhower@... [direwolf_packet] wrote:
? |
|
Re: Audio input device 0 error: Input/output error
David, sorry for the delay. Just to be sure I checked the patch level of Jessie: ?apt-get update ??? apt-get upgrade ??? apt-get dist-upgrade ??? rpi-update ??? reboot. ?still see the same error after an hour or so of clean operation. The sound devices are directly connected ...no USB hub. 73, NX2I, John "Insanity: Doing the same thing over and over again and expecting different results" - Albert Einstein On Fri, Mar 3, 2017 at 1:05 AM, David Ranch dranch@... [direwolf_packet] <direwolf_packet@yahoogroups.
|
|
Re: Serial PTT not functioning after exit
开云体育On 05/03/2017 19:48, wb2osz@...
[direwolf_packet] wrote:
? Just pulled and rebuilt from dev branch. That works for me (user is a gpio group member). Thanks! |
Nick G4IRX