Searching \ for '[PIC]: CSVD on PIC = YES!!' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'CSVD on PIC = YES!!'.

Exact match. Not showing close matches.
'[PIC]: CSVD on PIC = YES!!'
2001\12\12@053000 by

Russell McMahon wrote:
{Quote hidden}

Russell, pretty clever stuff, and you could do a
very simple version of this, suitable for a PIC.
I don't know if someone has tried this way or not.

With hardware just run the PIC output into a RC
filter (integrator) so the bitstream makes the
analogue sound waveform.

Assuming constant time period per bit (010101010101
= 2.5v out) etc, the PIC side to decode it is
incredibly simple.

ENCODING is pretty easy, since the spec of the RC
filter is known, the encoding computer can
simply run one calc per bit (per step) and see if
the RC filter has exceeded (or has not) the analogue
goal voltage (at the capacitor) for that step.
One simple calc per step for a known timer period,
from either 5v or 0v into a known RC filter with a
known (last) voltage on C. Encoding should be very
quick and easy, no complex math needed!

What you suggested above is adding a type of data
compression to the bitstream. What about another way,
which would be easy to do on a PIC and would NOT
require any additional math in the encoder:
If you get too many "1"s in sequence (or obviously
too many "0"s) replace it with a compressed data unit.
The system you choose can be refined to be something
VERY easy to implement on the PIC in real time.

Hope these make sense:
Bitstream.              Period actually generated.
1                       1
11                      2
111                     3
1111                    4

(next we add a 4-bit compression code)
11111 xxxxxxxx  5 to 260 (see below:)
11111 00000000        5 = 5 +0
11111 00000001        6 = 5 +1
11111 00000010        7 = 5 +2 (etc)
keeps going:
11111 11111110        259 = 5 +254
11111 11111111        260 = 5 +255

* any period 5 to 260 takes 13 bits.
Average data compression rate:
(260-(5.5x2))=249 num samples
(249/2)/13= 9.6   roughly???

So you can generate any EXACT period up to 260
length with never more than 13bits. Then keep
going as normal from there. This has the advantage
that the "bit" period to the RC filter remains
constant, so in software we just do the output
on an even beat like an interrupt. It never needs
a look ahead buffer in decoding.
-Roman

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

The only issue with compression then is the encoding delay introduced -
each 1 in a series would come twice as late as the last one.

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

>
> The only issue with compression then is the encoding delay introduced -
> each 1 in a series would come twice as late as the last one.
>
>
> >
> >So you can generate any EXACT period up to 260
> >length with never more than 13bits. Then keep
> >going as normal from there. This has the advantage
> >that the "bit" period to the RC filter remains
> >constant, so in software we just do the output
> >on an even beat like an interrupt. It never needs
> >a look ahead buffer in decoding.
> >-Roman

Hi, are you talking an ENCODING delay?
Encoding just generates the bitstream using the
RC filter model vs the desired analogue waveform,
then the encoder does the simple RLE compression
system in one pass. No encoding problems.
Depending on the simplicity of your RC filter
model you might even get an encoder on a PIC,
it only requires one calc per incoming "bit"
sample.

DECODING is by one bit per PIC interrupt
(for instance) and if the PIC gets 5 consecutive
"1" or "0" bits, it sets a specified period
based on the value of the next 8 bits, giving
ACCURATE periods from 5 to 260 bits.
Since the bitstream data is loaded as bytes
you only need the current byte you are decoding
I suppose that is a lookahead buffer but
a very easy one. That way you always have the
"next" 8 bits handy if you detect a compression
command.

It's late here, does that make sense?
-Roman

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

I just had an idea for an even simpler RLE
compression algorithm. I got the idea from the
old .PCX RLE system, which were good for
compressing 1bit data (b/w images) doing
one funcion for each data byte.

ENCODING:
* if bitstream data has no long strings
just save 7 bits:
First bit is a flag that shows
data is 7 separate bits (x=0).
incoming:  111010110110
stored:   x1110101
* if bitstream is for this byte is all
"1"s or "0"s, this is a run, so tally the
total length from here until the run ends.
Then express the remainder of the run as
a 7bit length.
First bit flag is (x=1) showing the other
7 bits are a run-length code.
incoming: 111111111111 -> continues to 41 places
stored:   x010 1001     (binary for length=41)
The bit type, a "1" or "0" is determined
from the last bit of the previous byte,
so it will compress runs from 9 onwards,
depending on where the run crosses the byte
boundary.

This compression system is VERY simple to encode
or decode, one simple calc per 8 bits.
A PIC could definitely encode high quality
audio bitstream in real time.
-Roman

Roman Black wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

The problems with this RLE encoding thing are:

1: CVSD type data generally does not have long runs of zeros or ones in it
because of its very definition: the step size is quickly increased to the
point where it catches up and goes the other way (ie: the bit polarity
flips).

2: CVSD is a constant-bit-rate scheme. This can be very important when
transmitting over a serial link (like radio). This RLE scheme is not
constant bit-rate.

3: CVSD is rather resilient to bit errors in the transmission path. Again
this would greatly confuse the RLE stuff.

Bob Ammerman
RAm Systems

{Original Message removed}
Bob Ammerman wrote:
>
> The problems with this RLE encoding thing are:
>
> 1: CVSD type data generally does not have long runs of zeros or ones in it
> because of its very definition: the step size is quickly increased to the
> point where it catches up and goes the other way (ie: the bit polarity
> flips).

Actually I suggested using RLE instead of CVSD,
as a RLE system tuned to a byte-sized data unit
is probably more suited to the minimal PIC approach.

I'm sure you could get 2:1 with the right RLE
system. At the 32kbit/sec rate you suggested
and with 2:1 RLE compression you get good voice
for only 2kbyte per second. That's 3.5 seconds
to 7 seconds of voice on a 16F876. Plenty enough
for many applications of products for the
visually impaired.

> 2: CVSD is a constant-bit-rate scheme. This can be very important when
> transmitting over a serial link (like radio). This RLE scheme is not
> constant bit-rate.

You said CVSD bits change in size. That can't
be a constant bitrate. ??
>Whats makes it 'Variable' is that the step size is increased whenever
the
>the transmitter finds itself sending a sequence of more than a couple
of
>consecutive zeros (or ones),

> 3: CVSD is rather resilient to bit errors in the transmission path. Again
> this would greatly confuse the RLE stuff.

Sure, but if the goal is a simple bitstream
player on a PIC, then RLE decodes very quickly
and minimum PIC instructions. I think it's worth
looking at all simple compression systems
that work that easily.

You could do STEREO 152kbit/sec audio on a
20MHz PIC which gives 32 instructions per 2 bits,
output it on 2 I/O pins into RC filters...
There's time in there for the 32inst timing loop,
every 8 timing loops.
Isn't that approaching CD audio sound quality?
-Roman

--