¿ªÔÆÌåÓý

  1. Direwolf
  2. Messages
Expanded Topics Messages Polls
Date
Re: iGate from direwolf or YAAC

 

When I think of YAAC (and many other APRS Clients), I think of maps, and other 'visual' aspects of receiving APRS data from a variety of sources.

When I think of Direwolf, AGW, aprx, etc.? I think of only the interface part.

So, if you are just looking at moving data around between ports (radios, internet, etc.) then Direwolf has a lot less overhead - and you can still interface with applications like YAAC.

Robert Giuliano
KB8RCO



On Thursday, October 14, 2021, 11:10:39 AM EDT, Danny K5CG via groups.io <k5cg@...> wrote:


Hello all,

I've got a PI400 connected to a TM-V71A and I've been using YAAC to iGate.

I've shut off the YAAC port for aprsis and added the parameters to direwolf.conf and verified it is working.

Is there any advantage/disadvantage/difference having direwolf do it instead of YAAC?

Thanks
Danny

Re: iGate from direwolf or YAAC

 

Direwolf can do full iGating and would simplify your software chain.


On Thu, Oct 14, 2021 at 11:10 AM Danny K5CG via <k5cg=[email protected]> wrote:
Hello all,

I've got a PI400 connected to a TM-V71A and I've been using YAAC to iGate.

I've shut off the YAAC port for aprsis and added the parameters to direwolf.conf and verified it is working.

Is there any advantage/disadvantage/difference having direwolf do it instead of YAAC?

Thanks
Danny



--

73,
AB1PH
Don Rolph
iGate from direwolf or YAAC

 

Hello all,

I've got a PI400 connected to a TM-V71A and I've been using YAAC to iGate.

I've shut off the YAAC port for aprsis and added the parameters to direwolf.conf and verified it is working.

Is there any advantage/disadvantage/difference having direwolf do it instead of YAAC?

Thanks
Danny
Re: alsaloop for multimode

 

¿ªÔÆÌåÓý

For anyone who wants reasonably comprehensive information on how 9600 v 1200 is handled in the V-71, take a look at page 9 of the Kenwood service manual for a complete description, including levels.?



The information builds substantially on the basic information contained in the instruction manual.


On 9/10/21 11:11 am, David Ranch wrote:

There is a setting in the Kenwood V71 to enable TX pre-emphasis and narrower (aka "1200") or disable TX pre-emphasis (aka "9600"):

?? --> PDF page 83 --> Menu 518 (DAT.SPD)


Per Basil's email, he acknowledged he's always sending without pre-emphasis.? I agree that Direwolf and some modern TNCs will cope with this but many legacy TNCs (MFJ TNC2-design and many basic PIC-based TNCs like TNC-X can have issues with the resulting signal after the local "classic radio" applies the standard de-emphasis circuit.? This is well described here:

??
+1

On this very topic, I'm personally torn to keep "legacy compatibility" or say "screw the old hardware, let's move on with newer stuff".? It would be slick if Direwolf could apply an emulated pre-emphasis to only the 1200bps AFSK signal.? If that was there, I think we could have the best of both worlds here.
It's probably easy for members of a Direwolf list to think old hardware has disappeared but I strongly suspect it exists in large numbers "in the wild". I think that all users should stick with long-standing convention with regard to pre-emphasis for 1k2 packet to minimise network connection issues with hardware based sites.

--David
KI6ZHD
Ray vk2tv


On 10/08/2021 02:51 PM, Rob Giuliano via groups.io wrote:
FYI, the 6-pin miniDIN 'data jack' does not have a separate TX audio pin
1??? Data In (Mic)????????4???? 9600bps RX Audio out (from radio)
2??? Ground???????????????? 5 ????1200bps RX Audio out (from Radio)
3??? PTT????????????????????? 6 ????Sql

So, either both modes send data directly into the discriminator, or neither does.
????? The TX TWIST concern should be the same for either.

Robert Giuliano
KB8RCO



On Friday, October 8, 2021, 04:57:53 PM EDT, Basil Gunn <basil@...> wrote:


  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

¿ªÔÆÌåÓý


There is a setting in the Kenwood V71 to enable TX pre-emphasis and narrower (aka "1200") or disable TX pre-emphasis (aka "9600"):

?? --> PDF page 83 --> Menu 518 (DAT.SPD)


Per Basil's email, he acknowledged he's always sending without pre-emphasis.? I agree that Direwolf and some modern TNCs will cope with this but many legacy TNCs (MFJ TNC2-design and many basic PIC-based TNCs like TNC-X can have issues with the resulting signal after the local "classic radio" applies the standard de-emphasis circuit.? This is well described here:

??

On this very topic, I'm personally torn to keep "legacy compatibility" or say "screw the old hardware, let's move on with newer stuff".? It would be slick if Direwolf could apply an emulated pre-emphasis to only the 1200bps AFSK signal.? If that was there, I think we could have the best of both worlds here.

--David
KI6ZHD


On 10/08/2021 02:51 PM, Rob Giuliano via groups.io wrote:

FYI, the 6-pin miniDIN 'data jack' does not have a separate TX audio pin
1??? Data In (Mic)????????4???? 9600bps RX Audio out (from radio)
2??? Ground???????????????? 5 ????1200bps RX Audio out (from Radio)
3??? PTT????????????????????? 6 ????Sql

So, either both modes send data directly into the discriminator, or neither does.
????? The TX TWIST concern should be the same for either.

Robert Giuliano
KB8RCO



On Friday, October 8, 2021, 04:57:53 PM EDT, Basil Gunn <basil@...> wrote:


  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

I remember asking the Yaesu rep when I bought my FT7100 (years ago now) .
He told me that radio only changed the receive pin.? That was all that was needed.

Rob KB8RCO


On Fri, Oct 8, 2021 at 18:04, Greg D
<ko6th.greg@...> wrote:
Yes, unless the radio "knows" you're in 1k2 vs 9k6 mode, and adjusts the audio path internally as a result.

My own Yaesu FT-847 has such a mode.? The user guide doesn't talk much about what it does other than to say that if one is trying to run 2400 baud "you may have to experiment with this Menu selection".? That implies it does affect the transmit audio path, if not the receive as well.

Greg? KO6TH


Rob Giuliano via groups.io wrote:
FYI, the 6-pin miniDIN 'data jack' does not have a separate TX audio pin
1??? Data In (Mic)????????4???? 9600bps RX Audio out (from radio)
2??? Ground???????????????? 5 ????1200bps RX Audio out (from Radio)
3??? PTT????????????????????? 6 ????Sql

So, either both modes send data directly into the discriminator, or neither does.
????? The TX TWIST concern should be the same for either.

Robert Giuliano
KB8RCO



On Friday, October 8, 2021, 04:57:53 PM EDT, Basil Gunn <basil@...> wrote:


  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

¿ªÔÆÌåÓý

Yes, unless the radio "knows" you're in 1k2 vs 9k6 mode, and adjusts the audio path internally as a result.

My own Yaesu FT-847 has such a mode.? The user guide doesn't talk much about what it does other than to say that if one is trying to run 2400 baud "you may have to experiment with this Menu selection".? That implies it does affect the transmit audio path, if not the receive as well.

Greg? KO6TH


Rob Giuliano via groups.io wrote:

FYI, the 6-pin miniDIN 'data jack' does not have a separate TX audio pin
1??? Data In (Mic)????????4???? 9600bps RX Audio out (from radio)
2??? Ground???????????????? 5 ????1200bps RX Audio out (from Radio)
3??? PTT????????????????????? 6 ????Sql

So, either both modes send data directly into the discriminator, or neither does.
????? The TX TWIST concern should be the same for either.

Robert Giuliano
KB8RCO



On Friday, October 8, 2021, 04:57:53 PM EDT, Basil Gunn <basil@...> wrote:


  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

FYI, the 6-pin miniDIN 'data jack' does not have a separate TX audio pin
1??? Data In (Mic)????????4???? 9600bps RX Audio out (from radio)
2??? Ground???????????????? 5 ????1200bps RX Audio out (from Radio)
3??? PTT????????????????????? 6 ????Sql

So, either both modes send data directly into the discriminator, or neither does.
????? The TX TWIST concern should be the same for either.

Robert Giuliano
KB8RCO



On Friday, October 8, 2021, 04:57:53 PM EDT, Basil Gunn <basil@...> wrote:


  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

  • With your setup, is this doing simultaneous decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency? It looks like it might be able to RX this way but not transmit. Not clear to me.

I've tested this a lot and contrary to other posters doing 1200 baud packet with your radio set to 9600 baud works quite well.

  • Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode

Yes

where you send all TX audio directly into the discriminator for transmission?

Does not appear to matter. I run all my packet gateways this way.

If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

I have NOT seen this as an issue. It certainly is NOT an issue for direwolf. I test with a KPC3+ a couple of times a year. That's a bench test and the "twist" issue could possibly be a problem with more marginal signals (or not as I have yet to experience that)

My primary goal was to transition my gateways to 9600 baud packet while still offering 1200 baud service. I've gone through a few iterations of solving this problem and have been testing and using the TM-V71a discriminator with 1200 baud packet for over a year now. Just thought I would mention my experience with PulseAudio and what did in fact work for me. (See previous github link).
Re: alsaloop for multimode

 

¿ªÔÆÌåÓý


Hello Basil,

Few questions if I may:

?? - With your setup, is this doing *simultaneous* decodes of 1200bps AFSK and 9600bps FSK signals on the same frequency?? It looks like it might be able to RX this way but not transmit.? Not clear to me.

?? - Does this solution mean you have the radio (looks like your using a Kenwood v71) always in "9600baud" mode where you send all TX audio directly into the discriminator for transmission?? If so, this means that all 1200bps modem tones won't have the expected pre-emphassis applied to the transmission and many remote legacy TNCs might not decode the packets due to the "twist" issue between the two tones having different signal levels.

--David
KI6ZHD



On 10/08/2021 08:22 AM, Basil Gunn wrote:

I didn't use alsaloop. I just made a Y mdin6 cable. This specifically was to run 1200 & 9600 baud packet on a single channel. Note that the PTT for both channels is tied together which for my case works fine.

I have this configuration working for Winlink email, Linux RMS Gateway & APRS Gateway using a Kenwood TM-V71a radio.

/Basil n7nix
Re: alsaloop for multimode

 

I didn't use alsaloop. I just made a Y mdin6 cable. This specifically was to run 1200 & 9600 baud packet on a single channel. Note that the PTT for both channels is tied together which for my case works fine.

I have this configuration working for Winlink email, Linux RMS Gateway & APRS Gateway using a Kenwood TM-V71a radio.

/Basil n7nix
alsaloop for multimode

 

did anybody try to divide the audio capture of the radio audio card into alsaloop and get some more outputs, which are fed into several direwolf instances with different configuration of speed (AFSK 1k2, QPSK 2k4,? 8-PSK 4k8)?

Michael
Re: rPi 4 / Signalink USB / Yaesu ft-895 / Direwolf.

 

The KPC-3+ and KPC-3 each use chips designed for 'wired' data transfer at 1200 baud.
You have to believe these chips were design with a lot better Signal to Noise Ratio that is common in radio.
Also, they are quite old.? A lot of Digital Signal Processing algorithms have been developed since those days.

FWIW, the TNC-X from Coastal ChipWorks (now MFJ-1270X) still uses the MX614 chip.?
I have one of the earliest ones and newer one.? Neither decode as well as a properly configured TT4 or better yet are any software modem - especially Direwolf!

Just my opinion, but I am guessing you will find the same.
This past week, I thought my TNC-X had failed.? It didn't seem to be decoding any signals.? So I ran the TNC-X and a Pi with Direwolf (Fe-Pi sound card) using a 6-pin miniDIN tee to feed the audio signal to both (disconnected PTT and TX on one).? Direwolf decoded more signals (estimate of about 20%).? I would imagine the 20% were the weaker signals.

In the end, it turned out the local DIGI was down, so most signals just weren't making it to my antenna.? Once the DIGI came back, my decodes where normal again.? In the end, the TNC-X works fine, but the sound card and Direwolf definitely worked better.?


Robert Giuliano
KB8RCO


On Thursday, October 7, 2021, 06:52:59 AM EDT, J K via groups.io <kuhnje@...> wrote:


Hello,

Thanks for the info on the Kantronics KPC-3+.? From what a gather, they are older, don¡¯t decode as well as current software modems even, but are oldies, buy goodies with mailbox features built-in.? Wanted to try one out for a while, so probably will pick one up.? When I get my board up and running, planning to use the KPC-3+ for it.? Already have a bit of stuff though: two SignalLinks with cables for Yaesu 8900R, Alinco DR-235, Anytone AT-779UV, TYT 9800, Kenwood K2-2pin HT¡¯s (such as Baofeng, TYT).? Also have a MoblinkD TNC3 (with cables also fir everything above).? Then of course a RPi¡¯s running DireWolf and a few EasyDigi¡¯s.? Two with USB control, one just VOX.? OCD probably, but like checking everything out.? Wants to get a Kantronics KPac-3+ for quite a while. :-)

11 Max Pro






M223
Re: rPi 4 / Signalink USB / Yaesu ft-895 / Direwolf.

 

Hello,

Thanks for the info on the Kantronics KPC-3+. From what a gather, they are older, don¡¯t decode as well as current software modems even, but are oldies, buy goodies with mailbox features built-in. Wanted to try one out for a while, so probably will pick one up. When I get my board up and running, planning to use the KPC-3+ for it. Already have a bit of stuff though: two SignalLinks with cables for Yaesu 8900R, Alinco DR-235, Anytone AT-779UV, TYT 9800, Kenwood K2-2pin HT¡¯s (such as Baofeng, TYT). Also have a MoblinkD TNC3 (with cables also fir everything above). Then of course a RPi¡¯s running DireWolf and a few EasyDigi¡¯s. Two with USB control, one just VOX. OCD probably, but like checking everything out. Wants to get a Kantronics KPac-3+ for quite a while. :-)

Sent from my iPhone 11 Max Pro
Re: USB soundcard on raspi

Serge
 

Hi everyone,
after several tests, Brent's proposal since to work fine for me
So Brent, thanks for your help.

By the way, I'm working on an APRS based paging system for the B-EARS (Belgian Emergency Amateur Radio Service).
A alternative to POCSAG.

73's Serge ON5MZ
Re: Repeating "GPSD: Location fix is now 2D/3D"

 

WSPR needs to be timed within the window.
Many microcontroller based WSPR (and some other modes) transmitters use the PPS to time the TX because microcontroller crystals won't keep accurate enough time when run over long periods of time.?

Also, since the WSPR TX frequency window is only 200 Hz wide (per band), many use the PPS to correct the frequency to keep in within the window over varying operating conditions (in place of a TCXO).?

Robert Giuliano
KB8RCO



On Wednesday, October 6, 2021, 10:40:50 PM EDT, David Ranch <direwolf-groupsio@...> wrote:



?
I completely disagree, there are all sorts of things that need that precision in ham radio, Voting and simulcast to name a couple.

Ok.. you got me there.. simulcasting and accurate voting repeater systems really do need precision clocks but I would argue they only need accurate time amoungst eachother.? I don't know if they really need to be aligned to the world clock.? Anyway.

--David
KI6ZHD
Re: Repeating "GPSD: Location fix is now 2D/3D"

 

¿ªÔÆÌåÓý


?
I completely disagree, there are all sorts of things that need that precision in ham radio, Voting and simulcast to name a couple.

Ok.. you got me there.. simulcasting and accurate voting repeater systems really do need precision clocks but I would argue they only need accurate time amoungst eachother.? I don't know if they really need to be aligned to the world clock.? Anyway.

--David
KI6ZHD
Re: RFI issues with RPi3B+

 

I still to try the Fe-Pi clone hat, but bought a cheap Sabrebt (one with volume control on it and you can turn headphone and mic off by buttons). Have four cheap Sabrent USB audio, plus this one now. No Linder having any RFI issues. Might just continue using Sabrent witty controls. I like that just a push of button can turn iGate off or difioeater off, while keeping other running.

Sent from my iPhone 11 Max Pro

On Sep 13, 2021, at 4:19 PM, J K via groups.io <kuhnje@...> wrote:

?Have the hats coming now, which I¡¯m sure will wire fine. I¡¯ll probably use the one that is similar to the Fe-Pi and around with the Audio injector for something else.

Also, found this USB audio adapter in one of my junk drawers that I totally forgot about. If picture can¡¯t be posted here, it¡¯s one of those USB audio adapters that has about a 4¡± USB cable, then has a volume dial on the adapter itself, plus buttons turn on/off the speaker or microphon independent. It¡¯s working and is kind of cool because it¡¯s another point to adjust volume (found it works well to use dongle knob to make fine adjustments), plus the button switches are pretty cool if you, say, want to turn off the digipeter but still have iGate running (or vice-versa). Found my RFI issue really wasn¡¯t much of an issue anyway now that I¡¯m connected to an outdoor antenna (Diamond V2000A). Very cool. I¡¯d say with the dongles, it¡¯s seems about 99% solidrbut expect with a hat it to be 100^. :-)



Sent from my iPhone 11 Max Pro




image0.jpeg

Re: Repeating "GPSD: Location fix is now 2D/3D"

 



On Wed, Oct 6, 2021 at 3:56 PM David Ranch <direwolf-groupsio@...> wrote:

?There is arguably NOTHING in amateur radio that needs this level of precision other than maybe than bragging rights

??
I completely disagree, there are all sorts of things that need that precision in ham radio, Voting and simulcast to name a couple.?


--David
KI6ZHD



On 10/06/2021 02:37 PM, Rob Giuliano via wrote:
A lot of conversation about the PPS.
I am pretty sure ths conversation was about getting position infomration through gpsd, not time (beyond the data stamp).
I have no idea how a Garmin GLO2 could implement a PPS - its Bluetooth.

Is this just additional commentary for tose using gpsd for more than position?
? I don't see anything on PPS in the Direwolf manual.
? I am not sure how Direwolf benefits from a PPS?

Not trying to be critical, just checking if I missed something.

Robert Giuliano
KB8RCO


On Wednesday, October 6, 2021, 12:33:07 PM EDT, Fred Hillhouse <fmhillhouse@...> wrote:


Hi Ray,

Thanks for the link. I think my networked GPS (u-blox) has 1PPS. I haven't really checked it out. The Garmin GLO2 doesn¡¯t have the capabilities. At least, that is what I gather from ppscheck. This project doesn't need it and hopefully the JS8CALL project doesn't either.

Fred N7FMH

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ray Wells
Sent: Friday, October 01, 2021 8:55 PM
Subject: Re: [direwolf] Repeating "GPSD: Location fix is now 2D/3D"

Fred,

I know you've done the hard yards and it's working for you but you may
still find this page about gpsd interesting.


FWIW I ran into the same 2D/3D problem as you but I can't remember which
(RS232) GPS (Garmin 18 series or older Ublox) I used at the time. I
ended up compiling GPSD from sources to get an updated version. But this
was near enough to two years ago.

Ray vk2tv

On 2/10/21 9:18 am, Fred Hillhouse wrote:
>
> Hi David,
>
>
>
> Thanks for the update and how strange if this was a gpsd thing.? What
> version were you running before?
>
> Version 3.17
>
> Gary¡¯s comment: Wow, that is 4 years old.? You need to update that.
> 3.23.1 is current.
>
> I am not sure but came from the apt repository. I didn¡¯t install gpsd
> initially on this RPI. I wouldn¡¯t have done a build from source.
>
> Do you know what was the specific fix in the newer GPSD that resolved
> your problem?
>
> Sorry I don¡¯t.
>
> Best regards,
>
> Fred N7FMH
>
> --David
> KI6ZHD
>
> On 10/01/2021 02:30 PM, Fred Hillhouse wrote:
>
>? ? Problem has been resolved. I now get a solid 3D fix.
>
>? ? The solution: update to the latest revision of GPSD. Revision 3.23.1
>
>? ? As background, I have a Garmin GLO 2 which will support up to four
>? ? users. A similar unit is the Dual XGPS160. I have used it in the
>? ? past for an Android tablet with the hopes of also sharing with an
>? ? RPi. Currently, The tablet, RPI and my PC are receiving data.
>
>? ? I was asked why I would use a GPS like this. When running multiple
>? ? RPIs, which may not have sky view, a GPS with a view can share
>? ? with each.
>
>? ? Best regards,
>
>? ? Fred N7FMH
>
>? ? [mailto:[email protected] <mailto:[email protected]>] *On Behalf
>? ? Of *Fred Hillhouse
>? ? *Sent:* Wednesday, September 29, 2021 5:06 PM
>? ? *Subject:* Re: [direwolf] Repeating "GPSD: Location fix is now 2D/3D"
>
>? ? GPS has been running for at least a day.
>
>
>? ? Define "GPS has been running for at least a day".? By default,
>? ? your GPS puck won't be activated by gpsd and start listening for
>? ? GPS details until it has a listening client like direwolf, cgps,
>? ? gpsmon, etc.? This seems to be a default for minimizing power
>? ? consumption.? The gpsmon tool doens't show how long it's been
>? ? running with a 3D fix but cgps does.
>
>? ? The GPS has had a device connected to a device. It supports 4
>? ? different devices. One device is the same RPi Direwolf is running
>? ? on but is an terminal window on my PC with /cgps /running. Now a
>? ? second device (PC/u-center) is connected.
>
>? ? What constitutes a ¡°very good¡± lock?
>
>
>? ? That's evidently a huge topic in itself and is well outside the
>? ? scope of this Direwolf.? I did a search for "gpsd 3d lock" and
>? ? this hit seems like a good start:
>
>? ?
>? ? <>
>
>? ? A key point in that article is that though your system lists it's
>? ? using X satellites, it doesn't mean it's hearing them well.? This
>? ? can be due to local RF interference, etc.
>
>? ? I can see I have a 3D position all the time now that my Windows PC
>? ? is connected. I am aware of the FIX differences and how everything
>? ? can affect the satellite signal; trees buildings, angle of
>? ? antenna, etc. Not being snarky! If this was a serial GPS or a
>? ? USB-GPS (serial?) there would be no BT layer and for serial, using
>? ? /dev/ttyS0 would be correct and USB would be similar. Based on an
>? ? exchange with Robert KB8RCO it seems this maybe the case here. If
>? ? may be that each of the four possibilities need /dev/ttys0-3? In
>? ? the end, I will have learned a little more.
>
>? ? This is what I get when running /gpsmon/. Any clues there?
>
>
>? ? More information is available in cgps but there are other tools
>? ? available to troubleshoot GPS issues such as gpsprof but I've
>? ? never used them.? Ultimately, I don't think your issue is with
>? ? Direwolf.. it's going to be somewhere in the GPS into GPSD area.
>? ? I would start here:
>? ? <>
>
>? ? I will certainly check this group. From my PC experience on
>? ? needing to actually connect to a COM port, I wonder if a RPi
>? ? ¡°comport¡± must be connected as well. Robert, KB8RCO, suggested
>? ? something regarding auto-connecting at reboot but I haven¡¯t chased
>? ? that since the basic connection is not functional yet.
>
>? ? Thank you!
>
>? ? Fred N7FMH
>
>
>? ? Screenshots from the u-blox u-center app:
>
>? ? ------------------------------------------------------------------------
>
>? ? Avast logo <>
>
>
>
>? ? This email has been checked for viruses by Avast antivirus software.
>? ? <>
>
>
>
>
>








--
This email has been checked for viruses by Avast antivirus software.
Re: Repeating "GPSD: Location fix is now 2D/3D"

 

If I build a Stratum1 network Time Server, I'll get something that can do the job. For now, positioning is good.


Fred N7FMH

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ray Wells
Sent: Wednesday, October 06, 2021 4:53 PM
To: [email protected]
Subject: Re: [direwolf] Repeating "GPSD: Location fix is now 2D/3D"

Hi Fred,

Both my Ublox devices - LEA4 (IIRC) and a considerably newer M8 - have
1PPS so yours likely does too. The Garmin I dabbled with was the 18-5Hz
with sentences sent five times per second for better positional accuracy
but its PPS seemed to not play nicely with gpsd. Either that or I wasn't
smart enough to make it happen! I cut my losses and bought the M8 board
for the RPi4 for my Stratum 1 network time server.

Take care

Regards
Ray vk2tv



On 7/10/21 3:33 am, Fred Hillhouse wrote:
Hi Ray,

Thanks for the link. I think my networked GPS (u-blox) has 1PPS. I haven't really checked it out. The Garmin GLO2 doesn¡¯t have the capabilities. At least, that is what I gather from ppscheck. This project doesn't need it and hopefully the JS8CALL project doesn't either.

Fred N7FMH

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ray Wells
Sent: Friday, October 01, 2021 8:55 PM
To: [email protected]
Subject: Re: [direwolf] Repeating "GPSD: Location fix is now 2D/3D"

Fred,

I know you've done the hard yards and it's working for you but you may
still find this page about gpsd interesting.


FWIW I ran into the same 2D/3D problem as you but I can't remember which
(RS232) GPS (Garmin 18 series or older Ublox) I used at the time. I
ended up compiling GPSD from sources to get an updated version. But this
was near enough to two years ago.

Ray vk2tv

On 2/10/21 9:18 am, Fred Hillhouse wrote:
Hi David,



Thanks for the update and how strange if this was a gpsd thing. What
version were you running before?

Version 3.17

Gary¡¯s comment: Wow, that is 4 years old. You need to update that.
3.23.1 is current.

I am not sure but came from the apt repository. I didn¡¯t install gpsd
initially on this RPI. I wouldn¡¯t have done a build from source.

Do you know what was the specific fix in the newer GPSD that resolved
your problem?

Sorry I don¡¯t.

Best regards,

Fred N7FMH

--David
KI6ZHD

On 10/01/2021 02:30 PM, Fred Hillhouse wrote:

Problem has been resolved. I now get a solid 3D fix.

The solution: update to the latest revision of GPSD. Revision 3.23.1

As background, I have a Garmin GLO 2 which will support up to four
users. A similar unit is the Dual XGPS160. I have used it in the
past for an Android tablet with the hopes of also sharing with an
RPi. Currently, The tablet, RPI and my PC are receiving data.

I was asked why I would use a GPS like this. When running multiple
RPIs, which may not have sky view, a GPS with a view can share
with each.

Best regards,

Fred N7FMH

*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On Behalf
Of *Fred Hillhouse
*Sent:* Wednesday, September 29, 2021 5:06 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [direwolf] Repeating "GPSD: Location fix is now 2D/3D"

GPS has been running for at least a day.


Define "GPS has been running for at least a day". By default,
your GPS puck won't be activated by gpsd and start listening for
GPS details until it has a listening client like direwolf, cgps,
gpsmon, etc. This seems to be a default for minimizing power
consumption. The gpsmon tool doens't show how long it's been
running with a 3D fix but cgps does.

The GPS has had a device connected to a device. It supports 4
different devices. One device is the same RPi Direwolf is running
on but is an terminal window on my PC with /cgps /running. Now a
second device (PC/u-center) is connected.

What constitutes a ¡°very good¡± lock?


That's evidently a huge topic in itself and is well outside the
scope of this Direwolf. I did a search for "gpsd 3d lock" and
this hit seems like a good start:


<>

A key point in that article is that though your system lists it's
using X satellites, it doesn't mean it's hearing them well. This
can be due to local RF interference, etc.

I can see I have a 3D position all the time now that my Windows PC
is connected. I am aware of the FIX differences and how everything
can affect the satellite signal; trees buildings, angle of
antenna, etc. Not being snarky! If this was a serial GPS or a
USB-GPS (serial?) there would be no BT layer and for serial, using
/dev/ttyS0 would be correct and USB would be similar. Based on an
exchange with Robert KB8RCO it seems this maybe the case here. If
may be that each of the four possibilities need /dev/ttys0-3? In
the end, I will have learned a little more.

This is what I get when running /gpsmon/. Any clues there?


More information is available in cgps but there are other tools
available to troubleshoot GPS issues such as gpsprof but I've
never used them. Ultimately, I don't think your issue is with
Direwolf.. it's going to be somewhere in the GPS into GPSD area.
I would start here:
<>

I will certainly check this group. From my PC experience on
needing to actually connect to a COM port, I wonder if a RPi
¡°comport¡± must be connected as well. Robert, KB8RCO, suggested
something regarding auto-connecting at reboot but I haven¡¯t chased
that since the basic connection is not functional yet.

Thank you!

Fred N7FMH


Screenshots from the u-blox u-center app:

------------------------------------------------------------------------

Avast logo <>



This email has been checked for viruses by Avast antivirus software.
www.avast.com <>










--
This email has been checked for viruses by Avast antivirus software.













--
This email has been checked for viruses by Avast antivirus software.
4781 - 4800 of 10484