SparkFun Forums

[Sparky99]

Hi, Im a very new user to the arduino, and i need help getting started with a project.

I have a sensor that outputs 77 bits of binary code in 140ms,
I believe it is manchester coding, this data contains 6* 2 digit hex numbers. I need to be able to send this binary data to the arduino . initially it would be good to show the incomming data on the screen.
1111111001010011010101000110011111001101000110110110111111011001110000000
11111110 01 01001101 01 01000110 01 11110011 01 00011011 01 10111111 01 10011100 00000(spaces added by me to show data split)
This converted to hex should give 4D,46,F3,1B,BF,9C

I believe the 1111111 start sequence is posibly to inform the receiver that data is being sent and the 00000 at the end informs the receiver that is the end of the string.

The end result im looking for is the arduino to read the binary data and convert it to hex and display either on screen or lcd display.
The sensor has two output connections that i have connected to earth and Digital pin 2.
I now strugling to make anything happen. Im not sure of the Baud rate. I have tried some code obtained from various sources but nothing seems to happen.
Like all tasks in life it seems the first steps are the hardest.

Any help greatly received.

[Valen]

I would start with learning how to sample an Interrupt-pin (I think pin 2 is one of them) , and log the changes in duration using the micros function as a timebase. As the pulse lengths(pulse high) and space lengths (signal low) may be of different duration. Depending on the baud rate of your serial connection to the pc, it might not be quick enough to send the pulse lengths in real time. So you may have to store it in memory first. Or only make a histogram count out of it. Once you know how long a bit takes, you can rebuild your program to interpret the signal changes as bits on the fly. Don't worry about converting it into hex yet. Just put them into the right sequence into bytes and sent them out to your pc for further analysis. Once you are sure where the header ends, how the hex values are seperated, and how many bits are left for the footer of the bitstream, should you worry about slicing the stream up into individual hex codes.

Also it helps if you allready know what the datastream contains.

[jremington]

These can be interesting challenges, but if you want help thinking about it, you'll need to provide more information.
For example, what sort of a sensor is it? That narrows down some of the possibilities.
Why do you think the data are Manchester encoded? Pulse width modulation is more common.
Six two digit hex numbers can be encoded in 48 bits, so what do you think the other bits do?

There are lots of web sites and forum posts (including Spark Fun) on decoding the bit streams from commercial RF weather sensors, IR remote controllers, etc. so spend some time with Mr. Google.

[Mee_n_Mac]

I have a sensor that outputs 77 bits of binary code in 140ms,

How often does your sensor spit out these 77 bits ? IOW how much 'dead time' is there btw the 140ms periods ?

FWIW I think Valen's approach should work well. The interrupt could be set to happen on both edges (rising & falling), yielding pulse times. Given the bit timing, the number of high and low bits in each high and low timing period could be determined. Thus the bitstream can be reconstructed ... and then parsed and decoded into a hex representation.

[Renate]

Are you quite sure that this is not inverted standard serial data @ 600 baud with 8 bits, 1 start, 1 stop, no parity?

If so, an inverter and a standard UART input will do the job.

[Sparky99]

Thanks for all the help. At present I use a logic anaylyser to study the output signal from the sensor, I then plot the output trace and manually read off the binary data, from this data i then convert the binary code to hex. Allthough vey time consuming its 100% accurate, I have included the latest trace available if that would help to identify what is being sent, I have converted the data to hex digits.11111111100101101101010010010001000100110100111001010101011101001111000 (data deciphered from trace)
1111111110 01 01101101 01 00100100 01 00010011 01 00111001 01 01010111 01 00111100 0 (spaces added by me to clarify)

Converted to required hex vaulues.

01101101 = 6D
00100100 = 24
00010011 = 13
00111001 = 39
01010111 = 57
00111100 = 3C

The sensor only outputs this data when asked for, selected by user pressing a button, no other data is sent.

[Renate]

It wasn't quite apparent what the signal was without the actual signal.
Is this thing an IR transmitter or supposed to be one?
You really could give us a hint.

So, it is a variant of standard serial, with inverted data, 8-N-1-1 running at 500 baud.
The zero is a 1 msec pulse with 1 msec rest.
The one is a 2 msec rest.
(It's not Manchester, not enough transitions.)

You just need to trigger an interrupt on the falling edge.
You don't care about the rising edge because it will always happen 1 mS later.

[Sparky99]

Hi sorry to not answer, The sensor is fitted to a telescope in an observatory. All the motions, pan, tilt, lens settings are measured very accurately and the data is fed into a processor. The processor outputs the data as shown. The telescope is of German design with the electronics made by a Korean company, both companies now finished trading. When the observer focuses on something of interest he operates the “trigger” and the processor outputs the data as shown.
These 6 hex numbers are the exact reference to enable the telescope to be aimed and focused on the same point again.

[jremington]

I tend to agree with Renate but this is not really standard serial, inverted or not. I agree that a "1" bit is a high followed by a low (one bit period) and a "0" bit is high for two half-periods. The way you have spaced out the bits, the pattern is not completely consistent with 8-N-1-1, which would be 10 bits/character, beginning with a 1 bit, followed by 8 data bits and ending with a zero bit. The exception is an extra 0 bit after the preamble.

The bit timing is not clear to me. What is the scale of the horizontal axis in the plot you posted? Note that the "highs" in the plots are always multiples of one "high" timing while the lows are always single (not consistent with Manchester encoding).

To keep things simple, you don't need interrupts to decode this signal. With an Arduino, you can use input polling and micros() to keep accurate track of time. Some variation of the following procedure will work: wait for a falling edge on the input and start the clock. Assuming a bit time of 2000 microseconds wait perhaps 500 microseconds so that you can sample at a convenient position and then sample every 2000 microseconds thereafter, recording a 1 bit if the input is low and 0 bit if the input is high. Use the logical OR and bit shift operators (<<1 or >>1 as appropriate) to accumulate the data bytes. For this method to work, the bit period has to be known quite accurately (to a few microseconds) as any timing error is cumulative and the sampling will eventually get out of sync with the message.

If you are really just beginning with Arduino, study the "blink without delay" tutorial to see how to use micros() to keep track of time. http://arduino.cc/en/Tutorial/BlinkWithoutDelay

Finally, keep in mind that "hex" is just one representation of a number. The bytes could be equally well represented by decimal integers or ascii characters.

Let us know how it goes!

[Renate]

Well, it is enough like standard serial that you could probably pass it through a pulse stretcher and into a standard UART.
The values of the RC should be about right, but will depend on the exact switching points of the Schmidt trigger.
Check with a scope, there should be no glitches in the signal, nor stretched too long.
You can adjust the R.

pulse.png

The "preamble" would just show up as a break.
The pause after the "preamble" is just a pause, no big deal.
The rest of the stuff is just 8-N-1-1.
The data out of the UART would have to be complemented.

The baud rate seems to be 500, but we could use more exact measurements.

Whether you actually decide to implement it this way or not, it would be an interesting test.

[Mee_n_Mac]

I have included the latest trace available if that would help to identify what is being sent, I have converted the data to hex digits.11111111100101101101010010010001000100110100111001010101011101001111000 (data deciphered from trace)
1111111110 01 01101101 01 00100100 01 00010011 01 00111001 01 01010111 01 00111100 0 (spaces added by me to clarify)

Converted to required hex vaulues.

01101101 = 6D
00100100 = 24
00010011 = 13
00111001 = 39
01010111 = 57
00111100 = 3C
r
The sensor only outputs this data when asked for, selected by user pressing a button, no other data is sent.

Do the above hex values represent what the receiver decoded or what you decoded from the bitstream ? IOW how sure are you that those values are 100% correct ? I ask because I don't count 77 clock periods in the attached waveform pic.

(click on to open)

bitstream.jpg

[Mee_n_Mac]

I looked at the pictured bitstream as NRZ-I and come up with a different set of 1's and 0's. Looking at my annotated pic below and dividing the stream into bytes (and adding 2 0's to the end) I get;

11111111 11001011 01101010 01001000 10001001 10100111 00101010 10111010 01111000
0xFF 0xCB 0x6A 0x48 0x49 0xA7 0x2A 0xBA 0x78

(click on to open)

bitstream.jpg

http://en.wikipedia.org/wiki/Non-return ... o_Inverted
Non return to zero, inverted (NRZI) is a method of mapping a binary signal to a physical signal for transmission over some transmission media. The two level NRZI signal has a transition at a clock boundary if the bit being transmitted is a logical 1, and does not have a transition if the bit being transmitted is a logical 0.

[Sparky99]

Sorry for the dalay in replying been working away.
Firstly i must apologise i think i have confused those that have answered. Im not looking to understand what the trace is i allready know that, i have been deciphering these traces for over 4 years using a logic analyser. I can get 100% accuracy, listed below the information is correct
I have included the latest trace available if that would help to identify what is being sent, I have converted the data to hex digits.11111111100101101101010010010001000100110100111001010101011101001111000 (data deciphered from trace)
1111111110 01 01101101 01 00100100 01 00010011 01 00111001 01 01010111 01 00111100 0 (spaces added by me to clarify)

Converted to required hex vaulues.

01101101 = 6D
00100100 = 24
00010011 = 13
00111001 = 39
01010111 = 57
00111100 = 3C
This data string is transmitted in 140ms.

What i need help on is getting the arduino to decipher the data steam and produce the hex characters, on the pc or on a seperate display.
I have played around with baud rates an various settings but can get nothing to give any kind of out put. The sensor output is connected to Ground and Digital pin 2.
many thanks for your help.
This

[Mee_n_Mac]

What i need help on is getting the arduino to decipher the data steam and produce the hex characters, on the pc or on a seperate display.
I have played around with baud rates an various settings but can get nothing to give any kind of out put. The sensor output is connected to Ground and Digital pin 2.
many thanks for your help.
This

Ok, but let's understand what the Arduino 'sees'. When you say '1111111110' to start the bitstream, the trace, which is what the Arduino must translate, is really like the pic below.

bitstream_begin.jpg

Now I've assumed that the pic included the entire waveform. Even so I get an extra '1' compared to your translation. What level is the line sitting at prior to the 1'st bit, a high level or a low level (not seen in trace above) ? Can we assume these levels are 5v and 0v ?

So what's your method ? That's part 1 of programming the Arduino.

[waltr]

Lets further clarify what you have done and what are trying to do:
1- You can read in the serial data steam into bytes. yes?
2- You now want to display (send to PC) the value of these bytes.
3- You want to see these bytes in a Text format such as 6C.
4- To do that you need to convert each nibble (4 bits) of each byte into an ASCII character representing the hex value.
5- This is a very common thing to do so search for "hex to ASCII conversion" for arduino.

OR is this not the problem?
1- Is it that you can not get the arduino to read the serial data stream correctly?
2- For that search for "bit banged" serial receiver code or IR remote serial receiver code.
3- This would be an arduino code project.