So it's keying but not decoding on the other end, I assume FSK is likely the issue but I really don't know.

It keys, it sends but my other station doesn't decode it.

It's currently going into a dummy load at 5W so I doubt it can be heard much further away than my approximate location.

Direwolf shows it's trying to send it

开云体育

Hello Patrick,

Well dad gum, I could have SWORE for the life of me I tried that

On you original post to the [email protected] list, you posted:

?? "RTS DTR -> FSK & PTT flash on for a moment then turn off"


Do you have any idea what you changed since that first post on 4/29 @ 1pm until now?



Next, you sent a follow up email stating "It keys, it sends but my other station doesn't decode it. ".? That sounds like a standard audio level tuning issue.? What is your receiving radio?? Is it also running Direwolf?? Regardless, check out what I wrote up about this for a few other sound cards:

??


I'm not sure how the SCU-17 will present itself to alsamixer so you might need to make all the changes via the SCU-17's physical knobs.

--David
KI6ZHD

It's definitely got to be a application issue.

I have a serial adapter on order as I can't find the one I have that shows via LED the signals going over the wire so that will have to wait but if I set WSJTX or FLRig or FLDigi to use RTS for PTT it triggers PROPERLY

If I set direwolf to RTS it triggers FSK and dead keys
If I set direwolf to DTR it triggers PTT and dead keys
If I set direwolf to RTS DTR it triggers PTT and FSK properly, as it should, RTS is set to PTT and DTR is set to FSK
-RTS DTR gives me PTT dead key
RTS -DTR gives me FSK dead key

It seems to me the application is sending the signal but not dropping it as it should or the signals are inverted from what they should be OR stop bits need to be put in place

direwolf is the common denominator in this equation. It's as if it's giving the wrong serial signal, and no I'm not the only one that's had this issue.
My fellow ham has had this issue and a search on the web can find others

I've found threads where others have had the issue and worked around the problem but quite frankly I shouldn't have to work around the problem, that's why I bought a sound serial interface device, to minimize the clutter and optimize space and power consumption.

At this point I'm seriously considering switching to a hardware TNC if I'm going to work around the problem.

While Direwolf is a novel application and concept it does not work in all situations, many YES but not all and some have to make it work by working around any problems they may run into.

This is sad to me. Will I use Direwolf again? Sure, I'll try it but if I run into similar issue I'll likely just spend the time or money to find another solution rather than waste hours upon hours of my time troubleshooting a problem I know to be a software issue.

So I have found if I set direwolf to

PTT /dev/ttyUSB1 -DTR RTS
then the FSK light comes on and when it transmits it flips from FSK to PTT.

That I find functional.

Now to figure out why nothing else understands it when it transmits.

I am thankful for all the replies and help, don't misunderstand my frustration but I do believe there is a issue with RTS and DTR in direwolf as I'm not the first to have this issue and likely not the last.

开云体育

Hello Patrick,

If I set direwolf to RTS it triggers FSK and dead keys
If I set direwolf to DTR it triggers PTT and dead keys
If I set direwolf to RTS DTR it triggers PTT and FSK properly, as it should, RTS is set to PTT and DTR is set to FSK
-RTS DTR gives me PTT dead key
RTS -DTR gives me FSK dead key

It seems to me the application is sending the signal but not dropping it as it should or the signals are inverted from what they should be OR stop bits need to be put in place

I also see on the LInuxHams list, you mentioned:

--
PTT /dev/ttyUSB1 -DTR RTS
then the FSK light comes on and when it transmits it flips from FSK to PTT without a dead key.
--

Are you saying that Direwolf keys up SCU-17 and it's "FSK" indicator lights up but Direwolf stays playing audio (AFSK modem tones), the SCU-17's turns off the FSK light and then turns on the PTT light?? If so, that does NOT sound right at all.? If you would, please try Direwolf v1.6.?? I would expect Direwolf v1.7* as very stable now but it's NOT released code and it's still undergoing change.

direwolf is the common denominator in this equation. It's as if it's giving the wrong serial signal, and no I'm not the only one that's had this issue.
My fellow ham has had this issue and a search on the web can find others

The vew fellow HAMs who have had issue have been either using unusual sound devices, using unusual isolation devices, etc.? Direwolf can be made to work with any of them but you have to determine what the right signal is for each of them.? In your circumstance, the SCU-17 documentation is non-existent which makes it extra hard.?

At this point I'm seriously considering switching to a hardware TNC if I'm going to work around the problem.

While Direwolf is a novel application and concept it does not work in all situations, many YES but not all and some have to make it work by working around any problems they may run into.

Of course the choice is yours but I can nearly guarantee you that Direwolf will out perform *any* hardware TNC you buy.? TNCs like a KPC3+ or PK96 can come close but most of the PIC/Arduino based units will have significantly poor decode rates.

This is sad to me. Will I use Direwolf again? Sure, I'll try it but if I run into similar issue I'll likely just spend the time or money to find another solution rather than waste hours upon hours of my time troubleshooting a problem I know to be a software issue.

Well.. I hear the frustration here but Direwolf has recommend hardware mentioned in the User Guide but you're not using that.? You also were doing a lot of testing and you might have actually missed the test that either "-DTR RTS" or "-DTR RTS" was actually working for you (ignore whatever the LED lights are as there is no FSK signal here in AFSK1200 packet).? FSK from an SCU-17 perspective is used for things like "real" RTTY or CW on HF radios.

--David
KI6ZHD

开云体育

--
Are you saying that Direwolf keys up SCU-17 and it's "FSK" indicator lights up but Direwolf stays playing audio (AFSK modem tones), the SCU-17's turns off the FSK light and then turns on the PTT light?? If so, that does NOT sound right at all.? If you would, please try Direwolf v1.6.?? I would expect Direwolf v1.7* as very stable now but it's NOT released code and it's still undergoing change.
--

Yes... I think, if I understand the question correctly.

Let me elaborate...

The SCU hase 3 LED indicator lights, FSK, PTT and Power...

Direwolf not running, FSK off, PTT off, Power on

Direwolf running, FSK on, PTT off, Power on

YAAC sends message, Direwolf triggers PTT then, FSK off, PTT on, Power on

Direwolf drops PTT, FSK on, PTT off, Power on

Exit Direwolf application, FSK off, PTT off, Power on

--
The vew fellow HAMs who have had issue have been either using unusual sound devices, using unusual isolation devices, etc.? Direwolf can be made to work with any of them but you have to determine what the right signal is for each of them.? In your circumstance, the SCU-17 documentation is non-existent which makes it extra hard.
--

The only documentation I know of for the SCU-17 is this...

But yea, they don't break things down all the way.

--
Of course the choice is yours but I can nearly guarantee you that Direwolf will out perform *any* hardware TNC you buy.? TNCs like a KPC3+ or PK96 can come close but most of the PIC/Arduino based units will have significantly poor decode rates.
--

Oh, I agree for sure! The CPU in the machine is by far more powerful than any TNC and would for sure have better error correcting!
I'm just getting frustrated, I've spent many hours working on this one issue and when I can open another app like FLDigi or WSJTX and make it work perfecting the first time it only adds to the frustration.

--
Well.. I hear the frustration here but Direwolf has recommend hardware mentioned in the User Guide but you're not using that.? You also were doing a lot of testing and you might have actually missed the test that either "-DTR RTS" or "-DTR RTS" was actually working for you (ignore whatever the LED lights are as there is no FSK signal here in AFSK1200 packet).? FSK from an SCU-17 perspective is used for things like "real" RTTY or CW on HF radios.
--

You're right, I very likely missed that with the FSK light on it wasn't keying. I am by no means perfect or infallible so therefor I do make mistake and I'll own.
For instance I didn't know there was recommended hardware. I perused through the guide but I can't say I read it all. I read some parts more than others.
As for FSK, no, I really had NO idea what is was used for. I can say in the past week or so I've learned some things I didn't know before

As for rolling back to 1.6 it seems I've run into a issue compiling it. I get the following.....

dwgpsd.c:64:2: error: #error libgps API version might be incompatible.
?? 64 | #error libgps API version might be incompatible.
????? |? ^~~~~
make[2]: *** [src/CMakeFiles/decode_aprs.dir/build.make:141: src/CMakeFiles/decode_aprs.dir/dwgpsd.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/patrick/direwolf/src/dwgpsd.c:64:2: error: #error libgps API version might be incompatible.
?? 64 | #error libgps API version might be incompatible.
????? |? ^~~~~
[ 16%] Building C object src/CMakeFiles/direwolf.dir/cm108.c.o
make[2]: *** [src/CMakeFiles/direwolf.dir/build.make:843: src/CMakeFiles/direwolf.dir/dwgpsd.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 17%] Built target text2tt
[ 19%] Built target utm2ll
[ 27%] Built target gen_packets
make[1]: *** [CMakeFiles/Makefile2:633: src/CMakeFiles/decode_aprs.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 29%] Built target ttcalc
make[1]: *** [CMakeFiles/Makefile2:579: src/CMakeFiles/direwolf.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

If I git checkout dev then it compiles just fine and starts out with...

-- Dire Wolf Version: 1.7.0-c9ffbd7
-- Build type set to: Release
CMake system: Linux
-- Target architecture: x86_64
-- Use SSE2 SIMD instructions
-- Use SSSE3 SIMD instructions
-- Use SSE 4.1 SIMD instructions
-- Use SSE 4.2 SIMD instructions
-- Use AVX SIMD instructions
-- Use AVX2 SIMD instructions
-- Looking for strlcpy
-- Looking for strlcpy - not found
-- Looking for strlcat
-- Looking for strlcat - not found
-- Could NOT find AVAHI (missing: AVAHI_COMMON_FOUND AVAHI_CLIENT_FOUND)
-- Configuring done
-- Generating done
-- Build files have been written
(Continues Compiling Successfully)

I know this message was very long, sorry about that, just trying to be thorough.

Got it all working.

I updated this thread on this group...

/g/direwolf/topic/other_stations_don_t_decode/90829585?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,90829585,previd%3D1651549724754083416,nextid%3D1649302366690394507&previd=1651549724754083416&nextid=1649302366690394507

The FTM-300DR does not support CAT control but the SCU-17 does take DTR and RTS commands and does trigger PTT on the 300DR.

Thank you everyone for the help!

I do apologize of I have offended anyone, my frustration has a tenancy to get the best of me at times.

While I still believe the someone on the direwolf team should polish up the RTS DTR commands to not grab one or the other if they have not been specified in the config file I do believe that direwolf is a VERY robust application for what it is being used for. It has very little overhead while having a lot of options and I am very thankful for the time that everyone has put into the application and don't want anyone to think I don't appreciate their hard work of which they likely don't get paid for.

Case Closed!