Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
samplestream:start [2024/04/18 00:47] optrix |
samplestream:start [2024/04/24 03:02] (current) optrix |
||
|---|---|---|---|
| Line 6: | Line 6: | ||
| * Applications where you need to search for events across time-windows, | * Applications where you need to search for events across time-windows, | ||
| * When you need very reliable ' | * When you need very reliable ' | ||
| + | * When you need to correct for lag based on a measurement rather than a fixed time\\ | ||
| - | ===How It Works=== | + | ===Key Classes/ |
| - | SampleStream lets you //iterate// over a query. | + | The key classes in the library are... |
| - | SampleStream takes an AQL request, a [[window size|window size]], a [[number of samples|number of samples]] | + | [[ssintro|samplestream]], used to scan over time-frames, |
| - | Every time you ask SampleStream for the next sample of data, it returns | + | [[class_LagCorrection|LagCorrection]], used to measure |
| - | For example, if you wanted | + | [[class_LagCorrectedQuery|LagCorrectedQuery]], used to create historical queries with lag-corrected data. |
| - | The next time you ask for a sample of data, it will be //step size// seconds away from the previous sample. | ||
| - | |||
| - | This makes it quite easy to scan over a period of time. | ||
| - | |||
| - | ===Differences to a Normal Query=== | ||
| - | |||
| - | There are some key differences between using SampleStream and a normal ARDI query... | ||
| - | |||
| - | ==Long Time Frames== | ||
| - | |||
| - | In the background, SampleStream only requests //part// of the data range you've requested (unless the time-frame is very small). | ||
| - | |||
| - | In long time-frames or very high-resolution data, there may be thousands or even millions of individual records to be process. Rather thank asking for them all at once - which can be stressful to the ARDI server and the systems it connects to - it requests a small window ahead of your current position. | ||
| - | |||
| - | This means your application never consumes too much memory or system resources at any one time. If you're searching for an event, it also means you can break out of the loop at any time and you won't request any redundant data from ARDI. | ||
| - | |||
| - | This is particularly useful if you don't know how far away your search target is - in some cases the data you're looking for is only seconds ago, but some applications might have //days// of the system being stopped/ | ||
| - | |||
| - | ==Consistent Time Buckets== | ||
| - | |||
| - | ARDIs APIs don't guarantee consistent time gaps in the data you get back from a query. Particularly if you're requesting discrete data (such as on/off signals), the returned time-stamps might be erratic. | ||
| - | |||
| - | The data returned from SampleStream is always consistently spaced. | ||
| - | |||
| - | ==Discrete Splitting== | ||
| - | |||
| - | As part of the previous point, the system also breaks discrete signals into different channels for each value. | ||
| - | |||
| - | For example, if you ask for a property that has a value of ON or OFF, instead of getting a single property back, you'll get **two** - one for ' | ||
| - | |||
| - | For each, you'll get the **percentage of the time window that the property was equal to the value**. | ||
| - | |||
| - | ==AI Normalisation and Formatting== | ||
| - | |||
| - | The samples include specific functions to return their results in formats that are suitable for use in AI, such as **Tensorflow**. | ||
| - | |||
| - | These are ready for immediate use in RNN or Convolutional Neural Network applications. | ||