--

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.

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

--

On Fri, 17 Mar 2017, bauerjv@mac.com 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/

On 17/03/2017 11:17 PM, bauerjv@mac.com 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

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.

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.

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