Go Down

Topic: LIFI VISIBLE LIGHT COMMUNICATON  (Read 3236 times) previous topic - next topic

TomGeorge

Hi,

Can you tell us your electronics, programming, Arduino, hardware experience?

Thanks.. Tom.. :)
Everything runs on smoke, let the smoke out, it stops running....

Mohit

Hi,

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 .

TomGeorge

#32
Jul 14, 2017, 10:54 am Last Edit: Jul 14, 2017, 10:54 am by TomGeorge
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.


Thanks.. Tom.. :)
Everything runs on smoke, let the smoke out, it stops running....

GoForSmoke

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.

https://www.arduino.cc/en/Serial/Begin

Quote
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.

Quote
Parameters

speed: in bits per second (baud) - long
config: sets data, parity, and stop bits. Valid values are :

    SERIAL_5N1
    SERIAL_6N1
    SERIAL_7N1
    SERIAL_8N1 (the default)
    SERIAL_5N2
    SERIAL_6N2
    SERIAL_7N2
    SERIAL_8N2
    SERIAL_5E1
    SERIAL_6E1
    SERIAL_7E1
    SERIAL_8E1
    SERIAL_5E2
    SERIAL_6E2
    SERIAL_7E2
    SERIAL_8E2
    SERIAL_5O1
    SERIAL_6O1
    SERIAL_7O1
    SERIAL_8O1
    SERIAL_5O2
    SERIAL_6O2
    SERIAL_7O2
    SERIAL_8O2
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Mohit

Quote
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  :)

AWOL

Google "forward error correction".

GoForSmoke

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?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

aarg

#37
Jul 14, 2017, 07:19 pm Last Edit: Jul 14, 2017, 07:19 pm by aarg
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.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

srnet

#38
Jul 14, 2017, 10:24 pm Last Edit: Jul 14, 2017, 10:25 pm by srnet
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. 
No PMs please, they dont get answered.

Go Up