Much appreciated. No rush as I'm a few months off implementing this feature. Thank you for your assistance.

I implemented this on a simple connected packet TNC hat I made but with no real plans to use it. I think it held responses in a a que and then let them go once TX INHIBIT was cleared. However, I don't remember what it did to the CBEACON. If I get once I get past our Independence Day July 4th activity, I'll grab a jumper and see what happens.

i discover that in a cbeacon whit dest=id work for that. thanks

开云体育

Ah!? Cool.? Saved.?

So, when this happens again, simply do the restore and reboot?

It will be interesting to compare the values in the backup file, to see if my theory about an illegal volume value is correct.

Thanks!!

Greg? KO6TH

Hi all,
I'm hoping someone can explain how direwolf reacts to the TX inhibit input.
When it is active the function clear (i.e no transmissions can occur) but I can't find anything in the manual that explains exactly what happens when the pin goes inactive.
As an example, if I am use direwolf as a APRS tracker configured to every 10 mins and I activate TX INHIBIT at the 9 min mark, I understand that the 10 min beacon will not be transmitted.
What happens if I then deactivate TX INHIBIT at the 11 min mark? Will direwolf immediately transmit the 10 min beacon that was missed, or will it wait until the 20 min mark?
Regards,

Ian
VK1IAN

In terminal, to save the current audio file settings as a file use..
"sudo alsactl --file /home/pi/alsa.backup store"

To restore...
"sudo alsactl --file /home/pi/alsa.backup restore"

If you don't need the file and just need to store and restore on the system..

"sudo alsactl store"
"sudo alsactl restore"

开云体育

Hi Michael, and anyone else who might be following this...

I've rebuilt the cable that goes between the audio dongle and the radio for better shielding, which I should have done in any event.? Very annoying, but it seems to work.? I opted not to mess with adding a DC blocking cap, at least not yet, as an RF pass-through problem wouldn't be stopped by them, and the radio's input doesn't seem to mind the 2.5v bias coming in.? Also, a cap could alter the frequency response, possibly requiring more tweaking.? But now, of course, by re-doing the cable, the problem has gone away.? :)

I still don't know how to recover a "blown" SD card - the specific condition where a reboot doesn't restore the speaker output from the Pi - other than re-imaging the SD card.? If I am at an event where I'm depending on this system for Winlink or such, my thought is to have a spare SD card on hand, boot from that, and while it's running, copy its (running) self to the failed one, so that I can continue using the system with minimal downtime.? Better would be to copy the spare's audio system settings to the running one and reboot, but I still can't find where they are stored.? {sigh}

Thanks to all for their help,

Greg? KO6TH

aprs.fi can show the comment, lastt status and last beacon. The text of last beacon... how set in direwolf? i try differents solutions in the beaconing lines, but i can?t set this field. the status i see that is posible with info=">status", but the text of last beacon? Thanks and sorry for my english.

Some caps may help. But if it's that sensitive, it may be better to try a different sound card chipset. I'd try the CM108. They seem far less problematic with RF.


I honestly don't think that shielding will make much of a difference. Or the caps. But it doesn't hurt to try. I'll bet if you tried the CM108 chipset you'd have much better luck than the odd TRRS dongle. Another option is figuring out a way to disable the ability to change the volume.?

Michael - NA7Q wrote:

Interesting. I don't know what chipset is in that dongle. Many
chipsets have volume switches that are built into the audio lines.
When grounded, they trigger the switch to go down or up. It sounds
like you may have triggered this switch by the grounding when you're
transmitting. I had this issue on a USB sound card a while back when I
was playing with a CM108. Which is one USB card that has played better
with RF than any other.
What does your wiring look like?

Yeah, this is looking more and more like the issue. The wiring is
simply a pin-to-pin connection, speaker to mike, and mike to speaker.
Common ground for everything. It's definitely triggered by RFI, since
transmitting into a dummy load, or into an antenna some distance away,
will run just fine. I can notice the volume control move with even a
single packet, when the antenna (twin-lead J-pole) is in the shack.

So how is the volume actually controlled? The wiring is sort of
shielded, but not very well. Do I need to isolate the Pi and radio with
some in-line DC-blocking caps, or does it need a complete isolation
transformer? I'm guessing it's the mike input to the USB dongle where
this is happening, as that's the not-so-shielded wire. The TRRS pinout
is frankly bizarre. Might try to squeeze a cap in there, at the dongle end.

I'm guessing that somewhere in the /var/run/udev files is where the
volume controls are kept. Based on the rsync tests, those are the only
files that seem to change across test runs.

Thanks,

Greg KO6TH

Interesting. I don't know what chipset is in that dongle. Many chipsets have volume switches that are built into the audio lines. When grounded, they trigger the switch to go down or up. It sounds like you may have triggered this switch by the grounding when you're transmitting. I had this issue on a USB sound card a while back when I was playing with a CM108. Which is one USB card that has played better with RF than any other.
What does your wiring look like??

开云体育

Hello Robert and al.

Yes, more than I needed to get going. Problem has been solved - hopefully - but this is what I did.

Step 1: on PC1 make Direwolf beacon every 5 seconds. Make a line connection from the output of a separate USB sound card to another PC2's sound in and run Direwolf there --> OK, so Direwolf works on both sides.

Step 2: on PC1 Direwolf beacons via a separate USB soundcard, sound output goes directly into the ACC2 sound input of the TS-2000. PC2 can decode successfully --> the TS-2000's internal audio path works with 9600 baud signals.

Step 3: on PC1 Direwolf beacons via the TS-2000, using the USB sound card built into the home brew ACC2 interface (handles audio in/out and PTT). PC2 cannot decode signals, although it sees them. On the SDR's waterfall signals look off. --> ??

Step 4: same as step 3, but now using 1200 instead of 9600 baud. PC2 decodes signals successfully --> the signal path works, but not for 9600 baud audio signals.

Step 5: same as step 3, but with a different USB sound card. PC2 cannot decode. --> the USB sound card is not the culprit.

Step 6: bypass the audio isolation transformer that is in between ACC2's audio out and USB sound card's audio in. PC2 can decode 9600 baud signals successfully --> the transformer mangles the 9600 signal into something undecodable.

Solution: take out the isolation transformer and use a direct connection between the USB sound card and ACC2 audio in.

It's funny, because I've been using these audio isolation transformers (Atech ATS-131) for the last eight years without any problems. I've got a dozen or so from an old commercial modem. Even in my last setup with an IC-820H I used them and transmitting 9600 baud signals was no problem at all. So the combo of this transformer with the TS-2000's ACC2 audio in is creating trouble. ACC2 audio out is no problem, because that path also has one of those ATS-131 transformers in it. So for now I use a direct connections until I can find some other isolation transformers.

Happy happy, problem solved and I've learned a lot of new stuff about Direwolf, too. In an hour I have Falconsat-3 floating by which means the first real-world test. With 1200 baud working fine I can also digipeat via the ISS and NO-84, so more fun to be had.

Thanks all. See you around.

Hans

BX2ABT.com

Sounds like you got what you need to get things going.

Good luck!

Robert Giuliano
KB8RCO

On Wednesday, June 30, 2021, 9:56:27 AM EDT, Hans Fong <hans@...> wrote:

Hello Rob. This is exactly what I was looking for. Got it working/beaconing, so now I can start testing my signal chain. A friend hinted that the audio signal input of the TS-2000 needs to be very high, so I'm going to start there. Cheers --Hans

开云体育

Greg, I have had the same issue, only rebooting always fixed it. However I have had A LOT more issues with Direwolf, and sound cards in general with Buster. I'd suggest going back to Jessie or Stretch. I prefer Jessie on my Pi's but sometimes I do use Stretch. Both are still far more reliable than Buster in my opinion. I'd suggest you try that, and then report back.?

If possible, find a sound card hat as well. That'll resolve the issues completely.

Thanks for the suggestion, but I need to stay with Buster.? The issue isn't with Direwolf, but with wsjtx.? The Pi is my overall "Radio Event Pi", which I use for anything ham-related that's not in the shack or car - I have other Pis (pies?) for those.? So, APRS, Packet radio / Winlink, SSTV, FLDIGI, etc.? It actually was on Stretch up through Winter Field Day, where I ran JS8Call on it.? For this past weekend with both the event and Field Day going in parallel, I thought I could use the setup for a few FD points between runners.? I noticed that wsjtx was back on version 1.1, which isn't compatible with the version 2.x that everyone is using now, and the current version 2.4 won't load on Stretch due to a bunch of incompatible library versions.? 2.4 loads fine on Buster, however.? (I didn't make any FD contacts, due to other issues.)

All that said, some progress!

One of the members of our local club suggested using rsync to essentially do a "diff" on the file system, to see what changed.? In running the tests, I had my HT on, monitoring the frequency, and noticed that when the failure occurred, the *volume* of the signal didn't simply stop, it *faded* to zero.? It seems that something is causing the "headphone" volume to plummet on transmit.? So, keeping the volume controls window open, I can see it move with each transmission.? Sometimes a little, sometimes it just dives to the bottom.? If I catch it in time, I can slide it back up and things progress.? If it craters, I'm guessing I'm hitting a bug where the volume set to an illegal value (hits zero and continues past?), and that bad value is remembered on reboot which prevents further use.? Not sure what file the volume settings are in...? Anyone?

So, is there a plausible mechanism where the volume control of the headphone is controlled by Direwolf somewhere?? Was this ever an intended "automation feature"?? Is there a way to lock the volume level in the system somewhere?

Or (perhaps more likely?), is there a mechanism in the USB Audio dongle where I'm somehow triggering the volume "controls", sort of like with Bluetooth headsets that have volume up and down buttons on them?? The USB dongle is this one:? but I see nothing in the description about volume buttons.? As noted in the first post, I'm connecting pin to pin speaker out to radio Tx and mike to radio Rx, via the annoyingly-wired TRRS plug.? PTT is on a different input to the rig (not shared with the mike in), and is controlled by a GPIO pin and an NPN transistor buffer.

Thanks!

Greg? KO6TH

I always setup my installs using Audacity to fine tune the receiver audio. I usually adjust it with an open squelch then put it around the 0.60-0.75 mark on the Audacity level. 1.0 is maximum and of couse I never get anywhere near that. I do this to check for any audio issues, like potentional noise, or just too much audio on the line.

Getting to my point. I have done this on a Pi Zero W running Jessie and the latest compiled Direwolf beta build. I'm using a custom built HAT sound card, similar to the Fe-Pi.?
I get audio reports that range from 100 to 150. With parenthesis markings ranging from 20 to 40. So a station might be a 128 (35/20). Performance seems to be fine.

So I'm wondering if this audio level is being all out of whack because of an older version of Jessie that I used, which typically I use an older version, or Stretch. But it's what I had on hand. Any ideas??

Greg, I have had the same issue, only rebooting always fixed it. However I have had A LOT more issues with Direwolf, and sound cards in general with Buster. I'd suggest going back to Jessie or Stretch. I prefer Jessie on my Pi's but sometimes I do use Stretch. Both are still far more reliable than Buster in my opinion. I'd suggest you try that, and then report back.?

If possible, find a sound card hat as well. That'll resolve the issues completely.?

Skyler, you are spot on. Allstar has no problems with the same setup. Literally swapping SD cards and not moving anything, Direwolf will stop working after a while with the USB sound card. Whereas Allstar never will. I don't know why Direwolf is like this. I've never successfully gotten USB sound cards to work with Direwolf without having to reboot it from minutes, hours, or sometimes a day after starting it.?

This is why I ONLY use HAT sound cards, like Fe-Pi, and now my soon to be released sound card HAT that's similar to the Fe-Pi. HATs have never given me issue. So that's what I suggest anyone do is use HATs where possible. Fe-Pi sound cards are no longer made, so that's unfortunate.?

I installed Direwolf as shown below and I’m seeing packets, but Direwolf says ERROR - Could not open config file direwolf.conf It’s in the same folder as the application

When I tried to Start the Winlink Session it says *** Unable to open TCP

Details are below

73 Brian K7BLS

I’m using MacBook, Big Sur Parallels Windows 10 Winlink Express 1.5.37.0 DINAH with minidin 6 to Kenwood TM-V71 Direwolf-1.7.0

In the WinLink Packet Winlink session the Setup is TNC Type KISS Packet TNC Model - NORMAL Serial Port - TCP TCP Host/Port 127.0.0.1 8100 Packet sound modem - direwolf-1.7.0fa91dd_i686\direwolf

When I open the Winlink Session it says

*** Starting WL2K packet session... *** Launching C:\RMS Express\direwolf-1.7.0-7fa91dd_i686\direwolf *** Soundcard modem is running. *** Initializing KISS over TCP Host 127.0.0.1 Port 8100 *** Initialization complete *** Ready

Direwolf is seeing packets (NOTE: Im on an APRS frequency so I can see packets)

Dire Wolf DEVELOPMENT version 1.7 A (Mar 15 2021) Includes optional support for: cm108-ptt Warning: Could not open 'symbols-new.txt'. The "new" overlayed character information will not be available. ERROR - Could not open config file direwolf.conf Try using -c command line option for alternate location. Available audio input devices for receive (=selected): 0: Microphone (USB Audio Device) 1: Microphone (High Definition Aud Available audio output devices for transmit (=selected): 0: Speakers (USB Audio Device) 1: Speakers (High Definition Audio Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate. Note: PTT not configured for channel 0. (Ignore this if using VOX.) Ready to accept KISS TCP client application 0 on port 8001 ... Ready to accept AGW client application 0 on port 8000 ...

Digipeater WIDE1 (probably WY7W) audio level = 196(57/33) [NONE] __||: Audio input level is too high. Reduce so most stations are around 50. [0.5] VE7XPL-9>T8RTWZ,VE7SLC-7,WY7W,WIDE1*,WIDE2-1:32Ll6J>/"4b}Keep Exploring!_$<0x0d> MIC-E, CAR, Yaesu FT1D, In Service N 48 24.7000, W 123 22.4800, 4 km/h (2 MPH), course 246, alt 75 m (246 ft) Keep Exploring!

When I try to Start the Winlink Session it says *** Starting to call N7NIX-10 *** Opening KISS over TCP Host 127.0.0.1 Port 8100 *** Unable to open TCP