Re: [Freetel-codec2] Math Question on Codec Documentation

[david]

Hi Bruce,

I've had a go at fixing (19), which is now (21), with some more explanation:
  https://github.com/drowe67/codec2/pull/50/files

Cheers,
David

On Fri, 2024-04-19 at 18:38 +0800, david wrote:
> Hi Bruce,
> 
> Thanks for reading codec2.pdf, and your kind comments.  
> 
> Actually I think you've found an error. For that section I was
> working
> back from the source code, sine.c, est_voicing_mbe()
> function.  Looking
> at the source, the "offset" variable has a negative sign before the
> "mr" term you suggested in your analysis. 
> 
> Note the source uses different variable names to codec2.pdf, we
> haven't gotten around to aligning the source code with the document
> nomenclature yet.
> I'm travelling at the moment, but will take a closer look when I
> return
> home in a week or so.
> 
> Thanks,
> David
> 
> On Thu, 2024-04-18 at 11:19 -0400, Bruce MacKinnon wrote:
> > Hi:
> > 
> > What you all are working on is very interesting.  Keep up the great
> > work!
> > 
> > I greatly appreciate the creation of the detailed description of
> > codec2 (https://github.com/drowe67/codec2/blob/main/doc/codec2.pdf)
> > .
> >  With that document, the code becomes easier to follow.  But I have
> > a
> > question about the math.  I’m not that sharp on DSP stuff, so this
> > may be an obvious question to you all. If this is the wrong place
> > to
> > ask, feel free to redirect me.
> > 
> > Page 14, equation 18 makes sense to me - you’re trying to
> > characterize the relationship between Sw() and W() within each band
> > of Sw().  And the W*(k - ROUND(mr)) also makes sense, since you
> > need
> > to remove the “repeating” concept from W() - a spectral copy of W()
> > is present across the bands of Sw() in the voiced case.  It’s like
> > a
> > modulo w0.
> > 
> > And the fact that the W* becomes W in equation 19 also makes sense
> > -
> > real/even in the time domain gives you real in the frequency
> > domain.
> > 
> > But I can’t figure out how (k - ROUND(mr)) becomes (k + ROUND(mr))
> > in
> > equation 19.  Certainly W(k - ROUND(mr)) and W(-k + ROUND(mr)) are
> > the same (even function in frequency domain), but how does W(k -
> > ROUND(mr)) equal W(k + ROUND(mr))?
> > 
> > I’m probably missing some property of the FFT that makes this true.
> > 
> > Thanks in advance,
> > 
> > Bruce KC1FSZ
> > 
> > 
> > 
> > 
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Math Question on Codec Documentation

[david]

Hi Bruce,

Thanks for reading codec2.pdf, and your kind comments.  

Actually I think you've found an error. For that section I was working
back from the source code, sine.c, est_voicing_mbe() function.  Looking
at the source, the "offset" variable has a negative sign before the
"mr" term you suggested in your analysis. 

Note the source uses different variable names to codec2.pdf, we haven't gotten 
around to aligning the source code with the document nomenclature yet.
I'm travelling at the moment, but will take a closer look when I return
home in a week or so.

Thanks,
David

On Thu, 2024-04-18 at 11:19 -0400, Bruce MacKinnon wrote:
> Hi:
> 
> What you all are working on is very interesting.  Keep up the great
> work!
> 
> I greatly appreciate the creation of the detailed description of
> codec2 (https://github.com/drowe67/codec2/blob/main/doc/codec2.pdf).
>  With that document, the code becomes easier to follow.  But I have a
> question about the math.  I’m not that sharp on DSP stuff, so this
> may be an obvious question to you all. If this is the wrong place to
> ask, feel free to redirect me.
> 
> Page 14, equation 18 makes sense to me - you’re trying to
> characterize the relationship between Sw() and W() within each band
> of Sw().  And the W*(k - ROUND(mr)) also makes sense, since you need
> to remove the “repeating” concept from W() - a spectral copy of W()
> is present across the bands of Sw() in the voiced case.  It’s like a
> modulo w0.
> 
> And the fact that the W* becomes W in equation 19 also makes sense -
> real/even in the time domain gives you real in the frequency domain.
> 
> But I can’t figure out how (k - ROUND(mr)) becomes (k + ROUND(mr)) in
> equation 19.  Certainly W(k - ROUND(mr)) and W(-k + ROUND(mr)) are
> the same (even function in frequency domain), but how does W(k -
> ROUND(mr)) equal W(k + ROUND(mr))?
> 
> I’m probably missing some property of the FFT that makes this true.
> 
> Thanks in advance,
> 
> Bruce KC1FSZ
> 
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 FSK demodulator issues

[david]

Hi Stephen,

The FSK modem has been used for burst applications (e.g. the FSK raw
data mode).  It's true that in general burst modem acquisition is more
challenging than for continuous streaming data.

It's difficult to comment on your specific case, as so many things are
unique to a specific implementation - and many things that can go
wrong.

If you can reproduce your problem using the command line fsk_xxx tools,
feel free to post command lines here to demonstrate the problem.

- David

On Tue, 2024-01-30 at 19:50 -0400, Stephen Downward wrote:
> Hello all,
> 
> I'm using the FSK demodulator from codec2 in a side project of mine.
> I have a 9600
> bps stream running at 4.8KHz deviation. Packets have 32 bits of
> preamble, followed by a 32 bit sync word and then the actual data.
> 
> I believe the FSK demodulator is having trouble locking on, and it's
> causing some of the initial bits to be flipped. My reasoning is as
> follows:
> 
> - I captured a sample of about a hundred packets, with 10 seconds of
>   nothing between each packet, and a few ms of transmission time per
>   packet
> 
> - If I allow, say, 10 flipped bits in the sync word, every packet
> decodes
>   properly.
> 
> - If I allow only 5 flipped bits in the sync word, the decode rate
> drops,
>   and continues to drop as I lower the allowed number of flipped
> bits.
> 
> - When I only allow 5 flipped bits, suddenly the modem is super
>   sensitive to parameters such as n_sym and the upper/lower frequency
>   estimation limits. For example, changing n_sym from 38 to 39 may
> cause
>   the decode rate to fall by 10% or more. However, different n_sym
>   values seem to work better for different packets. If I capture two
>   samples of a hundred packets each, each sample may have a different
>   n_sym where the maximum number of packets are decoded (at 5 allowed
>   bit flips)
> 
> - 5/32 bit flips would be enough to mangle many packets, if that
> error
>   rate was maintained for the entire duration of the packet. Thus,
> the
>   error rate must be dropping shortly after the sync word
> 
> Initially I thought it might be an issue with a slow AGC on the
> RTL-SDR. After turning off AGC, I'm still getting the same
> behaviour. This makes me think it's a problem with the FSK
> demodulator
> itself.
> 
> As far as I can tell, the FSK demodulator is primarily used in
> projects
> that send many packets in quick succession. I am wondering if it's
> poorly optimized for my use-case of having long periods between
> packets.
> 
> Thanks,
> Stephen
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Updating the libcodec2 binding in FFmpeg, fixed-point decoding

[david]

Hi Tomas,

Thanks for that work.  1.2 was clean up of the Git repo, so nothing
much has changed in terms of functionality.  We have no plans for a
fixed point version.  The .c2 file format is a corner use-case (we
focus mainly on the HF radio use case), but we have no plans to change
it.

A road map of what is currently placed for the entire FreeDV project
(which includes Codec 2) is here:

https://freedv.org/2023/11/30/ardc-grant-project-plan/

Do you have any way of measuring how many people are using the Codec 2
option in FFmpeg?

We have been looking into the use of the freedv-gui application (which
uses libcodec2) in various repos and found no evidence of the packaged
versions of freedv-gui actually being used.  The number of package
maintainers seems to to outnumber the end users.

We are interested in auditing the use of freedv-gui and Codec 2 to best
direct our efforts.  For example there is no point supporting package
maintainers if no one is using the packages - best to direct our
limited resources elsewhere.

I find it interesting that package maintenance is such a popular hobby
- we get more correspondence/requests for help on this topic than say
the DSP side of Codec 2 (where I like to play).

Thanks,
David

On Wed, 2023-12-27 at 18:48 +0100, Tomas Härdin wrote:
> Hi
> 
> I see codec2 has now reached version 1.2.0. I'm working on updating
> the
> libcodec2 binding in libavformat in FFmpeg accordingly.
> 
> So far I've been conservative, only allowing major version 0 and
> requiring version to be >= 0.8. So in effect versions 0.8 to 0.255.
> Now
> that 1.X is out I'm updating libavformat accordingly. Fortunately the
> .c2 format hasn't changed, so this is more of a heads up to be
> careful
> not to make breaking changes to the format :)
> 
> In effect what I'm doing is allowing versions 0.8 through 1.255.
> 
> I'm also adding tests to FFmpeg's testing system FATE. So far these
> tests are quite basic, only checking metadata rather than the actual
> decoded audio. This because libcodec2 uses floating point arithmetic.
> At some time I'd like to improve that. Are there any plans to
> implement
> a fixed-point decoder? I remember seeing some chatter about that.
> 
> /Tomas
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec 2 Algorithm description doc

[david]

Hi Greg,

Thanks for your comments, good to get a perspective from a non DSP
person.  Some thoughts:

1/ The modes are not interoperable.

2/ The "stable" question is a good one.  I consider codec2 unstable, as
I am dissatisfied with performance and enjoy experimenting.  Having
said that, the youngest mode is now 7 years old, and some haven't
changed in a decade.  I don't think we'd remove any existing modes that
had a user base > 1.

We do intend to converge on a smaller number of (improved) modes for
Codec 2 and FreeDV over the course of the next few years.

3/ Re documenting (e.g. IETF style), I'm also pondering the best way to
document Codec 2.  Corner use-cases I can think of are alternative
implementations (say on a FPGA or non-C99 compilers).  I say corner
cases as  in 99% of cases why not just use the reference C code? 

My current position is to use a combination of doc, reference C code,
and automated tests.  There are so many moving parts to codecs that I
feel the IETF paper-only style is not a strong approach.  G729, for
example, has come with C code since the mid 1990s.  As a counter
example - AMBE doesn't - which creates a barrier to entry.

Also - in an open source world - why not use the other tools we have
like the actual source code, and modern practices like automated
tests? 

Thanks,
David

On Wed, 2023-12-13 at 10:08 -0500, Greg Troxel wrote:
> david  writes:
> 
> > Here is first version of some Codec 2 algorithm documentation:
> > 
> > https://github.com/drowe67/codec2/blob/main/doc/codec2.pdf
> > 
> > It has a description aimed at Hams (sort of thing that could go in
> > a
> > Ham magazine), plus a maths/signal processing section. It pulls
> > together a bunch of work I've done since the start of the
> > project. Kindly funded by our ARDC grant.
> > 
> > I'm interested in review comments:
> > 
> > 1/ Any typos/spelling, wording issues.  A GitHub PR would be best
> > for these if you are comfortable with Git.
> > 2/ Anything that is not explained clearly?  Other topics that you
> > would like to see covered?
> 
> I'm coming at this as someone who worked in network protocols (sort
> of
> IETF adjacent) and has a hazy understanding of speech coding.  I've
> been
> lurking forever silently cheering you on.
> 
> Some meta comments about issues belonging in a spec.  These are
> partly
> about my impressions over the years, and a bit about the document.
> 
>   First, I think "codec2" is a family of codecs.  There are various
> modes
>   described by bitrate.   A decoder for one probably does not process
>   the other.  Or maybe it does and I'm confused.   The first point
> under
>   introduction says most of this, but it doesn't address interop.   I
>   realize "a codec with modes" and "a family of codecs" is perhaps
> just
>   wording choice, but to me the key point is that with the second
>   phrasing there is no expectation that a 700C decoder will decode a
>   700A stream, and even less so that it will decode a 3200 stream.
> 
>   I have long been unclear on whether codec2 is stable, in that if
> one
>   builds a device that uses a currently-defined mode that this can be
>   expected to remain interoperable over the long term.  I'm getting
> the
>   impression that each mode designation is by fiat stable, but that
> some
>   modes get retired.  And that therefore "implementing codec2" must
> be
>   done in such a way that a slightly different algorithm needs to be
>   able to be loaded.  But with an expectation the processing
>   requirements will not substantially change.  It now seems to be
> that
>   "700C" is a fixed definition, at least for the decoder, and that is
>   guaranteed to remain.  But, there might be a 700D.  (And yes, I get
> it
>   that 700 is much harder than 2400 to sound ok and hence there are
> more
>   revisions.)
> 
>   I have the impression that for a given mode, say 2400, there is a
>   single correct way to decode.  But that encoding might have valid
>   choices within the spec, resulting in better estimated parameters,
>   with no need for the decoder to be different.
> 
>   I think there should be a document that specifies each mode.  That
> can
>   be one doc for all, or per mode, and referring to a common
> doc.  None
>   of that is important; the point is that someone who wishes to
>   implement a mode from scratch can assemble a pile of paper and
>   implement from that, without reading your source code, and come up
>   with an interoperable implementation.  This is the IETF way, and i
>   think it has great merit.  It's also a huge amount of work.   In
> the
>   codec2 part, the theory and the "why are we

Re: [Freetel-codec2] Import to STM32

[david]

Hi Jan,

Please feel free to ask any question.

There's a list of files for the vocoder in the codec2.pdf doc I posted
a link to earlier today, well most of them anyway.  One trick is that
some of the tables are generated as part of the build process, so best
to follow the standard build process on an Ubuntu machine first, to
generate them.

Starting with all files then removing the unneeded ones is also a good
approach, as Mooneer hinted at.

- David

 On Wed, 2023-12-13 at 09:17 +0100, Jan Ropek wrote:
> 
> Hello everyone, I might get thrown out for asking this, but I want to
> import CODEC2 libraries into my STM32 project (created in CubeIde) -
> just the encoding and decoding, nothing else like FreeDV or other
> things. But I'm quite lost about which files to import and which not
> to. Is there a manual on which files to use? Or should I just try
> brute force? I assume I need to use some of these files from 
> https://github.com/drowe67/codec2/tree/main/src plus the memtools
> from here https://github.com/drowe67/codec2/tree/main/stm32/src,
> right?
> 
> Thank you very much. Jan.
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] Codec 2 Algorithm description doc

[david]

Hi, 

Here is first version of some Codec 2 algorithm documentation:

https://github.com/drowe67/codec2/blob/main/doc/codec2.pdf

It has a description aimed at Hams (sort of thing that could go in a Ham 
magazine), plus a maths/signal processing section. It pulls together a bunch of 
work I've done since the start of the project. Kindly funded by our ARDC grant.

I'm interested in review comments:

1/ Any typos/spelling, wording issues.  A GitHub PR would be best for these if 
you are comfortable with Git.
2/ Anything that is not explained clearly?  Other topics that you would like to 
see covered?

Thanks,
David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 in real time on STM32

[david]

Hi Jan,

We run Codec 2 half duplex (along with a bunch of other modem and FEC
code) on a 180 MHz stm32 and it works just fine in real time.  So your
expectations are quite realistic.

The build system we use for the stm32 is in
codec2/stm32/CMakeLists.txt, including C compiler flags (looks like we
use -O3).  We also use -O2 and -O3 on the build system for larger
machines and don't have any problems.

So it's probably some sort of configuration issue on your build system.
 A good approach is to start with something that works (e.g. our stm32
build system), then maybe move to the IDE.

- David

On Mon, 2023-11-20 at 14:21 +0100, Jan Ropek wrote:
> Hello,
> 
> my goal was to get Codec2 (encoding and decoding) working on
> STM32F446 running on 180MHz. So, I created a new project for Nucleo
> with F446RE and added Codec2 libraries to it. I compile with GCC
> (using STM32CubeIDE - based on Eclipse).
> 
> I have GCC optimization turned off and encoding and decoding works,
> but the problem is that encoding one 40ms frame (320 B) takes about
> 47 ms, so I am not able to use Codec2 in real-time. So, I am asking
> whether my requirements are unrealistic, or have I implemented Codec2
> incorrectly?
> 
> - I tried comparing CMSIS FFT and KISS FFT, it takes roughly the same
> time.
> 
> - When I turned on GCC optimization to O1 - encoding sped up to about
> 15 ms, but during decoding, a HardFault always occurred.
> 
> Can you please suggest what I might be doing wrong? Many thanks!
> 
> Best regards, Jan.
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Clarifications on quantization

[david]

> misleading to call this "spectral magnitudes" under Bit Allocation on
> the
> website. (Or are LPC coefficients actually also called spectral
> magnitudes?)

The LPC coefficients can be interpreted as conveying the spectral
magnitude information, try taking the DFT of the LPC synthesis filter
spectra.

> In the decoder, a signal is synthesized using the LPC synth filter.

No - we use freq domain techniques, see sine.c: synthesise().

> That should
> already be audible speech. But since the audio quality of pure LPC
> systems is
> low (you write of a "mechanical quality" in your thesis), you do the
> following
> trick: You get the DFT of the LPC-produced signal and extract the
> harmonic
> amplitudes - but from the RMS for reasons not well understood. You
> then apply
> the sinusoidal model (ie. "Reverse FFT"?) including phase information
> derived
> from the voicing bits. Effectively, you are enhancing the LPC
> synthesized speech
> by correcting the harmonic phases, resulting in increased quality.
> 
> Did I get this right?

Not really. The harmonic magnitures are extracted from the LPC
synthesis filter spectra, and we also sample the LPC synthesis filter
spectra to obtain the dispersive part of the phase spectra.

> 
> PS: Off-topic, but what system did you write your thesis in? Is this
> TeX or Troff?
> 

I made a poor decision to use Word, various versions through the 90's.
 I did use Word basic for some automation.

- David




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Clarifications on quantization

[david]

Hi Robin,

> Regarding the quantization of sinusoidal magnitudes/amplitudes, you
> write in a
> blog post (https://www.rowetel.com/?p=130) that the "red line" Am is
> quantized.
> This is not the plain frequency curve (the green one Sw). How exactly
> do you
> derive Am from Sw?

By sampling the LPC synthesis filter Pw=1/|A(e^jw)|^2 at each harmonic.

> But in the Harmonic Sinusoidal Model, you need to have all L
> amplitudes
> available to synthesize the speech signal. How is that achieved? Are
> you simply
> synthesizing 10 harmonics with an appropriately scaled Wo no matter
> what?
> 

The LSPs are converted back to LPC coeffcients {ak}, which are used to
create a LPC synthesis filter, which we sample.  Well actually we take
the RMS value of the spectra in that band rather than sampling at the
harmonic centre.  The blog post you linked to explains that a little
further down, and I think it's in the thesis too.

> The fundamental frequency is determined by trying a number of
> frequencies
> between 50-500 Hz, determining the sinusoidal amplitudes, decoding
> that data and
> comparing it with the original signal? The fundamental frequency will
> be the one
> where that comparison yields the smallest error. This is the
> algorithm described
> in chapter 3.4 of your PhD thesis.
> 
We use the non linear pitch estimation algorithm (in the thesis), the
the MBE pitch estimator (which you outlined above) is used for
refinement of the pitch estimate.

> What's the algorithm you are using to estimate voicing?

The MBE algorithm, but the voicing of all bands is averaged to get a
single metric which we compare to a threshold.

> Furthermore, LPC analysis is performed directly on the speech samples
> (time
> domain) according to the block diagram. How does that fit together
> with using Am
> which is obviously a feature in the frequency domain?

The Am are extracted using freq domain techniques for the purpose of
estimating voicing.  In the LPC quantised modes, then Am are then
discarded and the time domain LPC are transformed to LSPs and sent to
the decoder, where the Am are extracted.
 
> I do have a little bit of experience in signal/audio processing, but
> still find
> it hard to understand all of it. Okay I admit, I get terribly
> confused.

Yes, we realise there is a gap here.  We plan to write a complete
algorithm description to provide a reference in one place.

Cheers,
David R



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - September 16-17, 2023

[David Holman]

Mel,

I have mine on order.  I am glad to hear that it is working well.

Thanks

David, AC7DS


On 9/15/23 19:14, Mel Whitten wrote:


The SM1000 is available now.  I have received the two I ordered and 
they work FB!


Mel, K0PFX

*From:* David Holman 
*Sent:* Friday, September 15, 2023 6:33 PM
*To:* freetel-codec2@lists.sourceforge.net
*Subject:* Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - 
September 16-17, 2023


Is the modem back in production?

Thanks

David, AC7DS

On 9/15/23 16:28, Mooneer Salem wrote:

Hi all,

This is a reminder that this month's FreeDV Activity Day is this
coming weekend. (As a reminder, Activity Day takes place on the
third weekend of every month.) This event will bring together
people interested in HF digital voice on the air for conversation
and fun. Contacts using the official application as well as the
SM1000 handheld microphone and other supporting devices and
applications are welcome.

*Event time*: 12AM Pacific time (0700Z) on September 16 to 11:59PM
(0659Z) on September 17 (48 hours).

*Suggested frequencies*:
80 meters: 3.625, 3.643, 3.693 or 3.697 MHz
60 meters (in countries where allowed): 5.4035 MHz or 5.3665 MHz
40 meters: 7.177 MHz
20 meters: 14.236 MHz or 14.240 MHz
17 meters: 18.118 MHz
15 meters: 21.313 MHz
12 meters: 24.933 MHz
10 meters: 28.330 or 28.720 MHz
10 GHz (for those in range of QO-100): 10489.640 MHz

(Note that LSB/DIGL is used below 10MHz as per current convention
for voice modes, USB/DIGU otherwise. 60 meters is of course
USB/DIGU only.)

As this isn't a contest, there's no pressure to make contacts or
send logs, but you can always confirm QSOs via the usual means if
you'd like (LoTW, eQSL, QRZ, etc.) Enabling reporting (PSK
Reporter and FreeDV Reporter) in the FreeDV application and
joining FreeDV Reporter and Discord are recommended, however, so
others can see that you're on the air and hearing them (for
instance, here's the current map of listeners). :D

Feel free to spread this far and wide among your local ham friends
and groups! :) Let me know if you have any questions about the
event and definitely post here if you have issues getting the
application working prior to the event.

Thanks,

-Mooneer K6AQ




___

Freetel-codec2 mailing list

Freetel-codec2@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


OpenPGP_signature
Description: OpenPGP digital signature
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - September 16-17, 2023

[David Holman]

Is the modem back in production?

Thanks

David, AC7DS

On 9/15/23 16:28, Mooneer Salem wrote:

Hi all,

This is a reminder that this month's FreeDV Activity Day is this 
coming weekend. (As a reminder, Activity Day takes place on the third 
weekend of every month.) This event will bring together people 
interested in HF digital voice on the air for conversation and fun. 
Contacts using the official application as well as the SM1000 handheld 
microphone and other supporting devices and applications are welcome.


*Event time*: 12AM Pacific time (0700Z) on September 16 to 11:59PM 
(0659Z) on September 17 (48 hours).


*Suggested frequencies*:
80 meters: 3.625, 3.643, 3.693 or 3.697 MHz
60 meters (in countries where allowed): 5.4035 MHz or 5.3665 MHz
40 meters: 7.177 MHz
20 meters: 14.236 MHz or 14.240 MHz
17 meters: 18.118 MHz
15 meters: 21.313 MHz
12 meters: 24.933 MHz
10 meters: 28.330 or 28.720 MHz
10 GHz (for those in range of QO-100): 10489.640 MHz

(Note that LSB/DIGL is used below 10MHz as per current convention for 
voice modes, USB/DIGU otherwise. 60 meters is of course USB/DIGU only.)


As this isn't a contest, there's no pressure to make contacts or send 
logs, but you can always confirm QSOs via the usual means if you'd 
like (LoTW, eQSL, QRZ, etc.) Enabling reporting (PSK Reporter and 
FreeDV Reporter) in the FreeDV application and joining FreeDV Reporter 
and Discord are recommended, however, so others can see that you're on 
the air and hearing them (for instance, here's the current map of 
listeners). :D


Feel free to spread this far and wide among your local ham friends and 
groups! :) Let me know if you have any questions about the event and 
definitely post here if you have issues getting the application 
working prior to the event.


Thanks,

-Mooneer K6AQ


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


OpenPGP_signature
Description: OpenPGP digital signature
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Change to static codec2 for internal builds of FreeDV?

[david]

Hi Richard,

> I just went through a painful update and dependency rebuild in Fedora
> Rawhide for codec 1.2 and I don't really want to go through that
> again 2 more times for Fedora 37 and 38.

Could you please explain where the pain points were?

Another question I've been pondering - do you have any evidence that
anyone is actually using the Fedora FreeDV packages?

The reason I ask is that for some reason we get a lot traffic/requests
from package maintainers ... which translates to a lot of effort. But
the on-air usage numbers of FreeDV are quite low and we know most of
them are Windows users. A proportion of Linux uses (Fedora or
otherwise) will likely build from source in order to obtain the latest.

So I am wondering if the package maintainers outnumber users of the
FreeDV packages they maintain.  I'd like to do a sanity check - make
sure the effort involved is actually helping end users and the FreeDV
project.

Thanks,
David





___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] New to the list

[David Holman]

All,

I am new to this list.  I was trying to find an SM1000 FreeDV Modem.  
Since I can't seem to buy one, I was going to build one myself.  Does 
anyone have any suggestions about how to get started with that?


Thanks

David, AC7DS




OpenPGP_signature
Description: OpenPGP digital signature
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] FreeDV at Dayton

[david]

Yes - well done Mooneer :-)

On Thu, 2023-05-18 at 13:20 -0500, walt...@k5wh.net wrote:
>  I say Ditto!
> 
> Brian said best. We all owe Mooneer a great deal indeed for all the
> fantastic things he's been doing for FreeDV for quite a while now.
> 
> Walter/K5WH
> 
> -Original Message-
> From: Brian Morrison  
> Sent: Thursday, May 18, 2023 12:23 PM
> To: freetel-codec2@lists.sourceforge.net
> Subject: Re: [Freetel-codec2] FreeDV at Dayton
> 
> On Thu, 18 May 2023 09:33:02 -0700
> Mooneer Salem  wrote:
> 
> > Hi all,
> > 
> > I'll be manning the HamOpen booth at Dayton this weekend (along
> > with 
> > the folks from M17), booth 1909. If you're going to Dayton,
> > definitely 
> > check us out!
> > 
> > (Also, as Mel previously mentioned, I'll be giving a FreeDV talk
> > at 
> > 9:15am on Sunday in Room 1. :)
> 
> Good news Mooneer, while you're talking make sure you absorb the
> glory for
> having worked so hard on FreeDV-GUI and the FreeDV Reporter. The
> current
> state of the whole system is a big leap forward.
> 
> All of us owe you our thanks for this massive effort :)
> 



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] FreeDV v1.8.5-20221118 released

[David Tiller]

I definitely use somewhat more mature Macs. 3, in fact. Please try to maintain 
build compatibility for as long as you can.

> On Nov 19, 2022, at 5:33 AM, Al Beard  wrote:
> 
> Hi all,
> 
> 
> I've downloaded Mooneer's  latest tar.gz and am, at this moment battling with 
> /!\ WARNING: Can't get path for '@rpath/liblpcnetfreedv.0.4.dylib'
> 
> But in the end, I won. You'll find it at:
> 
> http://www.unixservice.com.au/hamradio/freedv/FreeDVcatalina.dmg
> 
> 
> And again I ask: How many users of older MACs do we have?
> 
> Please be counted as, for every answer, perhaps 1000 others will
> just try and not give any feedback.
> 
> Alan VK2ZIW
> 
> 
> 
> On Fri, 18 Nov 2022 13:56:42 -0800, Mooneer Salem wrote 
> > Hi all, 
> > 
> > I've generated a pre-release build of FreeDV that contains the following 
> > since the previous pre-release build: 
> > 
> > * Additional AVX/AVX2 crash fixes (see drowe67/LPCNet#48) 
> > * wxWidgets update to version 3.2.1 (PR #302) 
> > 
> > Windows and macOS binaries (as well as source code) can be downloaded from 
> > https://github.com/drowe67/freedv-gui/releases/tag/v1.8.5-20221118 
> > . 
> > 
> > Thanks, 
> > 
> > -Mooneer K6AQ 
> 
> 
> --- 
> Alan VK2ZIW 
> Before the Big Bang, God, Sela. 
> OpenWebMail 2.53, nothing in the cloud. 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - December 16-17, 2022

[David Tiller]

Mooneer,

Your latest drop starts up and seems to mostly work!

 I've noticed a couple of things, however. Often hitting 'stop' hangs the app 
hard and you have to force quit it. Also, the waterfall sometimes starts 
'smearing' at the top, as if the audio is no longer updating.

Thanks again for your hard work! Now I just need someone to test with. :-)



> On Nov 15, 2022, at 12:02 AM, Mooneer Salem  wrote:
> 
> Hi David and Al,
> 
> I just sent out email re: a pre-release build that should work now (or well, 
> it seems to on my VM setup anyway). There do seem to be some UI glitches but 
> we can investigate those next after I get confirmation. For reference, the 
> link to that build is at 
> https://github.com/drowe67/freedv-gui/releases/tag/v1.8.5-20221114 
> <https://github.com/drowe67/freedv-gui/releases/tag/v1.8.5-20221114>.
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> On Mon, Nov 14, 2022 at 4:00 PM Al Beard  <mailto:bear...@unixservice.com.au>> wrote:
> Hi Mooneer,
> 
> I've downloaded your build for earlier OSX, sorry, doesn't work:
> 
> 
> Process:   FreeDV [653]
> Path:  /Applications/FreeDV.app/Contents/MacOS/FreeDV
> Identifier:FreeDV
> Version:   ??? (1.8.5)
> Code Type: X86-64 (Native)
> Parent Process:??? [1]
> Responsible:   FreeDV [653]
> User ID:   501
> 
> Date/Time: 2022-11-15 08:42:10.561 +1100
> OS Version:Mac OS X 10.15.3 (19D76)  
> Catalina
> Report Version:12
> Anonymous UUID:E215C155-F950-4ED2-AF3A-7CB392630AD3
> 
> 
> Time Awake Since Boot: 1900 seconds
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Reason:DYLD, [0x4] Symbol missing
> 
> Application Specific Information:
> dyld: launch, loading dependent libraries
> 
> Dyld Error Message:
>   Symbol not found: ___darwin_check_fd_set_overflow
>   Referenced from: 
> /Applications/FreeDV.app/Contents/MacOS/../libs/../libs/libcrypto.3.dylib 
> (which was built for Mac OS X 13.0)
>   Expected in: /usr/lib/libSystem.B.dylib
> 
> Binary Images:
>0x1021b4000 -0x102ba3ff7 +org.freedv.freedv (??? - 1.8.5) 
> <668B4C4A-EF82-3757-BEB0-0BEFA300FFB1> 
> /Applications/FreeDV.app/Contents/MacOS/FreeDV
>0x103bec000 -0x103d13fff +libcodec2.1.0.dylib (0) 
> <2B079505-DAF9-35D2-96FA-1271CC00468D> 
> /Applications/FreeDV.app/Contents/libs/libcodec2.1.0.dylib
>0x103d7b000 -   
> bash-5.1$ 
> 
> 
> On Sat, 12 Nov 2022 12:20:57 -0500, David Tiller wrote 
> > Mooneer, 
> > 
> 
> > Is there a build of FreeDV that'll run on OSX 10.13.6?  
> > 
> 
> > Thanks, K4DET 
> 
> > 
>> 
>> > On Nov 12, 2022, at 12:15 PM, Mooneer Salem > > <mailto:moon...@gmail.com>> wrote: 
>> 
>> > 
>> > Hi all, 
>> > 
>> 
>> > By popular demand, FreeDV Activity Day is moving to once a month! As 
>> > Activity Day last occurred on November 5-6, the next one will take place 
>> > on December 16-17, 2022. (Future Activity Days will take place on the 
>> > third weekend of every month.) This event will bring together people 
>> > interested in HF digital voice on the air for conversation and fun. 
>> > Contacts usingthe official application <https://freedv.org/>as well as the 
>> > SM1000 handheld microphone are welcome. 
>> > 
>> > 
>> 
>> > Event time: 12AM Pacific time (0800Z) on December 16 to 11:59PM (0759Z) on 
>> > December 17 (48 hours). 
>> > 
>> 
>> > Suggested frequencies: 
>> > 80 meters: 3.625, 3.643 or 3.693 MHz 
>> > 40 meters: 7.177 MHz 
>> > 20 meters: 14.236 MHz 
>> > 17 meters: 18.118 MHz 
>> > 15 meters: 21.313 MHz 
>> > 12 meters: 24.933 MHz 
>> > 10 meters: 28.330 or 28.720 MHz 
>> > 
>> 
>> > (Note that LSB/DIGL is used below 10MHz as per current convention for 
>> > voice modes, USB/DIGU otherwise.) 
>> 
>> > 
>> 
>> > As this isn't a contest, there's no pressure to make contacts or send 
>> > logs, but you can always confirm QSOs via the usual means if you'd like 
>> > (LoTW, eQSL, QRZ, etc.) Enabling PSK Reporter in the FreeDV application 
>> > and joining theQSO Finder <http://qso.freedv.org/>are recommended, 
>> > h

Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - December 16-17, 2022

[David Tiller]

Sorry, Mooneer, that didn't work. The current app requires OSX 12.0. 




> On Nov 12, 2022, at 1:04 PM, Mooneer Salem  wrote:
> 
> Hi David,
> 
> FreeDV does in fact work on macOS! For recent releases 
> (https://github.com/drowe67/freedv-gui/releases/tag/v1.8.4 
> <https://github.com/drowe67/freedv-gui/releases/tag/v1.8.4>), simply download 
> the FreeDV.dmg file and copy the FreeDV application inside it to the 
> Applications folder on the dock. Note that you'll likely need to go to your 
> security settings and allow it to run as the application is not currently 
> signed.
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> On Sat, Nov 12, 2022 at 9:51 AM David Tiller  <mailto:dtil...@davidtiller.com>> wrote:
> Mooneer,
> 
> Is there a build of FreeDV that'll run on OSX 10.13.6? 
> 
> Thanks, K4DET
> 
>> On Nov 12, 2022, at 12:15 PM, Mooneer Salem > <mailto:moon...@gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> By popular demand, FreeDV Activity Day is moving to once a month! As 
>> Activity Day last occurred on November 5-6, the next one will take place on 
>> December 16-17, 2022. (Future Activity Days will take place on the third 
>> weekend of every month.) This event will bring together people interested in 
>> HF digital voice on the air for conversation and fun. Contacts usingthe 
>> official application <https://freedv.org/>as well as the SM1000 handheld 
>> microphone are welcome.
>> 
>> Event time: 12AM Pacific time (0800Z) on December 16 to 11:59PM (0759Z) on 
>> December 17 (48 hours).
>> 
>> Suggested frequencies:
>> 80 meters: 3.625, 3.643 or 3.693 MHz
>> 40 meters: 7.177 MHz
>> 20 meters: 14.236 MHz
>> 17 meters: 18.118 MHz
>> 15 meters: 21.313 MHz
>> 12 meters: 24.933 MHz
>> 10 meters: 28.330 or 28.720 MHz
>> 
>> (Note that LSB/DIGL is used below 10MHz as per current convention for voice 
>> modes, USB/DIGU otherwise.)
>> 
>> As this isn't a contest, there's no pressure to make contacts or send logs, 
>> but you can always confirm QSOs via the usual means if you'd like (LoTW, 
>> eQSL, QRZ, etc.) Enabling PSK Reporter in the FreeDV application and joining 
>> theQSO Finder <http://qso.freedv.org/>are recommended, however, so others 
>> can see that you're on the air and hearing them (for instance, here'sthe 
>> current map of listeners 
>> <https://pskreporter.info/pskmap?preset=Z=FREEDV=3600=31.442130629514438,9.522916,1.9517274414542571>).
>>  :D
>> 
>> Feel free to spread this far and wide among your local ham friends and 
>> groups! :) Let me know if you have any questions about the event and 
>> definitely post here if you have issues getting the application working 
>> prior to the event.
>> 
>> Thanks,
>> 
>> -Mooneer K6AQ
>> ___
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net 
>> <mailto:Freetel-codec2@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 
>> <https://lists.sourceforge.net/lists/listinfo/freetel-codec2>
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net 
> <mailto:Freetel-codec2@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 
> <https://lists.sourceforge.net/lists/listinfo/freetel-codec2>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] [Announcement] FreeDV Activity Day - December 16-17, 2022

[David Tiller]

Mooneer,

Is there a build of FreeDV that'll run on OSX 10.13.6? 

Thanks, K4DET

> On Nov 12, 2022, at 12:15 PM, Mooneer Salem  wrote:
> 
> Hi all,
> 
> By popular demand, FreeDV Activity Day is moving to once a month! As Activity 
> Day last occurred on November 5-6, the next one will take place on December 
> 16-17, 2022. (Future Activity Days will take place on the third weekend of 
> every month.) This event will bring together people interested in HF digital 
> voice on the air for conversation and fun. Contacts usingthe official 
> application as well as the SM1000 handheld microphone 
> are welcome.
> 
> Event time: 12AM Pacific time (0800Z) on December 16 to 11:59PM (0759Z) on 
> December 17 (48 hours).
> 
> Suggested frequencies:
> 80 meters: 3.625, 3.643 or 3.693 MHz
> 40 meters: 7.177 MHz
> 20 meters: 14.236 MHz
> 17 meters: 18.118 MHz
> 15 meters: 21.313 MHz
> 12 meters: 24.933 MHz
> 10 meters: 28.330 or 28.720 MHz
> 
> (Note that LSB/DIGL is used below 10MHz as per current convention for voice 
> modes, USB/DIGU otherwise.)
> 
> As this isn't a contest, there's no pressure to make contacts or send logs, 
> but you can always confirm QSOs via the usual means if you'd like (LoTW, 
> eQSL, QRZ, etc.) Enabling PSK Reporter in the FreeDV application and joining 
> theQSO Finder are recommended, however, so others can 
> see that you're on the air and hearing them (for instance, here'sthe current 
> map of listeners 
> ).
>  :D
> 
> Feel free to spread this far and wide among your local ham friends and 
> groups! :) Let me know if you have any questions about the event and 
> definitely post here if you have issues getting the application working prior 
> to the event.
> 
> Thanks,
> 
> -Mooneer K6AQ
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] [Ham-Radio-Tech-Notes] [Announcement] FreeDV Activity Day - November 5-6, 2022

[David Ranch]

Hello Mooner,

Thank you to yourself and the larger team for putting together this 
event!  It's been a long time since I've dabbled with FreeDV and since 
I'm on a new machine, I thought I'd give it a try.  Question for you:  I 
am using Ubuntu 20.04 where the Canonical repos offer FreeDV (gui) 1.4 
and Codec2 0.9.2.  I know those are not the newest versions of code but 
are they current enough to be compatible with the newer versions of code?


--David
KI6ZHD


On 11/04/2022 05:12 PM, Mooneer Salem wrote:

Hi all,

There are now less than 7 hours until Activity Day weekend starts. 
Good luck! Please post any last minute questions here if you have them :)


Thanks,

-Mooneer K6AQ

On Sat, Oct 29, 2022 at 11:13 PM Mooneer Salem via groups.io 
<http://groups.io> <mailto:gmail@groups.io>> wrote:


Hi all,

Just a reminder that Activity Day weekend is only a week away! If
you haven't already, download the latest release of FreeDV and
make sure everything is working properly. Please post here if you
have any setup issues prior to next weekend and we'll help you get
situated :)

Thanks,

-Mooneer K6AQ

On Thu, Oct 6, 2022 at 12:18 AM Mooneer Salem mailto:moon...@gmail.com>> wrote:

Hi all,

We'll be doing anotherFreeDVActivityDayon the weekend of
November 5-6, 2022! This event will bring together people
interested in HF digital voice on the air for conversation and
fun. Contacts usingthe official application
<https://freedv.org/>as well as the SM1000 handheld microphone
are welcome.

(Note: this is different than previous Activity Days in that
you have the entire weekend, not just a 24 hour period. This
may continue for future Activity Days based on how the
upcoming one goes.)

*Event time:* 12AM Pacific time (0700Z) on November 5 to
11:59PM (0759Z) on November 6 (49 hours). /Note: Daylight
Saving Time ends in the US during Activity Day weekend./
/
/
*Suggested frequencies*:
80 meters: 3.625, 3.643 or 3.693 MHz
40 meters: 7.177 MHz
20 meters: 14.236 MHz
17 meters: 18.118 MHz
15 meters: 21.313 MHz
12 meters: 24.933 MHz
10 meters: 28.330 or 28.720 MHz

(Note that LSB/DIGL is used below 10MHz as per current
convention for voice modes, USB/DIGU otherwise.)

As this isn't a contest, there's no pressure to make contacts
or send logs, but you can always confirm QSOs via the usual
means if you'd like (LoTW, eQSL, QRZ, etc.) Enabling PSK
Reporter in the FreeDV application and joining theQSO Finder
<http://qso.freedv.org/>are recommended, however, so others
can see that you're on the air and hearing them (for instance,
here'sthe current map of listeners

<https://pskreporter.info/pskmap?preset=Z=FREEDV=3600=31.442130629514438,9.522916,1.9517274414542571>).
:D

Feel free to spread this far and wide among your local ham
friends and groups! :) Let me know if you have any questions
about the event and definitely post here if you have issues
getting the application working prior to the event.

Thanks,

-Mooneer K6AQ

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#1888)
<https://Ham-Radio-Tech-Notes.groups.io/g/main/message/1888> |
Reply To Group

<mailto:m...@ham-radio-tech-notes.groups.io?subject=Re:%20Re%3A%20%5BHam-Radio-Tech-Notes%5D%20%5BAnnouncement%5D%20FreeDV%20Activity%20Day%20-%20November%205-6%2C%202022>
| Reply To Sender

<mailto:moon...@gmail.com?subject=Private:%20Re:%20Re%3A%20%5BHam-Radio-Tech-Notes%5D%20%5BAnnouncement%5D%20FreeDV%20Activity%20Day%20-%20November%205-6%2C%202022>
| Mute This Topic <https://groups.io/mt/94153064/244332> | New
Topic <https://Ham-Radio-Tech-Notes.groups.io/g/main/post>


Group Email Addresses
Post: ham-radio-tech-no...@groups.io
<mailto:ham-radio-tech-no...@groups.io>
Subscribe: ham-radio-tech-notes+subscr...@groups.io
<mailto:ham-radio-tech-notes%2bsubscr...@groups.io>
Unsubscribe: ham-radio-tech-notes+unsubscr...@groups.io
<mailto:ham-radio-tech-notes%2bunsubscr...@groups.io>
Group Owner: ham-radio-tech-notes+ow...@groups.io
<mailto:ham-radio-tech-notes%2bow...@groups.io>
Help: ham-radio-tech-notes+h...@groups.io
<mailto:ham-radio-tech-notes%2bh...@groups.io>

Your Subscription
<https://Ham-Radio-Tech-Notes.groups.io/g/main/editsub/

Re: [Freetel-codec2] Q2 2022 FreeDV Activity Day results

[david]

Thank you Mooneer for organising the event :-)

On Sun, 2022-08-07 at 20:41 -0700, Mooneer Salem wrote:
> Hi all,
> 
> Another great Activity Day here! (Unfortunately, technical issues on
> my end* plus travel limited my time on the air this time, but there's
> always next time.) I took some screenshots of the activity reported
> by PSK Reporter and posted them up at https://imgur.com/a/a9QCoic for
> those interested.
> 
> Anyway, for those who participated, feel free to reply with how it
> went for you :)
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> (* Wi-Fi on macOS has been a constant problem for me. SDR apps on
> that platform have had a bad habit of producing choppy audio unless
> on Ethernet, hence causing me decode issues. I'm not sure why since I
> have a lot fewer issues related to Wi-Fi on my Windows and Linux
> devices. Fortunately, using the "data offloading" feature of my
> Netgear hotspot seems to be a decent workaround that lets me use
> hotel, etc. internet while also using Ethernet.)
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Function removed in 1.0.4?

[david]

Hi Richard,

Further to this Mooneer and I have released codec2 1.0.4_rc2 -
hopefully it resolves the interleave_frames' issue in this thread.  If
not - please raise an issue on GitHub.

Thanks,
David

On Sun, 2022-07-10 at 07:07 +0930, david wrote:
> Hi Richard,
> 
> Looks like the variable 'interleave_frames' has been removed (it was
> unused for some time) in 1.0.4
> 
> 1.0.4 might have been released prematurely - the 2020B/C modes are
> still experimental and now I can see the API has been temporarily
> hacked to support that experimentation (by me, earlier this year). 
> 
> 1.0.4 was pushed out quickly just to support a recent freedv-gui
> release.
> 
> Perhaps in this case we need a notation for interim releases to
> signal
> users outside of freedv-gui shouldn't be using a codec2 release (like
> a
> beta tag).  Or a more formal release procedure that catches issues
> like
> breaking other applications due to API changes.
> 
> As an aside there is no need for sdr angel or GNU radio to be using
> freedv_open_advanced(), they should be using freedv_open().
>  freedv_open_advanced() is only used for data applications.
> 
> Cheers,
> David
> 
> On Sat, 2022-07-09 at 11:45 -0500, Richard Shaw wrote:
> > Trying to rebuild codec2 deps with version 1.0.4 and ran into this
> > issue with gnuradio and sdrangel...
> > 
> > /builddir/build/BUILD/gnuradio-3.10.3.0/gr-
> > vocoder/lib/freedv_rx_ss_impl.cc: In constructor
> > 'gr::vocoder::freedv_rx_ss_impl::freedv_rx_ss_impl(int, float,
> > int)':
> > /builddir/build/BUILD/gnuradio-3.10.3.0/gr-
> > vocoder/lib/freedv_rx_ss_impl.cc:41:15: error: 'struct
> > freedv_advanced' has no member named 'interleave_frames'
> >41 | d_adv.interleave_frames = interleave_frames;
> >   |   ^
> > /builddir/build/BUILD/sdrangel-
> > 7.4.0/plugins/channelrx/demodfreedv/freedvdemodsink.cpp: In member
> > function 'void
> > FreeDVDemodSink::applyFreeDVMode(FreeDVDemodSettings::FreeDVMode)':
> > /builddir/build/BUILD/sdrangel-
> > 7.4.0/plugins/channelrx/demodfreedv/freedvdemodsink.cpp:436:13:
> > error: 'struct freedv_advanced' has no member named
> > 'interleave_frames'
> >   436 | adv.interleave_frames = 1;
> >   | ^
> > 
> > Thanks,
> > Richard
> > KF5OIM
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Function removed in 1.0.4?

[david]

Hi Richard,

Looks like the variable 'interleave_frames' has been removed (it was
unused for some time) in 1.0.4

1.0.4 might have been released prematurely - the 2020B/C modes are
still experimental and now I can see the API has been temporarily
hacked to support that experimentation (by me, earlier this year). 

1.0.4 was pushed out quickly just to support a recent freedv-gui
release.

Perhaps in this case we need a notation for interim releases to signal
users outside of freedv-gui shouldn't be using a codec2 release (like a
beta tag).  Or a more formal release procedure that catches issues like
breaking other applications due to API changes.

As an aside there is no need for sdr angel or GNU radio to be using
freedv_open_advanced(), they should be using freedv_open().
 freedv_open_advanced() is only used for data applications.

Cheers,
David

On Sat, 2022-07-09 at 11:45 -0500, Richard Shaw wrote:
> Trying to rebuild codec2 deps with version 1.0.4 and ran into this
> issue with gnuradio and sdrangel...
> 
> /builddir/build/BUILD/gnuradio-3.10.3.0/gr-
> vocoder/lib/freedv_rx_ss_impl.cc: In constructor
> 'gr::vocoder::freedv_rx_ss_impl::freedv_rx_ss_impl(int, float, int)':
> /builddir/build/BUILD/gnuradio-3.10.3.0/gr-
> vocoder/lib/freedv_rx_ss_impl.cc:41:15: error: 'struct
> freedv_advanced' has no member named 'interleave_frames'
>41 | d_adv.interleave_frames = interleave_frames;
>   |   ^
> /builddir/build/BUILD/sdrangel-
> 7.4.0/plugins/channelrx/demodfreedv/freedvdemodsink.cpp: In member
> function 'void
> FreeDVDemodSink::applyFreeDVMode(FreeDVDemodSettings::FreeDVMode)':
> /builddir/build/BUILD/sdrangel-
> 7.4.0/plugins/channelrx/demodfreedv/freedvdemodsink.cpp:436:13:
> error: 'struct freedv_advanced' has no member named
> 'interleave_frames'
>   436 | adv.interleave_frames = 1;
>   | ^
> 
> Thanks,
> Richard
> KF5OIM
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Spring 2022 FreeDV Activity Day wrap-up

[david]

Hi Mooneer,

Thanks for coordinating the event.

Just saying Sat/Sun (everywhere) would work better for me, rather than
defining the event based on times local to a certain geographical area.
 The current events are already spread across Sat/Sunday for me.

Cheers,
David

On Mon, 2022-05-30 at 15:27 -0700, Mooneer Salem wrote:
> Hi all,
> 
> I wonder--would making it last the entire weekend work better than
> having it only last 24 hours? Might give more of a chance for people
> to participate. What are your thoughts on that?
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> On Mon, May 30, 2022 at 7:17 AM Brian Morrison 
> wrote:
> > On Sun, 29 May 2022 15:45:08 -0700
> > Mooneer Salem  wrote:
> > 
> > > Hi all,
> > > 
> > > How did you guys enjoy Activity Day this weekend? What went well,
> > and what
> > > should be improved for next time?
> > 
> > Propagation conditions were very variable for me, solar indices
> > didn't
> > give a good idea of what was likely to work. The bands were very
> > quiet
> > for most of the weekend.
> > 
> > I heard one station in OE on 40m and a couple on 20m but the latter
> > were fleeting and I only realised that the 2nd one was there when a
> > lull in the TV volume allowed me to hear speech via the headphones
> > lying on my desk.
> > 
> > I recommend sending the sun a postcard to let it know what we're
> > planning :)
> > 
> > > 
> > > BTW, the next one is planned to be on August 6-7th, so save space
> > on your
> > > calendars now :)
> > 
> > OK, will do. Perhaps a schedule for activity with a few times/freqs
> > that
> > are likely to work for both US and Europe? That will probably need
> > some
> > thought with timezones affecting things.
> > 
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] FreeDATA has changed the Codec2 API

[david]

Hi Al,

I'm not aware of any significant changes to the API.  Is there a
specific GitHub hash or function you are referring to?

- David

On Tue, 2022-04-26 at 14:51 +1000, Al Beard wrote:
> Hi all,
> 
> The new FreeDATA code has changed the Codec2 API. Just informing
> developers out there, of other apps. 
> 
> --- 
> Alan VK2ZIW 
> Before the Big Bang, God, Sela. 
> OpenWebMail 2.53, nothing in the cloud. 
> 
>  ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] "freebeacon" Setting it up

[david]

Over last weekend I experienced Alan's beacon first hand. It was
configured to broadcast every few minutes.  The prompt did not identify
it as a beacon, it sounded like Alan testing.  When I called CQ on
7.177 it immediately responded to me with the same prompt. This was
very confusing to me, until I figured out what was going on.  

On the activity day weekend (and possibly at other times) in VK Alan's
beacon was effectively blocking any use of FreeDV 7.177.  Other users
have had to shift +/- 3kHz in order to use FreeDV on 40m.

I have emailed Alan several times asking him to disable his beacon or
adjust it such that it does not interfere with other users of the band.

Although I haven't checked the local regulations, I imagine a software
device configured in such a way that it interferes with other users of
the band is not permitted in Australia or any other country.

BTW this is not https://github.com/drowe67/freebeacon - this is Alan's
derivative.  Despite several invitations over many years his code has
not been reviewed and is not associated with the core FreeDV team.
FreeBeacon does not broadcast, and would only respond if triggered by a
special txt string.  And it should be configured to identify itself.

Can I suggest we close this topic?  I don't think it warrants our time
and attention either on this mailing list, or over the air.  Just like
FreeDV on 7.177 in VK, this topic seems to have taken over the list
discussion, at a time when there are for more interesting initiatives
going on.

- David

On Wed, 2022-02-23 at 12:44 -0800, Mooneer Salem wrote:
> Hi Al,
> 
> I added the qualifier "per FCC rules" in my last email to indicate
> that this is a US specific thing. Other countries, of course, have
> different rules. 
> 
> Anyway, regardless of where we all live, I'm sure we can agree that
> it's just as important to be good stewards of our allocated RF
> spectrum. Thus, we should do everything possible to minimize
> interference to other users, FreeDV and non-DV alike. Something that
> doesn't transmit back and simply uploads recordings somewhere seems
> like it'd be the least likely to interfere with people, at least IMO.
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> On Wed, Feb 23, 2022 at 12:36 PM Al Beard  > wrote:
> > Guys,
> > 
> > This is an INTERNATIONAL email group, I'm in Australia and not
> > subject to FCC rules.
> > So please, please think outside the square! At least mention your
> > country or state
> > your callsign.
> > 
> > We are trying to explore here, new technology!
> > 
> > Alan VK2ZIW
> > 
> > On Wed, 23 Feb 2022 13:46:37 -0500, David Tiller wrote 
> > > >  As for CW, IIRC it's allowed everywhere on the ham bands per
> > FCC rules. 
> > > 
> > 
> > > CW sent by a locally-controlled station is legal everywhere. CW
> > sent by an automatically-controlled digital station (for purposes
> > other than identification) is suspect. The part I mentioned
> > specifically says RTTY or digital modes. CW is it's own animal,
> > IIRC. Neither fish nor fowl, Data or Phone. 
> > > 
> > 
> > > 
> > > > On Feb 23, 2022, at 1:01 PM, Mooneer Salem 
> > > wrote: 
> > > 
> > > > As for CW, IIRC it's allowed everywhere on the ham bands per
> > > FCC rules.
> >  
> > 
> > 
> > 
> > --- 
> > Alan VK2ZIW 
> > Before the Big Bang, God, Sela. 
> > OpenWebMail 2.53, nothing in the cloud. 
> > 
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] "freebeacon" Setting it up

[David Tiller]

I'm K4DET in the US, obviously.

I'm glad you're not in the US and can run a parrot. We were trying to determine 
a way to help you guys out with some NA parrots. 

If you want to stay isolated in the outback with your cute new protocol that's 
fine with me.

So much for trying to help spread the word. Sheesh.

> On Feb 23, 2022, at 3:35 PM, Al Beard  wrote:
> 
> Guys,
> 
> This is an INTERNATIONAL email group, I'm in Australia and not subject to FCC 
> rules.
> So please, please think outside the square! At least mention your country or 
> state
> your callsign.
> 
> We are trying to explore here, new technology!
> 
> Alan VK2ZIW
> 
> On Wed, 23 Feb 2022 13:46:37 -0500, David Tiller wrote 
> > >  As for CW, IIRC it's allowed everywhere on the ham bands per FCC rules. 
> > 
> 
> > CW sent by a locally-controlled station is legal everywhere. CW sent by an 
> > automatically-controlled digital station (for purposes other than 
> > identification) is suspect. The part I mentioned specifically says RTTY or 
> > digital modes. CW is it's own animal, IIRC. Neither fish nor fowl, Data or 
> > Phone. 
> > 
> 
> > 
>> 
>> > On Feb 23, 2022, at 1:01 PM, Mooneer Salem > > <mailto:moon...@gmail.com>> wrote: 
>> 
>> > As for CW, IIRC it's allowed everywhere on the ham bands per FCC rules.
> 
> 
> 
> 
> --- 
> Alan VK2ZIW 
> Before the Big Bang, God, Sela. 
> OpenWebMail 2.53, nothing in the cloud. 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] "freebeacon" Setting it up

[David Tiller]

> As for CW, IIRC it's allowed everywhere on the ham bands per FCC rules.

CW sent by a locally-controlled station is legal everywhere. CW sent by an 
automatically-controlled digital station (for purposes other than 
identification) is suspect. The part I mentioned specifically says RTTY or 
digital modes. CW is it's own animal, IIRC. Neither fish nor fowl, Data or 
Phone.


> On Feb 23, 2022, at 1:01 PM, Mooneer Salem  wrote:
> 
> As for CW, IIRC it's allowed everywhere on the ham bands per FCC rules.

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] "freebeacon" Setting it up

[David Tiller]

Mooneer,

How about a version that passively listens and posts the details of what it 
hears on a website? 

Another answer would be to have it reply in a narrowband data mode to make it 
compliant with 97.221(c). Does CW count as digital?

> On Feb 23, 2022, at 01:26, Mooneer Salem  wrote:
> 
> Hi all,
> 
> Honestly, I consider it closest to being a repeater, though that doesn't help 
> with the legality. I wonder if there would still be value in having it behave 
> more like a beacon (one way periodic TX), even if that means it would only be 
> up on 10 meters and above.
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> 
> 
>> On Tue, Feb 22, 2022, 7:33 PM David Tiller  wrote:
>> > Thus far, in the last five years, you Gary have been the only one who's 
>> > asked.
>> 
>> That might be because running an automatically controlled voice parrot in 
>> the HF bands is legally murky here, unfortunately. I'd love to help out but 
>> I don't think it's kosher in the US.
>> 
>> Although, looking at the definition of a repeater from Part 97:
>> 
>> " Repeater. An amateur station that simultaneously retransmits the 
>> transmission of another amateur station on a different channel or channels."
>> 
>> There are 2 points that stick out - simultaneously and 'different channel'. 
>> Your parrot does neither of these. Humm.
>> 
>> How about an automatically-controlled digital station? Unless your emission 
>> is classified as RTTY or data, no joy.
>> 
>> § 97.221 Automatically controlled digital station. 
>> (a) This rule section does not apply to an auxiliary station, a beacon 
>> station, a repeater station, an earth station, a space station, or a space 
>> telecommand station. 
>> 
>> (b) A station may be automatically controlled while transmitting a RTTY or 
>> data emission on the 6 m or shorter wavelength bands, and on the 28.120– 
>> 28.189 MHz, 24.925–24.930 MHz, 21.090– 21.100 MHz, 18.105–18.110 MHz, 
>> 14.0950– 14.0995 MHz, 14.1005–14.112 MHz, 10.140– 10.150 MHz, 7.100–7.105 
>> MHz, or 3.585– 3.600 MHz segments. 
>> 
>> (c) A station may be automatically controlled while transmitting a RTTY or 
>> data emission on any other frequency authorized for such emission types 
>> provided that: 
>>  (1) The station is responding to interrogation by a station under local 
>> or remote control; and 
>>  (2) No transmission from the automatically controlled station occupies 
>> a bandwidth of more than 500 Hz. 
>> 
>> 
>>> On Feb 22, 2022, at 7:09 PM, Al Beard  wrote:
>>> 
>>> Hi Gary and all,
>>> 
>>> I've been building computer systems since the '80s. So, it's not hard for 
>>> me.
>>> 
>>> David VK5DGR supplied the "freebeacon" "C" sourcecode way back in the
>>> development of Codec2. A test piece of software, a "reverse beacon", to 
>>> "listen" 
>>> for a Codec2 signal and report on it's bit error rate and transmit that back
>>> in the text part of a transmission. And also a second piece of software to 
>>> use the API (library) and thus check for bugs.
>>> 
>>> I have no problem using the "C" compiler on Linux computers either PC
>>> or the Raspberry Pi and similar ARM based Small Board Computers.
>>> 
>>> Here I use a Banana Pi M2 Berry because it has a SATA port on which is
>>> an SSD. This keeps my power bill down (for this project). Just about
>>> any audio interface that can do a samplerate of 8000 samples per sec.
>>> And, any PTT interface, I use a USB serial port and DTR.
>>> 
>>> A "ready to go" SD card image can readily be made if there's sufficient 
>>> interest. Thus far, in the last five years, you Gary have been the only
>>> one who's asked.
>>> 
>>> 73
>>> 
>>> Alan VK2ZIW
>>> 
>>> On Mon, 21 Feb 2022 01:20:14 -0500, Gary Kohtala - K7EK via Freetel-codec2 
>>> wrote 
>>> > Alan, 
>>> > 
>>> > Please refresh our memory as to how one goes about setting up a  
>>> > FreeBeacon.  Seems that I looked into it early on but passed as it was 
>>> > beyond my abilities at the time. 
>>> > 
>>> > Thanks. 
>>> > 
>>> > Best regards, 
>>> > 
>>> > Gary, K7EK 
>>> > 
>>> 
>>> 
>>> --- 
>>> Alan VK2ZIW 
>>> Before the Big Bang, God, Sela. 
>>> OpenWebMail 2.53, nothing in the cloud. 
>>> 
>>> ___
>>> Freetel-codec2 mailing list
>>> Freetel-codec2@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>> 
>> ___
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] "freebeacon" Setting it up

[David Tiller]

> Thus far, in the last five years, you Gary have been the only one who's asked.

That might be because running an automatically controlled voice parrot in the 
HF bands is legally murky here, unfortunately. I'd love to help out but I don't 
think it's kosher in the US.

Although, looking at the definition of a repeater from Part 97:

" Repeater. An amateur station that simultaneously retransmits the transmission 
of another amateur station on a different channel or channels."

There are 2 points that stick out - simultaneously and 'different channel'. 
Your parrot does neither of these. Humm.

How about an automatically-controlled digital station? Unless your emission is 
classified as RTTY or data, no joy.

§ 97.221 Automatically controlled digital station. 
(a) This rule section does not apply to an auxiliary station, a beacon station, 
a repeater station, an earth station, a space station, or a space telecommand 
station. 

(b) A station may be automatically controlled while transmitting a RTTY or data 
emission on the 6 m or shorter wavelength bands, and on the 28.120– 28.189 MHz, 
24.925–24.930 MHz, 21.090– 21.100 MHz, 18.105–18.110 MHz, 14.0950– 14.0995 MHz, 
14.1005–14.112 MHz, 10.140– 10.150 MHz, 7.100–7.105 MHz, or 3.585– 3.600 MHz 
segments. 

(c) A station may be automatically controlled while transmitting a RTTY or data 
emission on any other frequency authorized for such emission types provided 
that: 
 (1) The station is responding to interrogation by a station under local or 
remote control; and 
 (2) No transmission from the automatically controlled station occupies a 
bandwidth of more than 500 Hz. 


> On Feb 22, 2022, at 7:09 PM, Al Beard  wrote:
> 
> Hi Gary and all,
> 
> I've been building computer systems since the '80s. So, it's not hard for me.
> 
> David VK5DGR supplied the "freebeacon" "C" sourcecode way back in the
> development of Codec2. A test piece of software, a "reverse beacon", to 
> "listen" 
> for a Codec2 signal and report on it's bit error rate and transmit that back
> in the text part of a transmission. And also a second piece of software to 
> use the API (library) and thus check for bugs.
> 
> I have no problem using the "C" compiler on Linux computers either PC
> or the Raspberry Pi and similar ARM based Small Board Computers.
> 
> Here I use a Banana Pi M2 Berry because it has a SATA port on which is
> an SSD. This keeps my power bill down (for this project). Just about
> any audio interface that can do a samplerate of 8000 samples per sec.
> And, any PTT interface, I use a USB serial port and DTR.
> 
> A "ready to go" SD card image can readily be made if there's sufficient 
> interest. Thus far, in the last five years, you Gary have been the only
> one who's asked.
> 
> 73
> 
> Alan VK2ZIW
> 
> On Mon, 21 Feb 2022 01:20:14 -0500, Gary Kohtala - K7EK via Freetel-codec2 
> wrote 
> > Alan, 
> > 
> > Please refresh our memory as to how one goes about setting up a  
> > FreeBeacon.  Seems that I looked into it early on but passed as it was 
> > beyond my abilities at the time. 
> > 
> > Thanks. 
> > 
> > Best regards, 
> > 
> > Gary, K7EK 
> > 
> 
> 
> --- 
> Alan VK2ZIW 
> Before the Big Bang, God, Sela. 
> OpenWebMail 2.53, nothing in the cloud. 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Fwd: [Announcement] FreeDV Activity Day - February 19-20, 2022

[David Grove]

Hi David & Mooneer

 

First of all - thank you to both of you for all your work in advancing
FreeDV/Codec2. It's very much appreciated

 

I like the idea of having a three-monthly activity day that, where feasible,
occurs just after other major activities (Hamventions etc)

 

On the activity day, I tried calling CQ on 7.177 MHz and 14.236 MHz on
several different modes from my home QTH (QRN S3-5) a few times with no
success. 

 

I also happened to be monitoring QSO finder when David, VK5DGR and Mel,
K0PFX were testing on 14.246 MHz. Unfortunately, nothing was heard at my end
on that frequency at the time.

 

At the end of the activity day, I checked PSK reporter and was unable to
find any reports of my callsign on FreeDV

 

I did however hear Alan, VK2ZIW's parrot on a couple of occasions on the
day. However, Alan is about 20 Km from me, so the 40m signal was marginal

 

Nevertheless, I'll keep on trying to reduce the QRN levels at my place and
I'll keep installing the new versions of FreeDV as they're released

 

I'm looking forward to the next activity day

 

Thanks again

 

Regards 

 

 

David Grove - VK2DWG

 

-Original Message-
From: david  
Sent: Tuesday, 22 February 2022 12:32
To: freetel-codec2@lists.sourceforge.net
Subject: Re: [Freetel-codec2] Fwd: [Announcement] FreeDV Activity Day -
February 19-20, 2022

 

> 1. It looks like May 28th-29th will be best for the next one as Dayton 

> is the weekend prior and there seem to be a fair number of other 

> contests across the rest of the month. Does that sound reasonable?

 

Every 3 months sounds good.  Like this time, I'll attempt to have a new
experimental waveform/codec to try out in May.

 

> 2. If you operated this one, how did it work out for you?

 

I managed to receive Mel, k0pfx long path 20M here in South Australia, 1-4dB
SNR on 700D.  I positioned myself in a campground 200km SE of Adelaide
(Parnka Point, in an area known as the Coorong) with sub S0 noise on 20m.
Simple end fed dipole.

 

I also monitored/took part in a few VK QSOs and was pleased to see the
modems handling the HF channel quite well.

 

Pretty happy about that :-)

 

Thanks for organising the event Mooneer :-)

 

- David

 

 

 

___

Freetel-codec2 mailing list

 <mailto:Freetel-codec2@lists.sourceforge.net>
Freetel-codec2@lists.sourceforge.net

 <https://lists.sourceforge.net/lists/listinfo/freetel-codec2>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Fwd: [Announcement] FreeDV Activity Day - February 19-20, 2022

[david]

> 1. It looks like May 28th-29th will be best for the next one as
> Dayton is the weekend prior and there seem to be a fair number of
> other contests across the rest of the month. Does that sound
> reasonable?

Every 3 months sounds good.  Like this time, I'll attempt to have a new
experimental waveform/codec to try out in May.

> 2. If you operated this one, how did it work out for you?

I managed to receive Mel, k0pfx long path 20M here in South Australia,
1-4dB SNR on 700D.  I positioned myself in a campground 200km SE of
Adelaide (Parnka Point, in an area known as the Coorong) with sub S0
noise on 20m.  Simple end fed dipole.

I also monitored/took part in a few VK QSOs and was pleased to see the
modems handling the HF channel quite well.

Pretty happy about that :-)

Thanks for organising the event Mooneer :-)

- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Starting an organization for FreeDV/Codec2 development

[david]

Sounds good Mooneer,

>* SM1000 replacement (faster hardware to support other FreeDV modes,
> Wi-Fi support for radios such as the IC-705, etc.)

Suggest the key requirement here is "ease of use", i.e. how to make
FreeDV as easy to use as SSB. An outboard box being one solution.
 Given the world is going SDR, a software library that can be included
in any radio is another.

> * Offering grants to individual developers to develop Codec2 and
> FreeDV further (e.g. fixed-point ports, improved/more modes, etc.)

* Technical excellence - e.g. speech quality, low and high SNR channel
performance, competitive with analog modes, speaker independence,
robustness to acoustic background noise, robustness to microphone
types/spectral shaping, level variation, source code/software
engineering quality.

Cheers,
David





___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Starting an organization for FreeDV/Codec2 development

[David Grove]

Hi Mooneer

 

An excellent suggestion

 

I agree with the concept and suggest that the mission be extended further to 
something like 

 

"promote the use of open source digital voice and data modes on commercial and 
amateur radio and encourage the development of resilient communication modes 
for adverse conditions"

 

This would give plenty of scope for the advancement of the technology way into 
the future

 

I agree with your key points, recognising that other participants may suggest 
others

 

Regards 

 

 

David Grove – VK2DWG

 

From: Mooneer Salem  
Sent: Monday, 21 February 2022 09:07
To: digitalvo...@googlegroups.com; freetel-codec2@lists.sourceforge.net
Subject: [Freetel-codec2] Starting an organization for FreeDV/Codec2 development

 

Hi all,

 

Over the past year or so, there have been several occasions where it would have 
been beneficial to have had an official organization steering FreeDV and Codec2 
development. For instance, the ARDC does not currently offer grants to 
individuals <https://www.ampr.org/apply/#eligibility> , not to mention the 
recent discussion about Windows Defender 
<https://github.com/drowe67/freedv-gui/issues/213>  and what it would take to 
get FreeDV "trusted" by Microsoft. I'd like to brainstorm what such an 
organization would look like.

 

First off, what would the mission of such an organization be? This seems 
obvious at first glance ("promote the use of open source digital voice modes on 
amateur radio"), but what would that entail exactly? A few potential things off 
the top of my head:

 

* SM1000 replacement (faster hardware to support other FreeDV modes, Wi-Fi 
support for radios such as the IC-705, etc.)

* General software process improvements (code signing of binaries, hosted 
Debian/Fedora/etc. package repos, etc.)

* General advocacy (e.g. presence at more ham radio related events, Zoom/etc. 
presentations about HF digital voice)

* Offering grants to individual developers to develop Codec2 and FreeDV further 
(e.g. fixed-point ports, improved/more modes, etc.)

 

On first thought, it seems that a non-profit/501(c)3 structure would be most 
appropriate given the mission of such a potential organization and its 
dedication to open source, but I'm wondering if some other structure would fit 
better. Another possibility is structuring it more like a membership club (IIRC 
there was a digital voice club back in the FDMDV days but I forget offhand what 
it was).

 

Anyway, if you have any suggestions or comments, they would be most welcome. 

 

Thanks,

 

-Mooneer K6AQ

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] improvements to codec2 above 1200 bits/s

[david]

On this GitHub discussion:

  https://github.com/drowe67/codec2/discussions/283

we are talking about improving codec2 at bit rates above 1200 bits/s,
an topic I haven't looked at for many years.

I'm hoping to get contributions from other developers, so am starting
out with some tutorial examples of how codec2 works using the c2sim
simulation tool.

- David


On Wed, 2022-01-12 at 08:54 +0100, Ugo Poddine wrote:
> Hi Alan,
> 
> Can you explain to me at what time the Id is triggered to be sent
> from your parrot (e.g. 15, 30, 45, 00 min) and if the Id is sent in
> FreeDV or in CW ?
> I have tried to link it at the moment without success, but perhaps at
> least trying to listen will help.
> 
> Thank-you, 73
> Ugo
> Il giorno 9 gen 2022, alle ore 07:04, Al Beard <
> bear...@unixservice.com.au> ha scritto:
> > Hi Ugo,
> > 
> > I run a "freebeacon" here and when triggered, will transmit back to
> > you or ident
> > every 15mins on Mode 700E on 7177 KHz LSB as it's the only 40m
> > frequency mentioned on QSO.freedv.org.
> > 
> > That is what you need over there in Europe. 
> > 
> > Yes it ties up one transceiver here and one antenna but it puts a
> > signal out 24x7.
> > 
> > Being in a suburban backyard, suffers from horrendous interference,
> > in particular the HFC cable phone system.
> > 
> > Alan VK2ZIW 
> > 
> > 
> > On Sun, 09 Jan 2022 06:49:02 +0100, Ugo Poddine wrote 
> > > Hello Ian, 
> > > 
> > > I agree with you that it's not so easy to find free-dv guys to
> > speak with at whatever time of the day and frequency, mainly in
> > Europe, where we are surly a small group. 
> > > 
> > > But I know that daily QSO takes place between VK, ZL and
> > Argentina in 20m, and also between UK and Germany, in 40m. 
> > > 
> > > Of course, it's not yet SSB, sometime you need to take some
> > rendez-vous before... 
> > > 
> > > I think that the big effort that David and the other developers
> > are doing surely need HAMs community help, if not with our
> > programming capabilities (unfortunately the matter is really hard),
> > at least with our effort in using and testing. 
> > > 
> > > I'm not offering myself for having a FreeDV contact with you
> > because my barefoot set-up (100W and a wire style), in the current
> > propagation conditions,  make me able to connect VK in a realiable
> > way only by digital chat protocols (e.g. Olivia). 
> > > 
> > > My best 73s 
> > > 
> > > IU1IPB Ugo 
> > > Il giorno 8 gen 2022, alle ore 10:51, "ian.lyckholm--- via
> > Freetel-codec2"  ha scritto:
> > > > I've been trying for some time to find someone using the above
> > > mode on several of the listed frequencies. I have also listed on
> > > the free-dv qso finder. 
> > > > No response anywhere. 
> > > > How many people are actually using this mode? 
> > > > Just thought I'd ask before abandoning the project. 
> > > > Cheers 
> > > > Ian Lyckholm VK5MA 
> > > >
> > > 
> > > 
> > > 
> > > > Freetel-codec2 mailing list
> > > 
> > > > 
> > > Freetel-codec2@lists.sourceforge.net
> > > 
> > > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> > > 
> > > > 
> > > 
> >  
> > 
> > 
> > --- 
> > Alan VK2ZIW 
> > Before the Big Bang, God, Sela. 
> > OpenWebMail 2.53, nothing in the cloud. 
> > 
> > 
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] test message

[david]

Hmm OK that worked.  I have also raised a ticket with SourceForge
support.  Lets see if any other lost messages come through ...

On Wed, 2022-01-12 at 07:36 +1030, david wrote:
> I have had a complaint that messages are not being posted to this
> list
> 
> - David
> 
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] test message

[david]

I have had a complaint that messages are not being posted to this
list

- David




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Serial Port Control for PTT

[david]

Hello Don,

Good to see the initial problem has resolved itself for you.

Re when Serial PTT control is asserted by freedv-gui, on balance I'm OK
with the current operation - ie PTT control is only assumed after Start
is pressed.  However I would be happy to hear other opinions - in
particular anyone that is experiencing practical problems with the
current design.

Sure, if you want to modify the grayed out behaviour of the PTT Dialog
check boxes as described below please feel free to raise a Github PR.

I'm unclear on the change you are suggesting in the final two
sentences. Perhaps it might be easier to post a PTT Dialog screen shot
in the Github PR to illustrate what it might look like.

Thanks,
David

On Sun, 2021-10-03 at 15:32 -0700, Don wrote:
> Another related item.  The dialog box has checkboxs for "DTR=+V" and
> "RTS=+V".  These can both be toggled whether "Use DTR" or "Use RTS"
> is
> selected.  The two "Use" boxes are mutually exclusive, checking one
> unchecks the other.
> 
> But the code only sets the line being used.  If only one line is
> going to
> be used, then the voltage checkbox for the other line should be
> gray'd out
> when not enabled.  I would prefer to set the "inactive" level of both
> lines.
> This is how I have seen other programs handle these lines.
> 
> Don
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Serial Port Control for PTT

[david]

Hi Don,

So are you using a single serial port to connect to two devices (i) IC-
756-ProIII and (ii) a custom radio interface ?

- David

On Sun, 2021-10-03 at 08:43 -0700, Don wrote:
> Yes, I agree with your suggested behavior and I'll try to implement
> it.
> 
> As for Hamlib, it also uses a serial port.  Any serial port
> application 
> needs to select handshking.  Maybe Hamlib does that internally based
> on
> the radio.
> 
> My radio (IC-756-ProIII) does not use any handshaking so the library 
> probably doesn't control those lines.  But my radio interface always
> drives PTT from RTS (and CW-KEY from DTR) so I need to turn those
> signals off even when using Hamlib to drive the CV-I interface.
> 
> Since Hamlib has more unknowns and complexity, I'll work on the basic
> serial port stuff first and then explore Hamlib setup as a seprate 
> task.
> 
> Don
> 
> On Sun, Oct 03, 2021 at 11:23:43AM +1030, david wrote:
> > Hi Don,
> > 
> > It's been some time since that code was written, but I'd suggest
> > desired behaviour is:
> > 
> > 1/ If Serial Port PTT has not been configured, do nothing when the
> > freedv-gui application starts.
> > 
> > 2/ If Serial Port PTT has been configured, when the freedv-gui
> > application is started the PTT control line should be set to
> > disable
> > Tx.  The exact action will depend on which PTT control line is
> > selected
> > (RTS or CTS) and the polarity.
> > 
> > 3/ On the PTT dialog.  When PTT configuration is complete and APPLY
> > or
> > OK is pressed, the PTT control line should be set to disable Tx.
> > 
> > If this is not the case, please feel free to raise an Issue on
> > GitHub,
> > or submit a PR to fix it.
> > 
> > -/-
> > 
> > Sorry I don't understand the issue around Hamlib.  Can you pls
> > describe
> > a use case when using Hamlib PTT where we might need to directly
> > control RTS or CTS lines?  When I use Hamlib for PTT control (say
> > for
> > my IC7200), I just set the serial port and rig model.  I had
> > assumed
> > that low level configuration like serial port control lines was
> > abstracted away when using Hamlib.
> > 
> > Thanks,
> > David
> > 
> > On Sat, 2021-10-02 at 16:36 -0700, Don wrote:
> > > I have found some issues with using the RTS line of a serial port
> > > for PTT.
> > > 
> > > First when the freedv-gui starts it does not set the port to the
> > > inactive
> > > state.  This can mean the transmitter turns on and stays on until
> > > the
> > > user tries to transmit.
> > > 
> > > Second, in the PTT dialog just setting the correct states and
> > > pressing "OK"
> > > or "APPLY" does not change the state of the port to the desired
> > > inactive
> > > levels.  I found some old documentation which told users to do
> > > just
> > > that,
> > > change the setting and press "APPLY".
> > > 
> > > There is a work around, the "Test PTT" function changes the state
> > > to
> > > active,
> > > then to inactive.
> > > 
> > > I think this is only an issue for the serial port, at least for
> > > my
> > > radios
> > > Hamlib just leaves the radio as it is until PTT is activated.
> > > 
> > > A related item which might be harder is the state of the serial
> > > port
> > > control lines when using hamlib.  There does not seem to be a way
> > > to
> > > do
> > > that in recent versions.  Older versions separated the settings
> > > for
> > > the
> > > serial control lines from the method which at least could have
> > > controlled them even when hamlib was in use.  An alternative
> > > would be
> > > to
> > > duplicate these setting in the hamlib part of the dialog.
> > > 
> > > It looks pretty easy to fix but before I do any work on it I want
> > > to
> > > be
> > > sure I understand the desired behavior.
> > > 
> > > Don - W7DMR
> > > 
> > > 
> > > ___
> > > Freetel-codec2 mailing list
> > > Freetel-codec2@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> > 
> > 
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Serial Port Control for PTT

[david]

Good question Mooneer.  Looking at the code, it appears that we
currently set the serial port PTT state when Start is pressed, rather
than on process/application start up.

This is a reasonable solution, and probably the reason why this
question hasn't come up before.  We also wait until Start is pressed to
take control of other hardware on the PC, such as the sound cards.

So we should probably discuss the benefits of taking control of the
serial port on application start up compared to the current situation
of when Start is pressed.

I don't have a strong opinion myself (I use Hamlib PTT).  We do need to
be careful of changing the behaviour of FreeDV in sensitive areas like
PTT control.

Cheers,
David

On Sun, 2021-10-03 at 11:17 -0700, Mooneer Salem wrote:
> Hi all,
> 
> To clarify, by "start", do we mean pushing the Start button in the
> GUI? Or when the process itself actually starts? I didn't think we
> did anything with Hamlib or the serial port immediately on start, but
> if that's incorrect, please feel free to fix.
> 
> Thanks,
> 
> -Mooneer K6AQ
> 
> On Sun, Oct 3, 2021 at 8:44 AM Don  wrote:
> > Yes, I agree with your suggested behavior and I'll try to implement
> > it.
> > 
> > As for Hamlib, it also uses a serial port.  Any serial port
> > application 
> > needs to select handshking.  Maybe Hamlib does that internally
> > based on
> > the radio.
> > 
> > My radio (IC-756-ProIII) does not use any handshaking so the
> > library 
> > probably doesn't control those lines.  But my radio interface
> > always
> > drives PTT from RTS (and CW-KEY from DTR) so I need to turn those
> > signals off even when using Hamlib to drive the CV-I interface.
> > 
> > Since Hamlib has more unknowns and complexity, I'll work on the
> > basic
> > serial port stuff first and then explore Hamlib setup as a seprate 
> > task.
> > 
> > Don
> > 
> > On Sun, Oct 03, 2021 at 11:23:43AM +1030, david wrote:
> > > Hi Don,
> > > 
> > > It's been some time since that code was written, but I'd suggest
> > > desired behaviour is:
> > > 
> > > 1/ If Serial Port PTT has not been configured, do nothing when
> > the
> > > freedv-gui application starts.
> > > 
> > > 2/ If Serial Port PTT has been configured, when the freedv-gui
> > > application is started the PTT control line should be set to
> > disable
> > > Tx.  The exact action will depend on which PTT control line is
> > selected
> > > (RTS or CTS) and the polarity.
> > > 
> > > 3/ On the PTT dialog.  When PTT configuration is complete and
> > APPLY or
> > > OK is pressed, the PTT control line should be set to disable Tx.
> > > 
> > > If this is not the case, please feel free to raise an Issue on
> > GitHub,
> > > or submit a PR to fix it.
> > > 
> > > -/-
> > > 
> > > Sorry I don't understand the issue around Hamlib.  Can you pls
> > describe
> > > a use case when using Hamlib PTT where we might need to directly
> > > control RTS or CTS lines?  When I use Hamlib for PTT control (say
> > for
> > > my IC7200), I just set the serial port and rig model.  I had
> > assumed
> > > that low level configuration like serial port control lines was
> > > abstracted away when using Hamlib.
> > > 
> > > Thanks,
> > > David
> > > 
> > > On Sat, 2021-10-02 at 16:36 -0700, Don wrote:
> > > > I have found some issues with using the RTS line of a serial
> > port
> > > > for PTT.
> > > > 
> > > > First when the freedv-gui starts it does not set the port to
> > the
> > > > inactive
> > > > state.  This can mean the transmitter turns on and stays on
> > until the
> > > > user tries to transmit.
> > > > 
> > > > Second, in the PTT dialog just setting the correct states and
> > > > pressing "OK"
> > > > or "APPLY" does not change the state of the port to the desired
> > > > inactive
> > > > levels.  I found some old documentation which told users to do
> > just
> > > > that,
> > > > change the setting and press "APPLY".
> > > > 
> > > > There is a work around, the "Test PTT" function changes the
> > state to
> > > > active,
> > > > then to inactive.
> > > > 
> > > > I think this is only an issue for the serial port, at least for
> > my
> > > > ra

Re: [Freetel-codec2] Serial Port Control for PTT

[david]

Hi Don,

It's been some time since that code was written, but I'd suggest
desired behaviour is:

1/ If Serial Port PTT has not been configured, do nothing when the
freedv-gui application starts.

2/ If Serial Port PTT has been configured, when the freedv-gui
application is started the PTT control line should be set to disable
Tx.  The exact action will depend on which PTT control line is selected
(RTS or CTS) and the polarity.

3/ On the PTT dialog.  When PTT configuration is complete and APPLY or
OK is pressed, the PTT control line should be set to disable Tx.

If this is not the case, please feel free to raise an Issue on GitHub,
or submit a PR to fix it.

-/-

Sorry I don't understand the issue around Hamlib.  Can you pls describe
a use case when using Hamlib PTT where we might need to directly
control RTS or CTS lines?  When I use Hamlib for PTT control (say for
my IC7200), I just set the serial port and rig model.  I had assumed
that low level configuration like serial port control lines was
abstracted away when using Hamlib.

Thanks,
David

On Sat, 2021-10-02 at 16:36 -0700, Don wrote:
> I have found some issues with using the RTS line of a serial port
> for PTT.
> 
> First when the freedv-gui starts it does not set the port to the
> inactive
> state.  This can mean the transmitter turns on and stays on until the
> user tries to transmit.
> 
> Second, in the PTT dialog just setting the correct states and
> pressing "OK"
> or "APPLY" does not change the state of the port to the desired
> inactive
> levels.  I found some old documentation which told users to do just
> that,
> change the setting and press "APPLY".
> 
> There is a work around, the "Test PTT" function changes the state to
> active,
> then to inactive.
> 
> I think this is only an issue for the serial port, at least for my
> radios
> Hamlib just leaves the radio as it is until PTT is activated.
> 
> A related item which might be harder is the state of the serial port
> control lines when using hamlib.  There does not seem to be a way to
> do
> that in recent versions.  Older versions separated the settings for
> the
> serial control lines from the method which at least could have
> controlled them even when hamlib was in use.  An alternative would be
> to
> duplicate these setting in the hamlib part of the dialog.
> 
> It looks pretty easy to fix but before I do any work on it I want to
> be
> sure I understand the desired behavior.
> 
> Don - W7DMR
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] facebook speech codec at 365bps

[david]

On Tue, 2021-09-14 at 09:24 +0800, Random via Freetel-codec2 wrote:
> In my opinion, the pitch estimator is the bottleneck of any
> narrowband vocoder, no matter the tranditional or the neural-network
> based.
> 
> LPCnet uses the (last-century) RAPT algorithm for the pitch
> estimation, and if the pitch value is wrong, the output would be very
> terrible. 
> 

A few years ago I spent some time exploring LPCNet, including working
with a few different pitch estimators.  I found that, quite remarkably,
LPCnet was insensitive to gross errors in the pitch estimator.  This
really surprised me, as I have a history of pain in developing pitch
estimators.  They are critical to old school low bit rate codecs like
Codec 2, MELP, AMBE.  

Lyra doesn't even have a pitch estimator - just sends high order mel-
spaced speech spectra, which I guess is densely sampled enough to
resolve pitch harmonics.

So my experience is NN codecs can bypass the harder parts of the whole
pitch estimator issue ... I think they are also picking up other cues
like the presence of low frequency harmonics in the mel spectra for
males.

In fact some of our early quantisation attempts at LPCNet had errors
like males turning into females (pitch shifts) if we got the spectral
quantisation at low frequency wrong ;-) 

An interesting research question - is a pitch "feature" needed for a
low bit rate NN codec?  LPCNet has one (1600 bits/s) - Lyra doesn't
(3000 bits/s).

- David

> 
> -- Original --
> From: "freetel-codec2" ;
> Date: Tue, Sep 14, 2021 06:25 AM
> To: "freetel-codec2";
> Subject: Re: [Freetel-codec2] facebook speech codec at 365bps
> 
> On Mon, 2021-09-13 at 07:24 +, Greg Maxwell wrote:
> > On Mon, Sep 13, 2021 at 7:05 AM Random via Freetel-codec2
> >  wrote:
> > > Is it speaker-independent ?
> > 
> > It's speaker independent with the additional per-speaker data
> > mentioned in my post.
> > 
> 
> That sounds like speaker dependence to me.
> 
> I encountered this with the early LPCNet work as well (as used in
> FreeDV 2020), the quality dropped off significantly for about 10% of
> voices (including mine!).  However I haven't tried the latest version
> of LPCnet from Jean-Marc, he's been steadily improving his NN model
> and
> codec.
> 
> The Lyra paper mentions some specific work in this area, so I'm sure
> it
> will be addressed in time.  High quality, speaker independent speech
> coding at sub 1000 bit's certainly feels possible.
> 
> Another issue to address is robustness to bit errors.  In codec 2 I
> avoid inter-frame coding (ie coding differences) to keep some
> tolerance
> to the high bit error rates.  This costs a few bits/s compared to a
> super efficient approach.
> 
> I figure tolerance to bit errors might be something we can train for
> in
> NN codecs.
> 
> - David
> 
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] facebook speech codec at 365bps

[david]

On Mon, 2021-09-13 at 07:24 +, Greg Maxwell wrote:
> On Mon, Sep 13, 2021 at 7:05 AM Random via Freetel-codec2
>  wrote:
> > Is it speaker-independent ?
> 
> It's speaker independent with the additional per-speaker data
> mentioned in my post.
> 

That sounds like speaker dependence to me.

I encountered this with the early LPCNet work as well (as used in
FreeDV 2020), the quality dropped off significantly for about 10% of
voices (including mine!).  However I haven't tried the latest version
of LPCnet from Jean-Marc, he's been steadily improving his NN model and
codec.

The Lyra paper mentions some specific work in this area, so I'm sure it
will be addressed in time.  High quality, speaker independent speech
coding at sub 1000 bit's certainly feels possible.

Another issue to address is robustness to bit errors.  In codec 2 I
avoid inter-frame coding (ie coding differences) to keep some tolerance
to the high bit error rates.  This costs a few bits/s compared to a
super efficient approach.

I figure tolerance to bit errors might be something we can train for in
NN codecs.

- David




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] codec2 - FreeDATA project

[david]

Great to see progress on open source HF data Simon :-)

Thanks,
David

On Sun, 2021-09-05 at 12:35 +0200, Simon Lang wrote:
> Hi everyone, here’s the latest state of codec2-FreeDATA:
> 
> https://github.com/DJ2LS/codec2-FreeDATA/blob/main/documentation/codec2-FreeDATA_05.09.2021_11_29_05.mp4?raw=true
> 
> 
> The project is moving forward - step by step - but still a lot of
> work to do. But as you can already see, I integrated the data module
> into the application, so no additional software is needed for sending
> data. All application settings are visible on the main screen. No
> hidden settings. Just those who are visible and necessary. Lets see
> If I can continue with this idea.
> 
> As soon as its possible to send data (which is already working, but
> unstable)  and the GUI + TNC is in a more stable state, I will make
> another announcement.
> 
> Have a good time!
> Simon, DJ2LS
> 
> 
> 
> 
> > > Am 19.07.2021 um 05:33 schrieb Simon Lang :
> > > 
> > > Hi everyone,
> > > 
> > > I’m Simon, DJ2LS, and I'm working on my project „codec2 -
> > > FreeDATA“ since some month.
> > > 
> > > My goal is to create a multiplattform, open-source TNC, with an
> > > easy to use GUI.
> > > At the moment the project is Linux only and not usable yet. It's
> > > a prototype and I’m improving my programming skills „learning by
> > > doing“. So expect a lot of failures, problems, uncommon
> > > programming stuff. But at least I thought - Just do it!  And here
> > > are the first results:
> > > 
> > > 
> > > # GUI 
> > > The basic GUI is already working. Easy selection of audio devices
> > > and radio via Hamlib. Some status messages of the TNC are working
> > > as well. A huge part, which is still not working, is the
> > > waterfall diagram to have a look over the band / channel and its
> > > busy state. 
> > > My plans are, to create a GUI with different modules:
> > > - Data transfer module
> > > - Chat module, with a modern, smartphone like design
> > > - Beacon module
> > > The entire GUI is a network application. So you can control and
> > > send data within your private network by default. The future idea
> > > is, sitting on the couch and chatting via HF...
> > > 
> > > # TNC
> > > The TNC itself is written in Python and will be a CLI
> > > application. But you don’t have to fight with a lot of CLI
> > > commands - Just start the TNC and everything can be configured
> > > via network GUI.
> > > I’m also doing some basic TNC behavior a little bit different:
> > > - You don’t have to connect to another station to send data and
> > > keeping the channel opened ( and the channel busy as well )
> > > This means, that if you want to send data to another station, you
> > > have to open a data channel ( automatically), which will be
> > > closed as soon as the data has been transmitted. 
> > > 
> > > 
> > > # ARQ
> > > I already created support for different ARQ modes :
> > > - Stop-and-Wait
> > > - Go-Back-N
> > > - Selective Repeat 
> > > You can also mix them together by selecting the amount of data
> > > frames per acknowledge burst and repeating lost frames. This is
> > > working in my development environment with some restrictions, but
> > > needs some more real tests with some kilometers between the
> > > stations. Somewhen in the future "path measurement" will
> > > automatically select the best constellation between frames per
> > > burst, amount of data and channel quality.
> > > 
> > > 
> > > 
> > > You can find everything in my Github repository:
> > > https://github.com/DJ2LS/codec2-FreeDATA
> > > 
> > > I don’t have that much time because of my job, so I’m doing
> > > everything step by step. 
> > > Actually I’m working on the data module and a huge amount of
> > > documentation needs to be done as well.
> > > But everything looks promising.  
> > > 
> > > 
> > > Have a good start into the week! 
> > > Simon, 
> > > DJ2LS 
> > > ___
> > > Freetel-codec2 mailing list
> > > Freetel-codec2@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] 1600 mode and constellation points

[david]

Hi Brian,

The BPSK pilot is used for acquisition (e.g. estimating the initial
frequency offset) and frame sync.  More power is allocated to the BPSK
pilot to make those two functions fast and reliable (an important
requirement for PTT digital voice).  As there is only one BPSK carrier,
the overhead in terms of total power is about 1dB IIRC.

The FreeDV 1600 waveform (the FDMDV modem) was an open source
implementation of an earlier waveform (see the History section on 
http://freedv.org) that was known to work well for this application.
 So it was something of a starting point for FreeDV, and a stepping
stone to later waveforms.

There are Octave and C versions of the modem (
https://github.com/drowe67/codec2/blob/master/README_fdmdv.md), plus
various blog posts, if you would like to experiment with the modem or
inspect it's implementation.

Cheers,
David

On Sun, 2021-08-22 at 22:59 +0100, Brian Morrison wrote:
> I'm looking for an explanation of something that was probably
> considered during the design of the 1600 mode but is implemented
> differently from other systems that use pilot tones.
> 
> Looking at the spectrum and the scatter diagram I see that the pilot
> tone amplitude is much larger than the QPSK carriers and I wondered
> why. The phase of these pilot tones (BPSK?) is the same as 2 of the
> QPSK points, in other systems I'm familiar with the BPSK modulated
> pilots are at a 45 degree offset from the QPSK points and have a
> lower
> amplitude because there is both phase and amplitude difference from
> the
> QPSK symbols to assist demodulation. This allows the use of a lower
> PAPR in the modulation, which is beneficial because it allows a
> larger
> amplitude for the QPSK bits and a less linear transmitter can be
> used.
> 
> No criticism is intended, I'm just trying to understand the trade
> offs,
> I suppose that there are only 4 symbol phases to worry about whereas
> with offset phase BPSK there are then 6, which really means 8.
> 
> No rush to get an answer, this is just an itch I wanted to scratch
> when
> I was testing with the recorded files that come with freedv and what
> I
> saw got me thinking.
> 
> Cheers
> 



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] SM1000 v5 firmware with 700E

[david]

Hello List,

Mooneer K6AQ (with a little help from me) has been doing some fine work
on bringing the SM1000 firmware up to date. There have been quite a few
changes to the internals of codec 2 and the FreeDV API over the past 12
months, which meant we were due for some maintenance on the SM1000
firmware.

He has also added 700E to the list of modes supported by the SM1000,
and both 700D and 700E now have compression and a Tx band pass filter.

Here are the .bin and .dfu file for the new firmware:

  http://www.rowetel.com/downloads/codec2/smartmic/sm1000v5.bin
  http://www.rowetel.com/downloads/codec2/smartmic/sm1000v5.dfu

The latest (draft) documentation:

https://github.com/drowe67/codec2/blob/4686212c15a5ee753ac37700f31ed9263ac08d37/stm32/doc/sm1000_manual.md

... and the Pull Request which documents the development:

  https://github.com/drowe67/codec2/pull/206

Thanks,
David




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] hello, and about phi0

[david]

Hi Tim,

It kind of depends where the it errors lie, but with enough frames,
both PER and coded BER should be minimised.

You could also compare BER results to the original phi0 implementation
in the CML library that we started from.

List: Tim is experimenting with part of the LDPC FEC decoding that was
optimised for 700D on the sm1000.  The algorithm he is looking at was
discussed a few years ago in this blog post:

https://www.rowetel.com/wordpress/store.html/?p=6413

Tim, if you are interested in other optimisation work in general, there
has been some recent work here:

 https://github.com/drowe67/codec2/pull/200

- David

On Wed, 2021-08-04 at 08:39 -0500, Tim Meehan wrote:
> Perhaps it is just PER that I should minimize on? I can't conceive of
> a case where your BER would go up but your PER would stay the same
> ...
> 
> On Wed, Aug 4, 2021 at 8:16 AM Tim Meehan  wrote:
> > Hi Al - nice to hear from you.
> > 
> > I'm trying to learn ARM cross compiling, but it would be nice to
> > also have some folks to check on live hardware. The only SDR I have
> > is receive-only (NooElec NESDR Nano2+, and your web link is NEAT!).
> > 
> > In the script snippet that I attached, there was a bit at the end
> > that I thought might have been the "figure of merit" ... if so ...
> > I can try and tune the knot placement based on these numbers.
> > 
> > Uncoded PSK Eb/No simulation:
> > No=  1.00 dB (1.26 linear)
> > Eb=  0.00 dB (1.00 linear)
> > Eb/No = -1.00 dB (0.79 linear)
> > Using: HRA_112_112
> > Using: HRA_112_112
> > Nframes: 100
> > CodeLength: 224 offset: 0
> > written: 22400
> > .xxx.x.x.x...xmeasured double sided (real) noise power:
> > 0.629226
> > xx.xxxxx..x
> > .xxtotal iters 5469
> > Raw   Tbits:  22400 Terr:   2268 BER: 0.101
> > Coded Tbits:  11200 Terr: 68 BER: 0.006
> >   Tpkts:100 Tper: 17 PER: 0.170
> > 
> > I gather that having both of these numbers small is good?
> > Minimizing on two numbers is a bit challenging, I might just try to
> > minimize based on sqrt(BER^2 + PER^2) ... any thoughts would be
> > appreciated.
> > 
> > On Wed, Aug 4, 2021 at 3:32 AM Al Beard  > > wrote:
> > > Hello Tim,
> > > 
> > > It's great to have you onboard. I'm more of an "implimenter", by
> > > no means good at C or C++.
> > > So I can't help to that depth.
> > > 
> > > I can compile code on ARM and Intel Linux platforms here and with
> > > transceivers, give it a go.
> > > 
> > > So, if I can be useful.
> > > 
> > > My SDR here in western Sydney, Australia can do Codec2 decode
> > > though currently in one mode.
> > > (easily changeable in a script file)  Web browse
> > > 110.143.195.8:8073
> > > 
> > > You may notice the M17 project has chosen the Codec2 modes 1600
> > > and 3200 to "replace" AMBE
> > > in an open source transceiver project. 
> > > 
> > > Welcome
> > > 
> > > Alan VK2ZIW 
> > > 
> > > On Tue, 3 Aug 2021 17:14:15 -0500, Tim Meehan wrote 
> > > > Hi - I'm not extremely versed in digital modes, but I am well
> > > versed in optimization. I think that HAM radio should be
> > > something open source, which is why Codec2 appeals to me. 
> > > > 
> > > > Before I post a large blob of C code, I wanted to mention that
> > > I have a program that I have written a genetic optimizer to move
> > > spline knots around - and I'd be happy to run the optimizer based
> > > on BER/PER ... however ... I need someone to explain to me how I
> > > might generate quantities  to optimize on. I don't need bunches
> > > of help, just enough so that I can write it myself. 
> > > > 
> > > > I found that the 16-sample clamped endpoint spline with log-
> > > spaced samples worked the best, so I'll chop out the higher
> > > sample density parts of the code. My hope was faster AND more
> > > accurate, but I think all I got was faster and LESS accurate.
> > > Perhaps wiser eyes than mine can help me out. 
> > > > 
> > > > The test script that I was using was: 
> > > > #!/bin/sh 
> > > > ./ldpc_enc /dev/zero - --sd --code HRA_112_112 --testframes 100
> > > \| ./ldpc_noise - - 1 \ 
> > > > | ./ldpc_dec - /dev/null --code HRA_112_112 --sd --
> > > testframes 
> > > > 
> > > > The code is (simply replace

Re: [Freetel-codec2] codec2 - FreeDATA project

[David Rowe]

Thanks Simon,

By way of introduction I've been working with Simon for nearly a year 
now in the general area of open source HF data.  Together we developed 
some use cases for HF data.  I then developed against those use cases 
when building up the new Codec 2 data modes that I most recently blogged 
on here:


  https://www.rowetel.com/?p=7688

Those data modes transfer chunks of bytes over HF radio channels; Simon 
is now working on the protocol and GUI layers of a modern open source HF 
data system.


- David

On 19/7/21 1:03 pm, Simon Lang wrote:

Hi everyone,

I’m Simon, DJ2LS, and I'm working on my project „codec2 - FreeDATA“ 
since some month.


My goal is to create a multiplattform, open-source TNC, with an easy 
to use GUI.
At the moment the project is Linux only and not usable yet. It's a 
prototype and I’m improving my programming skills „learning by doing“. 
So expect a lot of failures, problems, uncommon programming stuff. But 
at least I thought - Just do it!  And here are the first results:



# GUI
The basic GUI is already working. Easy selection of audio devices and 
radio via Hamlib. Some status messages of the TNC are working as well. 
A huge part, which is still not working, is the waterfall diagram to 
have a look over the band / channel and its busy state.

My plans are, to create a GUI with different modules:
- Data transfer module
- Chat module, with a modern, smartphone like design
- Beacon module
The entire GUI is a network application. So you can control and send 
data within your private network by default. The future idea is, 
sitting on the couch and chatting via HF...


# TNC
The TNC itself is written in Python and will be a CLI application. But 
you don’t have to fight with a lot of CLI commands - Just start the 
TNC and everything can be configured via network GUI.

I’m also doing some basic TNC behavior a little bit different:
- You don’t have to connect to another station to send data and 
keeping the channel opened ( and the channel busy as well )
This means, that if you want to send data to another station, you have 
to open a data channel ( automatically), which will be closed as soon 
as the data has been transmitted.



# ARQ
I already created support for different ARQ modes :
- Stop-and-Wait
- Go-Back-N
- Selective Repeat
You can also mix them together by selecting the amount of data frames 
per acknowledge burst and repeating lost frames. This is working in my 
development environment with some restrictions, but needs some more 
real tests with some kilometers between the stations. Somewhen in the 
future "path measurement" will automatically select the best 
constellation between frames per burst, amount of data and channel 
quality.




You can find everything in my Github repository:
https://github.com/DJ2LS/codec2-FreeDATA 
<https://github.com/DJ2LS/codec2-FreeDATA>


I don’t have that much time because of my job, so I’m doing everything 
step by step.
Actually I’m working on the data module and a huge amount of 
documentation needs to be done as well.

But everything looks promising.


Have a good start into the week!
Simon,
DJ2LS


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] LPCNet CPU improvements

[David Rowe]

Jean-Marc (the author of LPCNet) has emailed me to say he has reduced 
the CPU load of LPCNet on a modern laptop to about 5% and even achieved 
real time of a Pi 4 platform.  I don't have the cycles to play with this 
right now, but if anyone is interested in LPCNet running faster please 
see Jean-Marc's GitHub LPCNet repo.


- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] Controlled FreeDV testing

[David Rowe]

Hello List,

Here is a blog post on some automated FreeDV and SSB testing, over real 
world HF channels:


  http://www.rowetel.com/?p=7779

Thanks,
David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 audio input format

[David Rowe]

There are no firm guidelines for filtering of the input.

- David

On 18/6/21 5:49 pm, fin7...@gmail.com wrote:

Thanks.

How about filtering; should input audio be bandpass filtered or is 
there a built-in filtering in codec? If pre-filtering is required, 
what are the requirements for that?


t. matti

On Fri, Jun 18, 2021 at 10:54 AM David Rowe <mailto:da...@rowetel.com>> wrote:


Hi,

It should be 16 bit shorts, mono, 8 kHz sample rate.

    - David

On 18/6/21 3:17 pm, fin7...@gmail.com <mailto:fin7...@gmail.com>
wrote:

Hi,

I’m trying to investigate if Codec2 could be used in a software
project, where a low bit rate speech coding is required. I have
built the codec using the instructions from Github and with
included reference audio files I can get similar audio quality
what can be heard on Codec2 web page. However, if I try coding &
decoding with some other recordings, the voice quality is
unacceptable poor, even in case where there is no background
noise at all.

This makes me think that I have something wrong with my input
audio file format. What are the actual requirements for raw file
to get best possible performance? Sample rate, encoding etc?
At this stage I am using Audacity to convert the audio for testing.

Thanks, and keep up the good work!

t. Matti


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net  
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2  
<https://lists.sourceforge.net/lists/listinfo/freetel-codec2>

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
<https://lists.sourceforge.net/lists/listinfo/freetel-codec2>



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 audio input format

[David Rowe]

Hi,

It should be 16 bit shorts, mono, 8 kHz sample rate.

- David

On 18/6/21 3:17 pm, fin7...@gmail.com wrote:

Hi,

I’m trying to investigate if Codec2 could be used in a software 
project, where a low bit rate speech coding is required. I have built 
the codec using the instructions from Github and with included 
reference audio files I can get similar audio quality what can be 
heard on Codec2 web page. However, if I try coding & decoding with 
some other recordings, the voice quality is unacceptable poor, even in 
case where there is no background noise at all.


This makes me think that I have something wrong with my input audio 
file format. What are the actual requirements for raw file to get best 
possible performance? Sample rate, encoding etc?

At this stage I am using Audacity to convert the audio for testing.

Thanks, and keep up the good work!

t. Matti


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Questions about Codec2 embedded performance

[David Rowe]

Hi Josh,

Yes I am in general agreement with Bruce's comments.  Last I heard 
(about 1 month ago) the m17 project have put their own custom hardware 
development on hold and are focusing on ports to COTs HTs.


I'm quite keen on the custom open hardware approach because:

(i) re-use of COTS hardware involves a lot of pain, especially around 
licenses, closed firmware and not-quite-right, undocumented hardware.  
I'd rather we design what we want, or at least a custom, open source 
radio deck that firmware developers can really run with.


(ii) I'm a modem nerd and we can get better performance with custom 
modem waveforms - many of the current crop of modems (DMR/Fusion) are 
10dB off theory due to their waveform design. That's 10x the battery 
life or 10x the Tx power being thrown away.


But I digress.  To your questions:

1/ Re CPU load I haven't measured the codec alone but I estimate about 
half a floating point stm32, so 80 MHz or so.  We run the entire FreeDV 
stack (modem, codec, FEC, drivers, protocol) in a 168 MHz stm32f4 OK 
(half duplex).  It would be worth measuring this, we have quite a few 
tests in codec2/stm32.


2/ I'd suggest doing the protocol and DSP on one uC, save you a lot of 
interfacing hassles.  That's what we do. The chips are cheap.


3/ The codec DSP is all floating point, happy to work with you if you 
want to try some fixed point porting.  This would involve writing a 
bunch of tests to verify float versus fixed.  You might get some speed 
up by using SIMD instructions, but in general it takes more MIPS in 
fixed point than float, so it's likely the MIPS (and hence clock speed 
requirements) will go up.  As per (2), the chips are cheap, so might not 
be worth the bother.


4/ Another approach for a club project is to base in on a Rpi. Some UK 
Hams have built a neat HF FreeDV project:


    https://warc.org.uk/?page_id=123372

  and I've done some work with VHF data using RpiTx and RTLSDR, it 
could easily run voice too.  Battery consumption would be a bit high for 
a HT, but you get a lot of functionality quickly.


Cheers,
David

On 14/5/21 7:34 am, Josh Lloyd via Freetel-codec2 wrote:

Hi David & freetel-codec2,

Firstly I would like to express a great appreciation for Codec 2, it's 
excellent to see an open-source codec in this low bitrate space!


I have a question about the performance of the algorithm on embedded 
hardware. A collection of friends from the local amateur radio club 
have got together to try build a digital radio hand-held, essentially 
a walkie-talkie. This is to strengthen our understanding of digital 
radio, and to practice our electronics engineering.


I came across your algorithm when looking for free open-source codecs 
that could be used with a low bitrate, and I noticed that you already 
had this working on the SM1000 which runs an STM32F4. I understand 
that the CPU is also computing the baseband for TX and RX, so there is 
some spare headroom outside of the codec. My question is how much 
headroom is available, and what clock rate do you run the SM1000 at to 
get the necessary performance?


The team and I were postulating using an STM32L4 for our radio since 
it offers some very low power modes which are ideal for a battery 
powered device, but I am concerned that the 48MHz clock will be 
insufficient to run Codec 2. I intend to have a separate controller 
handle the packet radio, so that chore is lifted off the main processor.


Can you provide any insight into how Codec 2 currently performs and at 
which clock rate does it fail timing? Further, is there any reason to 
suspect that using fixed point or integer multiplication may increase 
the performance?


Thanks again to all those involved with Codec 2; and for your work on 
the thesis before it David, as well as the talks you've provided to 
the wider community.


Kind regards,
Josh


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] HF radio needed in Germany for HF data project (David Rowe)

[David Rowe]

Thanks Al and Bill,

There might be some scope for testing using remote stations when we get 
further along with the software development.


Cheers,
David

On 3/5/21 1:52 am, Bill Buhler via Freetel-codec2 wrote:

Hi David,

I've been following your development with interest. Would having a 
station setup in Utah help? I'm happy to connect my pi to my HF 
station for testing.


Is the per carrier symbol rate low enough to comply with the FCC's 
antiquidated requirements?


Thanks,

Bill Buhlet - AF7SJ




Sent from my Galaxy


 Original message 
From: Al Beard 
Date: 5/2/21 1:01 AM (GMT-07:00)
To: freetel-codec2@lists.sourceforge.net
Subject: Re: [Freetel-codec2] HF radio needed in Germany for HF data 
project (David Rowe)


Hi David and Simon,

Could you use a SSH connection to my Pi here with the FT-897D
connected to it?  (and backyard dipole here in Sydney)

You will have to email or ring me to arrange frequencies and modes
ie. USB/LSB, 80m, 40m or 20m.

From the shell on the PI, you can ssh out or use "wget" to load
software. It is on an FTTC (Fibre To The Curb) internet connection
with a fixed IP address.

This is how Joe K1JT compiled on ARM the early versions of his
Soft Decision Decoder in WSJTX.

I setup an SSH login on the internet facing machine with another
SSH to the Pi.

Alan VK2ZIW +61414353013

On Sun, 2 May 2021 13:02:31 +0930, David Rowe wrote
> Hi Ross,
>
> We've already moved through steps 1 (development against software
> channel simulator) and step 2 (one-way real world HF Tx to SDRs),
>  our progress to date is summarised here:
>
>    http://www.rowetel.com/?p=7688
>
> As you can see the physical layer aspect of the project is coming
> along nicely.  We have indeed been developing against CCIR poor
> (Multi-Path Poor or MPP in Ionos/Winlink nomenclature), and are
> getting encouraging results (see PNG in previous post).
>
> Simon lives in a flat so even local Tx is difficult for him, and at
> this stage of the project (protocol development) he really needs to
> test the back to back interactions between two radios.
>
> The HF/Mimo work sounds interesting, would love to see the papers!
>
> Thanks,
> David
>
> On 2/5/21 12:27 pm, Ross Whenmouth wrote:
> > Hi David & Simon,
> >
> > To start with, rather than using two back-back radios (presumably 
with

> > a large attenuation factor in the RF connection between the two), you
> > could use an HF channel simulator such as;
> > GNU Radio https://wiki.gnuradio.org/index.php/Channel_Model
> > <https://wiki.gnuradio.org/index.php/Channel_Model>
> > Ionos (Winlink) https://winlink.org/content/ionos_simulator
> > <https://winlink.org/content/ionos_simulator>
> > PathSim http://www.moetronix.com/ae4jy/pathsim.htm
> > <http://www.moetronix.com/ae4jy/pathsim.htm>
> > (CCIR has published standardised HF channel models (eg CCIR poor) 
with

> > which to configure your channel simulator)
> >
> >
> > Once you are ready to try out your modem "over the air", to start
> > with, you probably only need to set up a transmitter at your QTH as
> > you are blessed with access to a large number of public web SDRs
> > around continental Europe: http://rx.linkfanel.net/
> > <http://rx.linkfanel.net/>
> >
> > Notably, there are nearby receivers in Karlsruhe and Stuttgart, 
and if

> > you are looking for a longer path (~450 km), the receiver at the
> > University of Twente, Enschede, Netherlands is a good option.
> > Karlsruhe http://sdr.pjs.de:8073/ <http://sdr.pjs.de:8073/>
> > Stuttgart http://dj9kaikiwi.ddns.net:8073/
> > <http://dj9kaikiwi.ddns.net:8073/>
> >    " http://bat-server.dyndns.org:8073/
> > <http://bat-server.dyndns.org:8073/>
> >    " http://dl2sba.ddns.net:8073/ <http://dl2sba.ddns.net:8073/>
> > University Twente http://websdr.ewi.utwente.nl:8901/
> > <http://websdr.ewi.utwente.nl:8901/>
> >
> >
> > PS: Some very interesting research into 2x2 MIMO for HF digital
> > channels has been performed recently - I can send you the papers if
> > you are interested.
> >
> >
> > 73 ZL2WRW
> > Ross Whenmouth
> >
> >
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2


---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 

Re: [Freetel-codec2] HF radio needed in Germany for HF data project (David Rowe)

[David Rowe]

Hi Ross,

We've already moved through steps 1 (development against software 
channel simulator) and step 2 (one-way real world HF Tx to SDRs), our 
progress to date is summarised here:


  http://www.rowetel.com/?p=7688

As you can see the physical layer aspect of the project is coming along 
nicely.  We have indeed been developing against CCIR poor (Multi-Path 
Poor or MPP in Ionos/Winlink nomenclature), and are getting encouraging 
results (see PNG in previous post).


Simon lives in a flat so even local Tx is difficult for him, and at this 
stage of the project (protocol development) he really needs to test the 
back to back interactions between two radios.


The HF/Mimo work sounds interesting, would love to see the papers!

Thanks,
David

On 2/5/21 12:27 pm, Ross Whenmouth wrote:

Hi David & Simon,

To start with, rather than using two back-back radios (presumably with 
a large attenuation factor in the RF connection between the two), you 
could use an HF channel simulator such as;
GNU Radio https://wiki.gnuradio.org/index.php/Channel_Model 
<https://wiki.gnuradio.org/index.php/Channel_Model>
Ionos (Winlink) https://winlink.org/content/ionos_simulator 
<https://winlink.org/content/ionos_simulator>
PathSim http://www.moetronix.com/ae4jy/pathsim.htm 
<http://www.moetronix.com/ae4jy/pathsim.htm>
(CCIR has published standardised HF channel models (eg CCIR poor) with 
which to configure your channel simulator)



Once you are ready to try out your modem "over the air", to start 
with, you probably only need to set up a transmitter at your QTH as 
you are blessed with access to a large number of public web SDRs 
around continental Europe: http://rx.linkfanel.net/ 
<http://rx.linkfanel.net/>


Notably, there are nearby receivers in Karlsruhe and Stuttgart, and if 
you are looking for a longer path (~450 km), the receiver at the 
University of Twente, Enschede, Netherlands is a good option.

Karlsruhe http://sdr.pjs.de:8073/ <http://sdr.pjs.de:8073/>
Stuttgart http://dj9kaikiwi.ddns.net:8073/ 
<http://dj9kaikiwi.ddns.net:8073/>
   " http://bat-server.dyndns.org:8073/ 
<http://bat-server.dyndns.org:8073/>

   " http://dl2sba.ddns.net:8073/ <http://dl2sba.ddns.net:8073/>
University Twente http://websdr.ewi.utwente.nl:8901/ 
<http://websdr.ewi.utwente.nl:8901/>



PS: Some very interesting research into 2x2 MIMO for HF digital 
channels has been performed recently - I can send you the papers if 
you are interested.



73 ZL2WRW
Ross Whenmouth


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] HF Data modes Part 3

[David Rowe]

Hi Al,

Sure - feel free to try it out, using the code from here:

  https://github.com/drowe67/codec2/pull/180

The ota_test.sh script has options for setting the frequency, and the 
rig model, you may need to tweak the aplay line so it's finds your sound 
card.


Some of the receiver code may run a little slow on a Pi, but as it's not 
real time that may not be a show stopper.


- David

On 27/4/21 11:35 am, Al Beard wrote:

Hi David,

Can I participate? My Pi clone (Banana Pi M2 Berry) and transceiver
FT897D are running here 24x7. Audio by a Behringer UCA 202 the original
Texas Instruments USB audio dongle and PTT via serial port.

Could my Pi receive and retransmit what it received?

7053KHz is not too cluttered but does occasionally get clobbered
by the Optus HFC Cable to phone lines box (still running).
I also have spots from my solar system every 40KHz on 7040, 7080 etc.

Alan VK2ZIW

On Sun, 25 Apr 2021 08:44:34 +0930, David Rowe wrote

Further to this I've just had a fun couple of weeks building up some
automated tests for the new data modes, and have obtained some
encouraging results:

    http://www.rowetel.com/?p=7688

If anyone would like to try testing the data modes there's a script
that sends test frames from your radio to any KiwiSDR:

     $ ./ota_test.sh kiwisdr.areg.org.au -m yourHamLibModel

- David

On 15/4/21 6:38 am, David Rowe wrote:

I've been making some progress on open source, HF data modes:

   http://www.rowetel.com/?p=7665

Currenlty having fun sending bursts of data frames to KiwiSDRs around
Australia.

- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2


---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] HF Data modes Part 3

[David Rowe]

Further to this I've just had a fun couple of weeks building up some 
automated tests for the new data modes, and have obtained some 
encouraging results:


  http://www.rowetel.com/?p=7688

If anyone would like to try testing the data modes there's a script that 
sends test frames from your radio to any KiwiSDR:


   $ ./ota_test.sh kiwisdr.areg.org.au -m yourHamLibModel

- David

On 15/4/21 6:38 am, David Rowe wrote:

I've been making some progress on open source, HF data modes:

  http://www.rowetel.com/?p=7665

Currenlty having fun sending bursts of data frames to KiwiSDRs around 
Australia.


- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Bit error artefact handling comparison between Codec2 and Opus

[David Rowe]

Fine Business Adrian, yes I've found the Codec 2 modes are usable with a 
few percent bit errors.  I actually have a function called "ear 
protection" in Codec 2 to avoid some of the wilder excursions due to bit 
errors.


The use of compression is interesting.  I've been thinking of using 
compression and equalisation to limit the dynamic range of the speech 
signals entering the codec, which will make them easier to code, 
especially at a low bit rate.


Cheers,
David

On 17/4/21 11:02 pm, Adrian Musceac wrote:


Hi,


I have done some investigation recently into the comparative bit error 
handling of Codec2 and Opus over the air with a VHF modem. I have 
saved some audio files from the results which can be loaded in Audacity.


Codec2 samples had a bitrate of 1400 bps, Opus samples had a bitrate 
of 9400 bps. Both codecs were used with a 40 ms frame duration, Opus 
was configured with fixed bitrate and no DTX.



For both codecs I have recorded samples with and without audio 
compressor on.


My conclusion is that Codec2 handles bit errors in the audio stream a 
lot better than Opus with default settings as you can see in the wav 
files below.


Opus has high pitch high amplitude artefacts which are difficult to 
listen to when bit errors are present in a default configuration.


Using an aggressive audio compressor setting with Opus improves the 
response to bit errors quite a lot, while for Codec2 there is not much 
improvement added by audio compression, except for a little improved 
readability resulting from less dynamic range.


Hope this is useful to someone.


Audio samples:

- no audio compression

http://qradiolink.org/images/opus_errors_no_compressors.wav

http://qradiolink.org/images/codec2_errors_no_compressor.wav


- with audio compression

http://qradiolink.org/images/opus_errors_with_compressors.wav

http://qradiolink.org/images/codec2_errors_with_compressor.wav



Adrian



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] HF Data modes

[David Rowe]

I've been making some progress on open source, HF data modes:

  http://www.rowetel.com/?p=7665

Currenlty having fun sending bursts of data frames to KiwiSDRs around 
Australia.


- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 vs Lyra?

[David Rowe]

Al,

My understanding ii that Lyra is currenlty optimised for arm64 systems.  
Like LPCNet, it may still need a port of several key functions to some 
sort of x86 SIMD instruction set like AVX.


- David

On 9/4/21 8:34 pm, Al Beard via Freetel-codec2 wrote:

Hi all,

I've loaded this "bazel" build system on Ubuntu 20.04 LTS on a Pentium 
E5300 box (no AVX/AVX2).

 apt install bazel-4.0.0; ln -s /usr/bin/bazel-4.0.0 /usr/bin/bazel
bazel build -c opt :encoder_main
bazel build -c opt :decoder_main

I note the audio samplerate is 16000 whereas Codec2 and the M17 
project go with 8000.

Running their test script:
:
*export PATH=$PATH:/data/downloads/yy4418/lyra/bazel-bin*
*bazel-bin/encoder_main --model_path=wavegru --output_dir=$HOME/temp 
--input_path=testdata/16khz_sample_01.wav*
*bazel-bin/decoder_main  --model_path=wavegru --output_dir=$HOME/temp/ 
--encoded_path=$HOME/temp/16khz_sample_01.lyra*

*
*
*output*
I20210409 20:36:27.839759 178277 decoder_main_lib.cc:97] Elapsed 
seconds : 9
I20210409 20:36:27.839819 178277 decoder_main_lib.cc:98] Samples per 
second : 12246.8


*time aplay $HOME/temp/16khz_sample_01_decoded.wav*
*Playing WAVE '/root/temp/16khz_sample_01_decoded.wav' : Signed 16 
bit Little Endian, Rate 16000 Hz, Mono*

*
*
*real0m8.481s*
*user0m0.195s*
*sys0m0.071s*

 So from an 8.5 sec test file, when decoded takes:
*real0m11.183s*
*user0m11.050s*
*sys0m0.105s*

W20210409 20:43:22.203222 178355 kernels_generic.h:241] SumVectors: 
using generic kernel!
I20210409 20:43:32.897627 178355 decoder_main_lib.cc:97] Elapsed 
seconds : 10
I20210409 20:43:32.897687 178355 decoder_main_lib.cc:98] Samples per 
second : 11307.7



== Conclusion =

My Pentium E5300 2.6 GHz is not powerful enough!


The encode phase is quick, super quick:
time encoder_main --model_path=wavegru --output_dir=$HOME/temp 
--input_path=testdata/16khz_sample_01.wav

WARNING: Logging before InitGoogleLogging() is written to STDERR
I20210409 20:57:47.317165 178410 encoder_main_lib.cc:94] Elapsed 
seconds : 0
I20210409 20:57:47.317334 178410 encoder_main_lib.cc:95] Samples per 
second : 5.12104e+06


real0m0.049s
user0m0.034s
sys0m0.012s


Alan VK2ZIW

*On Thu, 8 Apr 2021 14:34:12 +0800, Random wrote*
> Thanks a lot, David.
>
> Could you please squeeze Lyra to 2400bps ? Such that we can compare 
its performance with that of LPCNet.

>
> Best Regards.
>
> -- Ô­Ê¼Óʼþ --
>
> *·¢¼þÈË:* "freetel-codec2" ;
> *·¢ËÍʱ¼ä:* 2021Äê4ÔÂ7ÈÕ(ÐÇÆÚÈý) ÏÂÎç4:25
> *ÊÕ¼þÈË:* "freetel-codec2";
>
> *Ö÷Ìâ:* Re: [Freetel-codec2] Codec2 vs Lyra?
>
> Hmm, I wonder how quickly I can get this into a FreeDV mode :-)
>
> 3000 bit/s is a bit high for HF, but nice for VHF.  Might be cool for
> the m17 project.
>
> On 7/4/21 5:18 pm, David Rowe wrote:
> > Further to this, I've just bee told Google has open source Lyra :-)
> >
> > 
https://opensource.googleblog.com/2021/04/lyra-enabling-voice-calls-for-next-billion-users.html 


> >
> >
> > - David
> >
> >
> > ___
> > Freetel-codec2 mailing list
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2


---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 vs Lyra?

[David Rowe]

Hmm, I wonder how quickly I can get this into a FreeDV mode :-)

3000 bit/s is a bit high for HF, but nice for VHF.  Might be cool for 
the m17 project.


On 7/4/21 5:18 pm, David Rowe wrote:

Further to this, I've just bee told Google has open source Lyra :-)

https://opensource.googleblog.com/2021/04/lyra-enabling-voice-calls-for-next-billion-users.html 



- David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 vs Lyra?

[David Rowe]

Further to this, I've just bee told Google has open source Lyra :-)

https://opensource.googleblog.com/2021/04/lyra-enabling-voice-calls-for-next-billion-users.html

- David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] BSD style license for Codec 2

[David Rowe]

Thank you all for your responses (I also had a few off list).

Very interesting.  Some take-aways for me:

1/ It's not as onerous as I had thought for companies to link a LPGL 
library with a closed source application.


2/ There seems to be deep value in having an open source speech codec 
that can't be closed.  This is something I have perhaps lost track of; I 
spend most of my time messing around with the DSP.


Thanks,
David




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] BSD style license for Codec 2

[David Rowe]

Indeed.  Although I'd probably just contact the copyright holders of 
each source code file.  There aren't that many in a small project like 
Codec 2.


- David

On 25/3/21 10:52 pm, Tomas Härdin wrote:

tor 2021-03-25 klockan 07:08 +1030 skrev David Rowe:

Hello List,

Codec 2 is currently licensed under LGPL 2.1.  From time to time I have
been contacted by people who wish to use it in applications that
include, other closed software.  While this mix is technically possible
with the LGPL - it's onerous and not very practical.

Switching licenses is more onerous as you have to get permission from
every contributor to do so.

/Tomas



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] BSD style license for Codec 2

[David Rowe]

That's a good question!  I don't think freedv-gui would _have_ to 
change, as I think BSD licensed code can run with GPL applications OK.  
I hadn't really thought about the license for freedv-gui 


- David

On 25/3/21 7:39 pm, Mooneer Salem wrote:
Quick question: would FreeDV's license also (need to?) change? Or 
would Codec2 going to BSD not affect it?


-Mooneer K6AQ

On Wed, Mar 24, 2021 at 2:19 PM Richard Shaw <mailto:hobbes1...@gmail.com>> wrote:


On Wed, Mar 24, 2021 at 3:40 PM David Rowe mailto:da...@rowetel.com>> wrote:


I'd be interested in your thoughts around Codec 2 moving to a
BSD style
license.


It's not a problem for Fedora (or probably any linux distro) so
okay with me :)

Thanks,
Richard
KF5OIM
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] BSD style license for Codec 2

[David Rowe]

Hello List,

Codec 2 is currently licensed under LGPL 2.1.?0?2 From time to time I have 
been contacted by people who wish to use it in applications that 
include, other closed software.?0?2 While this mix is technically possible 
with the LGPL - it's onerous and not very practical.?0?2 Other open source 
codecs, such as Opus, use more permissive licenses like BSD.


I'd be interested in your thoughts around Codec 2 moving to a BSD style 
license.


Thanks,
David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 vs Lyra?

[David Rowe]

Greg - LPCNet quantised to 3000 kbit/s would indeed be an interesting 
comparison; Jean-Marc and I have been quantising LPCNet at beneath 2000 
bit/s, in my case to squeeze it through a HF Radio channel. I suspect 
the focus on 3000 bit/s is because that is the lowest rate that makes 
sense for VOIP.


Adrian - there is a paper linked from the Lyra page.

- David

On 28/2/21 11:09 pm, Adrian Musceac wrote:
While interesting and newsworthy, I'd assume from the start that this 
codec has the same advantages and pitfalls as other ML applications, 
i.e. works very well in 90% of cases and fails dramatically in 10% of 
edge cases. Even though the page specifies it is aimed at a completely 
different domain (not radio) I would say there is no chance it can 
replace Codec2 soon, and I think the same for LPCNet unfortunately. 
Sometimes 99.9 % of reliability of a robotic voice is better than 90% 
reliability of high quality voice. Amateur radio seems to me like a 
combination of all kinds of languages, foreign accents and all sorts 
of messy real world input.


That said, I'd still be interested to read a paper regarding their 
approach and improvements to state of the art.


Adrian

On February 28, 2021 2:16:16 AM UTC, David Rowe  
wrote:


Hi Michael,

Thanks for the post - very interesting.  Sure is an exciting time
for speech coding.

The speech quality of Lyra is vastly better than anything Codec 2
can offer at a similar bit rate (3000 bits/s). Codec 2 would sound
closer to the Speex 3 kbit/s samples on the Lyra page.   Lyra has
reasonable CPU complexity (single thread of a modern smartphone),
but that's still much higher than Codec 2 (which runs on
microcontrollers). Lyra presently has no low bit rates modes
(Codec 2 is commonly used at 700 bits/ for HF radio
applications).  Codec 2 is open source and GPL Licensed.  I'm not
clear where Lyra stands on those issues.  The latency of Lyra
appears quite high (90ms).

Lyra is a Machine Learning (ML) based codec, so in a similar class
to Jean-Marc Valin's LPCNet, which is open source. Our initial
attempt with using LPCNet in real world scenarios (e.g. FreeDV
2020 for HF radio) shows a lot of promise, but has some speaker
dependence and possibly quantisation issues (it breaks down on
some speakers - sounds great on others). The Lyra team claim to
have put a lot of work into speaker-independence, and the project
has a lot of resources behind it :-)

Codec 2 presently has one very part-time person working on the
core speech codec and several other people kindly contributing to
other parts of Codec 2/FreeDV :-)

At 3kbit/s Lyra would fit neatly into VHF/UHF radio type
applications, that would be a cool demo.

Cheers,
David

On 28/2/21 4:50 am, mgraves mstvp.com wrote:


Hi,

While I’ve watched from afar, this is my first message to this list.

I was wondering how Codec 2 compares to this latest effort from
Google; Lyra.


https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-codec-for.html?m=1

Michael Graves

mgra...@mstvp.com <mailto:mgra...@mstvp.com>

o: (713) 861-4005

c: (713) 201-1262

sip:mgra...@mjg.onsip.com



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 vs Lyra?

[David Rowe]

Hi Michael,

Thanks for the post - very interesting.  Sure is an exciting time for 
speech coding.


The speech quality of Lyra is vastly better than anything Codec 2 can 
offer at a similar bit rate (3000 bits/s).  Codec 2 would sound closer 
to the Speex 3 kbit/s samples on the Lyra page. Lyra has reasonable CPU 
complexity (single thread of a modern smartphone), but that's still much 
higher than Codec 2 (which runs on microcontrollers). Lyra presently has 
no low bit rates modes (Codec 2 is commonly used at 700 bits/ for HF 
radio applications).  Codec 2 is open source and GPL Licensed.  I'm not 
clear where Lyra stands on those issues.  The latency of Lyra appears 
quite high (90ms).


Lyra is a Machine Learning (ML) based codec, so in a similar class to 
Jean-Marc Valin's LPCNet, which is open source. Our initial attempt with 
using LPCNet in real world scenarios (e.g. FreeDV 2020 for HF radio) 
shows a lot of promise, but has some speaker dependence and possibly 
quantisation issues (it breaks down on some speakers - sounds great on 
others). The Lyra team claim to have put a lot of work into 
speaker-independence, and the project has a lot of resources behind it :-)


Codec 2 presently has one very part-time person working on the core 
speech codec and several other people kindly contributing to other parts 
of Codec 2/FreeDV :-)


At 3kbit/s Lyra would fit neatly into VHF/UHF radio type applications, 
that would be a cool demo.


Cheers,
David

On 28/2/21 4:50 am, mgraves mstvp.com wrote:


Hi,

While I’ve watched from afar, this is my first message to this list.

I was wondering how Codec 2 compares to this latest effort from 
Google; Lyra.


https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-codec-for.html?m=1

Michael Graves

mgra...@mstvp.com <mailto:mgra...@mstvp.com>

o: (713) 861-4005

c: (713) 201-1262

sip:mgra...@mjg.onsip.com



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] A poll for preference. Analog or digital? on RepeaterBuilder

[David Rowe]

Hi Mooneer,

I tend to agree - most hams just want a turn-key appliance that they can 
get on the air with, and a large user base so they have someone to talk 
to - and that is fine.  The Linux/open source community tends to be more 
sensitive to open/closed source issues.  However Ham Radio is a broad 
hobby, and Codec 2 has some appeal to those that lean towards 
experimentation.


Re 2020 - a modem/waveform upgrade like the recent 700D/700E work might 
help it.


Cheers,
David

On 17/2/21 9:01 am, Mooneer Salem wrote:
(For reference, the thread Alan is referring to is here 
<https://groups.io/g/repeater-builder/topic/a_poll_for_preference_analog/80561243?p=Created,,,20,1,0,0::recentpostdate%2Fsticky,,,20,2,0,80561243=1>.) 



I get the feeling that proprietary vs. open (in the sense of 
licensing/patents) isn't the most important issue for most hams per 
se. However, it does manifest itself indirectly in several ways. One 
way in particular is increased difficulty in implementation for third 
parties; for instance, Icom was the only source for new D-STAR radios 
for quite a while until Kenwood came out with (and then discontinued) 
the TH-D74A. Ironically, the seemingly high usage of DMR in the 
commercial space likely lowered the adoption cost enough such that 
it's increasingly becoming one of the preferred VHF/UHF digital voice 
modes.


Anyway, promoting "open" in the sense of "ease of adoption" 
(patent/royalty free, implementable simply by linking in the Codec2 
libraries, etc.) is probably going to be the most productive way of 
arguing it overall.


(BTW, I recently had a QSO in 2020 mode and it sounded pretty good 
IMO. Of course, it was far more sensitive to SNR and propagation 
disruptions than 700D and E, so I don't foresee using it too often--at 
least until we're higher up in the sunspot cycle, anyway.)


-Mooneer K6AQ

On Mon, Feb 15, 2021 at 12:09 PM Al Beard via Freetel-codec2 
<mailto:freetel-codec2@lists.sourceforge.net>> wrote:


Hi,
Have you been reading the topic: A poll for preference. Analog or
digital?
on the RepeaterBuilder email group?

It's all about audio quality or intelligibility.

Not one has mentioned, *we are stuck using proprietary vocoders.*

No innovation is possible either in the audio encoding or decoding,
yet keeping the systems (data over radio layer) compatible.


---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec 2 DSGL Assessment

[David Rowe]

Hi Mark,

Just the Codec.  I did wonder about the modems, but couldn't find 
anything relevant in the DSGL.


- David

On 16/2/21 7:39 am, Mark Jessop wrote:
Would this only apply to the voice codec itself, and not the modems 
(OFDM, FSK) within the codec2 repository?


Cheers,
Mark

On Tue, Feb 16, 2021 at 7:23 AM David Rowe <mailto:da...@rowetel.com>> wrote:


Hello List,

I've applied for and received an assessment of the Codec 2
software by
my local (Australian) Defence Export Controls (DEC) organisation:

1/ It has been assessed as "listed" on the Defence and Strategic
Goods
List, which means it may require a permit to be exported or
published in
activities which are "controlled".

2/ However my current "activity" does not require a permit as the
software is in the public domain.

3/ DEC would like to be contacted if the software ever gets used for
military applications, or in weapons of mass destruction (!).

I guess it's a compliment that the capabilities of Codec 2 border on
those considered important by defense organisations.

Users of Codec 2 in other countries might want to ask for a similar
assessment to make sure you stay on the correct side of your local
law.
I would guess that many countries have similar laws - they tend to be
aligned.

- David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 and OpenGD77

[David Rowe]

Sounds good Eric.  I don't have the bandwidth to work on this one 
myself, but if you have any questions or maybe some review just let me know.


- David

On 3/2/21 8:31 am, e...@jacksch.com wrote:


Hi David,

In short, yes. I don’t think it is viable to bypass the modem on the 
GD77, and as I understand it current OpenGD77 firmware is using much 
of the available space.


I’m interested in many things, but in this case whether we can just 
replace the codec.


For the code inclined, the C code that uses two block of the original 
radio firmware is here:


https://github.com/rogerclarkmelbourne/OpenGD77/tree/master/firmware/source/dmr_codec

and the source to the tool that extracts the codec code from the 
original firmware is here:


https://github.com/rogerclarkmelbourne/OpenGD77/tree/master/tools/codec_dat_files_creator

I too would love an open radio from the ground up, but being able to 
drop firmware into a $70 2m/70cm handheld is still pretty cool.


Cheers,

Eric

*From:*David Rowe 
*Sent:* February 2, 2021 14:35
*To:* freetel-codec2@lists.sourceforge.net
*Subject:* Re: [Freetel-codec2] Codec2 and OpenGD77

Hi Danilo,

I think Eric's proposal was just to swap out the codec, and perhaps 
using the existing modem on the radio?


The current FreeDV modes we have ported to the stm32 (1600 and 700D) 
are aimed at HF channels, and the GD77 probably doesn't have the RF 
hardware to support them (e.g. a SSB style radio deck).  FreeDV 
includes the modem, protocol, FEC, and Codec 2 - which may be overkill 
for this project.


I can't recall the exact CPU/memory breakdown between Codec 2 and the 
other parts of the FreeDV stack, but I imagine Codec 2 alone would 
require substantially less resources.


While a GD77 port would be cool, I lean towards full ground up open 
source radio designs like M17 although I'd like to use better modems 
:-)  At some point I'm going to try my open vhf/uhf PI+RTLSDR based 
radio project with voice - it's already running the FreeDV stack and 
has plenty of CPU.


Cheers,
David

On 3/2/21 4:37 am, Danilo Beuche wrote:

Hi,

I'd like to share my thoughts on this, as I also have some GD77
and love the OpenGD77 FW (main reason for getting these). I have
some experience with porting FreeDV to the STM32 arm processor as
I was one of the developers who integrated Codec2 into the UHSDR
Firmware a couple of years ago.

The hardware in the OpenGD77 GD77 is surely not powerful enough
for 700D, it may be possible to get it to work with 1600D. FreeDV
also eats a big slice of your RAM (~64k at least) of which the
GD77's MK22FN512VLL12R has only 128k. 120 Mhz is also less than
the 168Mhz of the SM1000 or the MCHF with an STM32F4xx processor.
As both processor belong to the CORTEX-M4 family, they should have
similar performance per MHZ.

In measurements for 1600D on the MCHF with the UHSDR software,
this takes roughly 70% load in the signal processing path from
48khz IQ to audio for 1600D. Doing the math 168/120 * 70% load =
98% load. 2% cycles left. SSB decoding takes about 10%, the
remaining 60% went to FreeDV. Not a problem in SM1600 as it does
less signal processing and doesn't have to run a graphical UI in
addition (which the MCHF does).

700D runs ok on the STM32F7 processor with 216 Mhz and processor
caches (CORTEX-M7 design), speeding up code execution quite
significantly. The STM32H7 with 480 Mhz is not concerned about
decoding 700D at all, there is plenty of cpu power left. But those
are unfortunately not in those handhelds.

But for a different FreeDV mode better suited for VHF/UHF usage or
a different signal processing chain it might be an entirely
different story. Thats is where I have to hand over to David and
the other experts.
And just for the record: I would love to have a "completely" open
source GD77 with digital voice.

Danilo

Can't say anything about the DM1801

On 02/02/2021 18:21, Daniel Mundall wrote:

Hi Eric,

Funny that you mention OpenGD77 as last month I discovered
these radios (Baofeng DM-1801 in my case) and picked up two of
them off of aliexpress with codec2 being the primary reason
for my purchase.

There are 4 reasons why I think they would be great fit for
codec2:

  * They're cheap ($65-75) & available which means you could
get a larger adoption.
  * They run on an ARM platform either STM32 or similar processor.
  * And there's already an open source firmware without
inventing that.
  * The audio encoding isn't a separate chip (at least on the
DM1801) it's software encoding.

Interestingly enough original portion of the memory containing
the software audio codec is retained in OpenGD77 to avoid
patent issues.

Another cool possibility that I haven'

Re: [Freetel-codec2] Codec2 and OpenGD77

[David Rowe]

Hi Danilo,

I think Eric's proposal was just to swap out the codec, and perhaps 
using the existing modem on the radio?


The current FreeDV modes we have ported to the stm32 (1600 and 700D) are 
aimed at HF channels, and the GD77 probably doesn't have the RF hardware 
to support them (e.g. a SSB style radio deck). FreeDV includes the 
modem, protocol, FEC, and Codec 2 - which may be overkill for this project.


I can't recall the exact CPU/memory breakdown between Codec 2 and the 
other parts of the FreeDV stack, but I imagine Codec 2 alone would 
require substantially less resources.


While a GD77 port would be cool, I lean towards full ground up open 
source radio designs like M17 although I'd like to use better modems 
:-)  At some point I'm going to try my open vhf/uhf PI+RTLSDR based 
radio project with voice - it's already running the FreeDV stack and has 
plenty of CPU.


Cheers,
David

On 3/2/21 4:37 am, Danilo Beuche wrote:


Hi,

I'd like to share my thoughts on this, as I also have some GD77 and 
love the OpenGD77 FW (main reason for getting these). I have some 
experience with porting FreeDV to the STM32 arm processor as I was one 
of the developers who integrated Codec2 into the UHSDR Firmware a 
couple of years ago.


The hardware in the OpenGD77 GD77 is surely not powerful enough for 
700D, it may be possible to get it to work with 1600D. FreeDV also 
eats a big slice of your RAM (~64k at least) of which the GD77's 
MK22FN512VLL12R has only 128k. 120 Mhz is also less than the 168Mhz of 
the SM1000 or the MCHF with an STM32F4xx processor. As both processor 
belong to the CORTEX-M4 family, they should have similar performance 
per MHZ.


In measurements for 1600D on the MCHF with the UHSDR software, this 
takes roughly 70% load in the signal processing path from 48khz IQ to 
audio for 1600D. Doing the math 168/120 * 70% load = 98% load. 2% 
cycles left. SSB decoding takes about 10%, the remaining 60% went to 
FreeDV. Not a problem in SM1600 as it does less signal processing and 
doesn't have to run a graphical UI in addition (which the MCHF does).


700D runs ok on the STM32F7 processor with 216 Mhz and processor 
caches (CORTEX-M7 design), speeding up code execution quite 
significantly. The STM32H7 with 480 Mhz is not concerned about 
decoding 700D at all, there is plenty of cpu power left. But those are 
unfortunately not in those handhelds.


But for a different FreeDV mode better suited for VHF/UHF usage or a 
different signal processing chain it might be an entirely different 
story. Thats is where I have to hand over to David and the other experts.
And just for the record: I would love to have a "completely" open 
source GD77 with digital voice.


Danilo



Can't say anything about the DM1801

On 02/02/2021 18:21, Daniel Mundall wrote:

Hi Eric,
Funny that you mention OpenGD77 as last month I discovered these 
radios (Baofeng DM-1801 in my case) and picked up two of them off of 
aliexpress with codec2 being the primary reason for my purchase.

There are 4 reasons why I think they would be great fit for codec2:

  * They're cheap ($65-75) & available which means you could get a
larger adoption.
  * They run on an ARM platform either STM32 or similar processor.
  * And there's already an open source firmware without inventing that.
  * The audio encoding isn't a separate chip (at least on the DM1801)
it's software encoding.

Interestingly enough original portion of the memory containing the 
software audio codec is retained in OpenGD77 to avoid patent issues.


Another cool possibility that I haven't felt out yet but in theory 
because of the two slot TDMA setup I think either a repeater mode or 
full duplex audio should be possible.


Anyway, I just got the radios so soon as I have a chance I'm going to 
get OpenGD77 loaded up and play around with it.


One thing that David or the others might be better suited to answer 
is how much hardware functions of the STM32 have been used in the 
codec2 port. Because there could be hardware limitations with what is 
even available as far a hardware functions on the MCU.


Regards,

Daniel Mundall VA7DRM


On Tue, Feb 2, 2021 at 5:59 AM Eric Jacksch <mailto:e...@jacksch.com>> wrote:


I don't know enough about CODECS to know the right answer (thus must
post here), but right now the OpenGD77 source basically includes an
bit of assembly language to call some binary code lifted out of the
vendor's original firmware. My interest is to drop in a different
CODEC, but I don't know enough about them to understand exactly what
needs to be done.

On Tue, 2 Feb 2021 at 02:48, Mooneer Salem mailto:moon...@gmail.com>> wrote:
>
> I'm thinking M17 (based on Codec2) might be better to
incorporate since it's already building in routing type features
that DMR, D-STAR, etc. already have. I'm not really familiar with
OpenGD77 but it seems like a neat project. Unfortunately 

Re: [Freetel-codec2] Mailing List & Logo

[David Rowe]

Hi Blender,

Well your ability to add Pizazz is much appreciated!  Yes, good point we 
don't have a logo. It would also be nice to standardise some other 
branding aspects like colors/fonts used across Codec 2 and FreeDV (then 
business cards, t-shirts etc).


You've made some good points below.  Some thoughts from me:

1/ It's a codec that is focused on speech rather than general audio 
signals.  I have attached a PNG of some speech waveform.


2/ It was started to address the issue of patent free speech codecs.  So 
"free as in speech" is really important.


3/ As you pointed out - main application is HF radio, your idea of 
circling the world is a good one.  Radio in general I guess.


- David

On 31/12/20 9:22 am, Blender Bach wrote:

Hello!
     In response to, "I imagine you know more about this process 
having designed a few logos."  I'm not a professional. My process was 
basically, someone tells me what they would like in their logo, and 
then I design it with more "Pizazz." I never had experience with 
corporate "things." But I can design logos. 
In terms of ideas, I noticed that MP3, OPUS, AAC, etc. have their own 
logo, however, Codec 2 has no logo, which is why I decided to try and 
help make one. However, I will attempt to answer your questions to 
the best of my ability.


/*"What the Codec 2 project is about"* - The Codec 2 Project is an 
audio codec that works well with voices, and makes audio files that 
are very small./

/
/
/*"What we would like a log to show" *- I had this idea, that since 
Codec 2 is used for ShortWave, I thought that a globe with the text 
(Codec 2) wrapped around it feels right. However, my ideas might not 
be the same as yours./

/
/
/*"Where it will be used"* - Software that uses Codec 2 has that Icon 
probably when browsing .c2 files. The website. Companies that feature 
it. I'm not really sure./


_As I mentioned, I have no experience with professionalism. _


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Mailing List & Logo

[David Rowe]

Thanks Jeroen, the idea of "subclassing" the logo is a good one!

Thinking about it, Tux is recognizable as a character/figure, without 
the word "linux".  So the image works without any associated text.


- David

On 31/12/20 9:14 am, Jeroen Vreeken wrote:

Hi,

Allow me to add my 2 cents...
One of the nice things I always liked about the Linux mascot/logo Tux 
is the way the logo could be used for more than just being a static 
image. If you were less creative you could just paste your sub-project 
on its belly, but I have seen very creative usages of Tux as a mascot 
(and not just a logo) in various poses, but all of them still screamed 
'Linux'.
If it was up to me (and it is not) I would aim for a similar thing: A 
recognizable logo and mascot that can be used in creative ways, yet 
still clearly signals 'codec2' or 'freedv'. (Imagine the 
nowherville-amateur-radio-codec2-enthousiasts club creating their own 
derivative and it should still make sense)


73,
Jeroen PE1RXQ


On 12/30/2020 08:56 PM, David Rowe wrote:


Hi,

I was that guy and this is indeed the right place.  I think your 
original post was on the digital voice Google group. Was the Codec 2 
mailing list really that hard to find?  I just Googled the term and 
it came straight up, plus it is mentioned on the Codec 2 web page.


Re logo - thank you for your offer.  Rather that generating an image 
immediately, can we please start with a discussion what the Codec 2 
project is about, what we would like a log to show, where it will be 
used?  I've been through this process before in the corporate world, 
part of the branding process. I imagine you know more this process 
having designed a few logos.


Bruce, Mel, Walter - I would be interested in your thoughts, and 
those of anyone else on the list who has thoughts about the 
direction/image/purpose of Codec 2.


Here are some of the original blog posts for the project, that 
capture some of the initial motivation:


http://www.rowetel.com/?p=128

http://www.rowetel.com/?p=121

And I guess you've found the codec 2 page:

http://www.rowetel.com/wordpress/?page_id=452

This mailing list has a limit of attachment sizes - pls use URLs to 
link to any large files.


Cheers,
David

On 31/12/20 6:05 am, Blender Bach wrote:
A few weeks ago, I created a conversation in the Codec 2 Google 
Groups. It was regarding the Codec 2 Logo. A guy there asked me to 
please move the conversation to the "Codec 2 Mailing List." I 
however, don't even know what that is so I am hoping I am doing this 
right. Please tell me if I sent it to the right place, because I am 
confused indeed.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2





___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2




___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Mailing List & Logo

[David Rowe]

Hi,

I was that guy and this is indeed the right place.  I think your 
original post was on the digital voice Google group. Was the Codec 2 
mailing list really that hard to find?  I just Googled the term and it 
came straight up, plus it is mentioned on the Codec 2 web page.


Re logo - thank you for your offer.  Rather that generating an image 
immediately, can we please start with a discussion what the Codec 2 
project is about, what we would like a log to show, where it will be 
used?  I've been through this process before in the corporate world, 
part of the branding process.  I imagine you know more this process 
having designed a few logos.


Bruce, Mel, Walter - I would be interested in your thoughts, and those 
of anyone else on the list who has thoughts about the 
direction/image/purpose of Codec 2.


Here are some of the original blog posts for the project, that capture 
some of the initial motivation:


 http://www.rowetel.com/?p=128

 http://www.rowetel.com/?p=121

And I guess you've found the codec 2 page:

 http://www.rowetel.com/wordpress/?page_id=452

This mailing list has a limit of attachment sizes - pls use URLs to link 
to any large files.


Cheers,
David

On 31/12/20 6:05 am, Blender Bach wrote:
A few weeks ago, I created a conversation in the Codec 2 Google 
Groups. It was regarding the Codec 2 Logo. A guy there asked me to 
please move the conversation to the "Codec 2 Mailing List." I however, 
don't even know what that is so I am hoping I am doing this right. 
Please tell me if I sent it to the right place, because I am confused 
indeed.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] SM1000

[David Rowe]

Hello Usman,

Can you pls tell us a little more about your project?

Some general comments:

1) If that chip is not available you could use any method you like to 
get 5V, like another switcher chip or just a 5V lab supply.


2) If you don't intend to use USB OTG you might not need this.

3) Just for EMI, you can get away without it for a one off project.

4) Just use any 5V to 3V3 low drop out regulator.

I can't suggest any pin-pin replacements, but f you can locate some 
candidates (and supply data sheets) we may be able to comment.


- David

On 29/12/20 3:28 pm, Muhammad Usman Akbar wrote:
I am Muhammad Usman Akbar from Pakistan and a student of Telecom 
engineering final year from islamia University of Bahawalpur.

I am taking about the following IC's.
1. TPS54329E used in the power circuit (12-15 VDC -> 5 VDC
2. STMPS2141 used in OTG USB interface
3. EMIF02-USB03F2 also used in OTG USB interface
4. LD3985M33R used in 5V to 3.3 V PS.

On Mon, Dec 28, 2020, 11:49 PM David Rowe <mailto:da...@rowetel.com>> wrote:


Hello Usman,

1/ Can you please send us a link that explains your project, who
you are, and your University Department?  We are happy assist with
student projects but need to be sure they are not defense related.

2/ Also pls ask a specific question - such as "can I substitute
this part number (data sheet link) for SM1000 component XYZ".  You
will have to do your homework first - working out which parts you
need t substitute.

- David

On 28/12/20 6:03 pm, Muhammad Usman Akbar wrote:

Hi, Everyone
I am final year student and want to design a same SM1000 hardware.
I am working on a hardware design of SM1000.
I am following the version F available online on GitHub Rowetel.
I face some problems in selecting components because components
used in SM1000 previously not available in my country (Pakistan).
Or some of the components not clearly find on internet.
Anyone here who guide me to found alternate components or the same.
Your reply is highly appreciated.
Thanks in  advance.

Regards:
Usman

On Fri, Dec 18, 2020, 4:17 AM David Rowe mailto:da...@rowetel.com>> wrote:

Hi Jesper,

I think if you use clean samples - ie person speaking close
to the mic (but not clipped), you might be able to make it a
bit better.

Increasing the bit rate is a major job - but you could try
other open source codecs like Opus.

- David

On 18/12/20 8:39 am, Jesper Norberg wrote:

Hi David,

So, these samples I picked up from drill sergeants on
youtube, the ones I use in the end will be cleaner.
Ideally I would like to get at least some amount of
agitation in the voice to work, it does seem like a very
plausible scenario if we're talking soldier communication
potentially mid-combat.
I'm going to experiment a bit to see if I can figure out a
mastering chain that filters out what confuses the algorithm.

Do you think it's possible to improve the results by
increasing the bitrate? If so, how would you suggest I
approach it? Is it sufficient to expand on the 3200
algorithm or would the assumptions you mentioned also need
to be changed?

Best regards
Jesper

On Thu, Dec 17, 2020 at 8:18 PM David Rowe
mailto:da...@rowetel.com>> wrote:

Hi Jesper,

Interesting samples!  It seems to do OK on what I would
call "clean speech" - e.g. the female starting at 1:02,
and male at 1:30, but struggles with the people
shouting, or samples that were recorded from microphones
far away from the speaker (room acoustics).  I had
trouble understanding some of the source samples.

I'm sorry but I don't think there is much we can do with
pre-processing to improve the quality.  To get the very
low bit rates we make certain assumptions about the
input speech, e.g. the people speaking close to the
microphone.

Cheers,
David

On 17/12/20 10:24 pm, Jesper Norberg wrote:

Hi everyone!

I'm working on a project where I want to add a digital
radio feel to military voice lines. I found codec2 and
really like the sound in the examples, but I'm having
trouble reproducing the same audio quality. Some of it
sounds good, but especially when the voice line gets
more agitated it starts breaking apart. Appending an
audio sample to show what I mean, this is a 8khz 16 bit
mono sample with a codec2 bitrate of 3200, which from
what I understand should be the highest quality. The
sample is first women then men, both with 

Re: [Freetel-codec2] (off lIst) freebeacon nearly working for mode 700E

[David Rowe]

Oops - that was meant to go off list - sorry!

On 29/12/20 5:13 am, David Rowe wrote:


Hi Al,

Please put this in the form of a GitHub Pull request.  This will 
encourage people to work with you on your code:


1. Clone freebeacon

2. Commit your changes to your local repo.

3. Push to your remote repo on github

4. Press the Pull Request button.

Please put some of that determination into learning a new skill like 
the basics of GitHub.


Churchill had determination - but also knew he had to learn new skills 
and adopt new technology.  If you keep doing the same thing you will 
get the same results.


There are many step by steps guides - even one at the top of the 
GitHub page:


"Learn Git and GitHub without any code!"

- David

On 28/12/20 10:48 pm, Al Beard via Freetel-codec2 wrote:

Hi all,

Modified freebeacon in mode 700D works fine but in mode 700E,
in Rx "sync" never comes true.

Can somebody look at this please?

---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] SM1000

[David Rowe]

Hello Usman,

1/ Can you please send us a link that explains your project, who you 
are, and your University Department?  We are happy assist with student 
projects but need to be sure they are not defense related.


2/ Also pls ask a specific question - such as "can I substitute this 
part number (data sheet link) for SM1000 component XYZ".  You will have 
to do your homework first - working out which parts you need t substitute.


- David

On 28/12/20 6:03 pm, Muhammad Usman Akbar wrote:

Hi, Everyone
I am final year student and want to design a same SM1000 hardware.
I am working on a hardware design of SM1000.
I am following the version F available online on GitHub Rowetel.
I face some problems in selecting components because components used 
in SM1000 previously not available in my country (Pakistan). Or some 
of the components not clearly find on internet.

Anyone here who guide me to found alternate components or the same.
Your reply is highly appreciated.
Thanks in  advance.

Regards:
Usman

On Fri, Dec 18, 2020, 4:17 AM David Rowe <mailto:da...@rowetel.com>> wrote:


Hi Jesper,

I think if you use clean samples - ie person speaking close to the
mic (but not clipped), you might be able to make it a bit better.

Increasing the bit rate is a major job - but you could try other
open source codecs like Opus.

- David

On 18/12/20 8:39 am, Jesper Norberg wrote:

Hi David,

So, these samples I picked up from drill sergeants on youtube,
the ones I use in the end will be cleaner.
Ideally I would like to get at least some amount of agitation in
the voice to work, it does seem like a very plausible scenario if
we're talking soldier communication potentially mid-combat.
I'm going to experiment a bit to see if I can figure out a
mastering chain that filters out what confuses the algorithm.

Do you think it's possible to improve the results by increasing
the bitrate? If so, how would you suggest I approach it? Is it
sufficient to expand on the 3200 algorithm or would the
assumptions you mentioned also need to be changed?

Best regards
Jesper

On Thu, Dec 17, 2020 at 8:18 PM David Rowe mailto:da...@rowetel.com>> wrote:

Hi Jesper,

Interesting samples!  It seems to do OK on what I would call
"clean speech" - e.g. the female starting at 1:02, and male
at 1:30, but struggles with the people shouting, or samples
that were recorded from microphones far away from the speaker
(room acoustics).  I had trouble understanding some of the
source samples.

I'm sorry but I don't think there is much we can do with
pre-processing to improve the quality.  To get the very low
bit rates we make certain assumptions about the input speech,
e.g. the people speaking close to the microphone.

Cheers,
David

On 17/12/20 10:24 pm, Jesper Norberg wrote:

Hi everyone!

I'm working on a project where I want to add a digital radio
feel to military voice lines. I found codec2 and really like
the sound in the examples, but I'm having trouble
reproducing the same audio quality. Some of it sounds good,
but especially when the voice line gets more agitated it
starts breaking apart. Appending an audio sample to show
what I mean, this is a 8khz 16 bit mono sample with a codec2
bitrate of 3200, which from what I understand should be the
highest quality. The sample is first women then men, both
with examples in descending intensity.

I'm a bit new at this, is there any preprocessing/settings
that I could apply in order to improve the quality?

Original

https://drive.google.com/file/d/1IWyV_CwK0KYXC0_ZN3t3QJNk9UCwTOp9/view?usp=sharing


codec2 - 3200

https://drive.google.com/file/d/1Ww1QsNUw8s5TLQXQnBln4CkgpmjUuVFS/view?usp=sharing

Best regards
Jesper


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net  
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net  
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@

[Freetel-codec2] (off lIst) freebeacon nearly working for mode 700E

[David Rowe]

Hi Al,

Please put this in the form of a GitHub Pull request.  This will 
encourage people to work with you on your code:


1. Clone freebeacon

2. Commit your changes to your local repo.

3. Push to your remote repo on github

4. Press the Pull Request button.

Please put some of that determination into learning a new skill like the 
basics of GitHub.


Churchill had determination - but also knew he had to learn new skills 
and adopt new technology.  If you keep doing the same thing you will get 
the same results.


There are many step by steps guides - even one at the top of the GitHub 
page:


"Learn Git and GitHub without any code!"

- David

On 28/12/20 10:48 pm, Al Beard via Freetel-codec2 wrote:

Hi all,

Modified freebeacon in mode 700D works fine but in mode 700E,
in Rx "sync" never comes true.

Can somebody look at this please?

---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

[David Rowe]

We've also used it to send an email when a FreeDV signal was received:

https://github.com/drowe67/freedv-gui/blob/master/USER_MANUAL.md#udp-messages

-David


On 28/12/20 4:25 am, walt...@k5wh.net wrote:


The purpose of that, was to update the QSO finder when stations 
started up.


But it was never implemented on the QSO finder side.

Walter/K5WH

*From:* Mooneer Salem 
*Sent:* Sunday, December 27, 2020 3:14 AM
*To:* freetel-codec2@lists.sourceforge.net
*Subject:* Re: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

There's some code in FreeDV to open a UDP port and have it accept 
commands. I haven't looked too much at it, so perhaps David would know 
more.


-Mooneer K6AQ

On Sat, Dec 26, 2020 at 7:06 PM Al Beard via Freetel-codec2 
<mailto:freetel-codec2@lists.sourceforge.net>> wrote:


Hi Mooneer and any other developers,

Could a "connetivity" mechanism to/from the FreeDV GUI app such
that another app can trigger Tx and get an Rx

valid signal?

The "another" app could be "Asterisk", "HamVOIP" or "mvoice" etc..

Alan VK2ZIW

*On Sun, 20 Dec 2020 15:48:33 -0800, Mooneer Salem wrote*
> Yeah, I'm not 100% sure if it's a backwards compatibility issue
or some bug but reverting to 1.4.3 did seem to help for one or two
people.
>
> BTW, the measures I took thus far to reduce misreports to PSK
Reporter are still not 100%; my callsign was reported as "K6TQ"
earlier instead of "K6AQ". We'll have to look more into FEC at
some point for sure.
>
> -Mooneer K6AQ
>
> On Sun, Dec 20, 2020 at 2:49 PM David Rowe mailto:da...@rowetel.com>> wrote:
>


>
> Yes its should be backwards compatible, so if it's a
reproducible issue we should fix it.  IIRC I have a ctest that
checks backwards compatibility for 700D.
>
> - David
> On 21/12/20 9:13 am, Mooneer Salem wrote:
>


> David, quick question. Is 1.5.0/1.5.1 supposed to be
backwards compatible with 1.4.3? At least a couple of
people have reported that received signals were garbled.
(I recorded myself via a WebSDR earlier today and was able
to decode myself with 1.5.1, FWIW.)
>
> -Mooneer K6AQ
>
> On Sun, Dec 20, 2020 at 2:37 AM David Rowe
mailto:da...@rowetel.com>> wrote:
>


>
> Hi Al,
> I don't run the QSO.freedv.org
<http://qso.freedv.org/> website - you'll need to talk
to  the maintainer.
> SM1000 support for 700E is possible (it's about the
same CPU as 700D), if some one wants to work on it
 however it would be nice to get the band pass
filter running on the SM1000 to support the
clipper/compression.  To date we've left the BPF out
of the SM1000 due to CPU, so some optimisation work
required there.
    >
> - David
>
> On 20/12/20 3:34 pm, Al Beard via Freetel-codec2 wrote:
>

*Thanks David,*
> *
> *
> *I've recompiled the Codec2 library with the
latest on my "parrot" repeater.*
> *(Fedora 30 armv7hl) (a Pi clone, Banana Pi M2
Berry)*
> *But error:*
> */data/home/alanb/bin/parrot: undefined symbol:
freedv_get_uncorrected_errors*
> *
> *
> *I'll look into that*
> *
> *
> *I've compiled the Ver 1.5 devel FreeDV GUI on
Fedora 29 x86_64, my "main" box.*
> *
> *
> *We are having some good Sporadic E openings on
10m and 6m between here and New Zealand.*
> *
> *
> *Can we have some frequencies on the
QSO.freedv.org <http://qso.freedv.org/> website
for bands 17m and up such that there*
> *is a "standard" on each band?*
> *
> *
> *Also, is there a possibility the SM1000 can run
mode 700E?*
> *
> *
> *Alan VK2ZIW*
> *
  

Re: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

[David Rowe]

Yes its should be backwards compatible, so if it's a reproducible issue 
we should fix it.  IIRC I have a ctest that checks backwards 
compatibility for 700D.


- David

On 21/12/20 9:13 am, Mooneer Salem wrote:
David, quick question. Is 1.5.0/1.5.1 supposed to be backwards 
compatible with 1.4.3? At least a couple of people have reported that 
received signals were garbled. (I recorded myself via a WebSDR earlier 
today and was able to decode myself with 1.5.1, FWIW.)


-Mooneer K6AQ

On Sun, Dec 20, 2020 at 2:37 AM David Rowe <mailto:da...@rowetel.com>> wrote:


Hi Al,

I don't run the QSO.freedv.org <http://QSO.freedv.org> website -
you'll need to talk to  the maintainer.

SM1000 support for 700E is possible (it's about the same CPU as
700D), if some one wants to work on it  however it would be
nice to get the band pass filter running on the SM1000 to support
the clipper/compression.  To date we've left the BPF out of the
SM1000 due to CPU, so some optimisation work required there.

- David

On 20/12/20 3:34 pm, Al Beard via Freetel-codec2 wrote:

    *Thanks David,*
*
*
*I've recompiled the Codec2 library with the latest on my
"parrot" repeater.*
*(Fedora 30 armv7hl) (a Pi clone, Banana Pi M2 Berry)*
*But error:*
*/data/home/alanb/bin/parrot: undefined symbol:
freedv_get_uncorrected_errors*
*
*
*I'll look into that*
*
*
*I've compiled the Ver 1.5 devel FreeDV GUI on Fedora 29 x86_64,
my "main" box.*
*
*
*We are having some good Sporadic E openings on 10m and 6m
between here and New Zealand.*
*
*
*Can we have some frequencies on the QSO.freedv.org
<http://QSO.freedv.org> website for bands 17m and up such that there*
*is a "standard" on each band?*
*
*
*Also, is there a possibility the SM1000 can run mode 700E?*
*
*
*Alan VK2ZIW*
*
*
    *
    *
*On Sun, 20 Dec 2020 13:50:33 +1030, David Rowe wrote*
> Thanks Walter and Mooneer.  I'd be interested to know the RMS
power you can develop with 700D/E with the clipper option.
> - David
>
> On 20/12/20 10:30 am, Mooneer Salem wrote:
>


> Looks like it's working reasonably well, though the 20 meter
band fell out shortly after we all got it installed. More
testing tomorrow for sure. :)
>
> -Mooneer K6AQ
>
> On Sat, Dec 19, 2020 at 2:26 PM mailto:walt...@k5wh.net>> wrote:
>

Have it loaded and running now.
>
> Working on a couple others as I type to get some end to
end testing.
>
> Many thanks David, and best of the holidays.
>
> Walter/K5WH
>
> -Original Message-
> From: David Rowe mailto:da...@rowetel.com>>
> Sent: Saturday, December 19, 2020 3:34 PM
> To: freetel-codec2@lists.sourceforge.net
<mailto:freetel-codec2@lists.sourceforge.net>
> Subject: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM
compression
>
> I've been working on a new FreeDV 700E mode, and some
compression for FreeDV 700D and 700E to increase the average
power.  A Christmas present for you to play with
>
> 700E is designed to handle fast fading like 700C, but like
700D has powerful FEC. My bench tests indicate 700C & E are
equivalent on moderate fading channels (2Hz dopdler/2ms
spread), but on very fast fading (4Hz/4ms) 700E does better
- 700C & D fall over. 700D works better at lower SNRs on
slow fading channels.
>
> I've also been testing against compressed SSB, which as
Helmut suggests is pretty hard to beat, as it's so robust to
fading. However 700E is hanging on quite well with fast
fading, and becomes noise free as the SNR increases.
>
> -/-
>
> The second innovation is compression of the 700C/D/E
waveforms, to increase average power significantly.
>
> Please be careful adjusting the Tx drive and especially
enabling the Tool - Options - Clipping. It can drive your PA
quite hard.  I have managed 40W RMS out of my 75W PEP
transmitter.  Make sure your transmitter can handle long
periods of high average power. My IC7200 and
> FT-817 seem OK.
>
> At the same equivalent peak power - 700D is doing well
when compressed SSB is -5dB SNR and rather hard on the ears.
>
> -/-
>
> Peter VK3RV, Jose LU5DKI, and Barry VK3BRT tried 1.5.0
last night and report it works on real HF channels.
> The latest manual describes the new features:
>

Re: [Freetel-codec2] LPCNet new release?

[David Rowe]

Hi Richard,

I think there have just been minor bug fixes to LPCNet.  Is there any 
way we can diff against the ver 0.2 release?  Then I can tell you for sure.


Once FreeDV 1.5 has settled in, we can consider a new release of that 
and Codec 2 if you like.


Cheers,
David

On 21/12/20 2:15 am, Richard Shaw wrote:
So I kinda messed up with my package in Fedora. I tried to make the 
library private to codec2/freedv by putting it in a subdirectory of 
the default library dir.


Codec2 finds and builds against it fine, but then can't find it once 
installed because it's not in the library search path. I've considered 
multiple work arounds but in the end I decided it's just easier to 
maintain a library soversion.


I've noticed quite a few commits since the 0.2 release. Should I 
assume that there's been API/ABI incompatible changes made? And if so, 
is it time for a 0.3 release?


Thanks,
Richard
KF5OIM


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

[David Rowe]

Hi Al,

I don't run the QSO.freedv.org website - you'll need to talk to the 
maintainer.


SM1000 support for 700E is possible (it's about the same CPU as 700D), 
if some one wants to work on it  however it would be nice to get the 
band pass filter running on the SM1000 to support the 
clipper/compression.  To date we've left the BPF out of the SM1000 due 
to CPU, so some optimisation work required there.


- David

On 20/12/20 3:34 pm, Al Beard via Freetel-codec2 wrote:

*Thanks David,*
*
*
*I've recompiled the Codec2 library with the latest on my "parrot" 
repeater.*

*(Fedora 30 armv7hl) (a Pi clone, Banana Pi M2 Berry)*
*But error:*
*/data/home/alanb/bin/parrot: undefined symbol: 
freedv_get_uncorrected_errors*

*
*
*I'll look into that*
*
*
*I've compiled the Ver 1.5 devel FreeDV GUI on Fedora 29 x86_64, my 
"main" box.*

*
*
*We are having some good Sporadic E openings on 10m and 6m between 
here and New Zealand.*

*
*
*Can we have some frequencies on the QSO.freedv.org website for bands 
17m and up such that there*

*is a "standard" on each band?*
*
*
*Also, is there a possibility the SM1000 can run mode 700E?*
*
*
*Alan VK2ZIW*
*
*
*
*
*On Sun, 20 Dec 2020 13:50:33 +1030, David Rowe wrote*
> Thanks Walter and Mooneer.  I'd be interested to know the RMS power 
you can develop with 700D/E with the clipper option.

> - David
>
> On 20/12/20 10:30 am, Mooneer Salem wrote:
>


> Looks like it's working reasonably well, though the 20 meter band 
fell out shortly after we all got it installed. More testing tomorrow 
for sure. :)

>
> -Mooneer K6AQ
>
> On Sat, Dec 19, 2020 at 2:26 PM <mailto:walt...@k5wh.net>> wrote:

>

Have it loaded and running now.
>
> Working on a couple others as I type to get some end to end
testing.
>
> Many thanks David, and best of the holidays.
>
> Walter/K5WH
>
> -Original Message-
> From: David Rowe mailto:da...@rowetel.com>>
> Sent: Saturday, December 19, 2020 3:34 PM
> To: freetel-codec2@lists.sourceforge.net
<mailto:freetel-codec2@lists.sourceforge.net>
> Subject: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression
>
> I've been working on a new FreeDV 700E mode, and some
compression for FreeDV 700D and 700E to increase the average
power.  A Christmas present for you to play with
>
> 700E is designed to handle fast fading like 700C, but like 700D
has powerful FEC. My bench tests indicate 700C & E are equivalent
on moderate fading channels (2Hz dopdler/2ms spread), but on very
fast fading (4Hz/4ms) 700E does better - 700C & D fall over. 700D
works better at lower SNRs on slow fading channels.
>
> I've also been testing against compressed SSB, which as Helmut
suggests is pretty hard to beat, as it's so robust to fading.
However 700E is hanging on quite well with fast fading, and
becomes noise free as the SNR increases.
>
> -/-
>
> The second innovation is compression of the 700C/D/E waveforms,
to increase average power significantly.
>
> Please be careful adjusting the Tx drive and especially
enabling the Tool - Options - Clipping. It can drive your PA
quite hard.  I have managed 40W RMS out of my 75W PEP
transmitter.  Make sure your transmitter can handle long periods
of high average power. My IC7200 and
> FT-817 seem OK.
>
> At the same equivalent peak power - 700D is doing well when
compressed SSB is -5dB SNR and rather hard on the ears.
>
> -/-
>
> Peter VK3RV, Jose LU5DKI, and Barry VK3BRT tried 1.5.0 last
night and report it works on real HF channels.
> The latest manual describes the new features:
>
>

https://github.com/drowe67/freedv-gui/blob/118cb66ee4679518185db871ec0ae68071c406a4/USER_MANUAL.md

>
> You can download Windows 32 and 64 bit versions of FreeDV 1.5
here:
>
> http://rowetel.com/downloads/freedv
>
> -/-
>
> I'd be interested in any feedback.  If you have an interesting
test case (e.g. a bug or comparing SSB to FreeDV), pls send me
off air recordings of signals (FreeDV Tools-Record File from
Radio). That helps me make objective comparisons.  Recordings are
much more useful to me than anecdotes or subjective reports.
>
> Thanks,
> David
>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists

Re: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

[David Rowe]

If it's 100W PEP then 40WRMS is about right with the 
tools-options-clipping on (4dB PAPR).


On 20/12/20 3:19 pm, Mooneer Salem wrote:
On my Hermes Lite 2 + Hardrock-50, the latter was claiming 40 watts on 
700E without touching any settings in the app. Will need to play more 
to see how far it can be taken.


-Mooneer K6AQ

On Sat, Dec 19, 2020 at 7:22 PM David Rowe <mailto:da...@rowetel.com>> wrote:


Thanks Walter and Mooneer.  I'd be interested to know the RMS
power you can develop with 700D/E with the clipper option.

    - David

On 20/12/20 10:30 am, Mooneer Salem wrote:

Looks like it's working reasonably well, though the 20 meter band
fell out shortly after we all got it installed. More testing
tomorrow for sure. :)

-Mooneer K6AQ

On Sat, Dec 19, 2020 at 2:26 PM mailto:walt...@k5wh.net>> wrote:

Have it loaded and running now.

Working on a couple others as I type to get some end to end
testing.

    Many thanks David, and best of the holidays.


Walter/K5WH

-Original Message-
From: David Rowe mailto:da...@rowetel.com>>
Sent: Saturday, December 19, 2020 3:34 PM
To: freetel-codec2@lists.sourceforge.net
<mailto:freetel-codec2@lists.sourceforge.net>
Subject: [Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

I've been working on a new FreeDV 700E mode, and some
compression for FreeDV 700D and 700E to increase the average
power.  A Christmas present for you to play with

700E is designed to handle fast fading like 700C, but like
700D has powerful FEC. My bench tests indicate 700C & E are
equivalent on moderate fading channels (2Hz dopdler/2ms
spread), but on very fast fading (4Hz/4ms) 700E does better -
700C & D fall over. 700D works better at lower SNRs on slow
fading channels.

I've also been testing against compressed SSB, which as
Helmut suggests is pretty hard to beat, as it's so robust to
fading. However 700E is hanging on quite well with fast
fading, and becomes noise free as the SNR increases.

-/-

The second innovation is compression of the 700C/D/E
waveforms, to increase average power significantly.

Please be careful adjusting the Tx drive and especially
enabling the Tool - Options - Clipping. It can drive your PA
quite hard.  I have managed 40W RMS out of my 75W PEP
transmitter.  Make sure your transmitter can handle long
periods of high average power. My IC7200 and
FT-817 seem OK.

At the same equivalent peak power - 700D is doing well when
compressed SSB is -5dB SNR and rather hard on the ears.

-/-

Peter VK3RV, Jose LU5DKI, and Barry VK3BRT tried 1.5.0 last
night and report it works on real HF channels.
The latest manual describes the new features:


https://github.com/drowe67/freedv-gui/blob/118cb66ee4679518185db871ec0ae68071c406a4/USER_MANUAL.md



You can download Windows 32 and 64 bit versions of FreeDV 1.5
here:

http://rowetel.com/downloads/freedv

-/-

I'd be interested in any feedback.  If you have an
interesting test case (e.g. a bug or comparing SSB to
FreeDV), pls send me off air recordings of signals (FreeDV
Tools-Record File from Radio). That helps me make objective
comparisons.  Recordings are much more useful to me than
anecdotes or subjective reports.

Thanks,
David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net  
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Participant Policies

[David Rowe]

Thank you Albert - I like the idea of only addressing list behavior 
against the code of conduct to people off list, in private emails.  We'd 
probably need to nominate a couple of people to keep an eye on list 
behavior (including mine) and write those emails.


- David

On 20/12/20 11:28 am, Albert Cahalan wrote:

A code of conduct for Codec2/FreeDV and this mailing list is a good
idea.  The participant policies document is a good start, but has a
strong focus on gender issues and face-face behiavour.  We could
probably get away with something shorter and more concise.

The typical code of conduct, with that gender focus you noticed, often
gets abused as a weapon by people looking for drama and wanting to
be a hero or center of attention. Think of it as being like one of those
laws passed with the proponents claiming "oh, it'd never be used to do
those terrible things" and then later the terrible things are the main use.
Projects get mired in legalistic nitpicking over the rules, sometimes with
non-contributing people able to toss key contributors out of projects.

A better way: put up a warning somewhere about the obscure ITAR rules
that people might not be aware of, and leave all the rest to be dealt with
by private scolding along the lines of "hey, you're disrupting the project,
both of you, so take it someplace else" if anything serious ever happens.


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Freetel-codec2] FreeDV 1.5 - 700E and OFDM compression

[David Rowe]

I've been working on a new FreeDV 700E mode, and some compression for 
FreeDV 700D and 700E to increase the average power.  A Christmas present 
for you to play with


700E is designed to handle fast fading like 700C, but like 700D has 
powerful FEC. My bench tests indicate 700C & E are equivalent on 
moderate fading channels (2Hz dopdler/2ms spread), but on very fast 
fading (4Hz/4ms) 700E does better - 700C & D fall over. 700D works 
better at lower SNRs on slow fading channels.


I've also been testing against compressed SSB, which as Helmut suggests 
is pretty hard to beat, as it's so robust to fading. However 700E is 
hanging on quite well with fast fading, and becomes noise free as the 
SNR increases.


-/-

The second innovation is compression of the 700C/D/E waveforms, to 
increase average power significantly.


Please be careful adjusting the Tx drive and especially enabling the 
Tool - Options - Clipping. It can drive your PA quite hard.  I have 
managed 40W RMS out of my 75W PEP transmitter.  Make sure your 
transmitter can handle long periods of high average power. My IC7200 and 
FT-817 seem OK.


At the same equivalent peak power - 700D is doing well when compressed 
SSB is -5dB SNR and rather hard on the ears.


-/-

Peter VK3RV, Jose LU5DKI, and Barry VK3BRT tried 1.5.0 last night and 
report it works on real HF channels.

The latest manual describes the new features:

https://github.com/drowe67/freedv-gui/blob/118cb66ee4679518185db871ec0ae68071c406a4/USER_MANUAL.md 



You can download Windows 32 and 64 bit versions of FreeDV 1.5 here:

http://rowetel.com/downloads/freedv

-/-

I'd be interested in any feedback.  If you have an interesting test case 
(e.g. a bug or comparing SSB to FreeDV), pls send me off air recordings 
of signals (FreeDV Tools-Record File from Radio). That helps me make 
objective comparisons.  Recordings are much more useful to me than 
anecdotes or subjective reports.


Thanks,
David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Participant Policies

[David Rowe]

Thanks Bruce,

I would imagine keeping on the right side of the Defence and Strategic 
Goods List and Ham Radio regulations (or the local equivalent in any 
given country) would avoid any issues, and certainly the more dramatic 
scenarios you have alluded to.  I'll ask a few questions with my local 
authorities - they were very helpful last time.


I also feel we need to recognise the international nature of this 
project - and avoid being overly focused on US law.  Hopefully we can 
find a nice middle ground where we can all enjoy our hobby and keep our 
governments happy.


A code of conduct for Codec2/FreeDV and this mailing list is a good 
idea.  The participant policies document is a good start, but has a 
strong focus on gender issues and face-face behiavour.  We could 
probably get away with something shorter and more concise.


- David

On 19/12/20 6:40 am, Bruce Perens via Freetel-codec2 wrote:
Besides ITAR/EAR, looking at the treason laws in the USA, there is 
jail time for rendering aid to foreign military, and instructing in 
military activities requires your organization to be registered with 
the Attorney General (for careful watching).


I wrote participant policies for ORI about 2 years ago that IMO would 
have helped the mailing list with some social issues, not just export 
law. I think the Codec2 / DigitalVoice projects should edit out 
references to ORI and adopt them. See


https://www.openresearch.institute/developer-and-participant-policies/


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Quality drops for agitated voice lines

[David Rowe]

Hi Jesper,

I think if you use clean samples - ie person speaking close to the mic 
(but not clipped), you might be able to make it a bit better.


Increasing the bit rate is a major job - but you could try other open 
source codecs like Opus.


- David

On 18/12/20 8:39 am, Jesper Norberg wrote:

Hi David,

So, these samples I picked up from drill sergeants on youtube, the 
ones I use in the end will be cleaner.
Ideally I would like to get at least some amount of agitation in the 
voice to work, it does seem like a very plausible scenario if we're 
talking soldier communication potentially mid-combat.
I'm going to experiment a bit to see if I can figure out a mastering 
chain that filters out what confuses the algorithm.


Do you think it's possible to improve the results by increasing the 
bitrate? If so, how would you suggest I approach it? Is it sufficient 
to expand on the 3200 algorithm or would the assumptions you mentioned 
also need to be changed?


Best regards
Jesper

On Thu, Dec 17, 2020 at 8:18 PM David Rowe <mailto:da...@rowetel.com>> wrote:


Hi Jesper,

Interesting samples!  It seems to do OK on what I would call
"clean speech" - e.g. the female starting at 1:02, and male at
1:30, but struggles with the people shouting, or samples that were
recorded from microphones far away from the speaker (room
acoustics).  I had trouble understanding some of the source samples.

I'm sorry but I don't think there is much we can do with
pre-processing to improve the quality.  To get the very low bit
rates we make certain assumptions about the input speech, e.g. the
people speaking close to the microphone.

    Cheers,
David

On 17/12/20 10:24 pm, Jesper Norberg wrote:

Hi everyone!

I'm working on a project where I want to add a digital radio feel
to military voice lines. I found codec2 and really like the sound
in the examples, but I'm having trouble reproducing the same
audio quality. Some of it sounds good, but especially when the
voice line gets more agitated it starts breaking apart. Appending
an audio sample to show what I mean, this is a 8khz 16 bit mono
sample with a codec2 bitrate of 3200, which from what I
understand should be the highest quality. The sample is first
women then men, both with examples in descending intensity.

I'm a bit new at this, is there any preprocessing/settings that I
could apply in order to improve the quality?

Original

https://drive.google.com/file/d/1IWyV_CwK0KYXC0_ZN3t3QJNk9UCwTOp9/view?usp=sharing


codec2 - 3200

https://drive.google.com/file/d/1Ww1QsNUw8s5TLQXQnBln4CkgpmjUuVFS/view?usp=sharing

Best regards
Jesper


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net  
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Quality drops for agitated voice lines

[David Rowe]

Bruce,

I just did a quick search of the Australian Defence and Strategic Goods 
List (DGSL):


1/  Employing functions of digital “signal processing” to provide ‘voice 
coding’ output at rates of less than 700 bit/s;


2/ There are exemptions for technology in the "public domain" and "basic 
research".


Codec 2 does have a 450 bit/s mode, but it's more in the R/demo realm, 
I don't know of it being used by anyone. Codec 2 700C is in wide use.


When convenient, can you pls take a look at the equivalent US list?  
I've found in the past the Australian law in this area tends to be 
closely aligned with the US.


- David

On 18/12/20 9:00 am, David Rowe wrote:


Hi Bruce,

Some time ago I checked the Australian position on export of speech 
codec software - it's close to the US.  For bit rates beneath 2400 
speech codecs are on the export control list - right next to "software 
for designing nuclear weapons".  I applied to the Australian defense 
signals directorate and obtained a written exemption for Codec 2.


However the project has moved on since then so perhaps I should talk 
to them again, and check the current regulations.


I gather Jesper's use case is for entertainment.

Cheers,
David

On 18/12/20 8:26 am, Bruce Perens via Freetel-codec2 wrote:



On Thu, Dec 17, 2020 at 3:56 AM Jesper Norberg <mailto:jazzpur...@gmail.com>> wrote:


I'm working on a project where I want to add a digital radio feel
to military voice lines.


I'm not speaking for the project, but my personal feeling is that 
this endangers the project.


Codecs are on the US Munitions list, and the rules here in the US 
include that if people working on the project who are in the 
US* render aid *to defense projects, for example by answering your 
questions on this mailing list, our work is in danger of coming under 
the US export laws ITAR or EAR. Australia, where David is, has 
somewhat different rules, and they differ among countries. But this 
is serious stuff, and includes the potential for some of us to go to 
prison.


    Thanks

    Bruce


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Quality drops for agitated voice lines

[David Rowe]

Hi Bruce,

Some time ago I checked the Australian position on export of speech 
codec software - it's close to the US.  For bit rates beneath 2400 
speech codecs are on the export control list - right next to "software 
for designing nuclear weapons".  I applied to the Australian defense 
signals directorate and obtained a written exemption for Codec 2.


However the project has moved on since then so perhaps I should talk to 
them again, and check the current regulations.


I gather Jesper's use case is for entertainment.

Cheers,
David

On 18/12/20 8:26 am, Bruce Perens via Freetel-codec2 wrote:



On Thu, Dec 17, 2020 at 3:56 AM Jesper Norberg <mailto:jazzpur...@gmail.com>> wrote:


I'm working on a project where I want to add a digital radio feel
to military voice lines.


I'm not speaking for the project, but my personal feeling is that this 
endangers the project.


Codecs are on the US Munitions list, and the rules here in the US 
include that if people working on the project who are in the 
US* render aid *to defense projects, for example by answering your 
questions on this mailing list, our work is in danger of coming under 
the US export laws ITAR or EAR. Australia, where David is, has 
somewhat different rules, and they differ among countries. But this is 
serious stuff, and includes the potential for some of us to go to prison.


    Thanks

    Bruce


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Quality drops for agitated voice lines

[David Rowe]

Hi Jesper,

Interesting samples!  It seems to do OK on what I would call "clean 
speech" - e.g. the female starting at 1:02, and male at 1:30, but 
struggles with the people shouting, or samples that were recorded from 
microphones far away from the speaker (room acoustics).  I had trouble 
understanding some of the source samples.


I'm sorry but I don't think there is much we can do with pre-processing 
to improve the quality.  To get the very low bit rates we make certain 
assumptions about the input speech, e.g. the people speaking close to 
the microphone.


Cheers,
David

On 17/12/20 10:24 pm, Jesper Norberg wrote:

Hi everyone!

I'm working on a project where I want to add a digital radio feel to 
military voice lines. I found codec2 and really like the sound in the 
examples, but I'm having trouble reproducing the same audio quality. 
Some of it sounds good, but especially when the voice line gets more 
agitated it starts breaking apart. Appending an audio sample to show 
what I mean, this is a 8khz 16 bit mono sample with a codec2 bitrate 
of 3200, which from what I understand should be the highest quality. 
The sample is first women then men, both with examples in descending 
intensity.


I'm a bit new at this, is there any preprocessing/settings that I 
could apply in order to improve the quality?


Original
https://drive.google.com/file/d/1IWyV_CwK0KYXC0_ZN3t3QJNk9UCwTOp9/view?usp=sharing 



codec2 - 3200
https://drive.google.com/file/d/1Ww1QsNUw8s5TLQXQnBln4CkgpmjUuVFS/view?usp=sharing

Best regards
Jesper


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Do we need these comments

[David Rowe]

Thanks Adrian - I enjoy many aspects of developing digital voice 
systems, such as speech coding, modems for HF radio, and lately, machine 
learning.  Good fun, and lots to learn.  Apart from me, there are also 
many other people who are contributing.  Thanks to all.


Helmut - you can be our beta tester for the next FreeDV mode :-) Lets 
see if we can further improve performance in the areas you have listed.


Cheers,
David

On 7/12/20 7:23 pm, Adrian Musceac wrote:
Everybody is entitled to an opinion, that doesn't mean we all have to 
share it.

Mode 700C sounds fine for the bitrate, and so does mode 1400 and 1600.

David you've made a great effort with them, we're more than a few 
users who never use HF and are perfectly satisfied with the current 
technology in Codec2.


And we're not all on the hype train for neural net blackbox stuff that 
Google and other big co. are trying to push towards us.


Adrian

On December 7, 2020 5:36:44 AM UTC, Random <614678...@qq.com> wrote:

*Skyler's reply:
*
*Digital voice also sounds like crap
*

Well， if you use LPCNet+Codec2 at 2400bps， it sounds pretty good.

There are some NPU (neural processing unit) which can run LPCNet.


-- Original --
*From:* "freetel-codec2" ;
*Date:* Mon, Dec 7, 2020 01:30 PM
*To:* "freetel-codec2";
*Cc:* "Al Beard";
*Subject:* [Freetel-codec2] Do we need these comments

Date: Sun, 6 Dec 2020 14:24:45 -0700
Re: [repeater-builder] Finding good sites.msg
From: "Skyler Fennell"  import address
electricity...@gmail.com block email electricity...@gmail.com
block SMTP relay
web01.groups.io
Reply-To: repeater-buil...@groups.io
To: repeater-buil...@groups.io
Subject: Re: [repeater-builder] Finding good sites

>I Alan write:
>Now here's where Digital Voice solves two BIG problems on HF:

*Skyler's reply:
Digital voice also sounds like crap
*
On Sun, Dec 6, 2020 at 1:35 PM Alan Beard via groups.io
 wrote:

 

---
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 Rust Port

[David Rowe]

That's a good start.  However would be nice to have some automated 
tests, as speech can be so subjective.


It's possible for differences to creep in to any port.  Note to self - 
It would be nice to have some standardised tests so we can rubber stamp 
any port.  I can think of places would compare vectors and verify chunks 
of code at the unit test level.


This sort of thing is actually easier for fixed point code - you can 
make it bit exact end-end.


- David

On 3/12/20 2:24 pm, Matt Weeks wrote:
I just tested a few samples I captured myself on both. I did notice 
some minor floating point rounding differences, but it still seems to 
sound fine. I just reproduced the random number generator so the 
results would be the same.


On Wed, Dec 2, 2020 at 1:39 PM David Rowe <mailto:da...@rowetel.com>> wrote:


Wow that's cool Matt well done!  How did you verify the port?

This is always a problem with speech based systems, even verifying
the C port between platforms can be tricky as the random number
generators are different, floating point precision etc.  It is
possible to compare vectors for some of the processing stages.

    - David



___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Codec2 Rust Port

[David Rowe]

Wow that's cool Matt well done!  How did you verify the port?

This is always a problem with speech based systems, even verifying the C 
port between platforms can be tricky as the random number generators are 
different, floating point precision etc.  It is possible to compare 
vectors for some of the processing stages.


- David

On 3/12/20 4:37 am, Matt Weeks wrote:

Hello,
I was interested in a pure Rust speech codec, but didn't find one that 
seemed appropriate, so I started a port of Codec2 to Rust.


https://crates.io/crates/codec2
https://github.com/scriptjunkie/codec2

Many optimizations are not implemented yet, but it does work at a 
couple bitrates.


Matt

--

https://www.scriptjunkie.us/


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] M17 and grants

[David Rowe]

Sounds very exciting Bruce - well done to M17 and ORI :-)

- David

On 22/11/20 9:54 am, Bruce Perens via Freetel-codec2 wrote:
> Hi Al and others,
> 
> The M17 project has affiliated with Open Research Institute, so that
> they can solicit for grants as an IRS accredited 501 c 3 nonprofit
> organization. Since ARDC will be granting 5 million dollars a year to
> amateur radio Open Source projects every year, this is a viable prospect
> to fund more development, and something all Open Source ham projects can
> do. As you've probably heard, ORI received a half million-dollar grant
> for developing a 10 gigahertz satellite ground station design
> incorporating Codec2 as  Open Source and Open Hardware, and a number of
> smaller grants for various projects.
> 
> The target for any grant to M17 will be a radio that is manufactured,
> incorporates Codec2, and is entirely Open Source and Open Hardware.
> 
> Thanks
> 
> Bruce
> 
> 
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] dudestar app & neural CPU load

[David Rowe]

Indeed, lots of CPU there on phones.

I've looked at some recent papers[1][2][3]  on Neural speech synthesis
and much to my surprise some of the latest research uses sinusoidal +
noise models like Codec 2, and claim big drops in CPU.

So it's possible the CPU load will drop in time, perhaps down to that
available on commodity ARM chips.

- David

[1] Wang et al, "Neural Harmonic-plus-Noise Waveform Model with
Trainable Maximum Voice Frequency for Text-to-Speech Synthesis", 2019

[2] Engel et all, "DDSP: DIFFERENTIABLE DIGITAL SIGNAL PROCESSING", 2020

[3] Liu et al, "Neural Homomorphic Vocoder", 2020

On 19/11/20 2:59 pm, Bruce Perens via Freetel-codec2 wrote:
> One strategy would be to treat the m17 STM32 processor as a wireless
> interface alone, and do the codec processing and user interface in your
> phone. This would allow you to use the high computation codecs when you
> couple the m17 and your phone.
> 
> On Wed, Nov 18, 2020, 5:45 PM Al Beard via Freetel-codec2
>  <mailto:freetel-codec2@lists.sourceforge.net>> wrote:
> 
> Hi guys,
> 
> I've had a "play" and it may work, I have to setup a second system
> to talk to myself at the lower bit-rate modes.
> 
> Source and a Linux x86_64 binary at:
> www.unixservice.com.au/freedv <http://www.unixservice.com.au/freedv>
> 
> 73
> 
> Alan VK2ZIW
> 
> On Wed, 18 Nov 2020 06:08:37 +1000, Al Beard via Freetel-codec2 wrote
> 
> >
> > == Right now ==
> >
> > I'd like to see:
> >
> > 1) Adapt "dudestar" and "droidstar" to use the current FreeDV API.
> >     (minus the AI modes)
> >
> > 2) Adapt the above two apps to use other FreeDV modes, perhaps
> even 450.
> >
> > Does this make cents?
> >
> > Alan VK2ZIW
> >
> 
> 
> ---
> Alan VK2ZIW
> Before the Big Bang, God, Sela.
> OpenWebMail 2.53, nothing in the cloud.
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> <mailto:Freetel-codec2@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] interpolation

[David Rowe]

The synthesiser operates on 10ms frames, but in this mode, the
parameters are sent over the channel every 20ms.  So we use linear
interpolation to resample.

Or in maths, if you want to estimate the a sample half way between two
other samples:

x(0.5) = 0.5*x(0) + 0.5*x(1)

- David

On 16/11/20 8:05 pm, Random wrote:
> Hi, David,
> 
> The following is your codec2 source code.
> 
> Why the energy and the LSP need the linear interpolation ?
> 
> Why the interpolation factor is 0.5 ??
> 
> What's the mathematical theory or explanation or formula behind them ?
> 
> Thanks a lot.
> 
> /* interpolate */
> 
> ?0?2 ?0?2 /* Wo and energy are sampled every 20ms, so we interpolate just 1
> ?0?2 ?0?2 ?0?2 ?0?210ms frame between 20ms samples */
> 
> ?0?2 ?0?2 interp_Wo([0], >prev_model_dec, [1]);
> ?0?2 ?0?2 e[0] = interp_energy(c2->prev_e_dec, e[1]);
> 
> ?0?2 ?0?2 /* LSPs are sampled every 20ms so we interpolate the frame in
> ?0?2 ?0?2 ?0?2 ?0?2between, then recover spectral amplitudes */
> 
> ?0?2 ?0?2 interpolate_lsp_ver2([0][0], c2->prev_lsps_dec, [1][0],
> 0.5, LPC_ORD);
> ?0?2 ?0?2 for(i=0; i<2; i++) {
> lsp_to_lpc([i][0], [i][0], LPC_ORD);
> aks_to_M2(c2->fft_fwd_cfg, [i][0], LPC_ORD, [i], e[i], , 0, 0,
> ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 ?0?2 c2->lpc_pf, c2->bass_boost, 
> c2->beta, c2->gamma, Aw);
> apply_lpc_correction([i]);
> synthesise_one_frame(c2, [N*i], [i], Aw);
> ?0?2 ?0?2 }
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] LPCNet and Codec 2

[David Rowe]

In general yes, however I've found about 10% of speakers have problems
with LPCNet.  I'm not sure why - it's quite new technology.

- David

On 31/10/20 8:29 pm, Random wrote:
> Thanks for your reply.
> 
> No, I mean different person talking at different times.
> 
> Man, Woman, Boy, Girl, Elder??etc.
> 
> One model for all ?
> 
> 
> --?0?2Original?0?2--
> *From:* "freetel-codec2" ;
> *Date:*?0?2Sat, Oct 31, 2020 03:22 PM
> *To:*?0?2"freetel-codec2";
> *Subject:*?0?2Re: [Freetel-codec2] LPCNet and Codec 2
> 
> 
> 
> On 31/10/20 1:58 pm, Random wrote:
>> How is the effect for the Multi-Speaker case ?
> 
> Do you mean more than one person talking at once?
> 
> I haven't tried it.?0?2 However in general low bit rate speech codecs don't
> work well for more than one speaker.
> 
> - David
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 
> 
> ___
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> 


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] LPCNet and Codec 2

[David Rowe]

On 31/10/20 1:58 pm, Random wrote:
> How is the effect for the Multi-Speaker case ?

Do you mean more than one person talking at once?

I haven't tried it.  However in general low bit rate speech codecs don't
work well for more than one speaker.

- David


___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] Comments on the M17 project

[David Grove]

The possibilities are endless …

 

 

Regards 

 

 

David Grove 

david.gr...@fastmail.com.au <mailto:dave_gr...@fastmail.fm>  

+61-419-444-496

 

From: Al Beard via Freetel-codec2  
Sent: Monday, 26 October 2020 22:16
To: freetel-codec2@lists.sourceforge.net
Cc: Al Beard 
Subject: Re: [Freetel-codec2] Comments on the M17 project

 

Hi David VK2DWG, 

 

Consider a HF "hot spot". Can receive say mode 700D which uses the mode 700C 
codec.

adds the hot-spot callsign and sends to the cloud talk group HF1 and listeners 
treat it like any other

talk group except, in his radio, his radio recognises it is mode 700C data and 
de-codecs it accordingly.

Seemless.

His radio then recognises, to reply, use the same codec.

 

No need to "reinvent" the wheel.

 

In the DMR world, they do exactly the same thing except it's with encryption 
keys. They have a set, not just one.

 

Alan VK2ZIW

 

On Mon, 26 Oct 2020 13:42:52 +1100, David Grove wrote 
> Thanks Walter 
>   
> Unfortunately, as published, M17 is double the bandwidth that would be 
> feasible on Amateur HF using commonly available equipment. 
>   
> However, imagine the possibilities if the M17 protocol could be also be 
> adapted to operate on HF as well on higher RF frequencies. Perhaps with a 
> slower sample rate (say 4800) and carriers that would be compatible with 
> standard HF transceivers (eg 400, 800, 1200, 1600, 2200). My theory on symbol 
> rates and bandwidth is rusty, so happy to be corrected. 
>   
> It might be possible to receive on VHF at high quality/speed and rebroadcast 
> on HF at lower quality (of course, data rebroadcast on HF would take longer). 
> The M17 protocol could incorporate routing data to indicate what to 
> repeat/rebroadcast and where. 
>   
> Just a thought for what [UTF-8?]it’s worth. 
>   
> Comments anyone? 
> 
>   
> Regards 
>   
>   
> Dave [UTF-8?]– VK2DWG 
>   
> 
> From: walt...@k5wh.net <mailto:walt...@k5wh.net>   <mailto:walt...@k5wh.net> > 
> Sent: Monday, 26 October 2020 12:47 
> To: freetel-codec2@lists.sourceforge.net 
> <mailto:freetel-codec2@lists.sourceforge.net>  
> Subject: Re: [Freetel-codec2] Comments on the M17 project 
>   
> Here ya go Alan.  See if this can answer some if your questions on that. 
>   
> https://m17-protocol-specification.readthedocs.io/en/latest/ 
>   
> all the best.. 
> 
>   
> Walter/K5WH 
>   
> 
> From: Al Beard via Freetel-codec2  <mailto:freetel-codec2@lists.sourceforge.net> > 
> Sent: Sunday, October 25, 2020 3:27 PM 
> To: freetel-codec2@lists.sourceforge.net 
> <mailto:freetel-codec2@lists.sourceforge.net>  
> Cc: Al Beard mailto:bear...@unixservice.com.au> 
> > 
> Subject: Re: [Freetel-codec2] Comments on the M17 project 
>   
> Hi all, 
> 
>   
> 
> What about the "connection" to HF? 
> 
>   
> 
> HF where we have bandwidth restrictions hence low bit-rate codecs. 
> 
>   
> 
> That's why I asked the question: 
> 
>   
> 
> In the M17 protocol, is there a "codec specifier" ? 
> 
>   
> 
> Many more questions but one is enough. 
> 
>   
> 
> Alan VK2ZIW 
> 
>   
> 
>   
> 
> On Sun, 25 Oct 2020 10:30:17 -0500, walterh wrote 
> > Good to see you Gerhard.. 
> >   
> > I just heard last night that Doug should have his Dude Star application for 
> > Android devices released maybe as early as today, that supports M17. Like 
> > it does for all the other digital modes. 
> >   
> > I heard him using it last night and it sounded great. 
> >   
> > 
> > Lots of great work happening in just the past week. 
> >   
> > Walter/K5WH 
> >   
> > 
> > From: gerh...@oe3gbb.eu <mailto:gerh...@oe3gbb.eu>   > <mailto:gerh...@oe3gbb.eu> > 
> > Sent: Sunday, October 25, 2020 2:33 AM 
> > To: freetel-codec2@lists.sourceforge.net 
> > <mailto:freetel-codec2@lists.sourceforge.net>  
> > Subject: Re: [Freetel-codec2] Comments on the M17 project 
> >   
> > Hello Walter and all others, 
> > Very interesting project. 
> > I think a step in between could be to connect the M17-Client to a Gnu-Radio 
> > / Adalm Pluto TRX setup and use MMDVM / M17.  That would proove the audio 
> > quality best. 
> > I am goint to setup the M17-Client next days. Could also install a M17 
> > repeater at OE3XNK using LimeSDR or Pluto as soon some software is ready. 
> > Regards 
> > Gerhard OE3GBB 
> > 
> >   
> >   
> > Am 25.10.2020 02:24, schrieb walt...@k5wh.net <mailto:walt...@k5wh.net> :


> 
> > 
> > I honestly don't see how th