Date   

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.


Re: 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