How it sends data it sends data in packets and size of the packets can vary in between 5-9 but we usually program it for 8bit size of data packets and data packet is followed by start bit (transition from high to low) and there is parity bit at the end of data packet it is optional it helps us to check whether the data recieved is corrupted or not at receiver end and at last there is stop bit (transition from low to high ) so anything more you want me to learn about serial communication or is this enough ?
And what happens to the synchronisation of the serial stream when you interrupt (i.e. break) the transmission medium?
When i break the transmission medium terminal stop showing any data on receiver end as photodiode does not get any input from ir led but as i remove the object i get that garbage string which i am mentioning from start but always the same strung everytime same string and if i do this breaking repeatedly by luck suddenly i start getting back my original string which i don't know how ?
Rather than answer my question with your specific case, why don't you consider the general case of what happens to an asynchronous serial connection when it is broken?
What would expect to happen, and how do you support that belief?
What have you done to test it?
(BTW, you have the source for the software serial UART - reading through it might prove informative)
Sir frankly saying i do not know about that .
I have read that now from wikipedia
May be the reason i am getting that unwanted string is due to some type of break condition which came to know just now when you mentioned it i googled it and answer i get is following
"A "break condition" occurs when the receiver input is at the "space" (logic low, i.e., '0') level for longer than some duration of time, typically, for more than a character time. This is not necessarily an error, but appears to the receiver as a character of all zero bits with a framing error. The term "break" derives from current loop signaling, which was the traditional signaling used for teletypewriters. The "spacing" condition of a current loop line is indicated by no current flowing, and a very long period of no current flowing is often caused by a break or other fault in the line.
Some equipment will deliberately transmit the "space" level for longer than a character as an attention signal. When signaling rates are mismatched, no meaningful characters can be sent, but a long "break" signal can be a useful way to get the attention of a mismatched receiver to do something (such as resetting itself). Unix-like systems can use the long "break" level as a request to change the signaling rate, to support dial-in access at multiple signaling rates."
And Now the question occurs if this theory is right that some break condition occurs then how i can detect this break condition and most important thing if it is detected then how can i reset the whole system including the transmitter side resetted without pressing the reset button on arduino ??
Yes sir at that moment i do not understand but now i am getting little much all thanks to you just pointing me in right direction but please reply me for my question in reply #25
Mohit:
Yes sir at that moment i do not understand but now i am getting little much all thanks to you just pointing me in right direction but please reply me for my question in reply #25
You are barking up the wrong tree in #25. A break condition or framing errors are only one of many errors that you could have with a noisy receive. You could also receive fully formed characters with errors in them. In fact, the laws of probability say that you will. Resetting things isn't going to help with that.
aarg:
You are barking up the wrong tree in #25. A break condition or framing errors are only one of many errors that you could have with a noisy receive. You could also receive fully formed characters with errors in them. In fact, the laws of probability say that you will. Resetting things isn't going to help with that.
So then you tell me what should i do ? I have asked the same thing from you !!
Can you tell us your electronics, programming, Arduino, hardware experience?
Thanks.. Tom..
I have knowledge not much but i have full coding and hardware experience in Pic18f45k22 mcu. First i tried to perform my project with Pic mcu but Pic controller does not offer much inbuilt library so i decided to jump on arduino as it offers many libraries and online support . It is more easy with arduino to get help from google as for Pic controller .
Hi.
You need to adopt a protocol for your packet, as you are sending simple oneway data, your data should have a part of it that is always the same, an ID.
Your receiver software should look in the packet for this ID, if it can't find it , then don't display it.
At the moment you are Txing data, just turning the LED ON for HIGH and OFF for LOW, this is going to be susceptible to noise, especially as you are using the visible spectrum.
The virtual UART that Software Serial sets up are not able to correct errors, or compensate for noise.
You need to do some research into light and IR communication, to see how they syncronise and minimise noise problems.
Hello Mohit, I don't know if this is you but it may be;
A lot of people view serial data like it is sent all together in an instant.
For some, they imagine it is the whole message as one thing.
They will assemble ALL the text before they send and read it all before they prosecc any of it.
For others, each character is a blob. And there at least, a character is the smallest serial data to send.
But truth is that serial data is sent one bit at a time; start bit, data bits, end bit that at 9600 baud takes > 1ms to send.
So when you remove the blocking paper, was it in the middle of sending those bits leaving a broken message?
Serial can also send a parity bit that is made 1 or zero in order that all the 1 bits add to an even or odd number.
That is one built-in error check.
You may not need to go that far. If you only expect certain characters (alphas, digits) then get anything else is error.
An optional second argument configures the data, parity, and stop bits. The default is 8 data bits, no parity, one stop bit.
Syntax
Serial.begin(speed)
Serial.begin(speed, config)
below; N is for No parity bit or checking, E is for Even parity and O is for Odd parity.
Parameters
speed: in bits per second (baud) - long
config: sets data, parity, and stop bits. Valid values are :
Serial can also send a parity bit that is made 1 or zero in order that all the 1 bits add to an even or odd number.
That is one built-in error check.
You may not need to go that far. If you only expect certain characters (alphas, digits) then get anything else is error.
So I see you want me to enable the parity bit and check for errors at receiver end. I completely understood you but one thing i like to highlight to everyone that they are giving me suggestions and I appreciate them from my heart but all are giving me good ideas how to check errors but nothing how to obtain that string again if the error occurred.
Lets take a hypothetical situation I add this parity bit idea to my code (which is great personally telling not much complicated easy way to correct) and the error occur then after it what should i do ? How i compensate that error with the help of that parity bit ?
A warm thank you from my side to the arduino community forum member.for helping me at such an extent giving me ideas every so often Thnaks A Lot
First I wanted to find the conceptual error(s) that have you going in circles.
No, I was not telling you to use parity. I only showed that you can. Broken ASCII is easy enough to spot that the default is no parity and there are other techniques to check errors where data is not sent as ASCII chars but as binary values.
If someone tells you something and a loud noise makes you unable to hear, what do you do? Ask them to repeat?
How would you code that?
If you don't know what ASCII is, do not ask until you have looked it up and learned enough to ask intelligent, specific questions.
Do not think that anyone should have to type so much up that is already on the web and very easy to find.
@AWOL --- or error check and correct (ECC)? Quickpar for Arduino?
One easy thing you could try is using the OOK/ASK configuration of the RadioHead library. It is meant for radio transmissions but could be used experimentally for on/off light communications. It has features that help with noise and error handling.
Mohit:
all are giving me good ideas how to check errors but nothing how to obtain that string again if the error occurred
There are various checking mechanisms that can attempt to re-create a packet of data with errors, but not all errors can be corrected.
So if you really need to obtain 'that string again' you need a mechanism (protocol) that tells the transmitter to keep resending the string until you are happy its correct.
