开云体育


Re: Transmitting 100hz tone with dire for voice alert.

 

From the Kenwood TH-D74 manual in the APRS sections
?
?
?
VOICE ALERT
?
?
This function will notify another station as to whether or not they are within communications range by emitting beacon tones.When a Mobile Station is mobile with the Voice Alert function turned ON, other stations also with Voice Alert turned ON will hear the beacon sound of the Mobile Station if they have matching tone (CTCSS) frequencies and are within range, thus informing the stations that communications is possible.
In other words, having CTCSS on and another station sending 100 Hz on APRS, you will hear APRS, and if you both tune to the same frequency, you are withing Simplex range.? It's an odd function, but it's there.
Digipeaters should not send Pl.
?
Arnold, KQ6DI

On 09/07/2024 10:45 AM PDT kb3osp@... wrote:
?
?
Correct as dire is the digipeater having the radio with PL tone set will be pointless as it doesn't have a operator at the face of the radio with mic in hand. I want to do voice now and then for certain things and be able to use this feature in many mobile radios without hearing all the traffic though the digi. Voice alert setting in a radio like my mobile radio a Kenwood 710G will only "open" up the speaker when it hears the 100hz tone. Otherwise the radio is silent but still gets all the packet traffic but allows for you to know if another mobile or station is running voice alert by hearing the packet and you will be able to call them on the 144.39 to QSY to another frequency. Just didn't know if dire had this capability or not. I guess I will have to add something to a script or the program in development.

Jon
KB3OSP


Re: Transmitting 100hz tone with dire for voice alert.

 

Correct as dire is the digipeater having the radio with PL tone set will be pointless as it doesn't have a operator at the face of the radio with mic in hand. I want to do voice now and then for certain things and be able to use this feature in many mobile radios without hearing all the traffic though the digi. Voice alert setting in a radio like my mobile radio a Kenwood 710G will only "open" up the speaker when it hears the 100hz tone. Otherwise the radio is silent but still gets all the packet traffic but allows for you to know if another mobile or station is running voice alert by hearing the packet and you will be able to call them on the 144.39 to QSY to another frequency. Just didn't know if dire had this capability or not. I guess I will have to add something to a script or the program in development.

Jon
KB3OSP


Re: Transmitting 100hz tone with dire for voice alert.

 

The idea behind Voice Alert is to only transmit PL when transmitting voice. No PL when transmitting data. Transmitting PL all the time (by using PL on the radio) would defeat the point of Voice Alert and annoy listeners using Voice Alert to filter out the data transmissions.
?
The following command will synthesize a 100Hz tone:
?
ffplay -hide_banner -nodisp -autoexit -f lavfi -i 'sine=f=100'

There is likely a way to use ffmpeg/ffplay to mix this synthesized tone with the output of espeak but I haven't been able to figure it out.
?


Re: Transmitting 100hz tone with dire for voice alert.

 

PL from the radio is what I also use.? I believe this is the way it was intended to be implemented.
Arnold, KQ6DI

On 09/07/2024 3:45 AM PDT Charles J. Hargrove <n2nov@...> wrote:
?
?
Why not just use the PL tone of the radio?
?
On 9/7/2024 1:40 AM, Bob Cameron wrote:
containing the 100Hz tone
?
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
?
?


Re: Transmitting 100hz tone with dire for voice alert.

 

Why not just use the PL tone of the radio?

On 9/7/2024 1:40 AM, Bob Cameron wrote:
containing the 100Hz tone
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.

NYC-ARECS/RACES Nets 441.100/136.5 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM


NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32

"Information is the oxygen of the modern age. It seeps through the walls topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan

"The more corrupt the state, the more it legislates." - Tacitus

"Molann an obair an fear" - Irish Saying
(The work praises the man.)

"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan


Re: Transmitting 100hz tone with dire for voice alert.

 

开云体育

Hi Jon

I have never looked at speech output, but looking through the manual I see that espeak is called via a shell/bat script. It would seem to be easy to output the espeak to a wav file, merge another wav with it containing the 100Hz tone (using, say sox), then play the wav file out to the radio. I assume the PTT comes from Direwolf itself.

Cheers Bob VK2YQA

On 7/9/24 07:55, kb3osp@... wrote:

Working on a project and I have looked though the documentation as well as searched this group and have not come up with anything. When Direwolf uses speech for a beacon does it / can it transmit a 100 hz tone along with the speech for voice alerting radios? Or would I need to have another program output the tone when it is speaking?

Thanks in advance!
Jon
KB3OSP


Transmitting 100hz tone with dire for voice alert.

 

Working on a project and I have looked though the documentation as well as searched this group and have not come up with anything. When Direwolf uses speech for a beacon does it / can it transmit a 100 hz tone along with the speech for voice alerting radios? Or would I need to have another program output the tone when it is speaking?

Thanks in advance!
Jon
KB3OSP


Re: Good volume level to start with?

 

开云体育

On 9/2/24 23:20, JayMot DW7GDL via groups.io wrote:
...
As there's no standard APRS frequency in the Philippines, hams have to find their own regional frequency when setting up digipeater, taking into account the input and output frequencies of existing 2m repeaters in their area along with the digi's deviation. In the Manila area and central Luzon they use 144.440. We've selected 144.380 in Cebu based on the frequency pairs of any other repeaters within 150 or so kilometers.
?...

is interesting.




Re: Decoding 300 baud HF

 

Hi Larry,
By default, direwolf will try and print details about received packets as if they are APRS packets. The packets are being received successfully despite these "errors" that show up in the logs.
You can disable that APRS logging behavior by adding the -qd command line argument when you run direwolf.
?
-Brent WG0A


Decoding 300 baud HF

Larry
 

I'm decoding 14.105 MHz LSB with Direwolf. Most packets have format errors. I guess that it's because they are not APRS. For example:
?
KD2YCK-1 audio level = 59(11/11) ? ?__|||____
[0.3] KD2YCK-1>MAIL:Mail For:KD2YCK N1UGK NC8Q N2MH
ERROR!!! ?Unknown APRS Data Type Indicator "M", UNKNOWN vendor/model
?
KD0YTE-7 audio level = 39(30/12) ? ?_||||||__
[0.3] KD0YTE-7>ID:KD0YTE - Kirksville MO. EN30qf BPQ Packet Node <0x0d>
ERROR!!! ?Unknown APRS Data Type Indicator "K"
Use of "ID" in the destination field is obsolete. ?You can help to improve the quality of APRS signals.
Tell the sender (KD0YTE-7) to use the proper product identifier from
?
Can Direwolf parse non APRS packets?
?
Larry,? N7RTS
?


Re: Good volume level to start with?

 

Hi Thomas.
?
The repeater site is in the mountains east of here at around 390 meters/1270 feet elevation, if not more. It has either a 100 or 150 foot tower, I forget which but I think 150, which gets our repeaters' signals over the surrounding mountains (high hills, really.) A 5W digipeater should easily cover the entire Metro Cebu area with no dead zones. According to the coverage map at ke2dbe.com it should cover around 120 km. with a strong signal level. 5W HTs are able to communicate over the voice repeater from all over the Cebu City area including nearby cities with relative ease considering their low power and rubber duck antennas. As long as the digi at the repeater site can decode packets from APRS HTs my own digi and Igate should easily be able to receive and repeat them as well as ship them out to APRS-IS. We won't actually know for sure until we get it set up and test it but I have high confidence that it will work fine.
?
All of our repeaters now have multiple cavity filters for high Q. Two more were recently added to the 2m voice repeater to solve a QRM problem caused by another club's repeater which is located nor far from ours. I suspect some of their members use wide FM deviation because what was happening was, if they had a net at the same time we did, whenever anyone sent the CTCSS or PL tone to open our 2m repeater it was also receiving and repeating the edge of the deviation from whoever was using their repeater at the time. If the digi's radio is configured for NFM it shouldn't cause any QRM issues with voice repeaters, either ours or those of other clubs.
?
As there's no standard APRS frequency in the Philippines, hams have to find their own regional frequency when setting up digipeater, taking into account the input and output frequencies of existing 2m repeaters in their area along with the digi's deviation. In the Manila area and central Luzon they use 144.440. We've selected 144.380 in Cebu based on the frequency pairs of any other repeaters within 150 or so kilometers.
?
There's a group of Filipino hams living in the US, Canada and Australia that have been providing free Yaesu C4FM repeaters to Philippine ham radio clubs and organizations to establish a digital voice communications system in the Philippines, with Internet connections so we and that group can communicate after any disasters. My club's? President is going to see if he can source a free 2 meter FM radio from them (used is fine) that Digirig makes a cable for, which would cut down on my own expense: I'll already be donating a Raspberry Pi 3B+, a heatsink case with fans, a Pi power supply, microSD card, Digirig Mobile plus its cables, and will install and configure Direwolf so by installation time it should be basically a turnkey system costing the club very little money. They (we, but it's coming from the club treasury) just needs to provide an antenna and the coax and I think they already have a spool of RG-8/U.
?
73, de DV7GDL (recent license upgrade but I haven't changed my account on groups.io yet.)


Re: 300 baud HF settings

Larry
 

I have a lot of experience with the RSPDX and a good antenna. The last setup I posted is working great. Thank you



On Monday, September 2nd, 2024 at 3:29 PM, David Ranch via groups.io <direwolf-groupsio@...> wrote:


Hello Larry,

I thought that udp:7355 would do for the receiver and that null would be assumed for the transmitter. This is only for listening right now. I'll use ADEVICE instead. This is on a Debian Bookworm laptop, not a pi. The audio is coming in on UDP from SDR++. The version: Dire Wolf DEVELOPMENT version 1.8 D (Jul 27 2024). The current receiver is a SDRplay RSPDX.
So, like this?

net105.conf:
ACHANNELS 1
CHANNEL 0
ADEVICE udp:7355 null
MODEM 300 1600:1800 7@30 /4 D

direwolf -c ./net105.conf -t 0 -n 1 -b 16 -r 48000

That all looks reasonable. The tuning of the SDR software is beyond the scope of Direwolf but pay attention to it's setup in terms of gain, LNA, AGC, needless over sampling rates, noise blankers, etc. I'm sure there are some SDR guides out there on the Internet focused on optimal software tuning and don't forget, not all SDRs are equal and you do get what you pay for when trying to really dig out the weak signals if you have a good antenna.

--David
KI6ZHD







On Monday, September 2nd, 2024 at 1:31 PM, David Ranch via groups.io <direwolf-groupsio@...> wrote:

Hello Larry,

I'm running direwolf this way on Debian:

On what computer and radio hardware? What are your goals here? Just 300bps HF receive ONLY? Also, what version of Direwolf are you running? I would recommend to compile up the newest 1.8 "dev" branch as it has the best code available and is quite stable.


net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D

A few things:

- you don't show your ADEVICE line

- Since you're using "/4", I assume you're using a SBC like a Raspberry Pi, etc?

- which "modem" to pick is a bit all over the place right now. The older details in the User Guide documentation on page 67 of the UserGuide ( file:///home/dranch/Downloads/User-Guide-7.pdf ) and section 9.2.4 says to use modem "B" and not "D" though in the new 1.8 DEV code they are actually the SAME setting now ( line 734). I hope in the future that the newer User Guide cleans out all the old/redundant/deprecated demodulator lines.


command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355

- I don't think the "-B 300:1600:1800" is a legal command line string

- Is this a receive only setup or a receive/transmit setup?


Are these options optimal for HF 300 baud?

Yes... and I also see you have enabled FX.25 support which I would recommend as it can make a big difference for remote stations that support it. If the remote station doesn't support it, they will ignore that data and still continue to function. See for more details.




I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.

I can appreciate that point of view and for basic needs, that's possible but if you have advanced needs, you WILL need to use direwolf.conf.


I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.

Few things I can think of:

- What program are you using with Direwolf? Specifically if you plan on making HF packet BBS connections, you might consider using a AGWPE-based program that can support the new AX.25 v2.2 support in Direwolf. There are optimizations in this newer protocol which should help situations around re-transmissions, etc. compared to the v2.1 spec. I've found that most stations that support FX.25 will also support AX.25 v2.2. Btw.. if you DO enable this feature and try to initiate a connection to a remote station that does NOT support v2.2, there will be substantial delays until a connection is made as the remote station will ignore the v2.2 connection attempts. To disable this v2.2 support for known remote callsigns, use the " V20 <callsignA-1> <callsignB-2> etc" in the Direwolf conf file. See PDF page 141 of the User Guide for more details.

- If you are going to be transmitting, consider lowering your AX.25 MTU and/or MaxFrame (aka "window size"). Finding the right balance here depends on the error rate to the remote station depending on HF propagation. An MTU of 128 is about as high as you will want to go and some people tune it down to 64 for very bad propagation that requires lots of re-tries. Same thing for Window size. I would recommend to start with a window of 1 but if the path is very good, you might be able to get up to 4 (or maybe even better).


- There are other options mentioned in the User Guide section 10.3 that you might consider though unless you know what you're doing, leave the defaults alone. If you have QSOs with people on Net105, you might ask them what they recommend here in different times of the year (changes in propagation, etc), etc.

--David
KI6ZHD




Re: 300 baud HF settings

 

开云体育


Hello Larry,

I thought that udp:7355 would do for the? receiver and that null would be assumed for the transmitter. This is only for listening right now. I'll use ADEVICE instead. This is on a Debian Bookworm laptop, not a pi. The audio is coming in on UDP from SDR++. The version:?Dire Wolf DEVELOPMENT version 1.8 D (Jul 27 2024). The current receiver is a SDRplay RSPDX.
So, like this?

net105.conf:
ACHANNELS 1
CHANNEL 0
ADEVICE udp:7355 null
MODEM 300 1600:1800 7@30 /4 D

direwolf -c ./net105.conf -t 0 -n 1 -b 16 -r 48000

That all looks reasonable.? The tuning of the SDR software is beyond the scope of Direwolf but pay attention to it's setup in terms of gain, LNA, AGC, needless over sampling rates, noise blankers, etc.? I'm sure there are some SDR guides out there on the Internet focused on optimal software tuning and don't forget, not all SDRs are equal and you do get what you pay for when trying to really dig out the weak signals if you have a good antenna.?

--David
KI6ZHD







On Monday, September 2nd, 2024 at 1:31 PM, David Ranch via groups.io <direwolf-groupsio@...> wrote:

Hello Larry,

I'm running direwolf this way on Debian:

On what computer and radio hardware? What are your goals here? Just 300bps HF receive ONLY? Also, what version of Direwolf are you running? I would recommend to compile up the newest 1.8 "dev" branch as it has the best code available and is quite stable.


net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D

A few things:

- you don't show your ADEVICE line

- Since you're using "/4", I assume you're using a SBC like a Raspberry Pi, etc?

- which "modem" to pick is a bit all over the place right now. The older details in the User Guide documentation on page 67 of the UserGuide ( file:///home/dranch/Downloads/User-Guide-7.pdf ) and section 9.2.4 says to use modem "B" and not "D" though in the new 1.8 DEV code they are actually the SAME setting now ( line 734). I hope in the future that the newer User Guide cleans out all the old/redundant/deprecated demodulator lines.


command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355

- I don't think the "-B 300:1600:1800" is a legal command line string

- Is this a receive only setup or a receive/transmit setup?


Are these options optimal for HF 300 baud?

Yes... and I also see you have enabled FX.25 support which I would recommend as it can make a big difference for remote stations that support it. If the remote station doesn't support it, they will ignore that data and still continue to function. See for more details.




I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.

I can appreciate that point of view and for basic needs, that's possible but if you have advanced needs, you WILL need to use direwolf.conf.


I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.

Few things I can think of:

- What program are you using with Direwolf? Specifically if you plan on making HF packet BBS connections, you might consider using a AGWPE-based program that can support the new AX.25 v2.2 support in Direwolf. There are optimizations in this newer protocol which should help situations around re-transmissions, etc. compared to the v2.1 spec. I've found that most stations that support FX.25 will also support AX.25 v2.2. Btw.. if you DO enable this feature and try to initiate a connection to a remote station that does NOT support v2.2, there will be substantial delays until a connection is made as the remote station will ignore the v2.2 connection attempts. To disable this v2.2 support for known remote callsigns, use the " V20 <callsignA-1> <callsignB-2> etc" in the Direwolf conf file. See PDF page 141 of the User Guide for more details.

- If you are going to be transmitting, consider lowering your AX.25 MTU and/or MaxFrame (aka "window size"). Finding the right balance here depends on the error rate to the remote station depending on HF propagation. An MTU of 128 is about as high as you will want to go and some people tune it down to 64 for very bad propagation that requires lots of re-tries. Same thing for Window size. I would recommend to start with a window of 1 but if the path is very good, you might be able to get up to 4 (or maybe even better).


- There are other options mentioned in the User Guide section 10.3 that you might consider though unless you know what you're doing, leave the defaults alone. If you have QSOs with people on Net105, you might ask them what they recommend here in different times of the year (changes in propagation, etc), etc.

--David
KI6ZHD



Re: 300 baud HF settings

Larry
 

I thought that udp:7355 would do for the? receiver and that null would be assumed for the transmitter. This is only for listening right now. I'll use ADEVICE instead. This is on a Debian Bookworm laptop, not a pi. The audio is coming in on UDP from SDR++. The version:?Dire Wolf DEVELOPMENT version 1.8 D (Jul 27 2024). The current receiver is a SDRplay RSPDX.
So, like this?

net105.conf:
ACHANNELS 1
CHANNEL 0
ADEVICE udp:7355 null
MODEM 300 1600:1800 7@30 /4 D

direwolf -c ./net105.conf -t 0 -n 1 -b 16 -r 48000




On Monday, September 2nd, 2024 at 1:31 PM, David Ranch via groups.io <direwolf-groupsio@...> wrote:


Hello Larry,

I'm running direwolf this way on Debian:

On what computer and radio hardware? What are your goals here? Just 300bps HF receive ONLY? Also, what version of Direwolf are you running? I would recommend to compile up the newest 1.8 "dev" branch as it has the best code available and is quite stable.


net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D

A few things:

- you don't show your ADEVICE line

- Since you're using "/4", I assume you're using a SBC like a Raspberry Pi, etc?

- which "modem" to pick is a bit all over the place right now. The older details in the User Guide documentation on page 67 of the UserGuide ( file:///home/dranch/Downloads/User-Guide-7.pdf ) and section 9.2.4 says to use modem "B" and not "D" though in the new 1.8 DEV code they are actually the SAME setting now ( line 734). I hope in the future that the newer User Guide cleans out all the old/redundant/deprecated demodulator lines.


command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355

- I don't think the "-B 300:1600:1800" is a legal command line string

- Is this a receive only setup or a receive/transmit setup?


Are these options optimal for HF 300 baud?

Yes... and I also see you have enabled FX.25 support which I would recommend as it can make a big difference for remote stations that support it. If the remote station doesn't support it, they will ignore that data and still continue to function. See for more details.




I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.

I can appreciate that point of view and for basic needs, that's possible but if you have advanced needs, you WILL need to use direwolf.conf.


I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.

Few things I can think of:

- What program are you using with Direwolf? Specifically if you plan on making HF packet BBS connections, you might consider using a AGWPE-based program that can support the new AX.25 v2.2 support in Direwolf. There are optimizations in this newer protocol which should help situations around re-transmissions, etc. compared to the v2.1 spec. I've found that most stations that support FX.25 will also support AX.25 v2.2. Btw.. if you DO enable this feature and try to initiate a connection to a remote station that does NOT support v2.2, there will be substantial delays until a connection is made as the remote station will ignore the v2.2 connection attempts. To disable this v2.2 support for known remote callsigns, use the " V20 <callsignA-1> <callsignB-2> etc" in the Direwolf conf file. See PDF page 141 of the User Guide for more details.

- If you are going to be transmitting, consider lowering your AX.25 MTU and/or MaxFrame (aka "window size"). Finding the right balance here depends on the error rate to the remote station depending on HF propagation. An MTU of 128 is about as high as you will want to go and some people tune it down to 64 for very bad propagation that requires lots of re-tries. Same thing for Window size. I would recommend to start with a window of 1 but if the path is very good, you might be able to get up to 4 (or maybe even better).


- There are other options mentioned in the User Guide section 10.3 that you might consider though unless you know what you're doing, leave the defaults alone. If you have QSOs with people on Net105, you might ask them what they recommend here in different times of the year (changes in propagation, etc), etc.

--David
KI6ZHD


Re: Good volume level to start with?

 

开云体育

Hi,

Definitely respect any power restrictions imposed by the site owner.
Topography is an important factor and if your antenna is high (tower, tall building, natural peak) in an otherwise flat landscape (minimal obstructions) then you can expect good coverage even with low power.
As for interference issues, proper selection of the frequencies used by all the transmitters at the site is important. There are spreadsheets that can help identify conflicts based on the frequency and bandwidth of each transmitter on the site. Note however that those calculators only handle the intentional emissions.
Commercial site owners normally require strong filtering (cavities, isolators) on transmitters to keep unintentional emissions (spurs, harmonics) from interfering with other users of the site.
Privately owned amateur radio sites are well advised to follow that example (some do, some don't).
Note however that no amount of filtering can prevent intermod when the sum or difference of two transmitter frequencies matches the frequency of a third radio on the site (something that gets more and more difficult to avoid the more transmitters are at that same location).
That is why frequency planning is so important.

73,
Thomas
KK6FPP



Get


From: [email protected] <[email protected]> on behalf of JayMot DW7GDL via groups.io <jaymot123@...>
Sent: Sunday, September 1, 2024 11:53:00 PM
To: [email protected] <[email protected]>
Subject: Re: [direwolf] Good volume level to start with?
?
Thomas: The 5W limit is per my club's president who's also the main repeater person, and is because we already have two 2m repeaters and two 70cm repeaters at the site plus another club's 2m repeater is nearby. We've already had interference issues happening and I think he wants to avoid that again after adding the digipeater. I'll tell him what you said though, and see what he says.
?
David: I suppose I could get a Yaesu FT-2980R. Digirig also makes a cable that will work on it. (I like their cables as they're well-made, shielded and already have ferrites, vs. some sort of homebrew cable solution.) A commercial radio like a Motorola would need the homebrew cable provided a Moto data connector could even be found in the Philippines. We do have connections in the US and Canada who may be able to help though. I mean, on the one hand I highly doubt that the APRS traffic levels would ever put a strain on the FT-60, but on the other hand there's what Thomas said about the hidden node problem.
?
It's all food for thought. Thank you both for the information. 73.


Re: 300 baud HF settings

 

开云体育


Hello Larry,

I'm running direwolf this way on Debian:

On what computer and radio hardware?? What are your goals here?? Just 300bps HF receive ONLY??? Also, what version of Direwolf are you running?? I would recommend to compile up the newest 1.8 "dev" branch as it has the best code available and is quite stable.


net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D

A few things:

?? - you don't show your ADEVICE line

?? - Since you're using "/4", I assume you're using a SBC like a Raspberry Pi, etc??

?? - which "modem" to pick is a bit all over the place right now.? The older details in the User Guide documentation on page 67 of the UserGuide ( file:///home/dranch/Downloads/User-Guide-7.pdf ) and section 9.2.4 says to use modem "B" and not "D" though in the new 1.8 DEV code they are actually the SAME setting now ( line 734).? I hope in the future that the newer User Guide cleans out all the old/redundant/deprecated demodulator lines.
?

command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355

- I don't think the "-B 300:1600:1800" is a legal command line string

- Is this a receive only setup or a receive/transmit setup?


Are these options optimal for HF 300 baud?

Yes... and I also see you have enabled FX.25 support which I would recommend as it can make a big difference for remote stations that support it.? If the remote station doesn't support it, they will ignore that data and still continue to function.? See for more details.




I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.

I can appreciate that point of view and for basic needs, that's possible but if you have advanced needs, you WILL need to use direwolf.conf.


I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.

Few things I can think of:

?? - What program are you using with Direwolf?? Specifically if you plan on making HF packet BBS connections, you might consider using a AGWPE-based program that can support the new AX.25 v2.2 support in Direwolf.? There are optimizations in this newer protocol which should help situations around re-transmissions, etc. compared to the v2.1 spec.? I've found that most stations that support FX.25 will also support AX.25 v2.2.? Btw.. if you DO enable this feature and try to initiate a connection to a remote station that does NOT support v2.2, there will be substantial delays until a connection is made as the remote station will ignore the v2.2 connection attempts.? To disable this v2.2 support for known remote callsigns, use the " V20 <callsignA-1> <callsignB-2> etc" in the Direwolf conf file.? See PDF page 141 of the User Guide for more details.

?? - If you are going to be transmitting, consider lowering your AX.25 MTU and/or MaxFrame (aka "window size").? Finding the right balance here depends on the error rate to the remote station depending on HF propagation.? An MTU of 128 is about as high as you will want to go and some people tune it down to 64 for very bad propagation that requires lots of re-tries.? Same thing for Window size.? I would recommend to start with a window of 1 but if the path is very good, you might be able to get up to 4 (or maybe even better).


?? - There are other options mentioned in the User Guide section 10.3 that you might consider though unless you know what you're doing, leave the defaults alone.? If you have QSOs with people on Net105, you might ask them what they recommend here in different times of the year (changes in propagation, etc), etc.

--David
KI6ZHD


V1.8 (dev) - Packets being digipeated to NCHANNEL

 

I am trying to get IS-traffic to be sent via a networked-kiss interface.
?

packets retrieved from IS being digipeated to the network-kiss interface (in my case channel 6) produce the following output:

[ig>tx] OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
[6.is] X>X:}OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
?

expected behaviour:

[ig>tx] OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
[6.is] OE6PLD-2>APDW18:}OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
?
can anybody confirm this behaviour or has NCHANNEL running correctly?
?
regadrs
peter, OE6PLD
?
?


300 baud HF settings

Larry
 

I'm running direwolf this way on Debian:
net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D
command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355
Are these options optimal for HF 300 baud? I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.
I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.
?
thanks,
Larry
?
?


Re: Good volume level to start with?

 

Thomas: The 5W limit is per my club's president who's also the main repeater person, and is because we already have two 2m repeaters and two 70cm repeaters at the site plus another club's 2m repeater is nearby. We've already had interference issues happening and I think he wants to avoid that again after adding the digipeater. I'll tell him what you said though, and see what he says.
?
David: I suppose I could get a Yaesu FT-2980R. Digirig also makes a cable that will work on it. (I like their cables as they're well-made, shielded and already have ferrites, vs. some sort of homebrew cable solution.) A commercial radio like a Motorola would need the homebrew cable provided a Moto data connector could even be found in the Philippines. We do have connections in the US and Canada who may be able to help though. I mean, on the one hand I highly doubt that the APRS traffic levels would ever put a strain on the FT-60, but on the other hand there's what Thomas said about the hidden node problem.
?
It's all food for thought. Thank you both for the information. 73.


Re: Good volume level to start with?

 

开云体育


Hello DW7GDL,


I have a digipeater and igate at home, using a Retevis RT-95 (same radio as the Anytone AT-778UV) with its mic jack and external speaker jack connected to a Digirig Mobile which is connected to a Raspberry Pi 3B+ running Direwolf 1.7. I want to set up a, widerange digipeater-only at my club's repeater site only this time using a Yaesu FT-60R HT with its speaker mic jack connected to the Digirig. 5 watts would be all that's needed as that's all that the repeaters transmit at.

In addition to Thomas's points, you should be aware that running a high level APRS digi with an HT might be bad news depending on the traffic levels.? HT's aren't designed for heavy amounts of TX cycles and your radio might overheat or fail per-maturely.? You also seem like you want to decode weak APRS signals and while a Yaesu FT60 is a quality HT, it's receiver is probably not as good as many common amateur radio mobile radios.? If you can swing it, I think you'll be better served on all fronts with using a mobile radio.? Could be a good opportunity to get a used ex-commercial radio for this fixed function role.

--David
KI6ZHD