Date   

Re: Questions regarding N7nix's installation instructions

Gayland Gump
 

Basil,

Been trying to get paclink-unix to work but it is a no-go.  Am able to send via wl2ktelnet, but wl2kax25 has been failing pretty consistently with connection time outs to every contact site rmslist.sh as provided that I've tried so far.  I'm monitoring the spectrum with gqrx connected to an rtl-sdr and it appears that I am successfully sending out packets from my yaesu ft857D.

I've set my freq to 144.390 and have seen a good number of APRS contacts, on the direwofl log tail.  So I built xastir 2.0.9 from source.  I started it and set the interface to AGWPE localhost:8000 and it was populating a map well.  I didn't transmit my beacon though.  I've tried sending messages out and I believe direwolf is getting the messages, they are not triggering the transmitter to transmit packets.

That pretty much sums up where I am, though it appears that either APRS traffic has fallen off greatly or I've somehow tweaked some setting because I am not seeing much displayed on xastir's map the past couple days.

I have another pi/direwolf/udrc setup that was not configured by your scripts.  It is hooked up to one of my Baofeng HT's and it is transmitting, though I haven't gotten much incoming on it either and haven't connected with anyone.

I am hoping you'll be able to give me some ideas on how to troubleshoot things.  I am pretty much lost at the moment.

Thanks for your time.


Re: Questions regarding N7nix's installation instructions

Basil Gunn
 

So, using a clean install of 2016-05-23-compass.img onto a 32 GB SD,
and following the instructions provided
...

As it stands, only one packet has been received in the 30 minutes
that the system has be operating.
Tune your radio to 144.39. The 2M APRS frequency. That should give you
some traffic.

From what I can tell at present, I can't get a winlink password
without having a winlink client up running to get one.
Correct, thanks for pointing that out. So if you are a Winlink
newbie, just hit return for password & follow the Winlink
instructions.

Server FQDN?
So just what server fully qualified domain name are we
talking about here.
Use whatever host name you gave from the core install & add '.localnet'
eg. your_host_name.localnet


Finally, SSID, I take to be the name of one of my home wifi access
points, but "Bacon", who names their home networks "BACON".
I do. I like bacon & I'm a ham, a close relative to bacon. It has to
be different that any other AP in your home. Make something up you can
remember.

Let me know if my assumption is off base here.
All questions are good.

So, once I have some clarifications, on these particular items, I feel
comfortable proceeding with the of the paclink-unix setup.
I recommend you get the basic paclink-unix working first.

/Basil n7nix


Re: Questions regarding N7nix's installation instructions

Basil Gunn
 

The following line appears in
https://github.com/nwdigitalradio/n7nix/blob/master/CORE_INSTALL.md:

apt-get install -y mg jed rsync build-essential autoconf automake
libtool git libasound2-dev whois libncurses5-dev

I'd like to know if mg (microscopic GNU Emacs-style editor), jed
(editor for programmers (textmode version)), and whois (intelligent
WHOIS client) are essential to the scripts you are providing, or are
just tools you as the script author likes to have available?
The 2 Emacs editors are essential to me as my fingers are wired that
way. 'whois' is handy for debugging some network problems. All small
programs.

rsync - is already available on the compass image or is after the
running "apt-get update -y" you call for prior to the apt-get
install above. Does this serve any purpose then?
rsync is important for getting files on & off your device. Since the
compass image changes it may already be installed. I absolutely need
it and it costs nothing for apt-get to figure that out.

/Basil n7nix


Questions regarding N7nix's installation instructions

Gayland Gump
 

So,  using a clean install of 2016-05-23-compass.img onto a 32 GB SD, and following the instructions provided in https://github.com/nwdigitalradio/n7nix/blob/master/CORE_INSTALL.md
and running the ~/n7nix/config/core_install.sh script has, according to the follow on testing instruction has provided a working core installation, ax25, direwolf, and udrc.

As it stands, only one packet has been received in the 30 minutes that the system has be operating.  Possibly suggesting that the direwolf configuration could use some tweaks.  In any event I am looking at installing paclink-unix using these instructions: 
WooHoo! detected a second Packet!  Same sender though. 

But before I do I have a question regarding the information the instructions tell me the script will require I enter.  Specifically, Winlink password, server FQDN ( eg. check_test5.localnet), and SSID (eg. bacon).  Taking them in order here are my questions.

From what I can tell at present, I can't get a winlink password without having a winlink client up running to get one.  Winlink org instructions recommend winlink express, running on windows.  We are a windows free zone.  In any case, winlink orgs instructions say not to enter a password the first time you log on to winlink.org, they'll send and email.  So do I just put anything in the password or leave it blank?  Instructions say it is required!

Server FQDN?  So just what server fully qualified domain name are we talking about here.  The example suggest to me that I just makeup some random FQDN.

Finally, SSID, I take to be the name of one of my home wifi access points, but "Bacon", who names their home networks "BACON".    Let me know if my assumption is off base here.

So, once I have some clarifications, on these particular items, I feel comfortable proceeding with the of the paclink-unix setup.

Thanks for your patience!  Looking forward to input.

Gayland
KG7GCF 


    Questions regarding N7nix's installation instructions

    Gayland Gump
     

    I'm asking a these questions in an effort to increase my understanding of why and how we accomplish things in the Linux world.  They may be annoying to some of you, so I apologize in advance.  Sorry!


    apt-get install -y mg jed rsync build-essential autoconf automake libtool git libasound2-dev whois libncurses5-dev

    I'd like to know if mg (microscopic GNU Emacs-style editor), jed (editor for programmers (textmode version)), and whois (intelligent WHOIS client) are essential to the scripts you are providing, or are just tools you as the script author likes to have available?  If essential, how so?  

    rsync - is already available on the compass image or is after the running "apt-get update -y"  you call for prior to the apt-get install above.  Does this serve any purpose then?

    The remaining elements I recognize as being either tools or libraries needed to create an environment for building applications.

    More questions I am sure will follow as I move forward while following your much appreciated instructions.

    Gayland
    KG7GCF


    Re: WinDV

    VE3MIC
     

    Good point... although I am running on Windows 7 (32bit) I too am using a 1st run (lower serial bit rate) ThumbDV. Perhaps the issue is with the serial port and the bit rate of the ThumbDV?
    73 de Mike


    On Thursday, April 6, 2017 2:42 PM, Roland Kraatz <w9hpx.4@...> wrote:


    I run WinDV (ver. 1.5.8-3) on my 64bit Lenovo laptop running Windows 10 Home and with my NWDR ThumbDV (original slower serial rate) with no operating issues or gray lines.  It is my primary windows PC with lots of other software installed on it.
    73,
    Roland W9HPX



    Re: WinDV

    Roland W9HPX
     

    I run WinDV (ver. 1.5.8-3) on my 64bit Lenovo laptop running Windows 10 Home and with my NWDR ThumbDV (original slower serial rate) with no operating issues or gray lines.  It is my primary windows PC with lots of other software installed on it.

    73,

    Roland W9HPX


    Re: WinDV

    Mark L. Rehme
     

    I just checked, all of my machines are 64 bit, that could very well be the problem.

    I have Firefox on all of them also but I wouldn't think that would matter.

    I did try and load it on a XP machine - that didn't work.

    I might just have to dedicate a new machine with windows 10 so I can get this working.


    Thanks,

    Mark




    Re: WinDV

    Thomas Cichowicz <cichowicz@...>
     

    I've had similar issues from time to time. I've always been able to get the problem to go away by unplugging and re plugging the ThmbDV in and out, and or removing other USB devices that may be plugged in at the time and only have the ThmbDV in then re-launch the app. 

      Kinda hit or miss but it generally works. I've seen this on also 3 computers running Win7 64, I upgraded to win 10 on one of them and it still does it once in a while. 

      Good luck...

    ~TomC.



    Sent by pressing a send button. 

    On Apr 4, 2017, at 4:24 PM, Mark L. Rehme <mark.rehme@...> wrote:

    I have 3 machines with windows 7 on them, they all have the grey/white diagonal lines.

    I have uninstalled and installed numerous time on all the machines, at one time I though it was going to work but the lines came back.

    I don't know what to try at this point, New machine with a different operating system?


    Thanks,

    Mark   NR5L


    Re: WinDV

    ve3mic@...
     

    Interesting Mark.

    I'm wondering if all three of your Windows 7 installations are 64bit? I've been running WinDV on a Windows 7 laptop (32bit) for a couple of years now, and other than the occasional program hang when there is a lot of activity (D-STAR) activity going on, it's fine. I've even been through a few WinDV application program version updates along the way too. Wondering if it's a 32bit vs. 64bit thing? I'll try to install the latest WinDV on my 32 bit Windows 10 (yes 32bit!) netbook, and see what happens.

    73 de Mike



    Re: WinDV

    Mark L. Rehme
     

    I have 3 machines with windows 7 on them, they all have the grey/white diagonal lines.

    I have uninstalled and installed numerous time on all the machines, at one time I though it was going to work but the lines came back.

    I don't know what to try at this point, New machine with a different operating system?


    Thanks,

    Mark   NR5L


    Re: HF DV:

    Richard - VE7CVS
     

    Actually, 1200 bps over FM has a lot of redundancy that makes it work well in most conditions (if properly configured) - it's just not a very efficient use of bandwidth!

    I implemented some of the very first Bell 202 modems for packet radio back in 1979. That 'standard' that you see know comes from the VADCG (Vancouver Amateur Digital Communications Group), we got a stack of Bell 202-standard modems from the Canadian Imperial Bank of Commerce for a whopping $1.75 each - we bought them by the pound!

    The idea was to come up with a cheap, easy-to-implement-with-existing-2m-rigs modulation scheme - radios of that day were notoriously poor for digital radio, I modified ICOM IC22-U and IC22-S radios to bring their squelch detect down from several hundred to several tens of milliseconds - and other radios were even worse, some of the early synthesised rigs took forever to stabilise. Some of the squelch mods, and the 9-pin plug wiring standards for ICOM rigs came from me (although I was totally oblivious that I was creating anything resembling a 'standard'...).

    Modern radios can do 1200 bps with relative ease. It's still terribly slow, we at the VADCG saw 1200 bps as a stopgap until we could bring out fast, 220 MHz radios. Unfortunately, we never got that far. :(

    Another group that I belonged to in Vancouver brought out a very sturdy 56 kbps standard system (Dennis Rosenauer was the main instigator - and stellar RF engineer - for this system - for Dennis, 70 cm 'is DC' :-)


    - Richard

    On 3/17/17 4:12 PM, Stuart Longland VK4MSL wrote:
    On 17/03/17 20:54, Andrew O'Brien wrote:
    While I would like this to succeed, the SNR required for digital voice
    on most HF bands is such that it renders DV as only useful between
    stations with a lot of power and/or really high gain antennas.
    Well, this can be true of other systems like FM too. 1200 baud AFSK
    over FM is actually pretty terrible as a modem in performance.


    Re: HF DV:

    Stuart Longland VK4MSL
     

    On 18/03/17 11:20, Eubank, Greg (MVA) wrote:
    My initial thoughts are, that if there was a DV implementation that
    utilized Pactor Error detection and correction technology, that an HF DV
    protocol could theoretically be designed to provide similar performance
    of the Pactor method for Modulation/Demodulation.
    https://en.wikipedia.org/wiki/PACTOR seems to suggest you'll have to
    sweet-talk SCS into making a software version of their (proprietary)
    modem to run on Linux/armhf.

    I wish you luck.

    It is worth noting that DV is a very different beast to data. Audio
    delivery is hard real-time. If each character of this email was
    delivered with a random 1-3 second delay… it would be annoying to watch
    but not harmful to the intelligibility of the message.

    However, if a burst of no --- i --- se --- ca --- used delays playing
    back parts of an audio recording… this discontinuity of playback is
    disastrous. The broken-up signal cannot be understood, even though no
    audio samples have been lost, the human brain cannot process the parts
    in this disassembled manner.

    Data modems are intended on getting a packet of data from A to B
    *perfectly*. A single bit error means the data at the other end is
    corrupt and therefore useless. So they achieve lower BER by long
    synchronisation runs and lots of FEC.

    Voice modems are intended for constant data rate, and will generally
    produce a higher BER, but can synchronise very quickly, thus will handle
    sudden loss and return of signal better.
    --
    Stuart Longland (aka Redhatter, VK4MSL)

    I haven't lost my mind...
    ...it's backed up on a tape somewhere.


    Re: HF DV:

    Eubank, Greg (MVA) <Greg.Eubank@...>
     

    My initial thoughts are, that if there was a DV implementation that utilized Pactor Error detection and correction technology, that an HF DV protocol could theoretically be designed to provide similar performance of the Pactor method for Modulation/Demodulation.

     

    From: Andrew O'Brien [mailto:andrewobrie@...]
    Sent: Friday, March 17, 2017 02:55
    To: main@nw-digital-radio.groups.io
    Subject: Re: [nw-digital-radio] HF DV:

     

    While I would like this to succeed, the SNR required for digital voice on most HF bands is such that it renders DV as only useful between stations with a lot of power and/or really high gain antennas. Thus, use for Emcomm would be not widely adopted. IF software for HF DV use allowed access of an HF user into things like Dstar reflectors or call routing, that WOULD be useful for emcomm.

    Andy K3UK

     

    On Thu, Mar 16, 2017 at 8:08 PM, Brad NK8J <bradnk8j@...> wrote:

    Freedv  for voice or with icom dv (digital voice) dstar on HF

    On Thu, Mar 16, 2017, 5:21 PM Eubank, Greg (MVA) <Greg.Eubank@...> wrote:

    Do you have any plans for or is anyone presently working on an HF DV application?

     

    73's

     

        - Greg –

     

    KL7EV

     



     

    --

    Andy


    Re: HF DV:

    Alex Perez
     


    On Mar 17, 2017, at 3:22 PM, Tony Langdon <vk3jed@...> wrote:

    On 17/03/2017 11:17 PM, bauerjv@... wrote:

    I don't know that HF DV would have a value added for emcomm but FreeDV
    700C is a new mode and I have heard it work when the waterfall was
    barely visible.  The authors claim low SNR performance rivaling that
    of low signal level SSB.

    i agree with Andrew in general using previous digital modes, but if
    700C indeed performs as claimed, that view may now outdated.

    700C is under development, with the goal to equal or exceed the
    performance of SSB on HF channels.  It is getting closer to that goal
    all the time.  Latest results on non fading channels look pretty
    impressive.

    And, for those who are curious, here are some samples of what Codec2 700C sounds like, along with a comparison of the same audio at 1300 bits/sec, instead of 700


    Re: HF DV:

    Stuart Longland VK4MSL
     

    On 17/03/17 20:54, Andrew O'Brien wrote:
    While I would like this to succeed, the SNR required for digital voice
    on most HF bands is such that it renders DV as only useful between
    stations with a lot of power and/or really high gain antennas.
    Well, this can be true of other systems like FM too. 1200 baud AFSK
    over FM is actually pretty terrible as a modem in performance.

    http://www.rowetel.com/?p=3799 is written by the Codec2 author, thus
    might be seen by some as biassed, but in that, he analyses the AFSK/FM
    set-up typically used in packet and assesses its theoretical
    performance. The results were not great.

    It was built that way because people made use of what they had at the
    time, old Bell modems. It works well enough for most purposes, but it
    was never a stellar performer.

    Typically you need decent transmit power or high-gain antennas to make
    it work well. Yet, it is used a lot in emcomms. The saving grace is
    that the packet typically only needs a short burst of a few seconds to
    transmit a longish sentence that would take about 30 seconds to read
    out. So you can afford high power because the duty cycle is much lower.

    DV would take away that gain, but then again it can be recorded,
    transmitted with stronger FEC and stored for playback later, so if the
    operator is distracted, the message will still be there waiting for them
    when they get back to the radio. This is a trick that analogue voice is
    unlikely to pull off.

    As for FreeDV and D-Star HF; transceivers for both do have the advantage
    that if conditions get bad, it is a single button press usually to
    switch to SSB. Another button press and it's to CW. Or with a device
    like the UDRC, we can use PSK-31, etc.

    This is feature of amateur emcomms that we can switch and adapt as the
    conditions require. Commercial radios do not give their users the same
    luxury.

    Procedure can dictate how you go about switching modes. Our strength in
    emcomm is that we have all these modes at our disposal, and if one stops
    working, we can switch modes.

    This is less risky than switching frequencies, and you get to know
    digital modes by ear and most applications feature a waterfall.

    The application can pass through the analogue audio when there's no
    decodable signal anyway, so in that case the fall-back to SSB is automatic.

    A smarter application could be watching for PSK-31, slow CW, WSPR and
    DV, etc, and dynamically switch between them on receive, so the only
    decision an operator is making is what to use when transmitting, knowing
    the other end will figure out how to receive the message.

    It'd be difficult to pack this into a hand-held, although with
    single-board computers like the Raspberry Pi compute module, which could
    be paired up with the TLV320AIC3204 in a UDRC-compatible package that
    could conceivably fit inside a hand-held radio built for it.

    However, hand-helds seldom reach below 50MHz (I'll ignore 27MHz), and it
    is HF we're discussing here, where we can likely afford a bit more
    computing power to do such real-time processing as we can afford the
    slightly bigger form factor computers that would provide the necessary
    grunt.

    In short, I think it is premature to discount HF DV for emergency comms.
    It's no silver bullet, but rather, yet another tool in getting a
    message through.
    --
    Stuart Longland (aka Redhatter, VK4MSL)

    I haven't lost my mind...
    ...it's backed up on a tape somewhere.


    Re: HF DV:

     

    On 17/03/2017 11:17 PM, bauerjv@... wrote:

    I don't know that HF DV would have a value added for emcomm but FreeDV
    700C is a new mode and I have heard it work when the waterfall was
    barely visible. The authors claim low SNR performance rivaling that
    of low signal level SSB.

    i agree with Andrew in general using previous digital modes, but if
    700C indeed performs as claimed, that view may now outdated.
    700C is under development, with the goal to equal or exceed the
    performance of SSB on HF channels. It is getting closer to that goal
    all the time. Latest results on non fading channels look pretty
    impressive.

    --
    73 de Tony VK3JED/VK3IRL
    http://vkradio.com


    Re: HF DV:

    Curt Mills, WE7U
     

    On Fri, 17 Mar 2017, bauerjv@... wrote:

    I don't know that HF DV would have a value added for emcomm but FreeDV 700C is a new mode and I have heard it work when the waterfall was barely visible. The authors claim low SNR performance rivaling that of low signal level SSB.

    i agree with Andrew in general using previous digital modes, but if 700C indeed performs as claimed, that view may now outdated.
    Note that Codec2 is still being worked on and has several modes with different bit-rates. It may be too early yet to look for a solid implementation you can depend on for emcomm use.

    --
    Curt, WE7U. http://we7u.wetnet.net
    APRS Wiki: http://info.aprs.net/


    Re: HF DV:

    Jeff WA3PNY
     

    I don't know that HF DV would have a value added for emcomm but FreeDV 700C is a new mode and I have heard it work when the waterfall was barely visible.  The authors claim low SNR performance rivaling that of low signal level SSB.

    i agree with Andrew in general using previous digital modes, but if 700C indeed performs as claimed, that view may now outdated.


    jeff


    Re: HF DV:

    Andrew O'Brien
     

    While I would like this to succeed, the SNR required for digital voice on most HF bands is such that it renders DV as only useful between stations with a lot of power and/or really high gain antennas. Thus, use for Emcomm would be not widely adopted. IF software for HF DV use allowed access of an HF user into things like Dstar reflectors or call routing, that WOULD be useful for emcomm.
    Andy K3UK

    On Thu, Mar 16, 2017 at 8:08 PM, Brad NK8J <bradnk8j@...> wrote:
    Freedv  for voice or with icom dv (digital voice) dstar on HF

    On Thu, Mar 16, 2017, 5:21 PM Eubank, Greg (MVA) <Greg.Eubank@...> wrote:

    Do you have any plans for or is anyone presently working on an HF DV application?

     

    73's

     

        - Greg –

     

    KL7EV

     




    --
    Andy