This road gave me a run for my money with its unstable and rough surface in places, tight curves, blind corners, steep hills, and frequent fast descents into hairpins. I had to walk down some hills because I was fearful of wiping out.
Not so much crazy as why exactly would you need to cool a feedline or matching balun? Have you got an extraordinary mismatch? Shouldn't your RF be radiating instead of making heat? And the same comment for running a fan! Fairly extraordinary situation you have there, Neil.
The issue is that the radiation resistance is around 5 ohms, so I need to step the impedance down a ton to get a match. The loading coil between the matching transformer to get this 6m dipole down to the 10m band is what's overheating because of all the resulting current. :(
You're talking about a trap dipole which will require capacitors to fit up the impedances. A fan dipole is easier and will work the first time. Just wind up your excess length on the loading coils.
Well, even 10 gauge wire wasn't enough to prevent the 10m match from overheating when transmitting at 100W. Darn low radiation resistance. Guess it's time to graduate to copper tubing since magnet wire is hard to find in larger gauges. 👀 #AmateurRadio #HamRadio
Pretty sure the mountain of garbage code that #LLMs are spitting out is going to eventually result in a scramble like pre-Y2K to fix bugs and other issues before things truly spiral out of control. :/ #AI
Keep them in case you ever need to make your antenna longer again! I have a few old food jars repurposed for this, labeled with what antenna they came off of. #HamRadioShitPost
(No but seriously, I do have some 6"-10" pieces of "LMR400-like" coax bouncing around in my toolbox, despite never having any reasonable use of them.)
@va3wft This! I mean, why do you think they call them antenna farms?
Do make sure to plant them at least 1/2λ apart, or they'll crowd out and grow too short. If you're lucky, they're usable on a higher band, but it's just not the same.
Australia's solar waste investigation raises an interesting question of consistency. Where is the inquiry into mandatory 100% recycling of fossil fuel waste streams?
Can't get #DireWolf to actually transmit the packet audio burst via my FT-991a. I have this config setting:
ADEVICE plughw:CODEC,0
Which corresponds to these devices:
VID PID Product Sound ADEVICE ADEVICE HID [ptt]
--- --- ------- ----- ------- ------- ---------
08bb 29b3 USB Audio CODEC /dev/snd/controlC0 /dev/hidraw0
08bb 29b3 USB Audio CODEC /dev/snd/pcmC0D0c plughw:0,0 plughw:CODEC,0 /dev/hidraw0
08bb 29b3 USB Audio CODEC /dev/snd/pcmC0D0p plughw:0,0 plughw:CODEC,0 /dev/hidraw0
Bus 001 Device 017: ID 08bb:29b3 Texas Instruments PCM2903B Audio CODEC
I'm listening in on 144.390 MHz on my handheld while my FT-991a is transmitting, but all I get is the transmission starting and ending with no audio inside it. Any suggestions?
Anyone know why #DireWolf is hellbent on using /dev/ttyS0 with hamlib? I have this in direwolf.conf, which should force it to use /dev/ttyUSB1:
PTT RIG 1035 /dev/ttyUSB1 38400
But it refuses:
Dire Wolf version 1.7
Includes optional support for: gpsd hamlib cm108-ptt
Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:0,0 (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate.
Hamlib determined CAT control serial port rate of 38400.
User configuration overriding hamlib CAT control speed to 38400.
Retrying Hamlib Rig open...
Retrying Hamlib Rig open...
^C
QRT
Hamlib Error: rig_set_ptt command for channel 0 PTT
rig.c(947):rig_open entered
rig_settings_get_path: path=.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=0
serial_open: /dev/ttyS0
serial_open(335): open failed#1 No such file or directory
serial_open: Unable to open /dev/ttyS0 - No such file or directory
port_open: serial_open(/dev/ttyS0) status=-6, err=No such file or directory
rig.c(1178):rig_open returning2(-6) IO error
rig.c(947):rig_open entered
rig_settings_get_path: path=.config/hamlib_settings
rig_open: async_data_enable=0, async_data_supported=0
serial_open: /dev/ttyS0
serial_open(335): open failed#1 No such file or directory
serial_open: Unable to open /dev/ttyS0 - No such file or directory
port_open: serial_open(/dev/ttyS0) status=-6, err=No such file or directory
rig.c(1178):rig_open returning2(-6) IO error
rig_set_ptt: rig or rig->caps is null
Invalid parameter
?WATCH={"enable":false,"json":false};
If I make /dev/ttyS0 a symlink to /dev/ttyUSB1, it works flawlessly. What gives? :/
I've not run into this in the past, but not currently running direwolf this way either.
I've got direwolf set up with rigctld to handle the radio control, so direwolf just gets: `PTT RIG 2 localhost:4533` (note that's not the standard rigctld port)
Glad you can make it work that way -- I'm not saying it's the right choice, but it makes a lot of things easier.
I'm sure others involved with #FARPN @farpn might have a guess about your original issue. We've also been able to get `udev` to assign names to the serial ports for radios (like /dev/ic706 instead of /dev/ttyUSBS0), which can help with the issue of inconsistent serial port device names.
Alex KR1ST/PA1ST
in reply to Neil E. Hodges • • •