Sorry, I fail to see where this is going. If I know that the crankshaft turns exactly 360 deg. But with time and say a count of increments alone I cannot assign an exacty or am I overlooking the meaning of your post?
Makes sense. I'll probably wont go down into more low level coding to be honest and just take the short delay as given
I'm using a Lavision System along with their software called Davis. It compiles the frames into datasets in a format called .im7 it's pretty easy to access frames on that with matlab or python. I am not that far into the postprocessing yet but I've seen applications for large imagery (?) data sets using the xarray and python to organise, label and evaluate data. Hope that helps
I guess what I'm asking is how you determine which frame corresponds to which encoder interrupt. When you get the TDC start signal does that start recording frames one per encoder interrupt so that you can then access a particular one via some index?
I will take a SWAG and say the crank is missing a tooth that corresponds to TDC (Top Dead Center).
Doesn't say how this signal is created.
If you're just asking on how the TDC signal is created by the engine - there's a magnetic element put on the exhaust-sided camshaft and a corresponding sensor that reads the signal and puts it through to the control unit.
Edit: Well actually that's how the igntion TDC is created (its a 4 stroke). I also have a plain TDC signal which is created by a second rotary decoder sitting opposite of the 3600 increment decoder but only has one increment on its part of the shaft, if you get what I mean.
I was just curious how you had thought about this next step. I personally have considerable experience recording data that is synchronized to crank angle degree. For a one cylinder ICE, you can use the TDC signal you get from the engine if it's accurate. If your encoder has an index pulse, you can synchronize that to a mark on the flywheel with a strobe light triggered by the index pulse, etc. Whatever method you use can then start the interrupt service routine to start acquiring samples at each encoder interrupt. You can take the data asynchronously and flag the sample that occurs at TDC by setting a most significant bit/byte and then scanning the array for that starting sample, or any number of other ways.
I was just curious how you had thought about doing that. It's not important that you answer.
1 Like
I'm always interested in a discussion. What you're saying is actually really helpful I haven't thought on a visual clue to index a reference frame.
The engine is configured in a bowditch build. You can find some pictures on that on Google if you're not already familiar with it.
I'm telling you this because it means I am looking inside the engine through a glass piston from the bottom up. I can probably also arrange to bring in a light source from the side right beneath to firing deck on the upper part of the combustion chamber. A flash of light through a big flash or a smaller light thread might actually be possible. Triggered at a defined point on the crank angle, this might indicate the reference frame in the post processing directly! This is great, thanks a lot! I'm stoked to work that out somehow
Happy to stimulate a thought whenever possible! 
1 Like
At 1RPM, that is 360 degrees per minute. That is also 6 degrees per second. That is also .006 degrees per millisecond. If you count 10 milliseconds from TDC, how many degrees would that be? Same calculation steps for 1000RPM, or any measured RPM.
Unfortunately, it's not that simple. RPM varies significantly during a revolution and makes it impossible to accurately predict degrees of rotation based on time. Hard to simulate at home perhaps but if you plot the encoder output versus time you'll see the difference.
e.g the piston slows down on a compression stroke and speeds up during combustion.
It will be true if a large, heavy flywheel is used.
Better but not good enough for precise measurements. For example, if you are indicating cylinder horsepower by integrating cylinder pressure vs cylinder volume you are off by several percent if you take your samples based on time instead of actual angle.
That also requires an unlimited budget!
It is quite practical and relatively inexpensive to synchronize measurements to the output of a shaft driven encoder as OP is doing.
Maybe I am misunderstanding what you mean by an unlimited budget.
Well, RPM is ALWAYS a lagging measurement. Any synchronizing is ALWAYS a lagging measurement. So is taking a photo of something. The time is ALWAYS when the command is given, not necessarily when the photo was taken.
It's been so long, I am not sure, anymore, but are digital photos a scanning of the pixel array, one at a time, or is a full row or column transferred to memory in a single step?
True but I assume data transfer times as neglect able. The cameras are global shutter which means the full sensor is read almost at once. Max speed of the slowest camera is 22kHz which means internal data transfer must be lower than ~45us. The images are stored entirely in camera RAM before transferring them to a disk drive after a measurement which is why it's pretty quick, I guess
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.