--0__=80256A16003D562C8f9e8a93df938690918c80256A16003D562C 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." @MITVMA.MIT.EDU> image moved 21/03/2001 10:37 to file: pic08153.pcx) Please respond to pic microcontroller discussion list Sent by: pic microcontroller discussion list To: PICLIST@MITVMA.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 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 ----- From: "Jose S. Samonte Jr." To: Sent: Wednesday, March 21, 2001 9:49 AM Subject: Re: [PIC]: Would anyone understand...? > 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 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 listserv@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 listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@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 listserv@mitvma.mit.edu with SET PICList DIGEST in the body --0__=80256A16003D562C8f9e8a93df938690918c80256A16003D562C Content-type: application/octet-stream; name="pic08153.pcx" Content-Disposition: attachment; filename="pic08153.pcx" Content-transfer-encoding: base64 CgUBCAAAAABBADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABQgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --0__=80256A16003D562C8f9e8a93df938690918c80256A16003D562C-- -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body