Hi Rick,
I think Ben, VK6IC tested Codec 2 on windows, see this blog post:
http://www.rowetel.com/blog/?p=1473
Let me know if you need his email, his blog is listed in that post.
Cheers,
David
On Sun, 2011-10-09 at 10:20 -0400, Rick Muething wrote:
> All,
>
> I have communic
Hello Steve,
I haven't put any thought into a fixed point port yet, but it's open
source so feel free to experiment. I'd start with one fft call, and
look at the dynamic range of the signals into and out of the FFT. Then
ideally try to get very similar outputs from the fixed and float
versions f
Hi Bruce,
I think it means you need to collect 5 frames before decoding the first
1, so it means effectively a 5 frame delay.
This sort of approach is common in CELP codecs as well, that have some
information like LSPs at the frame rate (20-30ms), then the excitation
at a sub-frame rate of 5ms.
, but packet -> TCP or UDP entailed way
> too much (and too unpredicatable) overhead for me last year when I
> played around with it.
>
> 73, Bruce
> VE9QRP
>
> On Fri, Oct 28, 2011 at 12:30 AM, David Rowe wrote:
> > Hello,
> >
> > I am back develo
Re averaging of the speech information, I think we need some sort of
update every 20ms, but the amount of information varies depending on the
current speech frame.
There is a neat duality that helps us. The most perceptually important
frames that need high quality LSP quantisation (high energy vo
Hi Kristoff,
OK - so you are suggesting we could test a Codec 2 Digital Voice mode
over using DSTAR in data mode? Hmmm, interesting.
Couple of possibilities. I guess people with DSTAR radios already have
an interest in DV. So I guess anyone with a DSTAR radio and a laptop
could then start usi
Hello,
> > A good start for adding FEC to Codec 2 is to test the effect of bit
> > errors on each bit. Not all bits need protection. So strong codes can
> > be used to protect the most sensitive bits, leaving some bits
> > unprotected.
> Are there drawings or scematics of the exact bitformat of
On Tue, 2011-11-01 at 21:52 +, Trevor . wrote:
> --- On Tue, 1/11/11, ZPO wrote:
> > Should the FEC be considered part of the baseline CODEC or
> > a part of the external transport protocol?
>
> FEC is nothing to do with the CODEC it's in the transport protocol.
For low bit rate digital sp
Hi Kristoff,
> E.g. I looked in the source-code of c2enc.c and c2dec.c, but did not
> find any commands to -say- configure the bitrate of the encoder.
Only one bit rate is currently supported. Actually the work I am doing
to more efficiently encode LSPs suggests we can maintain roughly the
same
Hi Peter,
That's great work. Does the development board have audio I/O for
mic/spkr and possibly connection to a HF radio?
Perhaps we could look into a Makefile target for that platform to
automatically configure the build system and #ifdef or patch in the
changes.
Just curious - why couldn't y
.
> b)It might be nice to put parameters like FFT lengths in a
> centralized .h file.
>
> Currently, I'm using a commercial product called Rowley CrossWorks for
> ARM. It is a rich IDE based on top of gcc, so I need to work on what
> the underlying cross-compiler calls w
Hi Kristoff,
> I see that the new lower bitrate versions use differencial encoding
> ("coding frame-frame differences").
Well we could have different modes, for example:
- 40ms frames, with differential in time coding to get 1400 bps
- 20ms frames, at say 2000 bit/s
- even 10ms at some higher bi
Hello Bruce,
On Wed, 2011-11-02 at 15:58 -0700, Bruce Perens wrote:
> The entire purpose of compression is to remove redundant information. As
> David implements temporal delta coding and in general improves the
> codec, the cost (in reduction of speech quality) of losing a bit increases.
Actua
On Wed, 2011-11-02 at 16:39 -0700, Bruce Perens wrote:
> The original Turbo Code patent would expire August 29. Until then, it's
> licensed for free use by Amateurs.
IIRC really powerful codes like Turbo and LDPC require fairly big block
sizes, can anyone comment if they would work effectively on
I just posted a blog post that explains how the 1400 bit/s works:
http://www.rowetel.com/blog/?p=2255
I am currently working on a separate encoder and decoder for 1400 bit/s,
the work do date has been done with the c2sim simulation version of
Codec 2.
Thanks,
David
--
Hello Rick,
I don't have any firm ideas on SDP profiles, but I do thank you for
progressing some formats.
Several people have suggested that Codec 2 shouldn't be the final name
for the code, once again I don't have any strong feelings here. The
original name came from Bruce Peren's Codec 2 site
Hi Stuart,
I have a first pass at the API for multiple rates in the codec2-dev
branch:
https://freetel.svn.sourceforge.net/svnroot/freetel/codec2-dev/src/codec2.h
Just a mode flag in codec2_create();
Re packet loss repeating the last packet should work OK. The sinusoidal
algorithm naturally in
With Anthonys kind help I discovered that voice codecs beneath 2400
bit/s are also on a list of controlled exports for Australia. I have
contacted the government agency involved and they have said it will
probably OK but have advised me to submit a form to get an official OK.
This will take a few
Hi Stuart,
Thanks I have applied the patch to the codec2-dev branch.
Sorry I can't think of an easy way to combine two packets to increase
the speech quality.
Cheers,
David
On Mon, 2011-11-28 at 19:03 +, Stuart Marsden wrote:
> David,
>
> Attached is the patch produced with svn on linux
Hello Rick,
You covered a lot of ground there so I'll only make a few comments...
Yes I've played with quantising Wo and pitch (1/Wo) and the ideal law is
probably some where in between. At the time saving bits on Wo wasn't
significant but it probably is now.
The 2500 bit/s mode doesn't use dif
Hi Gullik,
Some of the 1400 bit/s code in codec2-dev hasn't been tested & debugged
at the bit stream level, but it should end up as 1400 bit/s. The bit
allocation for 1400 bit/s is in the blog post.
It would be great to test codec 2 with bit errors, good luck with that.
Cheers,
David
On Thu,
ortly."
So I'll get back the 1400 bit/s release work now.
Cheers,
David
On Tue, 2011-11-29 at 07:55 +1100, David Rowe wrote:
> With Anthonys kind help I discovered that voice codecs beneath 2400
> bit/s are also on a list of controlled exports for Australia. I have
> contact
ide ist necessary) and will try to change from 2500 to 1400 pbs.
>
> Gerhard OE3GBB
>
> -Ursprüngliche Nachricht-
> Von: David Rowe [mailto:da...@rowetel.com]
> Gesendet: Mittwoch, 21. Dezember 2011 02:56
> An: freetel-codec2@lists.sourceforge.net
> Betreff: Re:
Hello,
Last week I presented a paper on Codec 2 at linux.conf.au 2012. In fact
it was voted the best paper of the conference and I was asked to present
it again at the end of the conference. I put some effort into relating
Ham radio and Open source which went down well.
The video has been post
Hello List,
Today I received a letter from the Defense Export Control Office, an
office of the Australian Department of Defense. They have assessed
Codec 2 against the prohibited exports and WMD laws and found it "not
currently to be of concern", and "does not requires an export license".
This b
Hello,
Yes I have thought about such a mode "audio morse code" that will punch
through some sort of voice signal. I think the theoretical limit for
human speech is about 50 bit/s (i.e. text-speech).
The LSPs are where most of the bits are used, so you could test a low
bit rate vector quantiser.
Thanks David W. Actually it's really nice for my to take my PhD work
(that was gathering dust on a shelf), and put it to use in the real
world.
At lca.conf.au I was talking to Jean-Marc Valin about the interface
between academia and Open Source. I think that publishing source code
would help ad
Hello Peter,
Nice work, and thanks for the links to those resources.
The 1400 bit/s mode is buggy and still under development, so the bit
stream (and even bit rate) might change.
I've used Golay and Hamming codes in the past for Codec FEC. You won't
have any patent problems. I might be able t
Hello list,
Watching the discussion on wideband, I thought an example of LSPs in
action might help clarify how they work. Check out this plot:
http://www.rowetel.com/images/codec2/hts2a_lsp_47_large.png
>From this blog post:
http://www.rowetel.com/blog/?p=130
The green line is
Hi Andrew,
Good to see you are interested in Codec 2. Sure run same samples with
different background noise samples and post them here or on yr web
site.
Cheers,
David
On Tue, 2012-02-07 at 14:10 +, a.b...@surrey.ac.uk wrote:
>
> Hello David,
>
> Just found your newsletter site and web
Hello List,
I am also intrigued by the wideband possibilities for Codec 2 over
narrow HF digital radio channels. I was brainstorming this with Bruce
and Jean-Marc recently.
As Jean-Marc points out, there is some more spectral information above
4kHz. For example a few more peaks and troughs in t
Hi Bruce,
Good question.
I am not sure what's required to make very high pitched voices (such as
children) more intelligible through codecs. Having said that I know my
6 year old can be hard to understand through a mobile.
The current frequency range is adequate for all speakers I have heard
p
Thanks Steve:
> call. It is true to say the ear is not very sensitive to the precision
> with which this energy is reproduced.
Yes, that is what I meant.
- David
--
Keep Your Developer Skills Current with LearnDevNo
Hi Rick,
> What is your idea about the 12.8 kHz that I am working on? This was
> chosen to exploit the FFT to its fullest, given the current packet
> frequency. (With 16 kHz your could also achieve that at one packet per
> 20 ms, of course.)
I haven't checked out yr patch (as I am trying to sta
Hello Daniel,
Bringing non-DSP people up to speed with Codec 2 is an area I am also
interested in. Part of the Open Source/Ham ethic is to educate. The
sections in that paper on LPC, MELP, and AMBE are relevant to Codec 2.
I have also started experimenting with graphical ways to describe the
DS
Sounds good to my Rick, I am happy to help edit.
Thanks,
David
On Sat, 2012-02-11 at 21:59 +, Rick van Rein wrote:
> Hi,
>
> > I would be interested to hear what others on the list would like to hear
> > re explaining Codec 2.
>
> I think a non-DSP description of Codec2 would be a valuable
Hello list,
I have added a 1200 bit/s version to rev 318.
It's still a little experimental so I haven't popped up any samples yet.
It's based on a 24 bit/frame vector quantiser for the LSPs that
Jean-Marc developed. In this case it's not predictive, i.e. it doesn't
use frame-frame differences.
Hello List,
For those of you who can code C and would like to contribute to Codec 2,
here are some compartmentalised tasks that don't require a broad
knowledge of Codec 2 internals. They may require coming up to skill on
narrow areas.
1/ Work on 1200 bit/s VQ, see if you can improve the quality.
you won't save a huge amount of total bandwidth
over say g729.
- David
On Wed, 2012-02-15 at 07:54 -0700, Steve Strobel wrote:
> On Tue, Feb 14, 2012 at 8:49 PM, David Rowe wrote:
> >
> > 4/ Write an interleaver to re-arrange bits in a frame using a random
> > patter
Strobel wrote:
> On Tue, Feb 14, 2012 at 8:49 PM, David Rowe wrote:
> >
> > 4/ Write an interleaver to re-arrange bits in a frame using a random
> > pattern known to the encoder and decoder. Useful so that a few
> > consecutive bit errors are spread randomly over a fram
Nice work Joel and Mark good to see some Codec 2 bits floating
around my home town of Adelaide :-)
So this means you put OFDM modulation over FM? I guess that would work
OK if FM preserves the modem tones OK and the SNR is high.
I have been working on some link budget calculations which i
Hi Dan,
Yes using GNU-only options like that is fine.
Thanks,
David
On Thu, 2012-02-16 at 22:21 +, Daniel Ankers wrote:
> On 15 February 2012 03:49, David Rowe wrote:
> > Hello List,
> >
> > For those of you who can code C and would like to contribute to Codec
Hello Bruce,
> For this last point, David, can this be a one-off random pattern,
> written into the encoder/decoder code at compile time, or does it need
> to be negotiated for each connection? (I can't see why the latter
> would be needed, but I thought I'd ask.)
Lest say a one off random patter
-0800, Bruce Perens wrote:
> David,
>
> What would you do for frame synchronization? I think we can count on
> accurate timing.
>
> Thanks
>
> Bruce
>
> On 02/16/2012 12:39 PM, David Rowe wrote:
> > I have been working on some link budget calculati
:20 +, Daniel Ankers wrote:
> On 17 February 2012 00:29, David Rowe wrote:
> > Hi Dan,
> >
> > Yes using GNU-only options like that is fine.
> >
> > Thanks,
> >
> > David
> >
>
> Hi,
> Hopefully this patch will do what you need.
>
noise, you
> lose the same bits from one frame to the next. But you could
> 1. Send two frames per symbol, and only one per pair would be subject
> to the noise.
> 2. Alternate the bit distribution pattern, but then you'd have to sync
> to that.
>
> Thanks
>
>
nt above to 512 will build a 9+9+9 = 27 bit VQ
etc.
Cheers,
David
On Wed, 2012-02-15 at 14:49 +1100, David Rowe wrote:
> Hello List,
>
> For those of you who can code C and would like to contribute to Codec 2,
> here are some compartmentalised tasks that don't require a br
Along these lines if we could build/obtain USB (rather than analog sound
card) based SDR hardware, we could use low cost Android phone/tablets as
the GUI and signal processing (voice coding and OFDM modem) engines for
Codec 2 based radios.
- David
On Sat, 2012-02-18 at 22:13 +, Stuart Marsden
on the NDK, with a
> pure Java port as a back up plan.
>
> Matthew Pitts
> N8OHU
>
>
> ______
> From: David Rowe
> To: freetel-codec2@lists.sourceforge.net
> Sent: S
Yes that is a good idea Bruce. Would anyone like to take this task om?
>From rev 319 of codec2-dev there is code in the 2500,1500 & 1200 bit/s
modes to sort LSPs. If the LSPs are correctly ordered there won't be
any unstable filters in that part of the code. But it would be good to
see if any s
Hello Patrick,
Thanks for pointing those issues out, pls try rev 340.
gecb.txt is a new joint pitch-gain VQ codebook that Jean-Marc designed.
Will probably make 1000 bit/s possible using predictive techniques.
Cheers,
David
On Fri, 2012-03-02 at 10:37 +0100, Patrick Strasser wrote:
> Hello!
>
Thanks Jean-Marc for that excellent work and for documenting it on your
blog. This is a really good example of Vector Quantisation. A
2-dimensional vector can be easily visualised on an x-y axis - much
better than 10 dimensional data like the LSPs!
I ran some tests and can't hear the difference
Hello Peter, and Ronan,
> a) The Codec2 source code is under development and is, understandably,
> a moving target.
> b) The extra codebooks in the newer versions would take a lot more
> ROM, but thankfully, the STM32F4 has that. However, if the PC CPU
> utilization is any guide, the newer versio
--lsp --phase0 -o hts1a_phase0.raw
If it's the pitch estimator that is breaking then you will see it at the
very first step above (just the basic unquantised sinusoidal model).
Cheers,
David
On Mon, 2012-03-05 at 00:14 +0100, Patrick Strasser wrote:
> Am 2012-03-02 12:06, schrieb David Ro
> modulation and coding rates. At good conditions (not much fading, good
> SNR, low noise) one would use all the badwidth for the raw unprotected
> data and get high quality sound. If conditions get worse, you would
> switch to higher compression with lower speech quality and put in some
> FEC to c
ation
outputs.
Next step is to code this modem in C to get it running in real time. We
can then make a first pass at a real time PC based DV system. Anyone
like to help converting Octave to C code?
Thanks,
David
On Mon, 2012-03-05 at 18:13 +1030, David Rowe wrote:
> Hello List,
>
>
Hello,
Ed W has kindly sponsored the development of Asterisk support for Codec
2. This involved some patching of the Asterisk core, and the
development of an Asterisk codec module "codec_codec2.so".
This has some applications where header compression and trunking
multiple calls can make the band
Hello Kristoff,
I don't know of any one line resources for general DSP with Octave, but
this blog is a great resource for comms type DSP (modems etc) with many
examples written in Octave:
http://www.dsplog.com/
Cheers,
David
On Tue, 2012-04-17 at 23:00 +0200, Kristoff Bonne wrote:
>
Using coherent PSK demodulation a 1dB SNR in a 1kHz bandwidth is
possible with Codec 2 at around 1200 bit/s. A friend emailed me
recently:
"NBFM 5k dev needs about 6dB CN in a 15kHz BW to be
listenable ...
so the VHFDV should be about 12dB better."
One way an open
I'll take a look at this over the next few days
On Thu, 2012-04-26 at 07:37 +0200, Patrick Strasser wrote:
> David Rowe wrote on 2012-03-05 06:45:
> > Thanks Patrick I checked in your patch. Yes I was experimenting with 30
> > bit VQ codebooks recently, which i
+1000, David Rowe wrote:
> I'll take a look at this over the next few days
>
> On Thu, 2012-04-26 at 07:37 +0200, Patrick Strasser wrote:
> > David Rowe wrote on 2012-03-05 06:45:
> > > Thanks Patrick I checked in your patch. Yes I was experimenting with 30
> >
Thank you all for the burst of creativity, I am happy to follow the
group decision.
- David
On Sat, 2012-04-28 at 00:18 +0200, Gullik Webjörn wrote:
> +1
>
> On Fri, 2012-04-27 at 21:52 +, Rick van Rein wrote:
> > Ah!
> >
> > > Free speech deserves a free codec
> >
> > +1
> >
> > The best
Hi Guys,
Wow a lot of traffic on the list when I woke up today, that's great to
see :-)
A few months ago I figured we needed to get Codec 2 on the air.
Anthony as you suggest HF Digital voice running on a PC with a SSB
transceiver is the sweet spot for any new DV system.
This requires a HF modem
Hello,
Here is a blog post on some recent testing of the FDMDV modem:
http://www.rowetel.com/blog/?p=2433
Thanks,
David
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's
Hello,
I have added a FDMDV modem page to my web site:
http://www.rowetel.com/blog/?page_id=2458
plus typed up a README_fdmdv that explains all the files and how to use
them.
This modem was "lost" a few years ago as the initial implementation was
closed source. So I felt compe
Good work Bruce. The audio 925 mile path was with known test data (so I
could calculate the bit error rate at the rx). Hmm, but it might be
possible to extract the bit error pattern and apply that to Codec 2
data.
- David
On Tue, 2012-05-08 at 23:30 -0700, Bruce Perens wrote:
> I've put codec2.
Yes I need to (re) implement a 1400 bps version of Codec 2. I'll do
something about that over the next few days.
Cheers,
David
On Wed, 2012-05-09 at 11:00 +0100, Peter wrote:
> On 7 May 2012 02:17, David Rowe wrote:
> > Next step is to tweak Codec 2 to make it interface cleanl
Hello Phil,
> ./fdmdv_demod Codec2TT-MOD.raw data.bin Codec2TT-DEMOD.c2
>
> I was playing with the modem yesterday and the demodulated data went to
> the second output file. Not sure what data.bin is - maybe statistics?
david@bear:~/codec2-dev/src$ ./fdmdv_demod
usage: ./fdmdv_demod InputModem
Hello Peter,
Hmm, you may have uncovered a bug. We shouldn't be getting a segfault,
even when the decoder is fed random data due to the bit rate being
incorrect. Probably a look up table being overrun.
Can u pls email me your Codec2TT-DEMOD.c2? I'll track it down.
Thanks,
David
On Wed, 20
2012-05-09 at 11:44 -0400, si...@mungewell.org wrote:
> > On 7 May 2012 02:17, David Rowe wrote:
> >> Next step is to tweak Codec 2 to make it interface cleanly to the modem
> >> for some initial on-air tests.
> >
> > Ah damn, this is what I missed. Hence why
v has the fix.
BTW with the I note that with the compressed file at the wrong rate the
audio sounds like gibberish but isn't (physically) painful to listen to
- some codecs can hurt your ear with bit errors!
Cheers,
David
On Wed, 2012-05-09 at 21:13 +0930, David Rowe wrote:
> Hello Pe
At the end of:
https://freetel.svn.sourceforge.net/svnroot/freetel/codec2-dev/README_fdmdv.txt
there are list of TODOs. Some of these are not too hard (e.g. write a
function that returns a line of waterfall display - essentially a FFT),
or calculate the SNR of the receiver signal, or test the mo
Hi Bruce,
Good idea to bring this topic back on-list.
I have a couple of other comments:
1/ The current PAPR is for a canned test sequence of bits that repeats
itself every 80ms, not sure what it will be when the modem is driven by
codec data.
2/ FDMDV is designed for SSB radios, I don't think
Hello,
In rev 416 I have a working 1400 bit/s mode. Thanks Jean-Marc, I took
yr joint pitch-energy quantiser and combined it with the 36 bit/s LSP
quantiser.
After fixing a reversed sync bit in the modem we can now do end-end
speech over the modem:
david@bear:~/codec2-dev/src$ ./c2enc 1400 ../r
Hi Bruce,
On Thu, 2012-05-10 at 18:51 -0700, Bruce Perens wrote:
> On 05/10/2012 06:36 PM, David Rowe wrote:
> > At VHF it's probably OK to use a single tone (single carrier) PSK modem.
> OK. Currently I compare our FDMDV to FM, D-STAR, and DMR/TRBO in
> marketing litera
real channels and working out how to make it
more robust.
Cheers,
David
On Fri, 2012-05-11 at 09:51 +0100, Peter wrote:
> On 11 May 2012 05:24, David Rowe wrote:
> > If anyone decided to try this over the air pls convert the modulated
> > signal sample rate to 48kHz. Sox should be ab
Hello Bruce & List,
Some ideas of what a significant improvement over incumbent (analog and
1st gen DV) modes might be:
+ 6-12dB improvement in SNR for equivalent voice quality
+ half or a quarter of the RF BW
+ available in a $100 open hw/open sw box that sits between the Mic/Spkr
of any FM (VHF
Hi Guys,
Just wanted to point out that the current codec-modem system hasn't been
tuned for real HF channels yet, for example you will get R2D2 noises if
the modem can't find the signal or during fades. However it's a good
starting point and should work OK on good SNR channels.
I would be intere
Thanks Peter, rx_fdm_log[] is now malloc-ed from the heaps instead of
being allocated from the stack, and I added the fprintf line as well to
rev 454. Perhaps Windows has different stack limitations to Linux.
Cheers,
David
made On Sun, 2012-05-13 at 16:54 +0100, Peter wrote:
> On 13 May 2012 16
Nice work Stuart, very cool what can be done with pipes.
The mod & demod have filter memories that need to fill, and the
frequency and time acquisition takes a few symbols to acquire. This can
probably be improved a little. The modem was designed to sync up
quickly.
Cheers,
David
On Tue, 20
Hi Sergiy,
Thanks for pointing out the rather large memory requirements for the
FDMDV modem states.
Yes it is possible to significantly reduce the size of these arrays. I
don't have time to do this right now but if some one else would like to
work on this here are a few notes:
1/ tx_filter_memo
Hello Michael,
On one of the Codec 2 blog posts (I think the 1400 bit/s one from Nov
2011) some one ran the Codec thru an objective measure tool to get some
pseudo MOS scores.
Subjective testing could be crowd sourced on the web. Neat little
project if you are interested. Paired comparison test
;m creating a list of speakers at http://codec2.org/speakers David Rowe, I
> took the liberty of listing you, please correct your information as necessary.
> I listed myself.
> Mel Whitten, want to be o
Hello,
If it helps the FDMDV demod can sync up with up to +/- 200Hz frequency
offset at present. Its probably possible to make this several kHz if
reqd. After that a few Hz/s drift is no problem, so a LC oscillator
would be OK :-)
If the analog channelization is wider, it would be possible to "f
Yes these are my thoughts also Gullik.
Thanks you for your kind offer Rick. To the list - Rick has been very
helpful in mentoring me on HF modem technology over the last few months
- thanks Rick.
I should point out that Dave Witten is doing some fine work on a cross
platform Windows/Linux implem
Hello Rick,
Thanks for your explanation of using Direct X. I am curious about the
many methods of sound I/O available under Windows - could you please
tell us why the simpler wave type interface would be unsuitable, e.g.
waveInPrepareHeader/waveOutOpen etc.
Thanks,
David
On Sun, 2012-05-20 at
Hi Rick,
Yes now we have a modem running it would be good to try alternatives
like TCM. Hopefully it won't affect other parts of the modem much like
frequency offset or timing estimation.
Can u pls point me some TCM functions for that map roughly to the
fdmdv.c bits_to_dqpsk_symbols() & qpsk_to
Hi James,
The need for just such a box has been discussed at the Hamvention, and
we also dreamed up the microphone form factor. It would need a patch
cable or jumper system to interface with the various mic/spkr and PTT
standards.
Inside we would need some sort of 32 bit processor, but perhaps n
Hello Kristoff,
Hmmm, I can see how inverting audio would be a trap when driving a FM
system - it would deviate the wrong way.
Couple of questions:
1/ What other parameters is GMSK sensitive to, for example how about the
mapping of sound card audio levels to FM deviation,, of HP/LP filtering
o
nter to make one for you. (almost any hackerspace has
> these things thesedays!!!)
>
>
> So, instead of looking for "what processor to use". I would prefer to
> look for "what ready to use and already available board can be used
> for this?"
>
>
>
>
Hello,
I have just checked in some updates to the code that implements the
various bit rates. The rates are now a more standard 2400/1400/1200 and
1200 has been improved a little bit by using a 27 bit VQ.
I have updated 2400/1400/1200 the samples on the Codec 2 web site to
match the latest code
Hi Kristoff,
Perhaps as a first step a modem suitable for VHF that can be piped to
Codec 2 like the fdmdv:
./c2enc 2400 ../raw/hts1a.raw - | ./gmsk_mod - - | ./gmsk_demod - -
| ./c2dec 2400 - - | play -t raw -r 8000 -s -2 -
Interleaving and FEC can also be implemented this way for
experimentatio
Hello list,
Couple of thoughts here:
1/ It's possible to work out the symbol rate with a little DSP, for
example there is often a spectral line in the FFT of the modem signal at
the symbol rate. We use this in FDMDV to work out the symbol timing.
So we could look at the baseband modem signal and
Hello Kristoff,
> Concerning your example above: is there actually is a header in front of
> the raw codec2 file format? How can the encoder know the baudrate of a
> codec2 stream that is in a .c2 file?
> (for raw audio, I assume it to be 48000 Khz 16bit PCM, I hope that is OK?)
No it's just ra
I am not actually suggesting we use this, I just felt like looking
into the idea :-)
Cheers,
David
On Thu, 2012-05-24 at 16:16 +0100, Peter wrote:
> On 24 May 2012 15:32, David Rowe wrote:
>
> 2/ Yes the sync pattern is often called a unique word. I hav
Hi Kristoff,
> Do keep in mind that it does make sence to have a header in front.
> Certain information -like callsigns- are actually used to some device to
> make descisions on it.
> E.g. a repeater does routing based on information in the header. A radio
> can decide to open the squelch or no
Hi Bruce,
How will you handle Codec 2 frame sync? At 1200 bit/s it comes in 48 bit
packets.
- David
On Sat, 2012-05-26 at 08:55 -0700, Bruce Perens wrote:
> As discussed a few times previously, we can probably get Codec2 in 1200
> Baud mode to work on a 1200 Baud TNC in KISS mode, meaning witho
Hello Gullik,
Yes that is correct, fdmdv_mod() outputs a complex tx signal that could
be used to drive a complex up-converter. The main reason was a complex
output makes it easy to simulate small frequency offsets when I am
testing.
Cheers,
David
On Sun, 2012-05-27 at 22:19 +0200, Gullik Webjö
Hello,
I haven't tested it but I think 10-12 bits would be fine. The modem is
designed to handle SNRs of 5dB which is about the SNR from a 2-bit ADC
(1 sign bit and 1 magnitude bit).
However to test this properly you could simulate the quantisation to 10
or 12 bits between the mod and demod and
Hello Hisaharu,
there is one possible problem.
I have recently removed the 2500 bit/s mode and now have a 2400 bit/s
mode. However the Asterisk code was written for 2500 bit/s so may be
broken. I don't have access to two Linux machines at the moment so
can't test this.
I'll look into it later
1 - 100 of 1124 matches
Mail list logo
