UDP Bandwidth in Lidar application

[Controls Guy]

I'm looking at using a Slamtec S2E Lidar scanner, not quite industrial grade, more like Roomba/Battlebots.   I can talk to it manually via UDP and it works.   It has two modes for the data return from the scan, normal (1 measurement per 60-byte packet) and 'Express' (40 measurements per 126-byte packet).    You're supposed to be able to change the motor rpm, and it feels like it does, but parsing the return data seems to indicate it's doing about 600 rpm (10 Hz).  Both modes seem to send a packet about every 1.25ms.

I'm only interested in about 45 degrees of arc, and while I would like that 45 degrees to be scanned fast, I don't necessarily need 10 scans per second.   So the upshot is that I'm getting about  3600 degrees/sec of data when I could live with maybe 500, but I can filter the data myself for angle and throw away every other scan or something like that.   So I have two questions:

1) Is it feasible for BRX to process 800 60 to 126-byte packets a second?   I could dedicate a BRX to it with next to no logic.

2) Has anyone on the forum used this sensor and knows if the scan angle and/or rate can be adjusted and how?   Another thing that would work would be if there's a single scan request but I don't see any defined in the protocol.

Thanks!

[Controls Guy]

Oh, and the packet rate/size in addition to the rotational speed and the scan angle.

[BobO]

I'd say there is a good chance it could keep up.

[Controls Guy]

I'm looking into ways to filter the data before it's sent.  Plus 80-90% of packets I can just toss, outside the angle gate or the scan frequency gate.

[Controls Guy]

Maybe tomorrow I'll have time to try it with a BRX.

[Controls Guy]

Project update:  I decided the previous sensor wasn't going to work so now I'm qualifying No. 2.

67ms (15Hz) data interval.   About 50 byte header with misc sensor and scan info, comma delimited, followed by about 250-300 data points comma delimited.

Now here's the weird part.   Response packet is mixed ASCII and numeric, but the numeric is encoded in variable length hex (383==0d900 in a 4 byte field vs. 03 83), then the hex values are sent as comma delimited ASCII! 

Is it feasible to decipher that from Hex-as-ASCII to Real-People-Numbers at 300 values every 67ms plus have some time for stat/math analysis?   Seems doable to me, but maybe more like a PC job.

[BobO]

Project update:  I decided the previous sensor wasn't going to work so now I'm qualifying No. 2.

67ms (15Hz) data interval.   About 50 byte header with misc sensor and scan info, comma delimited, followed by about 250-300 data points comma delimited.

Now here's the weird part.   Response packet is mixed ASCII and numeric, but the numeric is encoded in variable length hex (383==0d900 in a 4 byte field vs. 03 83), then the hex values are sent as comma delimited ASCII! 

Is it feasible to decipher that from Hex-as-ASCII to Real-People-Numbers at 300 values every 67ms plus have some time for stat/math analysis?   Seems doable to me, but maybe more like a PC job.

If you can stay in co-processor based integer instructions for the variable length extraction, the conversion should be fine. Not sure what the stats would look like though. Should be pretty easy to test. But yeah, bleeding over into what a PC would do better.

[Controls Guy]

Thanks, BobO.  I'm beginning to think there's PLC pieces and PC pieces, so its probably going end up as a hybrid.  Would need I/O anyway if it were pure PC job, for example, so might as well get a PLC CPU to do the part of the work it excels at vs. just using straight I/O.