Searching \ for '[PIC]: Would anyone understand...?' 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/devices.htm?key=pic
Search entire site for: 'Would anyone understand...?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Would anyone understand...?'
2001\03\20@191719 by Jose S. Samonte Jr.

picon face
Good day to you sir. I'm a college student from the
Philippines.
Sir, please help me,'coz I'm really running out of time. =(
I am a complete beginner in PIC programming, and
I was tasked to do a wireless link between PICs(in MPASM/assembly
language),
in which data is transmitted, and the received data is
displayed in an LCD and PC serial port.
Would you help me sir? Your support would
really help me finish my studies.
Sir, would you accept a PIC programmer as a payment
for software services? I have a PGM16N which I got as a
donation from a friend, because I'm just a poor college student.
But I'm willing to give it up just for me to be able to finish my
studies. I've tried everything but I really can't do the wireless link.
It is really too hard for me. I know that someone out there would hear me
out. It's just that I'm really running out of time.
I'm appealing to everybody's understanding.
Would you help me? I really need your help.
Please don't let me fall.
Thank you very much sir and God Bless.
Best regards.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\20@193701 by Alice Campbell

flavicon
face
If RF is too hard, try infrared.  you can use a lens at the
reciever to extend the range.  Use a simple on/off blinker to
send plain ascii at a baudrate you choose.  A phototransistor
or pin diode, amplified with an opamp,  will make a good
reciever.  After all, infrared is just a little faster than
microwave.


alice

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\20@205326 by Petra Weeks

flavicon
picon face
Hi Jose
Still at it then, OK here's some clues, but like we have told you before, we
are not going to do your work for you.
So here goes:
Take a look for info on Holtek's  HT-12E & HT12D
The  HT-12E  can take four bits of data, ie 0x00 - 0x0F, and produces a
seriel bit stream + pre-set address.
This can be fed directly to a RF transmitter.
The HT12D takes the output from an RF receiver and if the address matches it
produces the 4 bits of data on
the four data output pins.

Admittedly this we only give you  limited functionality, but its very
simple, especially if you use a key board for input ( hexadecimal ).
As for the serial PC link, there is plenty of information at microchip.com
Have a look for   AN555  Software implementation of Asynchronous Serial I/O
and for the LCD  AN587  Interfacing to an LCD Module.

OK Jose,
take care, and good luck.

Petra Weeks (Ms)

{Original Message removed}

2001\03\20@214153 by Jose S. Samonte Jr.

picon face
Hello!

It's the problem I have. I got none of the Holtek's encoder and decoder.
All I have are samples of radio modules from Radiometrix.

Please help me anyone. I know that someone would understand me.
Thank you so much.
Best regards.


Petra Weeks <spam_OUTpetraTakeThisOuTspamWEEKS20.FREESERVE.CO.UK> wrote:
Hi Jose
Still at it then, OK here's some clues, but like we have told you before, we
are not going to do your work for you.
So here goes:
Take a look for info on Holtek's  HT-12E & HT12D
The  HT-12E  can take four bits of data, ie 0x00 - 0x0F, and produces a
seriel bit stream + pre-set address.
This can be fed directly to a RF transmitter.
The HT12D takes the output from an RF receiver and if the address matches it
produces the 4 bits of data on
the four data output pins.

Admittedly this we only give you  limited functionality, but its very
simple, especially if you use a key board for input ( hexadecimal ).
As for the serial PC link, there is plenty of information at microchip.com
Have a look for   AN555  Software implementation of Asynchronous Serial I/O
and for the LCD  AN587  Interfacing to an LCD Module.

OK Jose,
take care, and good luck.

Petra Weeks (Ms)

{Original Message removed}

2001\03\20@221117 by David Huisman

flavicon
face
Jose,

I am having difficulty understanding why you don't have enough information
to complete the project.

Aside from previous documentation I have forwarded to you, the Radiometrix
site http://www.radiometrix.co.uk/products/bimsheet.htm has ample
information regarding the use of their devices.

If someone else supplies you finished assembly code, what is it that you
have contributed to the project or learnt for your study ?
The object of the exercise is surely your learning and the way I see it,
hands on trial and error is an excellent way of obtaining that. I personally
have learnt far more from my failures than successes.

It may be beneficial to split the project and first learn how to write code
for the controller and then learn what the hardware must do to support
communications. It sounds as though a simpler initial project would help you
grasp the fundamentals.

I encourage you to persist in acquiring your understanding of the principles
rather than pleading for a quick fix.

This is not meant to be harsh or over critical in any way, just realistic
and I hope beneficial to you.

Regards

David Huisman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\21@010903 by Jinx

face picon face
I've built many of Harry Lythall's devices over the years for
both voice and data. Never a problem

http://sm0vpo.8m.com/index.htm

A great site, lots of freely-given information that you can use
to learn and build

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


2001\03\21@033950 by Jose S. Samonte Jr.

picon face
But my professor is not like that sir Roman.
A not-fully completed project is good as failed.


I hope someone out there would understand me,please?


Roman Black <fastvidspamKILLspamEZY.NET.AU> wrote:
Jose S. Samonte Jr. wrote:
>
> No sir Vasile.
> My life wouldn't go on if I'm not able to do this project.
> I would fail my studies if I'm not able to do this. Then
> I wouldn't be able to study for a year because my parents wouldn't
> be able to send me anymore to school, that's why I really want to graduate,
so
> I would be able to work, and help my parents.
>
> I hope that anyone would still understand me...


We understand you Jose. :o)

But paying someone to do your work is not good.
If you can't do the work you should not get the degree.
That is not fair to the rest of the people who
worked hard for their degrees. It is like paying
your teacher to pass you, even if you can't do the
work.

OK, we would all like you to pass. What you could
do is work hard on the parts of your project that
you can do. Like the LCD interface, etc. If you do
a good job on these parts, and it shows the teacher
that you have learned a lot and worked hard, you
should still pass the subject with the good parts
even though the RF part does not work.

The teacher needs to see that you learned the
stuff, that's more important than if the thing works.
:o)
-Roman

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



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

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


2001\03\21@035702 by Peter Betts

picon face
I do agree with the others that you have to actually be seen to have learnt
something.

However if you wish to get some help in getting your project working you
need to break it up into small pieces and tackle each one on it's own. Only
when you know how each bit works or even why it didn't work you can then
begin to build a system.

What specifically can't you get to work. What are the details of what you
have tried and observed? You cannot just ask someone else to do it all but
help in certain areas is acceptable. I would have also thought that your
teacher/professor is also there to help you.

Teachers don't just sit back and wait for you to finish it is their sole
purpose to educate and therefore help you learn. To help you learn might
include discussing the problems you are having and getting you to come up
with ideas of what to check.

Please say what you have written on the PIC to test the Radiometrix RF
units? What have you checked and what works? Can you even pulse the PIC
outputs? and then does the signal have the correct timings according to the
specification of the peripheral? Have you checked?

Remember KEEP IT SIMPLE, start off with small tasks and never try to get an
entire system working straight away unless you know how each component part
operates. Make many many prototypes and bolt them together, then start to
merge all the prototypes onto a single board design and even then you'll
have a few prototypes.

Pete

> -----Original Message-----
> From: ext Jose S. Samonte Jr. [dyoweespamspam_OUTUSA.NET]

> But my professor is not like that sir Roman.
> A not-fully completed project is good as failed.

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


2001\03\21@045139 by Jose S. Samonte Jr.

picon face
What my problem sir sir how to receive the preamble and the sync word.
In other words, how the receiving part would be able to recognize the preamble
and sync byte from the data needed to be shown on the LCD.




Peter Betts <KILLspamext-peter.bettsKILLspamspamNOKIA.COM> wrote:
> My problems are on the preamble, sync word, and the checksum/
> CRC. Basically, it's packet transmission and reception.

Preamble's are just a long string of 1's and 0's to indicate transmission is
about to start.

Sync words are just a collecting of 1's and 0's in a specific pattern that
is long enough for the receiving system to lock onto (correlate) and
synchronise at the appropriate bit rate.

Checksum is a Cyclic Redundancy Check and is normally a delay line with
XOR'ed taps fedback into the delay line input. (The feedback bit gives you
the "cyclic" term)

There are many many text books that explain CRC generation. It can be as big
or small as you like. If it's a PC you are talking to then I don't know the
correct polynomial for the CRC in this circumstance.

You notice how again you can break this down into smaller and smaller bits.
If it's a PC you're talking to get the speification of the interface and
read it. Then just try a simple terminal program and turn off all fancy
handshaking or parity checking. Just try raw data communications. When that
works try adding CRC (parity) etc etc.

Pete

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



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

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


2001\03\21@050207 by D Lloyd

flavicon
face
part 1 2869 bytes content-type:text/plain; charset=us-ascii
Hi,

I've never done this kind of thing before, but it sounds like you need some
kind of state machine with a sequence detector for the preamble.....

Once you detect a correct preamble (which I presume is just shifting serial
bits in and matching against a known pattern), you switch states to reading
the incoming data bit stream and partitioning it into bytes to display on
the LCD....If you dont get a decent preamble.....you wait around in the
first state until you do...

If you are after code for this, I certainly don't have any but it sounds
like a few loops with shifts with a compare.

Dan






(Embedded     "Jose S. Samonte Jr." <TakeThisOuTdyoweeEraseMEspamspam_OUTUSA.NET>EraseMEspamspam_OUTMITVMA.MIT.EDU>
image moved   21/03/2001 09:49
to file:
pic25804.pcx)





Please respond to pic microcontroller discussion list
     <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <PICLISTEraseMEspam.....MITVMA.MIT.EDU>


To:   EraseMEPICLISTspamMITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: Would anyone understand...?

Security Level:?         Internal


What my problem sir sir how to receive the preamble and the sync word.
In other words, how the receiving part would be able to recognize the
preamble
and sync byte from the data needed to be shown on the LCD.




Peter Betts <RemoveMEext-peter.bettsEraseMEspamEraseMENOKIA.COM> wrote:
> My problems are on the preamble, sync word, and the checksum/
> CRC. Basically, it's packet transmission and reception.

Preamble's are just a long string of 1's and 0's to indicate transmission
is
about to start.

Sync words are just a collecting of 1's and 0's in a specific pattern that
is long enough for the receiving system to lock onto (correlate) and
synchronise at the appropriate bit rate.

Checksum is a Cyclic Redundancy Check and is normally a delay line with
XOR'ed taps fedback into the delay line input. (The feedback bit gives you
the "cyclic" term)

There are many many text books that explain CRC generation. It can be as
big
or small as you like. If it's a PC you are talking to then I don't know the
correct polynomial for the CRC in this circumstance.

You notice how again you can break this down into smaller and smaller bits.
If it's a PC you're talking to get the speification of the interface and
read it. Then just try a simple terminal program and turn off all fancy
handshaking or parity checking. Just try raw data communications. When that
works try adding CRC (parity) etc etc.

Pete

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



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

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






part 2 165 bytes content-type:application/octet-stream; (decode)

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


2001\03\21@051723 by Kevin Blain

flavicon
face
your receiver might work like this

idle state......

some signal arrives - maybe you have a squelch indication, or the data line
toggles or something like that

At this point your receiver is expecting preamble. let's say you're using
1200 baud, and therefore it should expect to see alternate 1's and 0's every
1 second /1200 bits per secone = 833us per bit. therefore, if you were to
wait half this time from the first transition, sample the bit, then wait the
full 833us, sample again, and so on, you should be able to verify that it
alternates, if that is your preamble format. if it doesn't match from the
start, then it's not preamble, it's noise on the channel. If it matches to
start with, but then stops matching, maybe it's sync word, so go to the next
step.

your receiver now knows that some data is due, but is not sure when it is
going to start. So decide on the sync word you are going to use, and using a
similar method to above, detect when this word occurs - e.g. if your sync
word is 11001100 then your preamble detect should be going "Oi! that's not
preamble, because the signal didn't toggle every bit! therefore hand it over
to the sync word detection"



Don't stress over what might happen if your receiver misses this for
whatever reason, if, in the unlikely event of the preamble / sync word
occuring in the data, sure, the receiver will get confused and try to output
this as data, but it should be able to detect that the signal has
dissapeared (squelch?) and go back to idle state.

Your last step would be to get some form of checking going on, CRC of just
simply sum the bytes sent and have a couple of bytes at the end showing the
total, this would allow you to reject the garbage.

Regards, Kevin



{Original Message removed}

2001\03\21@052129 by Orbit Communications

flavicon
face
Jose,

This explanation goes a little deeper than you require but I have
given it as an example of how we achieve reliable communications.

Depending on the hardware used in your link, you may not get away with
long runs of "1"s and "0"s.

Normally a Data Slicer circuit is used in the receiver that tracks the
average DC level of the incoming signal and attempts to "slice" at the
mid point between the voltage level of "1" and "0".

Long runs of either polarity will cause this type of slicer to be
biased near the extreme top or bottom of the incoming waveform. This
leads to false triggering due to noise crossing the data detection
threshold.

The idea of the PREAMBLE is to condition the slicer to detect
transitions at as close to 50% as possible. If all incoming data is DC
balanced (same number of "1"s as "0"s then the slicer performance will
be optimal.

We use Manchester encoding for transmission over radio of data
packets.

We first send a small string of AAh to condition the slicer (the very
first byte is almost always lost).

We then send a unique SYNC byte that does not occur in the Manchester
encoding of the data (33h).

Next, the data is sent. To send normal NRZ data as Manchester via the
micro UART, you break each data byte into 2 nibbles. Each "1" in the
original data byte is sent as "1" "0" combination and each "0" as "0"
"1".

This decreases the throughput by 50% but increases reliability and
detection sensitivity.
As our units run up to 115kB, the "virtual" communication rate is
still very good.

Lastly we send a CRC-16 checksum.

Keep your packets small.

Also, ensure the transmitter is keyed on long enough before
transmission before data is sent and left on long enough to allow the
last byte out. We also send a PREAMBLE byte after the packet to ensure
last byte is received and don't have to worry about timing the last
byte.

The packet synchronisation is achieved by ensuring you get a PREAMBLE
followed immediately by a SYNC byte.

Any other combination is ignored.

After the synchronisation is achieved, you receive data into a buffer
until the required number of bytes is received.

It is a good idea to set a timer going during reception of data so
that if a partial packet is received, you can reset and start over.

Once all bytes are received, copy the buffer to another buffer (called
double buffering) , flag the buffer as full and then process the
received packet.

If packet is valid then the unit would send an acknowledge back to the
sending unit. If the sending unit does not get an acknowledge then it
will resend the original packet.
After (x) number of retries without success, your application can
determine how to handle a comms error.

On top of all this , our units monitor for clear channel before
transmission (by measuring RSSI - Received Signal Strength Indicator
levels). If the channel is being used when it "wants" to transmit, it
waits a "random" period of time and retries.

It is relatively easy to get RF transmission over several hundred
metres, the problems begin to increase as you want higher and higher
levels of reliability and guaranteed packet delivery.

Non critical applications such as remote control toys and garage door
openers are fine as the user simply holds the button at close range
and eventually a valid packet gets through.

Best Regards
David Huisman
----------------------------------------------------------------
Orbit Communications
Reliable RF data modules,wireless telemetry rfic and other
communication solutions

Web site: http://www.orbitcoms.com
Email: RemoveMEinfoKILLspamspamorbitcoms.com

PO Box 3469, Tuggerah, NSW 2259, Australia
Phone:+61-2-4329-7765
Fax:+61-2-4329-7893

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


2001\03\21@053831 by Jose S. Samonte Jr.

picon face
Thank you so much to all the people who understand me, but it is
really very vague for me.
Could anyone lend me a assembly code, even just for the preamble and
sync byte transmission and reception, please?

I hope for your understanding again...=)


Kevin Blain <spamBeGonekevinbSTOPspamspamEraseMEWOODANDDOUGLAS.CO.UK> wrote:
your receiver might work like this

idle state......

some signal arrives - maybe you have a squelch indication, or the data line
toggles or something like that

At this point your receiver is expecting preamble. let's say you're using
1200 baud, and therefore it should expect to see alternate 1's and 0's every
1 second /1200 bits per secone = 833us per bit. therefore, if you were to
wait half this time from the first transition, sample the bit, then wait the
full 833us, sample again, and so on, you should be able to verify that it
alternates, if that is your preamble format. if it doesn't match from the
start, then it's not preamble, it's noise on the channel. If it matches to
start with, but then stops matching, maybe it's sync word, so go to the next
step.

your receiver now knows that some data is due, but is not sure when it is
going to start. So decide on the sync word you are going to use, and using a
similar method to above, detect when this word occurs - e.g. if your sync
word is 11001100 then your preamble detect should be going "Oi! that's not
preamble, because the signal didn't toggle every bit! therefore hand it over
to the sync word detection"



Don't stress over what might happen if your receiver misses this for
whatever reason, if, in the unlikely event of the preamble / sync word
occuring in the data, sure, the receiver will get confused and try to output
this as data, but it should be able to detect that the signal has
dissapeared (squelch?) and go back to idle state.

Your last step would be to get some form of checking going on, CRC of just
simply sum the bytes sent and have a couple of bytes at the end showing the
total, this would allow you to reject the garbage.

Regards, Kevin



{Original Message removed}

2001\03\21@060331 by Jose S. Samonte Jr.

picon face
part 1 508 bytes content-type:text/plain; charset=US-ASCII (decoded quoted-printable)

Would anyone be willing to add a preamble and sync word transmission and
reception
to both my codes, which transmits and receives HELLO WORLD, please?
Thank you so much. I hope that you would understand me.
I know that I can get going when anyone would help me with this.
Thank you so much, in advance.
Best regards.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


part 2 5392 bytes content-type:application/octet-stream; name="sndhello.asm" (decode)

part 3 4444 bytes content-type:application/octet-stream; name="rcvhello.asm" (decode)

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


2001\03\21@061150 by D Lloyd

flavicon
face
part 1 5880 bytes content-type:text/plain; charset=us-ascii
Hi,

I know you said about failing the course but if you document HOW you COULD
do this, you will at least get some credit. As people say, learning is
about making mistakes and trying things out for yourself.........I'm sure
any professor who knows you have thought about the problem and devised some
kind of solution, even if you did not fully implement it, would be harsh
not to be lenient.

If you just say, "Well, I didnt do it and have no idea how to do it", then
they would be correct in not being too kind to you.
Why don't you talk to your professer regarding this; at least you are
keeping him/her informed of your problem and they know you are working hard
at a solution?

Regards,
Dan



(Embedded     "Jose S. Samonte Jr." <EraseMEdyoweespamEraseMEUSA.NET>spamEraseMEMITVMA.MIT.EDU>
image moved   21/03/2001 10:37
to file:
pic08153.pcx)





Please respond to pic microcontroller discussion list
     <@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU>


To:   .....PICLISTspam_OUTspamMITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: Would anyone understand...?

Security Level:?         Internal


Thank you so much to all the people who understand me, but it is
really very vague for me.
Could anyone lend me a assembly code, even just for the preamble and
sync byte transmission and reception, please?

I hope for your understanding again...=)


Kevin Blain <TakeThisOuTkevinb.....spamTakeThisOuTWOODANDDOUGLAS.CO.UK> wrote:
your receiver might work like this

idle state......

some signal arrives - maybe you have a squelch indication, or the data line
toggles or something like that

At this point your receiver is expecting preamble. let's say you're using
1200 baud, and therefore it should expect to see alternate 1's and 0's
every
1 second /1200 bits per secone = 833us per bit. therefore, if you were to
wait half this time from the first transition, sample the bit, then wait
the
full 833us, sample again, and so on, you should be able to verify that it
alternates, if that is your preamble format. if it doesn't match from the
start, then it's not preamble, it's noise on the channel. If it matches to
start with, but then stops matching, maybe it's sync word, so go to the
next
step.

your receiver now knows that some data is due, but is not sure when it is
going to start. So decide on the sync word you are going to use, and using
a
similar method to above, detect when this word occurs - e.g. if your sync
word is 11001100 then your preamble detect should be going "Oi! that's not
preamble, because the signal didn't toggle every bit! therefore hand it
over
to the sync word detection"



Don't stress over what might happen if your receiver misses this for
whatever reason, if, in the unlikely event of the preamble / sync word
occuring in the data, sure, the receiver will get confused and try to
output
this as data, but it should be able to detect that the signal has
dissapeared (squelch?) and go back to idle state.

Your last step would be to get some form of checking going on, CRC of just
simply sum the bytes sent and have a couple of bytes at the end showing the
total, this would allow you to reject the garbage.

Regards, Kevin



{Original Message removed}
part 2 165 bytes content-type:application/octet-stream; (decode)

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


2001\03\21@061608 by Kevin Blain

flavicon
face
assume your preamble sequence is 101010101010......


here are the instructions you will need:

btfsc    port,pin    ; This will skip over the next instruction if the port
pin is set to zero. using the goto instruction, you can use this and the
next instruction to set up loops to detect a 1, 0 sequence.

btfss    port,pin    ; this will skip over the next instruction if the port
pin is a 1.

use some goto instructions in there to make the program execute differenet
segments depending on if you were expecting a 1 or a 0 at that stage. (if
it's a zero, then you should expect a 1, and vice versa)

call    delay    ; download a delay routine from http://www.piclist.com or write
your own to delay exactly one bit period, and one that delays half a bit
period as I explained below.



You will need two loops, one for if it last received a 1, and should expect
a zero after a prescribed period of time, and another for if it last
received a zero, and therefore it should expect a 1. Write this all down, so
you can see in front of you the sequence you are checking for, then it
should be clearer to you.


But, I am  _not_ going to write the code for you. If you write something,
and post it, I will, and I am sure that the others will help you debug it if
you tell us where you think it is going wrong.


Regards, and best of luck

Kevin.

{Original Message removed}

2001\03\21@071937 by Russell McMahon

picon face
Jose,

An outline of what you are trying to do and why you are trying to do it
would be useful.
It's pretty clear that you are NOT going to get anyone here to write the
code for you BUT its also not certain exactly what you need.

You say you MUST have a RF link.
Why (briefly) may be useful.

You say it is a packet link with CRC and preamble and ....
Why?
This is indeed what you need for a "real" application but is possibly
overkill for you.

Is the link one way or two way?
You mention display of data on an LCD and on a PC.
How does the data flow?
What is the needed data rate?

From your original description I would understand the task to be as follows.
This understanding may be wrong.
IF it is wrong it makes it hard for people to understand you

"Data is provided to a PIC (PIC1) from an unspecified source.
The data is sent across a unidirectional serial link to a second PIC (PIC2)
PIC2 displays the data on an LCD and also sends it in serial to a PC via the
PC serial port."

Is this correct?

If the data rate was moderate you could probably "burble" it out constantly
in standard async format with data repeated at least twice for security and
many times if the rate allows. You could create a very simple protocol to
handle this.

eg data is broken into 4 bit nibbles nnnn
A 2 bit message address is used AA
There are initially 2 spare bits per byte ss.
Data bytes are made up of the above eg AAssnnnn

Imagine the data is sent 8 times at least per real nibble.

The receiver looks for at least eg 3 identical versions of the same data.

The following pseudo code is straight out of my head and is sure to have  a
logic flaw somewhere but if you follow it you should easily get the general
idea.
What this is doing is trying to bypass the normal more complex systems which
are used for efficiency and high accuracy.
NO preamble - it just sends in async all the time. Depending on your
hardware this should be OK.
NO error detection - just uses a N correct message system.
Note that the simple system used resets any time an invalid message address
is received and would have problems on links with more than the occasional
error. A little thought would allow an algorithm that does not reset the
counter and current address when a different address is received.
Adding parity checking per byte would help somewhat

This is very rude but would probably work OK depending how closely my
assumptions match your real situation..
NO packets - just a continuous stream of nibbles.
NO Manchester encoding and decoding.
Even a BASIC Stamp could handle this !!! :-)

I have assumed asynchronous data transmission is OK.
There are many PIC async routines on the web (start with Microchip app
notes).
The async transmit routine is trivial and the received routine almost so.


See above for explanation od AAssnnnn data word.


TRANSMITTER
============

Address AA = 00

Do until Californian power supply is reliable

   Get next data nibble         ; from your data source
   Do 8 times
       Send byte AAssnnnn
       pause several bit times
   EndDo
   Do while new data is not available
       Send byte AAssnnnn
       pause several bit times
   EndDo
   AA = AA + 1
   IF AA > 11 binary then
       AA = 00
   ENDIF

EndDo


RECEIVER

RecCount = 0                    ; counts valid address messages received
Current address = 99        ; address of messages being received
OldData = 11111111        ; Data received last time
SeenIt = 0                          ; Flag - data for this address already
processed


Do until universal; world peace arrives

   Receive 1 async data byte in ReceivedByte

   If AA in ReceivedByte <> Current Address

       RecCount = 0
       CurrentAddress = AA
       SeenIt = 0

   Else

       If ReceivedByte = OldData
           RecCount = RecCount + 1
       Else
           OldData = ReceivedByte
           RecCount = 1
       Endif

   Endif

   If RecCount > CountLimit ; say = 3

       Send receivedByte to display and PC
       SeenIt = 0

   Endif

EndDo




regards




               Russell McMahon




{Original Message removed}

2001\03\21@082201 by Olin Lathrop

face picon face
> Would anyone be willing to add a preamble and sync word transmission and
> reception
> to both my codes, which transmits and receives HELLO WORLD, please?

Look Jose, everyone has been telling you that you need to figure out
the problem yourself.  Your task is much more to learn about
microcontrollers than to create a radio link.  Therefore just giving
you code will defeat the purpose.  Perhaps if you ask specific
questions you will get a better response.  It's OK to be confused
about individual items - that's a natural part of the learning
process, but nobody is going to do your homework for you.

Take a deep breath and step back from this project.  Stop trying to
make it work but instead take a week or two just to learn about the
PIC.  Forget about the project and try a few simple things first,
like making some LEDs blink.  Then build up to more complicated
things.  Once you feel comfortable with the PIC and the tools, THEN
try to implement your project.

I imagine the problem is that you are nearing graduation time and you
have to get this project working.  I have two comments on this:

First, I'm surprised that someone who is about to graduate as an
electrical engineer hasn't already learned more about
microcontrollers.  This is something I would expect a serious EE
student to do on the side, whether required for course work or not.
I have a masters degree in EE myself.  I learned a lot of theory from
courses (which is important also, I'm not trying to belittle it), but
most of the practical information came from just DOING it even though
very little of this was required.

Second, if you can't learn about microcontrollers and then do this
project, you shouldn't be awarded a degree.  The information is all
out there in a form that any 4th year EE student should be able to
comprehend.  If you can't, you should seriously consider a different
career.

*** And no, do NOT send me personal email about your problems. ***

Now for a few general comments about your code:

 1)   NEATNESS COUNTS!  Every time I've looked behind code that
      looks like a mess, I've found a thought process that was a
      mess.  For starters, never use TABs.  Always have the editor
      insert hard spaces.  You can't assume what other people's tab
      stops are set to.  Second, line up things in columns.  I use
      10 for opcodes, 18 for operands, and 30 for comments.  The
      exact values don't matter that much as long as you are
      consistant.

      I cleaned up your code a bit below, just for my own sanity.

 2)   Comments have a purpose, use them.  The biggest cost of any
      real world code is maintenance.  Good comments are essential
      for allowing other people to understand your intent.
      Comments, if used properly, help you write more reliable code
      faster.  They are NOT something to be added on later.

I have commented about parts of your code below:


{Quote hidden}

What are these variables for?  Each one should have a comment behind
it.

>
> PIN_E    EQU     3
> RW       EQU     2
> RS       EQU     1

And what are these?

>
> ; -------------
> ; PROGRAM START
> ; -------------
> ;
>          org 0x000           ; startup = 0000h
> ;
> Start    bcf STATUS, RP0

This is OK for now, but not if you decide to use interrupts later.
The interrupt vector is at location 4.

{Quote hidden}

There should be a header comment here explaining what this subroutine
(?) is all about.  What does it do?  What does it take as input?
What does it produce as output?  What global state does it reqire
access to?

{Quote hidden}

Further discussion of this code is pointless until it is properly
documented.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinspamRemoveMEembedinc.com, http://www.embedinc.com

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


2001\03\21@082210 by Olin Lathrop

face picon face
> Could anyone lend me a assembly code, even just for the preamble and
> sync byte transmission and reception, please?

No, I don't think anyone should.  Once again you are trying to avoid
UNDERSTANDING what is going on.  I don't want any part of that.  I would
prefer you stop bothering everyone until you develop a better attitude.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolin@spam@spamspam_OUTembedinc.com, http://www.embedinc.com

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


2001\03\21@123837 by Bill Westfield

face picon face
   Once you detect a correct preamble (which I presume is just shifting
   serial bits in and matching against a known pattern),

It's probably not quite that simple.  A preamble is usually chosen so that
it can be detectable even if some of the bits are dropped.  It's purpose is
more or less to activate and stabilize those hardware parts of the system
so that by the time the data gets sent, everything is "ready."  aPROBABLY
what you want to do is shift bits as soon as you see the first transition,
and look for the sync byte (ie DON'T bother looking for the preamble.)  If
you WANT to, you can save more than one byte worth of the bits you've
shifted, and after you've detected the sync byte, see if the preceeding
bits match the end of the preamble pattern, but I don't think it's
necessary.  You shouldn't have to receive significantly more bits after the
first transition than there are in the preamble+sync byte altogether, of
course.  Failure to find a sync byte should be an error of some sort.

BillW

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


2001\03\21@131411 by Dale Botkin

flavicon
face
On Wed, 21 Mar 2001, William Chops Westfield wrote:

>     Once you detect a correct preamble (which I presume is just shifting
>     serial bits in and matching against a known pattern),
>
> It's probably not quite that simple.  A preamble is usually chosen so that
> it can be detectable even if some of the bits are dropped.  It's purpose is
> more or less to activate and stabilize those hardware parts of the system
> so that by the time the data gets sent, everything is "ready."  aPROBABLY
> what you want to do is shift bits as soon as you see the first transition,
> and look for the sync byte (ie DON'T bother looking for the preamble.)  If
> you WANT to, you can save more than one byte worth of the bits you've
> shifted, and after you've detected the sync byte, see if the preceeding
> bits match the end of the preamble pattern, but I don't think it's
> necessary.  You shouldn't have to receive significantly more bits after the
> first transition than there are in the preamble+sync byte altogether, of
> course.  Failure to find a sync byte should be an error of some sort.

That makes more sense.  When looking for the start of a packet, you would
simply shift bits into the receive register.  After each bit is received,
check to see if the receive register is a sync character; if so, you now
know you're receiving a packet, so start saving the data that follows.
Any preamble bits simply get shifted out of the receive register and
dropped into the bit bucket.  Did I get that right, Bill?

There is very simple and good code in the PIClist archive for bit-banged
serial transmit and receive.  I know it's simple because I figured out how
to use and modify it, and I know it's good because I've used it and it
works!

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

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


2001\03\21@173719 by Russell McMahon

picon face
Jose - onlist reply to offlist message

> Sir, could you help me on the preamble, sync byte, and checksum
> routines, please?
> I'm really so confused, but you were right sir about what I need to do
> about my project.
> Please help me. Thank you so much.
> I hope that you would understand. God Bless.
> Best regards.


You don't seem to be listening to anyone.
What I posted did not involve preamble or sync bytes or checksums.
If you are asking me for those it suggests that you did not read what I sent
or if you did read it, that you did not understand it.
What I sent was an outline only of how you might do your task simply rather
than the more complicated way that you are trying.

I also asked a number of questions to try and understand EXACTLY what your
requirement was.
You have not answered any of these questions.
I, and anyone else who has been reading your messages, do not yet know
exactly what you MUST achieve.
You seem to be trying to do something in a potentially complex way when
there MAY be more simple ways to do it.

Nobody is going to send you finished code.
People here will try and help you if you make it clear what you NEED to do
(and not just what you WANT to do or are TRYING to do).

Answer my questions to the list (not to me)

Explain where the data comes from.
Explain how much data is to be sent.
Explain whether it flows in one direction only.
Explain why you MUST use a radio link
Explain what the LCD is connected to and what data it is intended to
display.
Explain how the PC is involved.
Explain what software is to be used on the PC and what it will do with the
data.
Explain why you feel you need preamble and sync and checksum code rather
than the simple scheme I suggested.
Why are YOU doing THIS project? - did you choose it or was it assigned to
you?

This may sound like a lot of explaining BUT if you can't clearly and simply
explain this to us by now then chances are you can't explain it to yourself
either.
If you can't write it down (or haven't) then you don't know what you are
really trying to do.


To get things going consider using a hardwire connection in place of the
radio link to show the basic system is working. If you can't make the system
work with a wired connection then it will probably also not work with a
radio connection.

If you want to pass this course and repay your parent's investment in you
then you need to make good use of the help that IS being offered you. If
people sent you code it would probably still not do what you wanted if you
did not understand what was going on and you would be no better off.

Consider starting REALLY SIMPLY to get things going.
Can you send ANY data from PIC to PIC?
Can you send data from the PIC to the PC?
Can you display any data on the LCD?
Can you wire the PICs together and send data?
If the answer is no to all these questions then you need much more than a
few pieces of code.

When is the project due by?

Remember - God helps those who help themselves.
(a old simplistic saying, but with some truth in it)


God bless.
Try and make best use of the help that IS being sent you.
Remember, tell us what you MUST do and not just what you are trying to do.
Answer some questions.



                   Russell McMahon

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


2001\03\22@031833 by Mohamed Eldesoky

flavicon
face
Hi Jose
Don't worry
I am just doing  the same thing now
You can email me for discussion
Also you can check for http://www.radiometrix.co.uk

----- Original Message -----
From: "Petra Weeks" <EraseMEpetraspam@spam@WEEKS20.FREESERVE.CO.UK>
Sent: Wednesday, March 21, 2001 3:52 AM
Subject: Re: [PIC]: Would anyone understand...?


> Hi Jose
> Still at it then, OK here's some clues, but like we have told you before,
we
> are not going to do your work for you.
> So here goes:
> Take a look for info on Holtek's  HT-12E & HT12D
> The  HT-12E  can take four bits of data, ie 0x00 - 0x0F, and produces a
> seriel bit stream + pre-set address.
> This can be fed directly to a RF transmitter.
> The HT12D takes the output from an RF receiver and if the address matches
it
> produces the 4 bits of data on
> the four data output pins.
>
> Admittedly this we only give you  limited functionality, but its very
> simple, especially if you use a key board for input ( hexadecimal ).
> As for the serial PC link, there is plenty of information at microchip.com
> Have a look for   AN555  Software implementation of Asynchronous Serial
I/O
> and for the LCD  AN587  Interfacing to an LCD Module.
>
> OK Jose,
>  take care, and good luck.
>
> Petra Weeks (Ms)
>
> {Original Message removed}

2001\03\22@040657 by Russell McMahon

picon face
> I'm very sorry sir Russell.
> Please forgive me. I didn't mean to offend you or anybody.
> It's just that I'm so confused.
> I'm really very sorry.


No problem.
I'm not offended.
I'm just trying to help you to help yourself.
If you want to stop being confused you could answer the questions I asked
and post the answers to the PICLIST.
This would help other people understand your needs better.



           Russell

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


2001\03\22@044728 by Roman Black

flavicon
face
Kevin Blain wrote:
>
> assume your preamble sequence is 101010101010......
>
> here are the instructions you will need:
>
> btfsc    port,pin    ; This will skip over the next instruction if the port
> pin is set to zero. using the goto instruction, you can use this and the
> next instruction to set up loops to detect a 1, 0 sequence.
>
> btfss    port,pin    ; this will skip over the next instruction if the port
> pin is a 1.


Ha ha!! Thanks Kevin! Seeing assembler written by
an expert relly helped me with my own code. I wondered
how to work those port thingies. ;o)

And real good advice for the computing student.
-Roman

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


2001\03\22@164236 by Philip Martin

flavicon
face
Just as an aside to this thread, if you use the Radiometrix units with the
Holtek HT12 range of decoders make sure you use the Low data rate RX units.
I found out the hard way, and confirmed it with Radiometrix that their
higher data rate RX units pump out data too fast for the Holtek units to
decode.

Philip Martin.


{Original Message removed}

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