Date   

Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

John Schultz
 

No, the Raspi uses multiple time servers for time sync as long as internet is available.  I use a UBlox GPS dongle as my primary time source and a real time clock on the Pi to maintain time.  Try this:

$ sudo chronyc sources -v

That will show you your time sources.  If you had a GPS dongle plugged in NMEA would be at the top of the list with an "x" showing that it was providing time to the Pi.  Yours likely shows a question mark to the left of NMEA.


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

Your not having issues with time sync? I know my windows setup requires RTC to stay sync'd Macbook has no time issue.


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 
Edited

I have not dove into JS8call yet, primarily I operate FT8 & and just started on FT4. This new setup will be a backup to my 7300, however I set it up for my newly coming Xiegu G90 I plan to use for POTA activations.


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

John Schultz
 

Glad to hear it.  What are you planning to operate?  I'm on JS8call 24 x 7 on 7.078.

John
N0JDS


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

Thank You @John Schultz  that worked :-)

73


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

I will check if it set to true or false when I get home and in front of. Work has me tied up most of the day. I will report back with findings.


Re: Morse code program for Raspberry Pi

Dave Wickert
 

Hmm. While SSB does *suppress* the carrier, in practice it does not eliminate it entirely. While your ear might not be able to detect the SSB carrier, it is there if you look for it. For example I can see it on my SDRPlay -- and thus I can see the difference (albeit only a small one). Hope that helps.

73.

_-_-_ Dave, AE7TD

-----Original Message-----
From: RaspberryPi-4-HamRadio@groups.io <RaspberryPi-4-HamRadio@groups.io> On Behalf Of Jim Higgins
Sent: Wednesday, December 11, 2019 11:30 AM
To: RaspberryPi-4-HamRadio@groups.io
Subject: Re: [RaspberryPi-4-HamRadio] Morse code program for Raspberry Pi

Received from Daniel Holmes at 12/11/2019 13:10 UTC:

It also transmits CW using the sound card. On most radios it ends up
being a sideband signal, and not true CW due to the data nature of the
interface, but it’s generally still copyable—I really can’t tell a
difference when II’m working it.

You can't tell a difference a pure single frequency tone into a rig set for SSB produces a pure single frequency RF output.

Same for FSK RTTY and AFSK RTTY. No difference.

73 de Jim, KB3PU


Re: Morse code program for Raspberry Pi

Jim Higgins
 

Received from Daniel Holmes at 12/11/2019 13:10 UTC:

It also transmits CW using the sound card. On most radios it ends up being a sideband signal, and not true CW due to the data nature of the interface, but it’s generally still copyable—I really can’t tell a difference when II’m working it.

You can't tell a difference a pure single frequency tone into a rig set for SSB produces a pure single frequency RF output.

Same for FSK RTTY and AFSK RTTY. No difference.

73 de Jim, KB3PU


Re: PI-TNC Configure issue with LINBPQ and Bluetooth

Dan Dicke
 



Dan Dicke Electric
Sent via IPhone

On Dec 11, 2019, at 09:37, Dan Dicke Electric <res0xgcr@...> wrote:


<image0.jpeg>
As you can see I have the serial addresses ttyS0 and ttyAMA0. I currently have one pi-tnc 2 on my pi 4 and the second one coming probably Saturday to stack on top. After putting the tnc together I tested it and got good tones heard out through my mobile radio on another radio and my yellow DCD light comes on when receiving packet clusters so the tnc appears to be working. But I don’t have any connection to Pat winlink to it because I obviously don’t have something set correctly. I was an ADA software engineer for 11 years but that was 20 years ago. Never wanted to get near Linux and now I need to. Hehe

I don’t have bpq installed, tried and messed everything up using the bpq-config which I now know not to use, which lost my Bluetooth capabilities. So I, fortunately, had backed up my sad card before doing that so I reverted back to the previous ver and got my Bluetooth back

So going forward I believe that I need to use i2c to connect two tnc-pi’s. 

So I guess next step is to try to get bpq installed and working with one tnc without losing Bluetooth 

Dan
KE6NYT 

Dan Dicke Electric
Sent via IPhone

On Dec 11, 2019, at 08:07, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hello John, Everyone,

Good morning..

This problem arose when Pi models with Bluetooth were introduced. The system
originally uses the main serial port /dev/ttyAMA0 for Bluetooth and assigned
the second serial port /dev/ttyS0 to the Pi Header. This meant that which
port you had to use depended on the model of Pi you were using. This lead to
a lot of confusion and a lot of hacks were published, some of which disabled
Bluetooth and some moved it to the other port.

Many of the guides out there (including mine) disable bluetooth to give the GPIO-connected serial port access to the hardware UART.  This is required as the secondary serial port that the serial port was getting connected to is variably timed and thus is not very reliable for heavier traffic on the serial port.  Here is an extensive thread on the topic:

   https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=138223


The Pi team realised their mistake, and for the past couple of years the
system creates a symbolic link (think alias if you are not familiar with
Linux terminology) /dev/serial0 to whichever port is assigned to the Pi
Header. So applications can use /dev/serial0 for any model of Pi.

This is true only if the serial port is enabled via raspi-config or the user adds "enable_uart=1" in /boot/config.txt.  Once that's done, you'd see the following for a system that has bluetooth and console serial enabled:
--
# ls -la /dev | grep serial
drwxr-xr-x  4 root root          80 Dec 11 07:45 serial
lrwxrwxrwx  1 root root           5 Dec 11 07:45 serial0 -> ttyS0
lrwxrwxrwx  1 root root           7 Dec 11 07:45 serial1 -> ttyAMA
--
If the serial port isn't enabled (even without console services), the symlink for the Bluetooth side won't be created either


Many of the installation instructions for the TNC talk about editing files
cmdline.txt and config.txt. This is no longer necessary, and the suggested
changes are likely to break things.

While I agree that using raspi-config is user friendly, it's only a GUI tool to set the correct parameters in various /boot config files.  There is no magic here but yes, over time, config files can change so the user will need to adapt if things are changed. 

--David
KI6ZHD


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

John Schultz
 
Edited

The reason I asked if GPSD is set up on your Pi is because these are the exact symptoms I experience with my Icom 7200 if USBAUTO="true" in the file /etc/default/gpsd.  Once USBAUTO="false" everything works fine.

$ cat /etc/default/gpsd

Does that return a file with info?


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

my knowledge of linux/Pi coding is minimum and I learn more each day.


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

GPSD isnt issue, that was a response to last reply. Main issue is getting flrig, fldigi and now see wjst wont connect to ic-7300, I ran lsusb and it shows the silicon labs device which is the 7300. But when I select that port is software settings of these apps and choose baud rate which I know is correct, it won’t initialize and connect.


Re: Morse code program for Raspberry Pi

David Ranch
 


It's been discussed many times in various linux forums but doing CW properly isn't very easy.  The consensus keeps coming back to using a keyer such as a WinKeyer chip maintain proper TX timing, etc.  There are various Linux programs that support the Winkeyer but to get superior decodes, I would recommend to start with Flwkey as a lot of effort has gone into that code to decipher variably timed transmissions, decode through various weak signal and fade scenarios, etc:

   http://www.w1hkj.com/flwkey-help/

--David
KI6ZHD



On 12/10/2019 09:35 AM, Daniel Holmes wrote:
I’m not familiar with the exact setup (In college around the same time, I wrote an x86 assembly program for a class to decode CW via serial port!), but FLDIGI will decode CW nicely using a sound card setup.

Dan
--
Daniel Holmes, danielh@...
"Laugh while you can, monkey boy!" -- Lord John Whorfin


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mark Griffith
 

On a Raspberry Pi, you don't need to use gpsd unless you want constant updating of the time and such.  Usually, updating the time at boot is sufficient.

I use simpler techniques which work pretty good.

If all you want to do is update the system time and the current GPS coordinates when the Pi boots, I do this:

First setup the serial port for NEMA standards, which are 4800 baud:

DEVICE="/dev/ttyUSB0"
stty -F $DEVICE ispeed 4800 > /dev/null 2>&1

Then proceed to grab the raw data from the port:

cat < $DEVICE

If you want to decode the stream, pipe it to gpsdecode

cat < $DEVICE | gpsdecode

After that, you'll have to do some great regular expression work to pull the data from the decoded stream.  I put about 30 seconds worth into a data file to give the GPS receiver time to sync to a few satellites, and then extract from there:

GPSTIME=`tail -1 /var/tmp/gpstmp | sed -r 's/.*"time":"([^"]*)".*/\1/'`
GPSCOORDS=`tail -1 /var/tmp/gpstmp | grep -om1 "[-]\?[[:digit:]]\{1,3\}\.[[:digit:]]\{9\}"`

Then you can do something with that information.  If you want to update the time and GPS coords on a regular basis, use cron to run the same script every hour or every 6 hours, etc.

Like a said, a simple way, but it works well when gpsd decides it wants to be cranky.

Just my 2 cents.

Mark
KD0QYN


On Wednesday, December 11, 2019, 9:20:02 AM CST, John Schultz <sturmgewehr762@...> wrote:


If GPSD is configured on your system I suspect that is the issue.  I just posted a thread about my Icom issue and the solution here in the group.

John


Re: PI-TNC Configure issue with LINBPQ and Bluetooth

David Ranch
 


Hello John, Everyone,

Good morning..

This problem arose when Pi models with Bluetooth were introduced. The system
originally uses the main serial port /dev/ttyAMA0 for Bluetooth and assigned
the second serial port /dev/ttyS0 to the Pi Header. This meant that which
port you had to use depended on the model of Pi you were using. This lead to
a lot of confusion and a lot of hacks were published, some of which disabled
Bluetooth and some moved it to the other port.

Many of the guides out there (including mine) disable bluetooth to give the GPIO-connected serial port access to the hardware UART.  This is required as the secondary serial port that the serial port was getting connected to is variably timed and thus is not very reliable for heavier traffic on the serial port.  Here is an extensive thread on the topic:

   https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=138223


The Pi team realised their mistake, and for the past couple of years the
system creates a symbolic link (think alias if you are not familiar with
Linux terminology) /dev/serial0 to whichever port is assigned to the Pi
Header. So applications can use /dev/serial0 for any model of Pi.

This is true only if the serial port is enabled via raspi-config or the user adds "enable_uart=1" in /boot/config.txt.  Once that's done, you'd see the following for a system that has bluetooth and console serial enabled:
--
# ls -la /dev | grep serial
drwxr-xr-x  4 root root          80 Dec 11 07:45 serial
lrwxrwxrwx  1 root root           5 Dec 11 07:45 serial0 -> ttyS0
lrwxrwxrwx  1 root root           7 Dec 11 07:45 serial1 -> ttyAMA
--
If the serial port isn't enabled (even without console services), the symlink for the Bluetooth side won't be created either


Many of the installation instructions for the TNC talk about editing files
cmdline.txt and config.txt. This is no longer necessary, and the suggested
changes are likely to break things.

While I agree that using raspi-config is user friendly, it's only a GUI tool to set the correct parameters in various /boot config files.  There is no magic here but yes, over time, config files can change so the user will need to adapt if things are changed. 

--David
KI6ZHD


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

Mike - KD6BOS
 

I have not yet setup GPSD, unless it is setup as a default. I will try to find your thread and take a look at your findings.


Re: W3DJS Raspberry Pi Ham Radio Image v2.0 Released

John Schultz
 

If GPSD is configured on your system I suspect that is the issue.  I just posted a thread about my Icom issue and the solution here in the group.

John


Re: Raspi, Icom 7200 and GPS, cannot make this combination work

John Schultz
 

Thanks Kevin,

Yes the key piece of that info is to set USBAUTO to "false".  All of the tutorials set this to "true" and that's where our problems begin.

In fact, I cannot think of a reason why I would want this set to "true" on any of my systems so, I'm resetting that flag to false even on the currently working systems, that way there are no surprises in the future.

John


Re: Raspi, Icom 7200 and GPS, cannot make this combination work

Kevin
 

Had the same issue with IC-7300, the issue is with the configuration of the gpsd.

sudo nano /etc/default/gpsd

verify/edit following entries:

START_DAEMON=”true”
USBAUTO=”false”
DEVICES=”/dev/ttyACM0”
GPSD_OPTIONS=”-n”

Hit ctl-x y enter


Re: Raspi, Icom 7200 and GPS, cannot make this combination work

John Schultz
 

Well as it turns out, that tip from Jason about PPS was the key to the solution. 

I ran CGPS and paid attention closely to what was being displayed at the bottom.  CGPS was not working in spite of the presence of a GPS dongle.  As it turns out, CGPS was attempting to use ttyUSB0 (the radio) as it's source of GPS info. 

So I looked at /etc/default/gpsd and saw that ttyACM0 was correctly identified in that file however USBAUTO was set to "True".  This meant that USB plug in devices other than ttyACM0 were allowed to be added to the GPS daemon.  I flipped that flag to "false" rebooted and everything worked!  So while I do not know why the radio was being detected as a GPS source, constraining the GPS daemon to only allow ttyACM0 is the solution in this case.

In the photos:
CGPS is functioning
NMEA is recognized as a system time source
FLRig is connected to the rig and happy

John