Hello there!
I am looking for idea how to read this kind of bits:
The waveform begin with few secounds of 8khz , than we have ~2sec of silence, and than the most important :
I have to skip long 8khz wave form, look for the prefix and than try to read as uart with String function ?
Thanks in advance for the sugestions !
Please don't leave it as a huge mystery what this waveform is, and what produces it. Also all the other things you already know about it. Not providing this basic information places an unnecessary burden on us.
Sorry, You are rigt.
This waveform is from transmiter which send the temperature and humidity. It sends cyclically every 2 minutes waveform from the image.
Few sec of constant 8khz is send only after transmiter start to run.
Do you know the data protocol that they are using? Sorry for the sloppy edit...
Yes, exactly!
This is it:
Do you have a manufacturer, model number and datasheet/app note for the sensor?
It is probably not ASCII. You won't be able to read it with a UART, and String processing is completely out of the question.
Before you reply again, be aware that new users have a post limit on the first day. So if we continue in question and answer format, you will be locked out eventually. Best to think a bit and post as much information as you can, all at once.
@Blackfin
I dont have a datasheet for that:
@anon57585045
I think there is no specyfic protocol but row data, like that:
I'am close to figure out and decode (or in the middle 
I know the preamble data, the channel numebr data, place of temp and humidity bits data ( but not sure how to decode).
I decided to read now with arduino the bits becouse it will be easier to work on simple representation of data than on the waveform.
I realized that String function is wrong direction..do You know any ready function which can read this kind of bit stream ?
pulseIn() will read a single pulse and tell you the length. So consecutive calls to pulseIn() could maybe translate it into bits that you could decode. Unless you can find someone who has done some reverse engineering, or some documentation on the internet, you will have to reverse engineer the protocol yourself.
You could look at either the softwareSerial code, or the Infrared Remote Control protocols, both of which receive "random" bit streams.
The 8kHz preamble stuff means that you don't even need to guess bit-rate; you can measure the rate that the sender is sending exactly.
It looks like you already believe that the data section of that stream uses Manchester encoding: Manchester code - Wikipedia
Pretty sure there is a specific protocol. I too think it looks like Manchester encoding.
a7
The bit encoding is only a layer. You have to know what the bits mean.
Nevertheless, whoever designed the transmission between whatever is sending and receiving very probably employed a specific protocol.
Maybe not one anyone had ever seen before, I know that can be done. 
That it is not standard or popular or published or rational or efficient or robust or pretty is possible.
I don't think ppl use fuzzy protocols at this level of data comms.
a7
Not fuzzy, but often proprietary.
If the silent part of the diagram is 'about 2 seconds', the data part appears to be about 12 seconds. It is clearly not sending 8000 bits per second because that would be 12000 bytes of data, far too much for temperature and humidity.
I think the first step is to demodulate the signal. I would use the Timer1 Input Capture Pin (UNO Pin 8) to measure the time between rising edges. At 8 kHz the time would be 2000 clock ticks (at 16 MHz). Call any value under 3000 as HIGH and any value over 3000 as LOW. By noting the time each transition occurs, the underlying data can be recorded (like with an IR Remote).
Right on. Years ago I programmed an MC68HC11 to decode IR. My first program was a timer driven reader that just reported the intervals accurately. Then I had enough information to build a decoder program.
@6v6gt @alto777 @anon57585045 @johnwasser
I suspect that this could be not Manchester, please look on the picture bellow, marekd by red areas - these are too long HIGHs and LOWs for Manchester..
Till now, I fugured out:
A1-A2 - pramble
A2-B1 - channel 4 bits
B1-B2 - humidity 8 bits
B2- ... there is temperature and checksum or even more, because this section changes even if the all paramiters(temp, channel, humandity) are the same
IRremote - this is good direction! but also I will try to make own function based on timers and interrupts
Looks like 9 cycles per millisecond to me (9 kHz).
Try this sketch on an UNO with your signal connected to Pin 2.
const byte InputPin = 2;
const unsigned BufferSize = 300;
volatile uint16_t TimeDeltas[BufferSize];
volatile unsigned BufferIndex = 0;
volatile uint32_t LastTimeStamp = 0;
volatile boolean Recording = false;
void setup()
{
Serial.begin(115200);
delay(200);
pinMode(InputPin, INPUT);
attachInterrupt(digitalPinToInterrupt(InputPin), InputChange, CHANGE);
}
void InputChange(void)
{
uint32_t timeStamp = micros();
uint16_t delta = timeStamp - LastTimeStamp;
LastTimeStamp = timeStamp;
// Detect the start pulse: Pin went low after being high
// for more than 900 microseconds.
if (digitalRead(InputPin) == LOW && delta > 900)
{
BufferIndex = 0;
Recording = true;
}
if (Recording && BufferIndex < BufferSize)
TimeDeltas[BufferIndex++] = delta;
}
void loop()
{
noInterrupts();
// If the start pulse was seen but the signal has not
// changed for at least 2 milliseconds:
if (Recording && micros() - LastTimeStamp > 2000)
{
Recording = false;
Serial.println(BufferIndex);
for (unsigned i = 0; i < BufferIndex; i++)
{
Serial.print(TimeDeltas[i]);
Serial.print(", ");
Serial.println(TimeDeltas[i + 1]);
}
}
interrupts();
}You should get about 63 sets of rising and falling edges (at most 9 pulses for each of 7 milliseconds).
Well done! Without waveform and testing, impresive!
@johnwasser Thank You very much!
@anon57585045 @alto777 @Blackfin @westfw @6v6gt Thank You all guys for the effort !