Date   

Re: NWDR18 image release announcement

 

With a little digging you can find the unique identifier for the plugged in CT-62 cable and create a udev description to give it a name that remains consistent between plug-in instances.

An example for the ThumbDV™ is found at 
https://github.com/nwdigitalradio/ambeserver-install/blob/master/etc/udev/rules.d/99-thumbdv.rules
It makes link at /dev/ThumbDV regardless of which ttyUSB# the device is plugged into.

Also doing a ls /dev/serial/by-id will provide a direct path to the plugged in USB serial device.

On Thu, Dec 31, 2020 at 9:20 AM Basil Gunn <basil@...> wrote:

Re-stating your problem to see if I have it right:

CAT control is not working between an RPi 4 and and a Yaesu FT-100D
which is a multiband HF/VHF/UHF radio.
Connection is through a Yaesu CT-62 cable which is an 8 pin mDin to
USB serial device connection.

This has nothing to do with the DRAWS hat!

The most common problem is finding the correct Linux serial device name
for FLdigi/FLrig.

# With the CT-62 disconnected from the RPi find all current USB serial
device names:

  ls /dev/ttyU*
ls: cannot access '/dev/ttyU*': No such file or directory

# In my case their are NO USB serial devices plugged into the RPi.
# Now plug your CT-62 cable into your RPi and execute 'ls' to find the
# name of the serial device.

  ls /dev/ttyU*
/dev/ttyUSB0

# In this case the USB serial device name is /dev/ttyUSB0
# This is the device name to use in your FLdigi/FLrig configuration for
# CAT control.

Note if you unplug/plug your CT-62 cable in your RPi while it is running the
device name will change.

Eric Williams <kf4yep@...> writes:

> Thanks Basil for the rapid response,
>
> That's good to know. So, how do I get the frequencies to show up in
> the display and/or flrig? The cat cable is CT-62 with USB end. No
> serial-to-usb converters in the middle.







--
John D. Hays
Kingston, WA
K7VE

 


Re: NWDR18 image release announcement

Basil Gunn
 

Re-stating your problem to see if I have it right:

CAT control is not working between an RPi 4 and and a Yaesu FT-100D
which is a multiband HF/VHF/UHF radio.
Connection is through a Yaesu CT-62 cable which is an 8 pin mDin to
USB serial device connection.

This has nothing to do with the DRAWS hat!

The most common problem is finding the correct Linux serial device name
for FLdigi/FLrig.

# With the CT-62 disconnected from the RPi find all current USB serial
device names:

ls /dev/ttyU*
ls: cannot access '/dev/ttyU*': No such file or directory

# In my case their are NO USB serial devices plugged into the RPi.
# Now plug your CT-62 cable into your RPi and execute 'ls' to find the
# name of the serial device.

ls /dev/ttyU*
/dev/ttyUSB0

# In this case the USB serial device name is /dev/ttyUSB0
# This is the device name to use in your FLdigi/FLrig configuration for
# CAT control.

Note if you unplug/plug your CT-62 cable in your RPi while it is running the
device name will change.

Eric Williams <kf4yep@gmail.com> writes:

Thanks Basil for the rapid response,

That's good to know. So, how do I get the frequencies to show up in
the display and/or flrig? The cat cable is CT-62 with USB end. No
serial-to-usb converters in the middle.


Re: NWDR18 image release announcement

Eric Williams
 

Thanks Basil for the rapid response,

That's good to know.  So, how do I get the frequencies to show up in the display and/or flrig?  The cat cable is CT-62 with USB end.  No serial-to-usb converters in the middle.


Re: NWDR18 image release announcement

Basil Gunn
 

Eric,

Placing A Hold On Kernel Upgrade
* FOR REFERENCE ONLY, the current Linux kernel is safe to use with
DRAWS
You do NOT need to place a hold on kernel upgrade. That procedure was to
fix a problem that affected the DRAWS overlay last summer.

I will take this reference out of the 'Getting Started Guide' later on
today because that section was "For reference only, the current Linux
kernel is safe to use with DRAWS"

The drivers in the current kernel, 5.4.79-v7l+ #1373, works fine with DRAWS.

kf4yep@gmail.com writes:

Hi team,
I've been having issues with the Draws hat and it is installed on a Pi4. I first tried getting it to work on KM4ACKs Build-a-Pi (Ham experimentation right?). Then I formatted my sd card and followed the getting started guide https://nw-digital-radio.groups.io/g/udrc/wiki/8921 for image nwdr18.img.xz ( http://nwdig.net/downloads/nwdr18.img.xz ) 2020-Dec-05 08:36:33 1.8G and got as far as the fldigi configuration. ax.25/direwolf appeared to work and sent/received appropriately. fldigi keys the radio (yaesu FT-100d attached currently to 1 watt to dummy load) but it appears my cat cable is not reading or setting the radio frequency so I also tried fiddling with flrig to no avail. I stopped here. Reading further:
--------------------------------

* For reference only, the current Linux kernel is safe to use with DRAWS
*

To verify your current kernel version

uname - r
*

You should see: 4.19.118-v7l+

*

If you see : 5.4.51-v7l+ then your DRAWS hat will have problems

* The driver for the TI ads1015 chip is missing in this kernel.
*

To revert your kernel back to 4.19.118 run the following (courtesy of Thomas KF7RSF):

sudo rpi - upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2

*

Do NOT use the following commands:

* apt-get dist-upgrade
* apt full-upgrade

What I saw was not kernel 4.19....
and n7nix's verify_config guide 'sensors' fails to show
ads1015-i2c-1-48
so I try

*

* sudo rpi - upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2

and get sudo: rpi-upgrade: command not found

I formatted (again) and haven't connected to network or configured anything.
First check of uname -r gives me 5.4.79-v7l+

Help, please and thank you!
Eric Williams de KF4YEP



Re: NWDR18 image release announcement

Eric Williams
 

Hi team,
I've been having issues with the Draws hat and it is installed on a Pi4.  I first tried getting it to work on KM4ACKs Build-a-Pi (Ham experimentation right?). Then I formatted my sd card and followed the getting started guide https://nw-digital-radio.groups.io/g/udrc/wiki/8921 for image nwdr18.img.xz 2020-Dec-05 08:36:33 1.8G and got as far as the fldigi configuration.  ax.25/direwolf appeared to work and sent/received appropriately.  fldigi keys the radio (yaesu FT-100d attached currently to 1 watt to dummy load) but it appears my cat cable is not reading or setting the radio frequency so I also tried fiddling with flrig to no avail.  I stopped here.  Reading further: 

Placing A Hold On Kernel Upgrade

  • For reference only, the current Linux kernel is safe to use with DRAWS
  • To verify your current kernel version

    uname -r
  • You should see: 4.19.118-v7l+

  • If you see : 5.4.51-v7l+ then your DRAWS hat will have problems

    • The driver for the TI ads1015 chip is missing in this kernel.
    • To revert your kernel back to 4.19.118 run the following (courtesy of Thomas KF7RSF):

      sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2
  • Do NOT use the following commands:

    • apt-get dist-upgrade
    • apt full-upgrade
What I saw was not kernel 4.19.... 
and n7nix's verify_config guide 'sensors' fails to show
 ads1015-i2c-1-48
so I try
    • sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2
and get sudo: rpi-upgrade: command not found

I formatted (again) and haven't connected to network or configured anything.
First check of uname -r gives me 5.4.79-v7l+

Help, please and thank you!
Eric Williams de KF4YEP


Re: #support Low transmit audio #support

Basil Gunn
 

Use deviation guide here:
https://github.com/nwdigitalradio/n7nix/tree/master/deviation

Running measure_deviate.sh will allow you to output a tone so that you
can use alsamixer to change the 'Lo Drive' & 'PCM' alsa controls.

I used the Argent Data 6-pin MiniDIN adapter for the Moto CDM 1250
https://www.argentdata.com/catalog/product_info.php?products_id=169
You have to be careful how you plug that into CDM 1250

It looks like you are using the right hand mDin 6 connector. Channel 0
is the left hand mDin6 connector which is the default connector for
using scripts to set up packet.

If you can't get enough volume using the measure_deviate.sh script you
may have a defective DRAWS hat.

The soft temperature limit bit is set in the get_throttled register.
The current temperature, 59C, is fine but at some time your RPi over
heated.

kylemcdonald87@gmail.com writes:

First off thanks for creating such a versatile board!

I've ran through the setup a few times and I'm still having the same
low transmit audio problem. I've tried it with 2 radios (FTM-400 &
Motorola CDM1250). I have to have my HT turned up all the way and I
can still barely hear the data bursts. I've tried adjusting through
Manager as well as alsa from ssh and I'm not able to get much change.

Here is the output from my showudrc.sh: https://pastebin.com/raw/krbtCAm8



#support Low transmit audio #support

@K5LVL
 

First off thanks for creating such a versatile board!

I've ran through the setup a few times and I'm still having the same low transmit audio problem.  I've tried it with 2 radios (FTM-400 & Motorola CDM1250).  I have to have my HT turned up all the way and I can still barely hear the data bursts.  I've tried adjusting through Manager as well as alsa from ssh and I'm not able to get much change.

Here is the output from my showudrc.sh:  https://pastebin.com/raw/krbtCAm8


Re: DRAWS™ Cases have moved to production!

 

We will announce ship dates on the blog and the groups.io site


Re: DRAWS™ Cases have moved to production!

Christopher AI6KG
 


have they shipped yet?

On Sun, Dec 6, 2020 at 1:42 PM Bryan Hoyer <bhhoyer@...> wrote:
Yes, all orders will ship once the cases arrive.

Bryan K7UDR






Re: problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

OK...I have  fixed the GPS problem. I am still stymied by the failure of ax25 to update...even for the ancient UDRC-II.
John NX2I
p.s. Merry Christmas and Happy New Year!


Re: setalsa for Yaesu FT-8900? #ax25 #ft-8900

Basil Gunn
 

Has there been any progress with getting the FT-8900R to work with the
DRAWS hat on 2m/70cm.
Hi Brian,

Searching the forum I see Tom KE5ICX has his FT-8900 working with a
DRAWS in 03/2019.

https://nw-digital-radio.groups.io/g/udrc/message/2932

If you are having problems I recommend using the measure_deviate.sh
script in n7nix/deviation directory to output a tone that you can verify
with another radio like your HT. This will allow you to set your ALSA
settings and give you confidence that that PTT is working as well.

Be aware that on some Yaesu radios (FT-817/857/897) the COS/SQL pin
(pin 6 on mDin6 cable) should be disconnected to get receive audio
working. Also verify the ALSA control ADCFGA left & right is turned off.

/Basil


Re: setalsa for Yaesu FT-8900? #ax25 #ft-8900

Brian KM6IGY
 

Has there been any progress with getting the FT-8900R to work with the DRAWS hat on 2m/70cm. I was hoping to use it for emcomm purposes.  

73


Re: problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

Roger that. I was confusing with my other setup that has a draws board. 


On Wed, Dec 23, 2020, 3:45 PM Basil Gunn <basil@...> wrote:

> The gpsd is broken too, BTW

There is no GPS device on an UDRC II






problems updating ti NW18 #udrc-ii #image

Basil Gunn
 

The gpsd is broken too, BTW
There is no GPS device on an UDRC II


Re: problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

Basil,
here is the other output requested.
John
pi@udrc:~/n7nix/gps $ ./verify_time.sh

    timedatectl

               Local time: Wed 2020-12-23 14:51:00 EST
           Universal time: Wed 2020-12-23 19:51:00 UTC
                 RTC time: n/a
                Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

    chronyc sources

210 Number of sources = 6
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#? GPS                           0   3     0     -     +0ns[   +0ns] +/-    0ns
#? PPS                           0   3     0     -     +0ns[   +0ns] +/-    0ns
^+ time.richiemcintosh.com       2  10   377   537  -1438us[-1438us] +/-   55ms
^* hc-007-ntp1.weber.edu         1  10   377   580   +764us[ +466us] +/-   43ms
^+ darwin.kenyonralph.com        3  10   377   607  -2976us[-3274us] +/-   42ms
^+ ntp3.radio-sunshine.org       2  10   377   625  -1557us[-1856us] +/-   76ms

    chronyc sourcestats

210 Number of sources = 6
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
GPS                         0   0     0     +0.000   2000.000     +0ns  4000ms
PPS                         0   0     0     +0.000   2000.000     +0ns  4000ms
time.richiemcintosh.com    40  17  243m     +0.035      0.122  +1273us   915us
hc-007-ntp1.weber.edu       6   3   85m     -0.346      0.578   +637us   260us
darwin.kenyonralph.com     41  17  242m     +0.062      0.141  -1258us  1227us
ntp3.radio-sunshine.org    15   9  202m     -0.139      0.305  -1706us  1156us

    chronyc tracking

Reference ID    : 89BE0204 (hc-007-ntp1.weber.edu)
Stratum         : 2
Ref time (UTC)  : Wed Dec 23 19:41:20 2020
System time     : 0.000718676 seconds slow of NTP time
Last offset     : -0.000297520 seconds
RMS offset      : 0.000510251 seconds
Frequency       : 1.386 ppm fast
Residual freq   : +0.003 ppm
Skew            : 0.101 ppm
Root delay      : 0.083962500 seconds
Root dispersion : 0.001979063 seconds
Update interval : 1038.2 seconds
Leap status     : Normal

    chronyc activity

200 OK
4 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

    chronyd systemctl status

● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-12-23 08:18:29 EST; 6h ago
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
 Main PID: 512 (chronyd)
    Tasks: 2 (limit: 2063)
   CGroup: /system.slice/chrony.service
           ├─512 /usr/sbin/chronyd -F -1
           └─518 /usr/sbin/chronyd -F -1

Dec 23 08:18:29 udrc systemd[1]: Starting chrony, an NTP client/server...
Dec 23 08:18:29 udrc chronyd[512]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC…DEBUG)
Dec 23 08:18:29 udrc chronyd[512]: Frequency -6.727 +/- 7.664 ppm read from /var/lib/chrony/….drift
Dec 23 08:18:29 udrc chronyd[512]: Loaded seccomp filter
Dec 23 08:18:29 udrc systemd[1]: Started chrony, an NTP client/server.
Dec 23 08:34:07 udrc chronyd[512]: Selected source 173.255.215.209
Dec 23 08:34:07 udrc chronyd[512]: System clock wrong by 7473.992618 seconds, adjustment started
Dec 23 10:38:41 udrc chronyd[512]: System clock was stepped by 7473.992618 seconds
Dec 23 10:39:47 udrc chronyd[512]: Selected source 137.190.2.4
Hint: Some lines were ellipsized, use -l to show in full.

    gpsd systemctl status

● gpsd.service - GPS (Global Positioning System) Daemon
   Loaded: loaded (/lib/systemd/system/gpsd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-12-23 11:23:32 EST; 3h 27min ago
 Main PID: 1737 (gpsd)
    Tasks: 1 (limit: 2063)
   CGroup: /system.slice/gpsd.service
           └─1737 /usr/local/sbin/gpsd -n /dev/ttySC0 /dev/pps0

Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: SER: read-only device open of /dev/pps0 failed:…ectory
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: initial GPS device /dev/pps0 open failed
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: SER: device open of /dev/ttySC0 failed: No such…d-only
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: SER: read-only device open of /dev/ttySC0 faile…ectory
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: /dev/ttySC0: device activation failed.
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: /dev/ttySC0: activation failed, freeing device
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: SER: device open of /dev/pps0 failed: No such f…d-only
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: SER: read-only device open of /dev/pps0 failed:…ectory
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: /dev/pps0: device activation failed.
Dec 23 11:23:32 udrc gpsd[1737]: gpsd:ERROR: /dev/pps0: activation failed, freeing device
Hint: Some lines were ellipsized, use -l to show in full.
gpsd: 3.19 (revision 3.19)
pi@udrc:~/n7nix/gps $


problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

Basil,
here is the output requested.
It's lengthy so I've attached a file.

more to follow

73, John NX2I


Re: problems updating ti NW18 #udrc-ii #image

Basil Gunn
 

Since your problem is not related to "NWDR18 image release announcement"
please start a new thread.

The gpsd is broken too, BTW
Without some console output can't really comment on your problem.
In your new thread please show the output of:

showudrc.sh
cd
cd n7nix/gps
./verify_time.sh

John Spoonhower <jpspoonhower@gmail.com> writes:

Basil,
I am updating from NW17. this is NOT a fresh install. I have been updating
using the various *_verchk.sh scripts with the -u option.
The gpsd is broken too, BTW


Re: New to DRAWS - what order to troubleshoot installation/setup? #draws-manager #ft-817 #ft817 #draws #gps

Microbes
 

Hi Basil, I'm back at it.

So close. After pulling the #6 pin (and breaking the key off... oops), I can now see all sorts of APRS signals streaming in with:

tail -f /var/log/direwolf/direwolf.log

However, transmitting with:

./btest.sh -P udr0

shows up in this log, and the radio transmits, but still no reports on APRS.fi.

My hand-held, with a rubber duck, get reported just fine. The SSIDs are indeed different, -7 on the hand held and, according to the log, -11 for the DRAWS-817.

By 'check deviation config' I assume you meant this?

pi@drawspi:~/bin $ ./alsa-show.sh
==== List All sound card device names (3)
card 0: b1 [bcm2835 HDMI 1]
card 1: Headphones [bcm2835 Headphones]
card 2: udrc [udrc]

======= DRAWS
===== ALSA Controls for Radio Transmit =====
LO Driver Gain L:[-6.00dB] R:[-6.00dB]
PCM L:[-16.50dB] R:[-16.50dB]
DAC Playback PT L:[P3] R:[P3]
LO Playback CM [Full Chip]

===== ALSA Controls for Radio Receive =====
ADC Level L:[-2.00dB] R:[-2.00dB]
IN1 L:[Off] R:[Off]
IN2 L:[10 kOhm] R:[10 kOhm]
CM L:[10 kOhm] R:[10 kOhm]

Any further suggestions?

I know it's holiday time, I am in no rush and really appreciate your help.

-S






Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Sunday, December 20, 2020 5:19 PM, Basil Gunn <basil@pacabunga.com> wrote:

Much progress.
Great to hear.

udrcver.sh (in /bin or /n7nx/bin, same result):
Found a DRAWS HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0108
UUID: 07ca235a-b510-43c0-8ec5-86e5b78e646f
Vendor: NW Digital Radio

You have the current latest version of DRAWS hat.

systemctl status chronyd:
Instead of using systemctl try using this script for a more complete
look at gpsd/chrony status.

cd
cd n7nix/gps
./verify_time.sh

gpsmon now shows data! Yaaay!
I was able to start ax25 and see a direwolf PID.
Good

tail -f /var/log/direwolf/direwolf.log gave:
Indicates you are not receiving any packets.
Assuming you tuned your radio to the APRS 2M frequency 144.390 you
should be seeing plenty of received packets.

Check squelch setting on radio and you may have a SQL/COS problem and
you will have to remove pin 6 from your mDin6 connector.

Read the first part from this link:
https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md

Using ./btest.sh -P udr0 I can get the radio to switch to transmit and
hear the signal on a hand-held (on 144.39), but no raw packet shows on
aprs.fi.I am not too worried about that right now. Enough for one day.
Check deviation config, and distance to a working APRS gateway.

Also AX.25 tends to eat the first 2 transmitted packets after a
reset. It thinks they are TNC control packets. So always send 3 packets
after a power-on or ax25-restart.

*** Running as user: pi ***
Send a message beacon
Sent: /usr/local/sbin/beacon -c W4NKS-11 -d 'APUDR1 via WIDE1-1' -l -s udr0 :W4NKS :20 15:46:38 EST W4NKS mesg_beacon test from host drawspi on port udr0 Seq: 0


Re: problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

here is the output you requested:
2019 09 28 12:54:34 PDT: SD image version: nwdr14


On Wed, Dec 23, 2020 at 10:57 AM Basil Gunn <basil@...> wrote:

NWDR18 comes with gpsd version 3.21 installed.

 ./gp_verchk.sh
gp_verchk.sh: Detected gpsd package.
gpsd: current version: 3.21, installed: 3.21

Not sure why your gpsd version is at 3.19 unless you are not using
the NWDR18 image.

Run this command in a console to display the image version you are
using:

head -n1 /var/log/udr_install.log

2020 12 04 13:45:55 PST: SD image version: nwdr18

Also do NOT update gpsd with apt as I maintain the latest version from
source.


John Spoonhower <jpspoonhower@...> writes:

> Hi Basil,
> BTW running gp_verchk.sh reports the following after an update:
> 2020 12 23 07:20:49 EST: gp_install.sh: gps install script FINISHED
>
> gpsd version built (3.19) does not match source version (3.21)
>
> 2020 12 23 07:20:49 EST: gp_verchk.sh: gpsd program update script FINISHED
>
> pi@udrc:~/n7nix/gps $ ./gp_verchk.sh
> gp_verchk.sh: Detected gpsd package.
> gpsd: current version: 3.21, installed: 3.19
>
> 73, John, NX2I
>
> On Sat, Dec 5, 2020 at 12:52 PM Basil Gunn <basil@...> wrote:
>
>>
>> Release image nwdr18 Dec 5, 2020
>> last image nwdr17 Aug 21, 2020
>>
>> Latest NWDR RPi image, current_image.img.xz has been updated to
>> nwdr18.img.xz at this location:
>> http://images.nwdigitalradio.com/downloads
>>
>> This is the 4th image release this year. See the ChangeLog
>> (https://github.com/nwdigitalradio/n7nix/blob/master/ChangeLog) for
>> more information about what has changed.
>>
>> To update your current image without using the new image the following
>> procedure will get you most of the changes. In a console on your
>> Raspberry Pi type the following:
>>
>> **Back-up files you would rather not lose first**
>>
>> sudo apt-get update
>> sudo apt-get dist-upgrade
>> cd
>> cd n7nix
>> git pull
>> cd config
>> ./bin_refresh.sh
>>
>> You can verify & update program versions with these scripts:
>> ./bbs/bbs_verchk.sh
>> ./xastir/xs_verchk.sh
>> ./ax25/ax_verchk.sh
>> ./gps/gp_verchk.sh
>> ./hfprogs/hf_verchk.sh
>>
>> The hf_verchk.sh script will update to current versions of these HAM
>> programs. js8call wsjtx fldigi flrig flmsg flamp fllog flxmlrpc
>>
>> /Basil N7NIX
>>
>>
>>
>>
>>
>>
>
>
>






problems updating ti NW18 #udrc-ii #image

John Spoonhower
 

Basil,
I am updating from NW17. this is NOT a fresh install. I have been updating using the various *_verchk.sh scripts with the -u option.
The gpsd is broken too, BTW


On Wed, Dec 23, 2020 at 10:57 AM Basil Gunn <basil@...> wrote:

NWDR18 comes with gpsd version 3.21 installed.

 ./gp_verchk.sh
gp_verchk.sh: Detected gpsd package.
gpsd: current version: 3.21, installed: 3.21

Not sure why your gpsd version is at 3.19 unless you are not using
the NWDR18 image.

Run this command in a console to display the image version you are
using:

head -n1 /var/log/udr_install.log

2020 12 04 13:45:55 PST: SD image version: nwdr18

Also do NOT update gpsd with apt as I maintain the latest version from
source.


John Spoonhower <jpspoonhower@...> writes:

> Hi Basil,
> BTW running gp_verchk.sh reports the following after an update:
> 2020 12 23 07:20:49 EST: gp_install.sh: gps install script FINISHED
>
> gpsd version built (3.19) does not match source version (3.21)
>
> 2020 12 23 07:20:49 EST: gp_verchk.sh: gpsd program update script FINISHED
>
> pi@udrc:~/n7nix/gps $ ./gp_verchk.sh
> gp_verchk.sh: Detected gpsd package.
> gpsd: current version: 3.21, installed: 3.19
>
> 73, John, NX2I
>
> On Sat, Dec 5, 2020 at 12:52 PM Basil Gunn <basil@...> wrote:
>
>>
>> Release image nwdr18 Dec 5, 2020
>> last image nwdr17 Aug 21, 2020
>>
>> Latest NWDR RPi image, current_image.img.xz has been updated to
>> nwdr18.img.xz at this location:
>> http://images.nwdigitalradio.com/downloads
>>
>> This is the 4th image release this year. See the ChangeLog
>> (https://github.com/nwdigitalradio/n7nix/blob/master/ChangeLog) for
>> more information about what has changed.
>>
>> To update your current image without using the new image the following
>> procedure will get you most of the changes. In a console on your
>> Raspberry Pi type the following:
>>
>> **Back-up files you would rather not lose first**
>>
>> sudo apt-get update
>> sudo apt-get dist-upgrade
>> cd
>> cd n7nix
>> git pull
>> cd config
>> ./bin_refresh.sh
>>
>> You can verify & update program versions with these scripts:
>> ./bbs/bbs_verchk.sh
>> ./xastir/xs_verchk.sh
>> ./ax25/ax_verchk.sh
>> ./gps/gp_verchk.sh
>> ./hfprogs/hf_verchk.sh
>>
>> The hf_verchk.sh script will update to current versions of these HAM
>> programs. js8call wsjtx fldigi flrig flmsg flamp fllog flxmlrpc
>>
>> /Basil N7NIX
>>
>>
>>
>>
>>
>>
>
>
>





361 - 380 of 5683