Date   

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


    Re: HF DV:

    Brad NK8J <bradnk8j@...>
     

    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

     


    Re: HF DV:

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

    We have the Alaska Pacific Net (Alaska Emergency Preparedness Net) and also 60 Meters where we are blessed to experience increased noise floor conditions and I am hoping to establish an HF DV voice net that we can use to communicate during these challenging communications conditions.

     

    I’ve been following the ongoing announcements for the UDRC and PiDV/ThumbDV products and I feel it is about time for me to stop following and start moving!

     

    I see the opportunity to expand this technology to the Emergency Management and Disaster Preparedness community if we can come up with a simple and effective turnkey solution.

     

    Does anybody on the forum know of anybody incorporating this into the Amateur HF ALE Network? 

    I’d be interested in experimenting with this using my Micom ALE radio.

     

    73's

     

        - Greg –

     

    KL7EV

     

     

    From: John D Hays - K7VE [mailto:john@...]
    Sent: Thursday, March 16, 2017 13:29
    To: main@nw-digital-radio.groups.io
    Subject: Re: [nw-digital-radio] HF DV:

     

    Hi Greg,

     

    The primary amateur radio DV applications on HF are D-STAR (http://hf.dstar-relay.net) and Codec2.  

     

    The UDRC II is a candidate to support a Codec2 HF modem/controller.  I think there are people interested in doing this.

     

    The UDRC II plus a ThumbDV could be the basis of an HF D-STAR modem/controller/AMBE encoder/decoder but an application is needed.

     

    Do you have a particular application in mind?

     

     

    On Thu, Mar 16, 2017 at 2:05 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

     



     

    --

     


    John D. Hays

    K7VE

     

    PO Box 1223, Edmonds, WA 98020-1223

    Image removed by sender. Image removed by sender. Image removed by sender. Image removed by sender.

     


    Re: HF DV:

    Stuart Longland VK4MSL
     

    On 17/03/17 07:05, Eubank, Greg (MVA) wrote:
    Do you have any plans for or is anyone presently working on an HF DV
    application?
    You mean like this?
    http://www.freedv.org/

    --
    Stuart Longland (aka Redhatter, VK4MSL)

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