Optimum sampling strategy for unknown function
$begingroup$
this question is derived from a technical context (which I'll describe below so you get where this is aimed), but I think it's more of a math probelm: Assume you want to measure a sensor output which can have values from say 0 to 100 (we measure every second for example). This could be a temperature or a pressure or something like this. Now, sometimes nothing much happens for a long time, but then there may be a quick rise of temp/pressure/whatever. What I want to do is to log the value but not waste a lot of memory on logging basically the same value over and over again (memory space is the expensive quantity), but on the other hand I do not want to loose information in case something "interesting" happens.
Lastly, the signal may be noisy.
Thats it for the technical background.
The first idea that comes to mind is sampling with an equidistant sampling time interval (every five minutes or so). But this may lead to either producing lots of useless data or miss interesting movements.
My second thought is to lay a grid over the area, e.g. only measure when the signal crosses a line on the grid, e.g. when it goes from 0x to 1x and so on.
But in this case you could be ending up with signals that slightly vary from say 9 to 11 and although the signal is basically constant you produce a lot of data.
Furthermore, if you choose the distances to small you log a lot of noise.
Third idea: only log when the signal has changed by a certain relative amount, e.g. 10 percent, but then a change from 1 to 2 is 100 percent, while in a region of 90 only a change of 9 will trigger the next log-event, although this might be the region of interest.
I dont find any of the above ideas are good enough and I have the feeling that there might be some elegant solution to this I just couldn't think of.
I don't even have a term to search for or what this might be related to.
Lastly I hope its ok to not include any graphs or equations, I hope that you can understand clearly what I am asking for, Thanks.
EDIT: I am working on a microcontroller, so no complicated post-processing is easily possible.
sampling
asked Jan 3 at 21:43
jjstcooljjstcool
2008
$endgroup$
add a comment |
$begingroup$
this question is derived from a technical context (which I'll describe below so you get where this is aimed), but I think it's more of a math probelm: Assume you want to measure a sensor output which can have values from say 0 to 100 (we measure every second for example). This could be a temperature or a pressure or something like this. Now, sometimes nothing much happens for a long time, but then there may be a quick rise of temp/pressure/whatever. What I want to do is to log the value but not waste a lot of memory on logging basically the same value over and over again (memory space is the expensive quantity), but on the other hand I do not want to loose information in case something "interesting" happens.
Lastly, the signal may be noisy.
Thats it for the technical background.
The first idea that comes to mind is sampling with an equidistant sampling time interval (every five minutes or so). But this may lead to either producing lots of useless data or miss interesting movements.
My second thought is to lay a grid over the area, e.g. only measure when the signal crosses a line on the grid, e.g. when it goes from 0x to 1x and so on.
But in this case you could be ending up with signals that slightly vary from say 9 to 11 and although the signal is basically constant you produce a lot of data.
Furthermore, if you choose the distances to small you log a lot of noise.
Third idea: only log when the signal has changed by a certain relative amount, e.g. 10 percent, but then a change from 1 to 2 is 100 percent, while in a region of 90 only a change of 9 will trigger the next log-event, although this might be the region of interest.
I dont find any of the above ideas are good enough and I have the feeling that there might be some elegant solution to this I just couldn't think of.
I don't even have a term to search for or what this might be related to.
Lastly I hope its ok to not include any graphs or equations, I hope that you can understand clearly what I am asking for, Thanks.
EDIT: I am working on a microcontroller, so no complicated post-processing is easily possible.
sampling
asked Jan 3 at 21:43
jjstcooljjstcool
2008
$endgroup$
1
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
1
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14
add a comment |
$begingroup$
this question is derived from a technical context (which I'll describe below so you get where this is aimed), but I think it's more of a math probelm: Assume you want to measure a sensor output which can have values from say 0 to 100 (we measure every second for example). This could be a temperature or a pressure or something like this. Now, sometimes nothing much happens for a long time, but then there may be a quick rise of temp/pressure/whatever. What I want to do is to log the value but not waste a lot of memory on logging basically the same value over and over again (memory space is the expensive quantity), but on the other hand I do not want to loose information in case something "interesting" happens.
Lastly, the signal may be noisy.
Thats it for the technical background.
The first idea that comes to mind is sampling with an equidistant sampling time interval (every five minutes or so). But this may lead to either producing lots of useless data or miss interesting movements.
My second thought is to lay a grid over the area, e.g. only measure when the signal crosses a line on the grid, e.g. when it goes from 0x to 1x and so on.
But in this case you could be ending up with signals that slightly vary from say 9 to 11 and although the signal is basically constant you produce a lot of data.
Furthermore, if you choose the distances to small you log a lot of noise.
Third idea: only log when the signal has changed by a certain relative amount, e.g. 10 percent, but then a change from 1 to 2 is 100 percent, while in a region of 90 only a change of 9 will trigger the next log-event, although this might be the region of interest.
I dont find any of the above ideas are good enough and I have the feeling that there might be some elegant solution to this I just couldn't think of.
I don't even have a term to search for or what this might be related to.
Lastly I hope its ok to not include any graphs or equations, I hope that you can understand clearly what I am asking for, Thanks.
EDIT: I am working on a microcontroller, so no complicated post-processing is easily possible.
sampling
asked Jan 3 at 21:43
jjstcooljjstcool
2008
$endgroup$
this question is derived from a technical context (which I'll describe below so you get where this is aimed), but I think it's more of a math probelm: Assume you want to measure a sensor output which can have values from say 0 to 100 (we measure every second for example). This could be a temperature or a pressure or something like this. Now, sometimes nothing much happens for a long time, but then there may be a quick rise of temp/pressure/whatever. What I want to do is to log the value but not waste a lot of memory on logging basically the same value over and over again (memory space is the expensive quantity), but on the other hand I do not want to loose information in case something "interesting" happens.
Lastly, the signal may be noisy.
Thats it for the technical background.
The first idea that comes to mind is sampling with an equidistant sampling time interval (every five minutes or so). But this may lead to either producing lots of useless data or miss interesting movements.
My second thought is to lay a grid over the area, e.g. only measure when the signal crosses a line on the grid, e.g. when it goes from 0x to 1x and so on.
But in this case you could be ending up with signals that slightly vary from say 9 to 11 and although the signal is basically constant you produce a lot of data.
Furthermore, if you choose the distances to small you log a lot of noise.
Third idea: only log when the signal has changed by a certain relative amount, e.g. 10 percent, but then a change from 1 to 2 is 100 percent, while in a region of 90 only a change of 9 will trigger the next log-event, although this might be the region of interest.
I dont find any of the above ideas are good enough and I have the feeling that there might be some elegant solution to this I just couldn't think of.
I don't even have a term to search for or what this might be related to.
Lastly I hope its ok to not include any graphs or equations, I hope that you can understand clearly what I am asking for, Thanks.
EDIT: I am working on a microcontroller, so no complicated post-processing is easily possible.
sampling
sampling
asked Jan 3 at 21:43
jjstcooljjstcool
2008
asked Jan 3 at 21:43
jjstcooljjstcool
2008
edited Jan 3 at 22:08
jjstcool
asked Jan 3 at 21:43
jjstcooljjstcool
2008
asked Jan 3 at 21:43
jjstcooljjstcool
2008
asked Jan 3 at 21:43
jjstcooljjstcool
2008
2008
1
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
1
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14
add a comment |
1
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
1
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14
1
1
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
1
1
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "69"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f3061038%2foptimum-sampling-strategy-for-unknown-function%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Mathematics Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f3061038%2foptimum-sampling-strategy-for-unknown-function%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
$begingroup$
basically whenever you have too much data, compression is good choice. run-length encoding is good choice in this case, with some 10% error margin where the data will be considered the same value. If you store both the value and how many times the same value was encountered, recovering the full log is still possible.
$endgroup$
– tp1
Jan 3 at 22:00
$begingroup$
at tp1: see my edit. I think the run-length encoding is not exactly what I want, but it gave me something to look at, a starting point. Thanks
$endgroup$
– jjstcool
Jan 3 at 22:16
1
$begingroup$
The general term you are looking for is data compression. You assume your data has certain characteristics, like being stable for long periods of time, and record the other information, like transition times and new levels. In your case, how you distinguish transitions from noise is the hard part.
$endgroup$
– Ross Millikan
Jan 4 at 0:14