Keyboard Shortcuts
Likes
Search
Other Stations don't decode
|
One problem after another here. |
|
OK, I think I've got it figured out. This has been my obsession for a bit to long now and I'm glad to have it figured out.
I do apologize if I've offended anyone on my other threads. My frustration sometimes gets the best of me. Anyhow, if anyone runs across this thread regarding the SCU-17 here is what I have found. The SCU-17 can not and does not handle a 44100 sampling rate nor a 48000 sampling rate. The sampling rates I have found that works are between 22,000 (might be lower) and 38,000 Hz at most. I tried 40,000, 44,100, 48,000 and they didn't work. I have my sample rate set as follows.... ARATE 38000 The SCU-17 with Direwolf will trigger FSK and PTT at the same time depending on how you have it set. The default setting for the SCU are... DTR - FSK RTS - PTT To get the SCU to trigger PTT without FSK on you have to set PTT to -DTR RTS. This will turn FSK on when receiving but off when transmitting. This appears to not affect receiving in any way that I've noticed. Example:..... PTT /dev/ttyUSB1 -DTR RTS FSK and PTT on during transmit.... PTT /dev/ttyUSB1 DTR RTS Setting to RTS only will also work but will leave FSK stuck on. This does not seem to affect the transmitted signal and DTR RTS doesn't seem to affect receive either as far as I can see. Unfortunately when I was observing my radio's behavior I was only watching the lights. Just because FSK comes on does NOT mean the radio is keyed. To my detriment and many, MANY hours later I have figured this out so hopefully if someone else runs across these problems they can avoid wasting as much time as I have and can hopefully get on the air and enjoy what they have quickly! I do also want to thank the makers of Direwolf. They have put a LOT of time and effort into making it work. Though the serial signaling does need to be tuned to not grab a signal that has not been specified it does work and it works quite well. Direwolf has a lot of features that are easily configured via the config file and it works quit well with very little overhead. A very impressive application indeed! Hopefully someone else using a SCU-17 finds this thread useful. Here is my config file for reference and for software TNC use only ACHANNELS 1 ARATE 38000 #ARATE 44100 #ADEVICE plughw:CARD=CODEC,DEV=0 hw:CARD=CODEC,DEV=0 ADEVICE plughw:CARD=CODEC,DEV=0 DWAIT 0 #SLOTTIME 10 PERSIST 63 TXDELAY 50 #TXTAIL 10 FULLDUP OFF CHANNEL 0 MYCALL replace-me-with-your-call MODEM 1200 #MODEM 2400 #MODEM 4800 #MODEM 9600 # PTT Notes for the SCU-17 # DTR Triggers FSK, RTS Triggers PTT, -DTR will leave FSK on until TX is triggered #PTT COM1 RTS #PTT COM1 RTS -DTR #PTT /dev/ttyUSB1 RTS PTT /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if01-port0 DTR RTS AGWPORT 8000 KISSPORT 8001 FIX_BITS 1 |
|
Nice write-up! I am sure anyone working with the SCU-17 that comes across this will appreciate your sharing. A couple of quick comments on the configuration. 1. Interestingly you specify "PERSIST 63" (at its DEFAULT setting), but comment out "#SLOTTIME 10" (also at its DEFAULT setting). ??? These 2 KISS settings setting work together to determine whether to TX when the channel is deemed open. ??? As a suggestion, since the 2 work together, I recommend either comment both out, or specify both. ??? Since they are at their default, it will make no difference. 2. You chose ARATE 38000.? This is a nonstandard value and may not scale well. ??? Most often users go with multiples (or whole divisions) of the 44,100 and 48,000.? So 22,050 or 24,000. ??? Again, not any sort of fix, just a little more standard. 3. The SCU-17 has 2 "key ports": PTT and FSK (interestingly on the same jack). ??? So it kind of makes sense that it would key both when requesting TX. ??? It also makes sense that you would have to disable the unused pin of the serial port. ??? Thank Goodness Dire Wolf takes multiple parameters so you can specify -DTR RTS ?????? DTR LOW and RTS HIGH on TX ??? Many interface applications like ire Wolf only allow 1 parameter which would probably force user of the ??? SCU-17 (and similar devices) to 'live with' the FSK activating. Robert Giuliano
On Monday, May 2, 2022, 11:48:46 PM EDT, Patrick <kd7wpq@...> wrote:
OK, I think I've got it figured out. This has been my obsession for a bit to long now and I'm glad to have it figured out. I do apologize if I've offended anyone on my other threads. My frustration sometimes gets the best of me. Anyhow, if anyone runs across this thread regarding the SCU-17 here is what I have found. The SCU-17 can not and does not handle a 44100 sampling rate nor a 48000 sampling rate. The sampling rates I have found that works are between 22,000 (might be lower) and 38,000 Hz at most. I tried 40,000, 44,100, 48,000 and they didn't work. I have my sample rate set as follows.... ARATE 38000 The SCU-17 with Direwolf will trigger FSK and PTT at the same time depending on how you have it set. The default setting for the SCU are... DTR - FSK RTS - PTT To get the SCU to trigger PTT without FSK on you have to set PTT to -DTR RTS. This will turn FSK on when receiving but off when transmitting. This appears to not affect receiving in any way that I've noticed. Example:..... PTT /dev/ttyUSB1 -DTR RTS FSK and PTT on during transmit.... PTT /dev/ttyUSB1 DTR RTS Setting to RTS only will also work but will leave FSK stuck on. This does not seem to affect the transmitted signal and DTR RTS doesn't seem to affect receive either as far as I can see. Unfortunately when I was observing my radio's behavior I was only watching the lights. Just because FSK comes on does NOT mean the radio is keyed. To my detriment and many, MANY hours later I have figured this out so hopefully if someone else runs across these problems they can avoid wasting as much time as I have and can hopefully get on the air and enjoy what they have quickly! I do also want to thank the makers of Direwolf. They have put a LOT of time and effort into making it work. Though the serial signaling does need to be tuned to not grab a signal that has not been specified it does work and it works quite well. Direwolf has a lot of features that are easily configured via the config file and it works quit well with very little overhead. A very impressive application indeed! Hopefully someone else using a SCU-17 finds this thread useful. Here is my config file for reference and for software TNC use only ACHANNELS 1 ARATE 38000 #ARATE 44100 #ADEVICE plughw:CARD=CODEC,DEV=0 hw:CARD=CODEC,DEV=0 ADEVICE plughw:CARD=CODEC,DEV=0 DWAIT 0 #SLOTTIME 10 PERSIST 63 TXDELAY 50 #TXTAIL 10 FULLDUP OFF CHANNEL 0 MYCALL replace-me-with-your-call MODEM 1200 #MODEM 2400 #MODEM 4800 #MODEM 9600 # PTT Notes for the SCU-17 # DTR Triggers FSK, RTS Triggers PTT, -DTR will leave FSK on until TX is triggered #PTT COM1 RTS #PTT COM1 RTS -DTR #PTT /dev/ttyUSB1 RTS PTT /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if01-port0 DTR RTS AGWPORT 8000 KISSPORT 8001 FIX_BITS 1 |
开云体育Hello Patrick, OK, I think I've got it figured out. This has been my obsession for a bit to long now and I'm glad to have it figured out. Good to hear. The SCU-17 can not and does not handle a 44100 sampling rate nor a 48000 sampling rate.? The sampling rates I have found that works are between 22,000 (might be lower) and 38,000 Hz at most. I tried 40,000, 44,100, 48,000 and they didn't work. That doesn't sound right at all.? Try this command to display what sampling rates this SCU-17 device offers: ?? bash <(wget -q -O - ) -l usb -s You will want to use the NATIVE sampling rate offered by the card because if you don't and you use the "plughw" prefix in your direwolf.conf's "ADEVICE" line, this will make ALSA take the native sampling rate from the hardware and then interpolate it into the rate you specify.? That's MORE work for the computer to do and will yield poorer audio. I have my sample rate set as follows.... What makes you think that 38000 is better than say 48000 or 44100?
I think your observation here needs some more troubleshooting in the Direwolf code.? The way I interpret "-DTR" is that DTR should *never* be asserted on that serial port.? Curious, if you shutdown Direwolf and any other programs that might use the SCU-17.. now UNPLUG it's USB cable, wait 5 seconds, plug it's USB cable back in, and then run the "dmesg" command in a terminal window, what do the last 10 lines or so show about the USB device being detected by the kernel?? Hopefully someone else using a SCU-17 finds this thread useful. --David KI6ZHD |
|
-- |
开云体育Hello Patrick,
Very interesting this device has native 32000 support.? I don't think I've seen that before.
I'm not sure why you're seeing TWO of these though.? That's unusual if not wrong unless you have two of these unit connected
Your previous email said you were using "ADEVICE plughw:CARD=CODEC,DEV=0" aka.. you ARE using the "plughw" aspect of the ALSA sound system.? Anyway.. can provide some sound captures of direwolf running your SCU-17 at say 44100 and 48000 which DON'T decode on your other station?? This shouldn't be happening.? Btw.. what is your other station using for a soundcard, TNC, etc?
I'll have to look to see what might be going on here on v1.7 and v1.6.?? Btw.. for your compiler errors on v1.7, this is an issue with gpsd and it's ever changing libraries.? If you can DISABLE the support for gpsd at compile time just for this test, I think that will get you going.
Ok.. that looks all reasonable.
You're correct.. I forgot about that syntax.
Ugh.. sorry.. I was forgetting that the unit here is 10s of milliseconds.?? What you should shoot for here is say 120 to 200ms.? In Direwolf syntax, that should be a "12" to a "20".?? Start at "20" and see if everything works in communicating to remote packet stations (not just home packet stations).? Then slowly work your way down in say 25ms increments.? Since the FTM300 is a digital radio, I would think it can support faster than average key up times of about 150ms but you'll just have to experiment here.
See the Direwolf User Guide in the "MODEM" section.
I have it all written down:? ?? --David KI6ZHD |
|
--
Very interesting this device has native 32000 support.? I don't think I've seen that before. -- No idea, I didn't even know how to pull the data from the devices to figure that out, so thank you! -- I'm not sure why you're seeing TWO of these though.? That's unusual if not wrong unless you have two of these unit connected -- Yes, I do have two of this connected to this machine. One for my 857 and one for the 300DR -- Your previous email said you were using "ADEVICE plughw:CARD=CODEC,DEV=0" aka.. you ARE using the "plughw" aspect of the ALSA sound system.? Anyway.. can provide some sound captures of direwolf running your SCU-17 at say 44100 and 48000 which DON'T decode on your other station?? This shouldn't be happening. Btw.. what is your other station using for a soundcard, TNC, etc? -- Yea, I realized I already had plughw set correctly after I sent that massage but I was in a hurry and didn't want to blow up people's emails with the same message. My other stations that are listening are a Raspberry Pi using a CMedia sound fob running direwolf connected to a old Kenwood commercial radio that was repurposed just to act as a iGate for the local area. We had a very large gap here in N Idaho that we filled back in. The other radio is a Yeasu FT3D hand held, neither of them would decode at 44100 or 48000 48000 sample rate gave me the following... Dire Wolf DEVELOPMENT version 1.7 E (May? 1 2022) Includes optional support for:? gpsd hamlib cm108-ptt Reading config file direwolf.conf Audio device for both receive and transmit: plughw:CARD=CODEC,DEV=0? (channel 0) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 48000 sample rate. Warning: Calculated pre filter size of 417 is too large. Decrease the audio sample rate or increase the decimation factor. You can use -D2 or -D3, on the command line, to down-sample the audio rate before demodulating.? This greatly decreases the CPU requirements with little impact on the decoding performance.? This is useful for a slow ARM processor, such as with a Raspberry Pi model 1. Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 ... Interestingly enough 48000 worked for some reason this time. I've tried it before and it didn't. Got a 100% response 44100 on the other hand is attached as a wave file recorded from my iGate using FLDigi, it decoded once out of many tries. The iGate is using a CMedia sound fob -- Btw.. for your compiler errors on v1.7, this is an issue with gpsd and it's ever changing libraries.? If you can DISABLE the support for gpsd at compile time just for this test, I think that will get you going. -- Ahh, good to know, but how do I disable support for gpsd? As I'm just using direwolf as a TNC in this case I don't need it enabled but I'll add it to my notes in case I ever need to recompile and add it back in. -- Ugh.. sorry.. I was forgetting that the unit here is 10s of milliseconds.?? What you should shoot for here is say 120 to 200ms.? In Direwolf syntax, that should be a "12" to a "20". Start at "20" and see if everything works in communicating to remote packet stations (not just home packet stations).? Then slowly work your way down in say 25ms increments.? Since the FTM300 is a digital radio, I would think it can support faster than average key up times of about 150ms but you'll just have to experiment here -- Adjusted! I'll give it some testing later on but 20 sounds nice, there's not a lot of lag between key up and actual packet sending and decoding was working well. 100% success. Only small issue I see is I can't seem to get my audio level below about 70 to 80. Any lower and the pot on the SCU-17 goes quiet and adjusting it via alsamixer does nothing. -- See the Direwolf User Guide in the "MODEM" section. -- I'm content with /1. This machine is perfectly capable and is capable of running Windows 10 in a virtual environment while running everything else. Sure it slows a small bit but nothing that bothers me Between being a quad core 3.2Ghz w/HT and 32GB of RAM it should be fine Think I should add E+ or since it's default I presume it's assumed? -- I have it all written down: -- Wow, that's a heck of a guide! Looks like I've got some reading to do. I can't say I'll read it all right now but I am saving it to PDF for reference offline. Thanks a ton! |
开云体育Hello Patrick, > No idea, I didn't even know how to pull the data from the devices to figure that out, so thank you! There are other ways to do this but that one line is easy to run >Yes, I do have two of this connected to this machine. One for my 857 and one for the 300DR Ah.. ok. >48000 sample rate gave me the following... >Dire Wolf DEVELOPMENT version 1.7 E (May? 1 2022) >Includes optional support for:? gpsd hamlib cm108-ptt > >Reading config file direwolf.conf >Audio device for both receive and transmit: plughw:CARD=CODEC,DEV=0? (channel 0) >Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 48000 sample rate. <--------------------------- This is selecting the "A+" modem I think this is your issue.? For some reason, Direwolf is selecting the "A+" modem and not the "should be default E+" modem.? See page 67 of the Direwolf User Guide but try out the following line while using a sampling rate of 48000: -- MODEM 1200 E+ -- >Interestingly enough 48000 worked for some reason this time. I've tried it before and it didn't. >Got a 100% response That's not good. >44100 on the other hand is attached as a wave file recorded from my iGate using FLDigi, it decoded once out of many tries. >The iGate is using a CMedia sound fob Those don't sound like complete packets for sure.? There is also a "ticking" sound your signal that isn't good.? You need to make sure you find what's causing that. >Ahh, good to know, but how do I disable support for gpsd? >As I'm just using direwolf as a TNC in this case I don't need it enabled but I'll add it to my notes in case I ever need to recompile and add it back in. This needs more research but I think it would be at compile time but this doesn't seem to be disabling things as I would expect: ?? cmake .. -DGPSD_FOUND=FALSE Alternatively, you can follow my other Direwolf build guide to update the required Direwolf header file to recognize your newer libgps API version.? It's very simple to do: ?? --> Follow section 24.B >Adjusted! >I'll give it some testing later on but 20 sounds nice, there's not a lot of lag between key up and actual packet sending and decoding was working well. 100% success. Only small issue I see is I can't seem to get my audio level below >about 70 to 80. Any lower and the pot on the SCU-17 goes quiet and adjusting it via alsamixer does nothing. Setting your TXDELAY should have nothing to do with your incoming audio levels.? Regardless, I would assume since the SCU-17 has knobs on the front of it, you would need to adjust the RX level there and any digitally configured mixer settings would be ignored.? Is that not the case and BOTH methods of changing both the receive and transmit audio levels works? >I'm content with /1. This machine is perfectly capable and is capable of running Windows 10 in a virtual environment while running everything else. Sure it slows a small bit but nothing that bothers me >Between being a quad core 3.2Ghz w/HT and 32GB of RAM it should be fine >Think I should add E+ or since it's default I presume it's assumed? See above but YES... I think there is an issue with the default modem selection in the current Direwolf 1.7 code.? Another user was seeing a similar when using 300bps HF packet as well. >Wow, that's a heck of a guide! >Looks like I've got some reading to do. I can't say I'll read it all right now but I am saving it to PDF for reference offline. >Thanks a ton! Though focused on a Raspberry Pi, it really doesn't matter and since you're using a Debian based Linux distribution, most everything should work.?? If you were using an RPM based distribution, you can see my older guide which has a LOT more chapters in it covering a LOT more amateur radio program topics: ?? --David KI6ZHD |