@hallo OK!

@hallo OK, also doch .qmail. Ich hatte aus dem Manual den Eindruck, dass die gar nicht gebraucht wird und auch nicht verwendet werden sollte. Wollte darum mit $ uberspace mail forward oe1flp florian@oe1flp.at eine Weiterleitung einrichten, aber das geht dann logischerweise nicht, wenn oe1flp ja bereits eine Mailbox ist.

@hallo 🤦‍♂️🤦‍♂️🤦‍♂️ OK tut mir leid. Die hab ich echt einfach übersehen, weil sie im Dashboard nicht ersichtlich war. Keine Ahnung, warum ich das offenbar bei der Einrichtung des uberspace noch mit .qmail gemacht habe. Jetzt hab ich die .qmail gelöscht, bekomme aber immer noch keine Emails. Die landen scheinbar (nur) in ~/Maildir, aber nicht in meiner Mailbox.

@hallo Ich hab noch mal alles gecheckt und vorsichtshalber bestehende forwards (die sich allesamt nicht auf die fragliche, falsche Gmail-Adresse bezogen) von qmail weg verschoben. Im crontab ist auch kein "MAILTO=[...]". Trotzdem bekomme ich die Emails auf die Gmail-Adresse.🤔

@hallo Woran liegts, dass cron Emails mir an eine Adresse schickt, die eigentlich (inzwischen) nirgendwo in meinem Uberspace hinterlegt sein sollte? Die Adresse ist nicht im Dashboard, und es gibt keine Mail-Weiterleitung auf diese Adresse. Wo kann ich das allenfalls noch einstellen? (betrifft oe1flp@vega)

@ly2ss Thank you! Yes, the VHF/UHF coupler in my meter looks like the first image.

@ly2ss Thank you. Knowing that this (short) at least isn't completely unreasonable, I dug around a bit more and found schematics for the coupler of my meter (Diamond SX-600). There's chassis ground via the T3/T4 coils, so I guess it's alright? What threw me off was that I was getting some unexpected readings, and that the VHF/UHF coupler on the same meter does not have such a short.

A dumb question: On my SWR meter's SO-239 sockets (both the TX and ANT sides), there's an electric short (i.e., no resistance, positive continuity test) between the center and the shield. That should NOT happen, right?

For logging, I use @cloudlog from the day I was licensed. I was looking for self-hosted logging that I can use anywhere. For those who care (like me), it's open source and can easily be self-hosted. If you just want to use it, it's available as a service. Works perfect on mobile. Development by @2m0sql is extremely responsive, and he adds features constantly. Fantastic software all around! #recommendation

@kg5jst As a fellow attorney and radio amateur (in OE Austria 🇦🇹, however), I am very impressed by your Initiative. You're doing a very good thing!

@k5dru Thanks! Hm, interesting thought that hadn't crossed my mind. That other person, which I couldn't hear, would then have not used a CTCSS tone (and the one I could hear wouldn't have noticed because they had no CTCSS set on Rx). Makes sense, but would indeed be weird by this operator. I don't think I'll find out if that was the case, but I'll keep this in the back of my mind. Thanks a lot for your help!

@Tecci @hamradio_de @hamradio Thanks! I *think* I solved my problem, though I haven't yet fully understood it: https://mastodon.radio/@OE1FLP/109373176680051982

@k5dru h) CSV files that use "TSQL" and set the desired CTCSS tone in "rToneFreq" but the default tone of 88.5 for "cToneFreq" do not result in this problem. Similarly, the problem does not appear if one never uses a CSV file but only the application itself to program a memory channel.

Weird, but at least I've got it (mostly) figured out now! What remains a total mystery to me is how I heard only one of two stations over the repeater when using this buggy setup. I can't even hypothysize...

@k5dru e) For the FT-817ND, CHIRP - in the application window, not a CSV file - uses only one "Tone" - not suprising due to fact a).
f) When reimporting a CSV file, it appears that CHIRP messes up (with respect to the FT-817ND) *something* in lines (memory channels) that use TSQL.
g) As a result, CSV lines that use "TSQL" and have a non-default tone set for both "rToneFreq" and "cToneFreq" result in problems with sending out the CTCSS tone once applied to the transceiver.

@k5dru I think I have figured out the issue. It appears to stem from a few basic facts:
a) The FT-817ND cannot use "split" CTCSS tones.
b) #CHIRP CSV files use more than one columns to set CTCSS tones, namely "rToneFreq" and "cToneFreq".
c) If set to "TSQL" in CHIRP, it will export the same CTCSS tone to both of these columns.
d) If set to "Tone", CHIRP exports the set tone only to the "rToneFreq" column, and exports its default value of 88.5 to "cToneFreq".

@k5dru Thank you! That's excellent advice, thank you.

@n2rj Activating OE/WI-001 (if weather permits a relaxed walk up there with friends and family)! #SOTA 😃

@k5dru Very strange, right? 🤔🤔🤔 The "hearing-only-one-half" straight up doesn't make sense to me because to my radio it should be all the same, there shouldn't be any distinction between different source stations once their signal(s) has(have) gone through the repeater. I'll probably investigate further once I (and other operators on the repeater) have the patience, not right now.

@k5dru To summarize: It appears that either the programming software (same result with CHIRP and FTBasicMMO, btw) or the transceiver doesn't interpret the "TSQL" instruction correctly. I just don't understand in what way exactly it misinterprets it...

@k5dru I know that CTCSS on Rx is hardly necessary, so I'm fine with using "Tone" (which sets a CTCSS tone on Tx only). I'd just like to know what is happening (and, if possibly, use the repeater "as intended", i.e. with CTCSS on Rx, too).