Optimum sampling strategy for unknown function












0














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.










share|cite|improve this question




















  • 1




    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.
    – tp1
    Jan 3 at 22:00










  • 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
    – jjstcool
    Jan 3 at 22:16






  • 1




    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.
    – Ross Millikan
    Jan 4 at 0:14
















0














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.










share|cite|improve this question




















  • 1




    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.
    – tp1
    Jan 3 at 22:00










  • 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
    – jjstcool
    Jan 3 at 22:16






  • 1




    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.
    – Ross Millikan
    Jan 4 at 0:14














0












0








0







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.










share|cite|improve this question















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






share|cite|improve this question















share|cite|improve this question













share|cite|improve this question




share|cite|improve this question








edited Jan 3 at 22:08

























asked Jan 3 at 21:43









jjstcool

2008




2008








  • 1




    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.
    – tp1
    Jan 3 at 22:00










  • 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
    – jjstcool
    Jan 3 at 22:16






  • 1




    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.
    – Ross Millikan
    Jan 4 at 0:14














  • 1




    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.
    – tp1
    Jan 3 at 22:00










  • 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
    – jjstcool
    Jan 3 at 22:16






  • 1




    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.
    – Ross Millikan
    Jan 4 at 0:14








1




1




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.
– tp1
Jan 3 at 22:00




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.
– tp1
Jan 3 at 22:00












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
– jjstcool
Jan 3 at 22:16




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
– jjstcool
Jan 3 at 22:16




1




1




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.
– Ross Millikan
Jan 4 at 0:14




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.
– Ross Millikan
Jan 4 at 0:14










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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














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





















































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







Popular posts from this blog

1300-talet

1300-talet

Display a custom attribute below product name in the front-end Magento 1.9.3.8