Serial or count?

[dsaari]

Hello all,
I've been trying to utilize a pic to receive some input data from a light bar, and I'm struggling. The light bar (array of 40 send/receive pairs) outputs data in the following way; one long start pulse, then up to 40 subsequent pulses representing which beams are being blocked. The cycle then repeats. I've attached the datasheet for reference. I think that if I can getc 5 bytes starting after I see the start pulse, this might work. In fact my first getc works great but it appears as though there is missed data when I attempt additional getc's. I am not a serial communications expert by any means. All I did was looked at the data sheet to determine the baud rate of 1244, and set my pic to that. I have a sync pulse from the sensor going into the pic so I know when the transmission is about to start. The two while loops and the delay_us seem to allow my first getc to capture the correct information. The first byte seems to work great. if I block more than 8 beams the second getc doesn't capture it. Not until I block nearly half the beams do subsequent getc's capture anything and it really doesn't make sense. I am actually wondering if I need to setup the #use 232 differently since I don't have start bits and parity checking going on. Any pointers? Another path I started down was to actually count these pulses but this seems much nicer if I can just read them serially.

Lightbar data sheet:
https://dl.dropboxusercontent.com/u/33977865/SG14%20Digital%20Output%20User%20Manual%201%203.pdf
Compiler version 5.006

[Ttelmah]

The UART, _requires_ start bits. This is how async comms 'works'. The start bit is needed every eight or nine bits. So it isn't going to work using the UART.

The way to do this, is using the hardware timers and interrupts.
You'd need to start by timing the gap between a subsequent rising/falling edge, till you find one that is longer than 1mSec. This then starts your 'seek' cycle. You then time at intervals just a fraction 'early' of the 1.176mSec interval from this point, and if the signal is high, then the pulse is on. Repeat for the number of channels in use.
Hardware timer.

Best Wishes

[dsaari]

Ok, I suspected I needed to do that, just hoping for an easy way out. Anyway, I got it working, I've populated an array of 40 shorts (one for each channel). Now I need to serial out the information to a PLC. So I was thinking of moving the information into 5 bytes that I could send out. I was looking at a few built in functions that might make this elegant/simple but I don't see anything right off. Is there a way to simply shift the bits out of this array[40] into byte sized variables? Sorry for the stupid question, just point me in a direction, I'll get it.

Thanks in advance.

[dsaari]

Not real pretty or elegant but functional....

[FvM]

CCS C has a built-in function shift_left() for this purpose.

[John P]

What a truly atrocious interface! They have a limited grasp of spelling, too.

You will have to bet that your clock matches the unit's clock fairly exactly, and look for a pulse each from the un-blocked channels, at 0.804ms intervals. But if you don't really care which channels are clear or blocked, you could ignore which specific ones are clear; just count the pulses and see if you get 40 of them per cycle. By the way, they don't seem to specify the length of a pulse, only the spacing between trailing edges.

On the other hand, the time for a full cycle is specified, at 37msec. If that's accurate, you could use it to calibrate your processor's clock to match the sending unit, and thus be more confident in reading the line at the right times to get all 40 of the incoming pulses. But why can't they send 40 pulses and make them show the blocked/clear status by being "long" or "short"?

[rnielsen]

If you're simply concerned if the light bar is blocked or clear then I might suggest John's approach and just count how many pulses you receive. If you get all 40 of them then it's clear. If you receive less than 40 then you know it's blocked somewhere.

I don't think it would matter where the block is as long as you know it's blocked somewhere. Otherwise, this could be a timing nightmare.

Ronald

[gilroy]

You have, a programmable divider. Gives /2 to /33. Requirement is that the output of this must be in the range 0.8MHz to 8MHz.
This is followed by the PLL, which gives *2 to *513. Again programmable. Requirement here is that the output must be between 100, and 200MHz.
This is followed by another divider, which gives /2, /4 or /8. Output must be between 12.5, and 80MHz.




___________
Go through the braindumps design tutorial and 642-813 dumps guide to learnuseful web design skills. Become expert in web design with COMPTIA online course. For more detail Massachusetts Institute of Technology (MIT) best of luck

[FvM]

[Ttelmah]

I don't think you have to oversample.

The way to receive this, is to initially 'forget' times. It is basically an 'edge' protocol. The pulse width is specified as very variable. All you have is the simple thing of the presence of an edge, or not.

Have an array of 'times' all set to zero.
Then start by looking for a rising edge.
On this, setup a CTC interrupt to record every falling edge 'time' relative to this, and setup a 'timeout' to trigger at about 36mSec.
On the first interrupt, if the time you record is less than 0.952mSec, or greater than 1.352mSec, you go back to waiting for a rising edge.
Else, you just start recording the times of every falling edge, till the count is 40, or you see the timeout.

You then just analyse the times. Start with an array of 40 bits, all 'off'.
Then for the time of each falling edge, subtract 1.176mSec, and divide by 0.804mSec. The value you get from this, is the bit number to turn on.

You then have the frame decoded.
If you record the times in uSec (say), then calculations become simple integer arithmetic. With a bit of care, you can build in some rounding to cover a degree of timing variation.

Now, given there are 40 pulses, which could have all missing, or all present, you can't have more than a total error of 41/40 in the timing, without the calculation they show failing. 2.5%. Allow for a maximum of half this, gives a minimum time of 794uSec, versus their 804 'nominal'.

So with their example time of 32.528mSec - 32528uSec - 1176 = 31352/794 = 39.48 (39 using integer maths), so this sets bit 39. Edge times between 32.142, and 32.936mSecs will all be accepted as bit 39. Their 'nominal' value, is pretty much bang in the centre of this, and it won't accept the next value down by mistake. (using their calculation, 31.724mSec).

Best Wishes

[FvM]

Recording edge times is in fact an intelligent way to decode the protocol.

You may want to understand it as a kind of oversampling with "infinite" respectively very high resolution.

[Ttelmah]

and (of course), made easier by the PIC having hardware to do it.

It is an 'odd' protocol, since it actually requires very accurate timings, or it is going to fail (as with any protocol using a 'long' gap between synchronisation points, with a lot of 'bits' being sent in the gap, yet has a huge variation in the pulse widths they use. But if you study the way they talk about the times, and their example, it is the durations between falling edges that they expect to 'rely' on.

Best Wishes