[EE:] PIC Data Rx Sampling + {OT:] plbht

[Activ8]

plbht: I just went through a bunch of OT subject changed headers and
some of it blows and some of it is fun.

Bad new first, right?

EE:

Basically looking for code or suggestions to receive and verify an 8
bit ID code with a PIC.

PIC12F6875 - one sending data, another waiting for ID code.
4 MHz clock
gosintas: 1 on INT pin
gosoutas: 1, and who friggin' cares?
Data rate

433.92 MHz OOK RF link

If anyone has found the Microchip code eg for the garage door opener
type thingy, I haven't, and would appreciate the link. Their code
egs aren't easy to find IME.

gotta Rx an ID code from an RF link. Redundant Txs = true; I'll have
a few chances to verify a valid ID code before the world comes to an
end.

I'll Tx a preamble (or not) followed by an ID code.

I figger if I sample at a rate that's 3x bit rate (2400 baud max)
I'll be OK. IOW 2 1's out of 3 bits sampled = 1 - that makes up for
TARFU radio link. If not, TFB. Non critical app.

The Rx has no apriory knowledge of when the ID code will be sent
except that the ID code will be proceeded by a preable frame (or
not) to syncronize the Rx. After the preamble (or lack thereof ),
an 8 bit ID code will be sent.

PIC will run at 4 MHz clock (1 MHz instruction cycle) Data Rate is
low like 2400 baud. The Rx will wake the PIC via INT pin which will
also be the data in bit. Tx is OOK & IIRC wake will indicate the
first 1 Rx'd.

****
My brain's rough guesstimate is telling me that once the preamble
syncs the Rx, there's little chance at 3 sps that 8 bits could go
out of sync. Even with a 4 MHz resonator on the PIC or 4 MHz
internal osc, calibrated.

d'y'all agree with that assumption?
****

I never did find the uChip code for the garage door opener type
thingy and no, this is not a garage door opener, but may as well be


BTW, this POS has already been budgeted for production units at <$16
USD weighted avg per unit at 1 Tx unit w/ 5 Rx units - so we can't
talk about Sears, Home Depot, etc., just algoithms, really - unless
you change the subject line, add [OT], and deal with 20,000
additional subject changes, whines, bitches, etc.

--
Best Regards,
Mike

 

[Rich Grise]

"Activ8" <reply2group@ndbbm.net> wrote in message news:1gri12esjk4l7
....

Basically looking for code or suggestions to receive and verify an 8
bit ID code with a PIC.
....
gotta Rx an ID code from an RF link. Redundant Txs = true; I'll have
a few chances to verify a valid ID code before the world comes to an
end.

I'll Tx a preamble (or not) followed by an ID code.

I figger if I sample at a rate that's 3x bit rate (2400 baud max)
I'll be OK. IOW 2 1's out of 3 bits sampled = 1 - that makes up for
TARFU radio link. If not, TFB. Non critical app.

The Rx has no apriory knowledge of when the ID code will be sent
except that the ID code will be proceeded by a preable frame (or
not) to syncronize the Rx. After the preamble (or lack thereof ),
an 8 bit ID code will be sent.

PIC will run at 4 MHz clock (1 MHz instruction cycle) Data Rate is
low like 2400 baud. The Rx will wake the PIC via INT pin which will
also be the data in bit. Tx is OOK & IIRC wake will indicate the
first 1 Rx'd.

Are you saying that you can't use a chip that has an internal UART?

If you have to bitbang it, I stumbled on this when I put "PIC
microprocessor data sheet" in http://www.google.com , without
the quotes:
http://www.elecdesign.com/Articles/ArticleID/6402/6402.html

That tells you how to send, and he does some of the timing for
you. A serial receiver shouldn't be all that hard, but I'd
sample rapidly, and continuously. At least continuously until
I get a start bit, at which point I'd start syncing.

Good Luck!
Rich

 

[Activ8]

On Sat, 29 May 2004 04:10:54 GMT, Rich Grise wrote:

"Activ8" <reply2group@ndbbm.net> wrote in message news:1gri12esjk4l7
...
Basically looking for code or suggestions to receive and verify an 8
bit ID code with a PIC.
...
gotta Rx an ID code from an RF link. Redundant Txs = true; I'll have
a few chances to verify a valid ID code before the world comes to an
end.

I'll Tx a preamble (or not) followed by an ID code.

I figger if I sample at a rate that's 3x bit rate (2400 baud max)
I'll be OK. IOW 2 1's out of 3 bits sampled = 1 - that makes up for
TARFU radio link. If not, TFB. Non critical app.

The Rx has no apriory knowledge of when the ID code will be sent
except that the ID code will be proceeded by a preable frame (or
not) to syncronize the Rx. After the preamble (or lack thereof ),
an 8 bit ID code will be sent.

PIC will run at 4 MHz clock (1 MHz instruction cycle) Data Rate is
low like 2400 baud. The Rx will wake the PIC via INT pin which will
also be the data in bit. Tx is OOK & IIRC wake will indicate the
first 1 Rx'd.

Are you saying that you can't use a chip that has an internal UART?

Well, I wanted an 8 pin job - if I overlooked one with a UART, oops.
If I rejected one with a UART, there had to be a reason. I figure
the UART is only going to spit out what it thinks it's receiving
anyway, which is subject to be corrupted by interference.

If you have to bitbang it, I stumbled on this when I put "PIC
microprocessor data sheet" in http://www.google.com , without
the quotes:
http://www.elecdesign.com/Articles/ArticleID/6402/6402.html

That tells you how to send, and he does some of the timing for
you. A serial receiver shouldn't be all that hard, but I'd
sample rapidly, and continuously. At least continuously until
I get a start bit, at which point I'd start syncing.

Good Luck!
Rich

Thanks, I'll read it over. Sone months ago, I did find the article
on using a PIC as a SS spreader. The link implied that it showed how
to implement a sliding coorelator, but the article barely covered
sending.

I figured 3 samples per bit based on an FPGA project I managed to
join toward the end a few years ago. It was receiving 32 Mbps with a
128 MHz clock and the sampling rate took care of any clock drift in
the Tx or Rx. Too bad I can't recall the state diagram of that
thing. I remember the data frame had a sync bit that was a 1 for 1.5
bits and 0 for the other half bit - data at 50% DC. Any return to
zero that wasn't expected caused the receiver to shift it's timing
state.

Now interference is another matter so maybe I'd better look at more
redundancy and even interleaving. At such a low data rate I'll have
plenty of cycles to play with.

--
Best Regards,
Mike

 

[Rich Grise]

"Activ8" <reply2group@ndbbm.net> wrote in message

On Sat, 29 May 2004 04:10:54 GMT, Rich Grise wrote:
"Activ8" <reply2group@ndbbm.net> wrote in message news:1gri12esjk4l7
...
Basically looking for code or suggestions to receive and verify an 8
bit ID code with a PIC.
...
gotta Rx an ID code from an RF link. Redundant Txs = true; I'll have
a few chances to verify a valid ID code before the world comes to an
end.

Are you saying that you can't use a chip that has an internal UART?

Well, I wanted an 8 pin job - if I overlooked one with a UART, oops.
If I rejected one with a UART, there had to be a reason. I figure
the UART is only going to spit out what it thinks it's receiving
anyway, which is subject to be corrupted by interference.

If you're saying that the individual data bits themselves might get
scrambled more than a trivial number of times, then about the only
thing I could think of is something that would maintain a strict
protocol, like a uart - set it for a parity bit, and maybe 10 data
bits, if you can, and put a couple of check bits (like a mod 4 CRC)
in with each byte, and an overal CRC or ECC or whatever that stuff
is called. ;-)

And working on making the hardware robust is also a good idea. I've
seen discrete transistors with resistors, which seemed to work OK.

Good Luck!
Rich

 

[Activ8]

On Sun, 30 May 2004 03:20:53 GMT, Rich Grise wrote:

"Activ8" <reply2group@ndbbm.net> wrote in message
On Sat, 29 May 2004 04:10:54 GMT, Rich Grise wrote:
"Activ8" <reply2group@ndbbm.net> wrote in message news:1gri12esjk4l7
...
Basically looking for code or suggestions to receive and verify an 8
bit ID code with a PIC.
...
gotta Rx an ID code from an RF link. Redundant Txs = true; I'll have
a few chances to verify a valid ID code before the world comes to an
end.

Are you saying that you can't use a chip that has an internal UART?

Well, I wanted an 8 pin job - if I overlooked one with a UART, oops.
If I rejected one with a UART, there had to be a reason. I figure
the UART is only going to spit out what it thinks it's receiving
anyway, which is subject to be corrupted by interference.

If you're saying that the individual data bits themselves might get
scrambled more than a trivial number of times, then about the only
thing I could think of is something that would maintain a strict
protocol, like a uart - set it for a parity bit, and maybe 10 data
bits, if you can, and put a couple of check bits (like a mod 4 CRC)
in with each byte, and an overal CRC or ECC or whatever that stuff
is called. ;-)

And working on making the hardware robust is also a good idea. I've
seen discrete transistors with resistors, which seemed to work OK.

Good Luck!
Rich

Well, I've coded an interleaver before. That takes care of
interference to a degree - but the whole idea of an 8 bit code is to
recognize a valid signal and not trigger on interference. If the
code gets corrupted on the way, it'll be sent again anyway, so no
biggie.

I *was* worried about the clocks getting out of sync. The "sliding
correlator" I mentioned is really something that's used to aquire
sync in the first place. *Then* you'd go to tracking. Now that I
think of it, I don't think the clocks will get so far out of sync in
the time it takes to send 8 bits that it'll matter. I'd only need
tracking code if I were sending a lot of data frames.

So it's as simple as detecting the start bit and sampling the rest
often enough to detect 8 more bits.

I got a plan now. The RF link works, so I'll just do the rest while
I sleep.
--
Best Regards,
Mike

 

[Rich Grise]

"Activ8" <reply2group@ndbbm.net> wrote in message

So it's as simple as detecting the start bit and sampling the rest
often enough to detect 8 more bits.

Pretty much, yeah. I tend to forget that not everybody's read all
the same stuff I have - I was reading about bitbanging back in the
days of 8008s. In fact, my first home computer was an 8008 - the "Scelbi
8H." For I/O, it had address LEDs, data LEDs, and 3 or 4 status LEDs,
and 8 toggle switches and 3 pushbuttons. Which weren't debounced.

But I made it play "Daisy, Daisy."

Cheers!
Rich

 

[Activ8]

On Sun, 30 May 2004 14:50:34 GMT, Rich Grise wrote:

"Activ8" <reply2group@ndbbm.net> wrote in message

So it's as simple as detecting the start bit and sampling the rest
often enough to detect 8 more bits.

Pretty much, yeah. I tend to forget that not everybody's read all
the same stuff I have - I was reading about bitbanging back in the
days of 8008s. In fact, my first home computer was an 8008 - the "Scelbi
8H." For I/O, it had address LEDs, data LEDs, and 3 or 4 status LEDs,
and 8 toggle switches and 3 pushbuttons. Which weren't debounced.

But I made it play "Daisy, Daisy."

Cheers!
Rich

I didn't need to read about it. IT's one of those things that are
intuitive to me. My head was wrappped around needing to sync and
track which we did for *long* streams.

Ferinstance, you could call my keypad routine a bit banging scheme
since it samples and debounces and all kinds of other good stuff
like check for repeats or state changes (on > off; off > on)

I do remember reading a discussion over the effects of resonators on
Tx / Rx clock sync. I don't remember the result in terms of baud
rate/frame length limits ( oh, it was UART, so that's a short frame)
WRT clock drift, but that's easy enough to figger out. I think the
fact that the discussion came up at all is more important than the
nuts and bolt, 'cause it's an additional reminder to me to check
that kinda stuff.
--
Best Regards,
Mike