Changed this to read serial from port 1 and report on the usb serial

Changed the main loop to only start proccessing a packet once the hole packet has arived so that the serial reads will always have available data

I didnt realise that the serial reads are non blocking and will return 0xFF if no data is available instead of blocking, if the spead is too high then a overly small value is returned but this can be fixed by slowing the disk
Create README.md

added Readme
Simple Error checking

Looks at the 3 error bits of each reading to see if any of them are activated and only use's the readings that do not have any error bits.

My set up often returns the very long reading meaning that no good meserment where made for the sector as it is not spining at a controled speed with this code. But the error range is outside of the normal operating range and can there for be delt with as this range will only ever be the result of the lidar not reading properly.

I havent looked at the proccessing section enought to know if it is sensible or doing quite what i think but is is a start and my diff is hopefully easy to expand upon.
Merge branch 'master' of https://github.com/fishrockz/serialReadLidar
Two Tiny Tweaks, What a diffrence!

Classic mistake i have made many times myself, in other lang's this would have coused a run time error but as that would really mess stuff up the arduino handles it greacefully meaning you dont spot the otherwise clear bug

Getting the iniquality the wrong way round is another classic i have suffed many times from but it give really odd ansers if you dont fix the less ovius indexing bug, this touck me a little time to spot and only then did i reread the rest of the code to see the index bug outlined above.

Ardino is a right faff to debug some times!!! the teensy great once it works tho!
Quick Tweaks

Miss read the data sheet! only the last bite is a error bit but the second to last bit is also a signal strength warning so if ether of them are true then it ignores the data however i had had the third to last bit as a error bit as well but i turns out that on isnt a error or warning bit but a data bit so fixed to alow longer range

Oups :) more range now!
Merge pull request #1 from fishrockz/master

See if this helps