Searching \ for '[PIC]:RF transmission' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=rf
Search entire site for: 'RF transmission'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:RF transmission'
2002\05\20@162216 by Luc Bolly

picon face
Hello all

I'm a newcomer in this list. I'm discovering the PIC world (more specifically PIC 16Fxxx) since a few weeks. Until now, I've found all the answers either by my own experience or by looking in the Internet. But here, I'm blocked. So if someone can help ...

Description

I have two PICs (16F877 and 16F628) that must communicate. I use the integrated USART on both sides and everything works great if I cross-connect TX and RX lines between each PIC. In software, I use an interrupt (Timer 1 every 50 or 60 or ... ms) to send the data at my pace (2400 bps or 4800 bps). I use another interrupt on the other side (RCIE) and that's it. Not even implemented a buffer as each transfer is completed before next data is sent.

The problem

Once connected via a cable, it does work. But my goal is to replace the cable via a RF system. I'm not that good in electronic (mostly a system programmer), but I work with a friend who is supposed to be good. We are using transmitter and receiver from AUREL (we also tried another brand). The signaling is correct up to the transmitter, but after, we only saw "bzzz bzzzz bzzz" - nothing usable.

The question

Is there some special technics to be used with RF ? Does some of you have any idea about my problem ? Do I need to add some hardware excepted the transmitter and receiver (and the antenna of course) ?

Thanks for any help.

Luc Bolly

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\20@164929 by Sid Weaver

picon face
For lbolly

Most transmitters and receivers run all the time when turned on.  The
transmitter will modulate a signal when a signal is applied to its input pin,
otherwise only the carrier is being generated.

The first thing you have to do is disable one transmitter when its associated
receiver is receiving signals.  The receiver associated with the sending
transsmitter will also have to be disabled, other wise it will get spurious
data from its own transmitter.

This is easily accomplished by tying the ground sie of the transmitter power
to the collector of a 2N2222.  When the transistor is low, i.e., its base
low, the transsmitter if off.  By using one of your spare pins to take the
base high, the transistor will turn on, the collector will go to exxentially
ground and the transmitter will be active.  Same for the receiver.

That should be your first step.

I presume the data is sent by the transmitter via serout2, then received by
the receiver via serin2 using "str serstring\# of bytes" to receive and store
the data.  In case you don't know, which you probably do,  serstring must be
declared as:

serstring var byte(#of bytes)

Sid Weaver
W4EKQ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\05\20@183632 by Rick C.

flavicon
face
Whether you use RF or audio coupling to communicate, you will most likely be using an audio carrier to modulate the transmitter. A mark and space will be your "zero" or "one". Using Bell 212 tones will make it easier to troubleshoot because you can use a simple computer modem to test the modem circuits. You could either use a phone modem or design your own modulator/demodulator using EXAR, MOTOROLA, or Signetics chips, the latter probably more
trouble than its worth unless this is just a one-of-a-kind project.
Rick

Luc Bolly wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\05\20@225745 by Herbert Graf

flavicon
face
Quite a few RF modules out there require a waveform that goes "back and
forth" alot to keep the receiver properly locked. Try sending a string of
0x55 and 0xAA on the line before sending your "real" data, this should help
the receiver lock on properly. TTYL

> {Original Message removed}

2002\05\21@030848 by Mircea Chiriciuc

flavicon
face
I have donne a voting system with 50 remotes and a master. In that system I
used bidirectional RF transmission at aprox 4600 baud. The RF modules I have
used where BiM2-433 transciever modules from RADIOMETRIX
(http://www.radiometrix.com). This modules have
included a data shaper to get the audio received shaped to square wave and
it works great, CD (carrier detect) pin which tells you when you are in RX
mode if the transmitter it's on or off (used that to trigger the RX
interrupt). Transmitter and receiver can't be at the same time on and that
spares you a lot of extra components to use and it can be put in low power
mode where it uses a few uA. The bad news for you should be that it is not
recommended to use the USART for transmitting on RF because of the asimetry
af the data. (a 0 byte will be 0V on the transmitters input for 8time slots
and a 255byte will be 5V for 8time slots) and that causes the data shaper to
decalibrate and that will increase the error rate a lot. The best way to do
this is to write your own send and receive routines and use a simetrical
data encoding like manchester, where a 1bit is a 10 transition on a time
slot and a 0 is a 01 transisiton on a time slot so a 0byte will be
0101010101010101 and that is simetrical enough.
You also have to calibrate tha data shaper at the begining of the
tranmission by sending a burst of 0101010101010. You can use an osciloscope
on the receiver and trigger the spot by CD to see when the data is stabile
so you can determine the burst length accordingly to the modules you use.

Happy codding,
Mircea Chiriciuc
EMCO INVEST
EraseMEsaschaspam_OUTspamTakeThisOuTgo.ro


{Original Message removed}

2002\05\21@054219 by Andrei B.

picon face
--- Mircea Chiriciuc <saschaspamspam_OUTGO.RO> wrote:
> The bad news for you should be that it
> is not
> recommended to use the USART for transmitting on RF because of the
> asimetry
> af the data. (a 0 byte will be 0V on the transmitters input for 8time
> slots
> and a 255byte will be 5V for 8time slots) and that causes the data
> shaper to
> decalibrate and that will increase the error rate a lot.

Keeping the RS323 serial routines, one could do something else: (an
additional IC is acceptable)

Use the serial-to-IR transceiver TOIM3232 or TOIM4232 from Vishay
Telefunken.

It converts the serial data into pulses adequate for IR transmission,
and it should also be adequate for RF.



=====
ing. Andrei Boros
Centrul pt. Tehnologia Informatiei
Societatea Romana de Radiodifuziune

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

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


2002\05\21@060615 by Mircea Chiriciuc

flavicon
face
It is a good idea. There are also other IC's to convert RS232 to FSK
modulation. One of them is made from RADIOMETRIX for this purpose only and
it's a very powerful one, with receive and transit buffer and meny other
great features, but in my project dimensions and cost were the main factors
for my choice. Writting code is cheaper and smaller than those IC's.

Mircea Chiriciuc
EMCO INVEST

{Original Message removed}

2002\05\21@075438 by Olin Lathrop

face picon face
>>
Is there some special technics to be used with RF ? Does some of you have
any idea about my problem ? Do I need to add some hardware excepted the
transmitter and receiver (and the antenna of course) ?
<<

It depends on how the bit signal is being encoded to RF.  If it's just 100%
modulated AM, then the receiver has to discover the mid level between a 1
and a 0.  This is usually handled by sending in packets, with each packet
having a preamble with overall 50% 1s and 0s so the receiver AGC can settle
before the packet payload is sent.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\05\23@065600 by Luc Bolly

picon face
Hello all,

Thank you all for your informations. I will do a first test with a
software solution and a manchester encoding. It seems to be quite easy
to implement and it is costless. The only drawback is that both PICs are
busy during the synchro + transmission.

If someone still have an idea, don't hesitate (take this into account:
I'm using ASM (MPLAB) to program the PICs, the transmission is AM
modulated in 433 KHz).

The thing I don't understand is that the two components are sold
together and the receiver has a "digital" output. In my (too simple)
point of view, this was a complete way of sending data across the air
without coding anything. But I just receive a square wave (the carrier).

Luc Bolly

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\23@102752 by Tal Dayan

flavicon
face
A question regarding Manchester encoding since it was mentioned and we are
currently
implementing it.

In Manchester encoding, '0' are transmitted as two periods of T with a
transition between them and '1' are transmitted as one period of 2T (and of
course a transition between the bits).

Is there any advantage for Manchester encoding compared to an a similar
encoding where '0' are transmitted as only a single T period ? That is, '1'
are transmitted as 2T period, '0' as a single T period and the transition
are only between the bits, never in the middle of a bit ?

Looks like the second encoding is easier to implement, uses the same
bandwidth, faster in most cases and allow the same accuracy of clock
extraction/tracking.

Thanks,

Tal

> {Original Message removed}

2002\05\23@111928 by Mircea Chiriciuc

flavicon
face
If I got it right you want to do something like 010=LHHL where L=1T low and
H=1T high? Instead of  LHHLLH that would be manchester?
If so, the difference comes when you want to send 0000000 or 111111.
That woul be in manchester HLHLHLHLHLHLHL or LHLHLHLHLHLH, and in the
"similar" encoding LLLLLLLLLLLL or HHHHHHHHH. Ad this sould create a problem
for the digital output of your receiever. The dat shaper for the sqare wave
output is couple in series with a capacitor. If the voltage is constant L or
H will charge tha capacitor and after a while depends on capacitors value
the square comes back the L. And the next high state of the square wave will
be shorter than emmitted and you have a problem with that byte. Use
manchester. Send a preamble of 1ms of 1010101010 then the byte. Then a start
bit 01. Then the byte. Then a stop bit 01. So you can alway resinc for the
each byte on the start bit. That will do event at high bauds.

Receive goes licke this:

If you have carrier then
1. wait for let's say 5 transitions from L to H of the preamble
then look for the double 00 timeslot (first from the preamble and the
second from the start bit)
2. after the start's bit up transition wait 1/4 of timeslot (half of the up
transition)
3. from here sample eight times at full timeslot to aquire the 8 bits of the
transmitted byte
4. wait for the stop bit's down transition
5. wait a 1/2 timeslot and goto 2 te receive as many byte you have in a
packet

Hope it helped,

Mircea Chiriciuc
EMCO INVEST


When yes
----- Original Message -----
From: "Tal Dayan" <RemoveMEtalTakeThisOuTspamZAPTA.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Thursday, May 23, 2002 5:26 PM
Subject: Re: [PIC]:RF transmission


> A question regarding Manchester encoding since it was mentioned and we are
> currently
> implementing it.
>
> In Manchester encoding, '0' are transmitted as two periods of T with a
> transition between them and '1' are transmitted as one period of 2T (and
of
> course a transition between the bits).
>
> Is there any advantage for Manchester encoding compared to an a similar
> encoding where '0' are transmitted as only a single T period ? That is,
'1'
{Quote hidden}

> > {Original Message removed}

2002\05\23@120404 by Eisermann, Phil [Ridg/CO]

flavicon
face
Mircea wrote:

> -----Original Message-----

[snip]

{Quote hidden}

The purpose of manchester and differential manchester is two-fold: One,
prevent baseline wander. Second is to provide a way for the receiver to sync
to the sender's clock (by forcing a transition in the middle of a bit).

By sampling at fixed intervals, you defeat the second purpose. clocks can
drift and/or run at different speeds. For long packets, you could very well
incorrectly decode the data. It makes more sense to sample the data and
record the time between transitions. After you sync with the preamble and
the start bit, the receiver is at a known place in the data stream. For each
transition, you know the direction and time interval. Then you can figure
out what bit was sent in spite of minor clock variations.

Perhaps I'm overly complicating the issue?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\05\23@161608 by Tal (Zapta)

flavicon
face
> If I got it right you want to do something like 010=LHHL where
> L=1T low and
> H=1T high? Instead of  LHHLLH that would be manchester?

Using your notation (and spaces to separate between bits), 110010 will look
like:

hh ll h l hh l
1  1  0 0 1  1

000000 will look like

 h l h l h l
 0 0 0 0 0 0

111111 will look like

 hh ll hh ll hh ll
 1  1  1  1  1  1

As you can see, the clock can always be recovered, the transmission time is
statistically shorter and the bandwidth is about the same.

Also, I think it is easier to encode/decode this encoding using a PIC then
Manchester encoding.

Does this make sense

Tal

> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...