Sensor Data

Question

Sensor Data

Steve Jones - SSC Editor

SSC Guru

Points: 736183
More actions
September 2, 2013 at 9:01 pm

#281953

Comments posted to this topic are about the item Sensor Data

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Dalkeith Hall of Fame Points: 3688 More actions · Answer 1

This is an excellent topic. I do a bit of work for a timing company. I actually helped time the Haddington Sprint Triathlon on Sunday last weekend. We can time races of anything up to 10,000 racers. We could do bigger but we probably would have to buy in extra RFID chips.

The set up is essentially no different to a stock and inventory tracking system although we don't do geographic tracking. Times are recorded at specific locations and direction is inferred from the timing points.

For people just starting to get into this area our main problems arise as a result of ommitted data. RFID companies will tell you that the percentage reads is exceptionally high for their particular antennae's but be cautious of any claims and if possible try and independently verify any sales claims. Both passive and active chips are frequently compromised and in many situations it is almost impossible to obtain information unless you have good backup systems. This is outside the realms of pure SQL design but you guys will be the first to spot the ommissions.

We are dealing with only small sets of data compared to data for a large company but even then the boxes generate a lot of information the software actually chucks 90% out. Not that its inaccurate because its too sensitive. Typically the reading boxes are dumb and just produce text files or text streams. If someone goes over a matt they could read 20 times. With each read happening within a fraction of the other.

Gating and how you deal with that can have major performance hits on databases. People have solved these problems though so solutions do exist.

cloudydatablog.net

rmontgom Old Hand Points: 343 More actions · Answer 2

I think I remember a few years ago an article about some larger grocery store tracking movements of shopping carts through the store as a way to track and map customer movements. The idea being to determine common routes, sequence, popularity, time spent per area (product), etc. They could then compare sales per product to traffic patterns, and to exit patterns to cashier placements.

This would then be used (as an example) to improve product placements. And not the way you might think. Oh no, don't put most popular things towards the front. Rather, lay out the store so as to lead people past less frequently visited areas en route to more popular ones as a way to boost sales of the former.

webrunner SSC-Dedicated Points: 31862 More actions · Answer 3

Fascinating idea. Does anyone have any suggestions for sites or books that discuss how to integrate a sensor and a SQL database? Sounds like that would be fun to try.

Thanks,

webrunner

-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Robert-378556 SSCertifiable Points: 5917 More actions · Answer 4

webrunner (9/3/2013)
Fascinating idea. Does anyone have any suggestions for sites or books that discuss how to integrate a sensor and a SQL database? Sounds like that would be fun to try.
Thanks,
webrunner

Usually there's no direct integration. Sensors capture data and forward it to application in text or binary format. Application can poll sensor or install an event handler (=interrupt handler or equivalent to sql trigger) that's triggered on incoming event (new data).

Application can do anything with the data, filter, analyze and insert results and/or raw data into database.

For example, video surveillance starts recording only when something changes in input stream, handling application takes care of noise tolerance (daylight change, flies, mosquito,... ).

First step is to decide what kind of data you want to capture and what kind of sensors you want to play with.

webrunner SSC-Dedicated Points: 31862 More actions · Answer 5

Robert-378556 (9/4/2013)
webrunner (9/3/2013)
Fascinating idea. Does anyone have any suggestions for sites or books that discuss how to integrate a sensor and a SQL database? Sounds like that would be fun to try.
Thanks,
webrunner
Usually there's no direct integration. Sensors capture data and forward it to application in text or binary format. Application can poll sensor or install an event handler (=interrupt handler or equivalent to sql trigger) that's triggered on incoming event (new data).
Application can do anything with the data, filter, analyze and insert results and/or raw data into database.
For example, video surveillance starts recording only when something changes in input stream, handling application takes care of noise tolerance (daylight change, flies, mosquito,... ).
First step is to decide what kind of data you want to capture and what kind of sensors you want to play with.

Ah, I see now. Thanks for your reply!

- webrunner

-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html