Tweet
Hi Hitby,
wow! You are much faster than I expected. Even faster than the brand new garlic service
1.-------------------
How did you account for TMP102 being a 3.3V type?
2.------------------
RPM: Arduino offers plenty ways to measure rpm SW or HW. As we want to have a fast system we should focus to HW frequency measurement.
A. Either counting a counter directly and look at it after i.e. 1ms and reset it. The counts represent frequency.
B. Else let counter run by internal clock and let rpm sensor perform an interrupt. The contence of the counter represents pulse time and can be transferred into rpm.
In both cases we need to decide at what lowest rpm we want to have valuable values. Upper frequency is no problem. Here are some links 1 2
And we can understand now that we an not load a single Arduino with all tasks. I.e. at using timers we get conditions impeding each other. It will be no major problem if motor control / pulser gets another rpm signal. For first tiem research state it is the by far fasterst approach.
Of course for further elicitations we can refine. But it would be helpful if we have a separated data acquisition system we can add deliberately at any running setup if we want to look deep into it. Please all think in terms of building stones and not in terms of monolitoc finla all in one solutions. Those refer to cost reduction for series production - and there it pays of course!
3.----------------
Regarding format: Sorry it was a misunderstanding. I referred to an # id at begining of every line printed. But it can be made more easy.
i.e.
If we transmit command #2 to Arduino it will start and continue string type #2 up to the next command.
Examples:
#1 For good reading at terminal
Input voltge[mV]: 873<TAB> Input current[A]: 23.55<CR><LF>
Temp1[°C]: 18.19<TAB>Temp2[°C]: 28.06<CR><LF>
#2 For CVS format i.e. as input to dashboard. This format can be fixed in order to interface to dashboard while others can be changed deliberately. This format is important for maximum throughput of data.
873,8.19,3960,28.06,1545,3177<CR>
#3 For whatever we decide to
873 8.19<TAB>3960<TAB>28.06<TAB>1545<TAB>3177<CR>
#4 i.e. raw data in hex notation for absolut fastest data acquisition
Default will be #1 for good reading while dashboard will initialize i.e. with #2 making irrelevant all other controls being implemented.
4.--------------
It would be helpful introducing another command like: t5 telling arduino to transmit a line of values every 500ms.
Default will be i.e. 9 while dashboard will initialize i.e. with t1
5.-----------
Please regard that ADC incorporates a controllable preamplifier. It might be important to regard for it.
Thanks for your contributipn
JS
wow! You are much faster than I expected. Even faster than the brand new garlic service
1.-------------------
How did you account for TMP102 being a 3.3V type?
2.------------------
RPM: Arduino offers plenty ways to measure rpm SW or HW. As we want to have a fast system we should focus to HW frequency measurement.
A. Either counting a counter directly and look at it after i.e. 1ms and reset it. The counts represent frequency.
B. Else let counter run by internal clock and let rpm sensor perform an interrupt. The contence of the counter represents pulse time and can be transferred into rpm.
In both cases we need to decide at what lowest rpm we want to have valuable values. Upper frequency is no problem. Here are some links 1 2
And we can understand now that we an not load a single Arduino with all tasks. I.e. at using timers we get conditions impeding each other. It will be no major problem if motor control / pulser gets another rpm signal. For first tiem research state it is the by far fasterst approach.
Of course for further elicitations we can refine. But it would be helpful if we have a separated data acquisition system we can add deliberately at any running setup if we want to look deep into it. Please all think in terms of building stones and not in terms of monolitoc finla all in one solutions. Those refer to cost reduction for series production - and there it pays of course!
3.----------------
Regarding format: Sorry it was a misunderstanding. I referred to an # id at begining of every line printed. But it can be made more easy.
i.e.
If we transmit command #2 to Arduino it will start and continue string type #2 up to the next command.
Examples:
#1 For good reading at terminal
Input voltge[mV]: 873<TAB> Input current[A]: 23.55<CR><LF>
Temp1[°C]: 18.19<TAB>Temp2[°C]: 28.06<CR><LF>
#2 For CVS format i.e. as input to dashboard. This format can be fixed in order to interface to dashboard while others can be changed deliberately. This format is important for maximum throughput of data.
873,8.19,3960,28.06,1545,3177<CR>
#3 For whatever we decide to
873 8.19<TAB>3960<TAB>28.06<TAB>1545<TAB>3177<CR>
#4 i.e. raw data in hex notation for absolut fastest data acquisition
Default will be #1 for good reading while dashboard will initialize i.e. with #2 making irrelevant all other controls being implemented.
4.--------------
It would be helpful introducing another command like: t5 telling arduino to transmit a line of values every 500ms.
Default will be i.e. 9 while dashboard will initialize i.e. with t1
5.-----------
Please regard that ADC incorporates a controllable preamplifier. It might be important to regard for it.
Thanks for your contributipn
JS
Comment