I'm trying to capture a 'packet' of data. I'm able to read pin 2 and get the data stream but I would like to start the capture of the data at the beginning of the packet. Each packet happens about every 1/2 second.
To capture the data, I created an array and perform a DigitalRead on pin 2, then store the state in the array, then delay for the next bit, then loop for 600 times. I was trying to figure out how I can recognize when there is no data (or all logic 0's) then start the capture as soon as the pin goes high.
I tried creating another array to read pin 2 and look for 8 0's in a row and set a boolean to true once it is met but I can not seem to get it to function properly and I am not sure if this is a good way of recognizing the beginning of the packet. I welcome any ideas.
I have a device that outputs a data stream. Basically a pin that goes high and low. It is coming off the microprocessor in the device. I am trying to use the arduino to watch the data and look for certain things to happen. The data is not standard serial. There is a burst/packet of information ever 1/2 second or so. In between packets the logic level is low. I am trying to use the period in between packets to recognize when the next packet is about to start. I am able to read the data captured successfully but my goal is to catch the starting of the packet.
Example of the packet:
100101010100110000000000000000000000000000000000010010101010011
^^^^^^^^^^ ^^^^^^^^^^
packet data period between packet packet data
There must be some protocol to define when a packet starts and ends. From your description the data stream is LOW between packets and the first HIGH represents the start of the packet. How many bits are in a packet. Is the first HIGH part of the packet, or just a marker - a Start bit ?
Why do you say the data is not standard serial ? It looks very like an inverted standard serial.
Assuming you know the protocol and the bit-rate is not too fast it should be easy to write some code to read the data.
If the normal Serial library will not do the job I suspect the code in yet another software serial could be adapted to meet your need. But an even simpler system may be sufficient when we know all about it.
Unfortunately if you want to make such a diagram you must use "code" tags to enclose it and check that it looks right. That was wrong either way.
A packet is denoted by a "flag", generally the pattern 01111110, which is the start and end character. Any other pattern in the stream which might comprise six or more ones is "bit-stuffed" with a zero after five ones, so the flag containing six ones is unique. There is also an abort character comprising seven ones. In the case illustrated, the zeroes represent transitions and the ones, non-transitions, so it guarantees a clock reference transition at least every six non-transitions.
The packet is detected by continuously shifting bits through a register and comparing with 0x7E, after which discovery the bits are fed through the "bit-de-stuffer" and thence shifted in eight at a time. It is possible that the ending flag might occur on a non-byte boundary, whether this represents an error depends on the protocol. The last two bytes in the packet are generally a checksum (CRC).
So it probably is "standard serial", just not asynchronous serial to a UART. You usually use a dedicated USRT chip, but of course, it can be done in software and often is at lower baudrates up to 19200 or so.
