Found weird thing. Granity in test stimulus mode sometimes jerks one direction.
You can see it on the graph below. It also at some position has weird resistance bump.
Something wrong with math somewhere…
It’s strange - I thought German encoder is 3000ppr and your one setup for 2048 and also no commutation…
It looks like you have the same noise. No difference.
It could be ADC noise of Simucube itself…
I don’t really want to change back to 10K for now, but I checked before - it was rock solid.
If you will round up sincos output to the nearest PPR - it will be also solid.
All noise and drift is those microsteps.
Could you put scope frequency to 50hz and check if you have any drift? Just check that number is not going slowly one direction…
Changed to 50hz just says scope waiting edit somethings happening but still says scope waiting. how long do you want me to run it for?
It’s ok - it takes a minute to collect points for 50hz. It shows after some number of points collected… So 50hz is slower
1 Like
So Im looking at how it resolves position during vibration.
This one 2M resolution
This one 0.5M resolution
You can clearly see that there is no difference - it just doesn’t have 2M in it.
Looks like it’s stable. I found that Chinese one stable in some position and in others it drifts away…
Can you try to find such position where it will be slowly moving up or down?
You can just check number in the position.
Not sure what you mean. Do you want me to do the .5m 2m test if so do i just have to change to x16 or change the ppr as well?
Mash do you want to do a discord chat or something?
Just changed to just to x16 the noise the jocking makes is bigger ie larger wave
Ok, I’ve found where 2M is better than 0.5M. So I’m setting up program for tiny tiny vibrations. I can clearly feel them and see on a position change. But they barely noticable.
2.0M
0.5M
It becomes even more obvious if we check calculated speed out of those 2.
2.0M - it’s very noisy as you can see
0.5M - this one is complete useless crap
Since I can feel those movements, I would assume that it should have real difference.
Now it’s a question where is this noise comes from, is it real drift and how to fix those.
Yes, let’s do chat.
You need to change PPR for sure.
Have you got discord?
used 131072 still sounds different
To make one thing clear - Tomo‘s SinCos isn‘t gernan overall, it only has a german IC inside and it is the same that Mash is using respectively that is sold by Mige itself.
The german one that Mash wants to see compared to his ist the Heidenhain that is sold by Simtronix, and that has 3600 lines.
I will get one within the next weeks, but for comparison I would need someone in the area of munich that uses the small Mige Mige with the chinese one sold by Tomo/Mige.
So outcome of test:
- There is a noise and drift. Absolute encoder would still seriously benefit accuracy
- 2M has significant impact on velocity/acceleration calculations vs 0.5M on absolutely sensible movements.
- We maybe don’t need accuracy, but only resolution. It’s possible that drift doesn’t matter as well as spikes. If Simucube does reasonable filtering - resolution is there and it’s very possible that more accurate encoders would yield zero value.
With current Ioni capabilities of 4/6/8 bit only 3600 lines would yield lower resolution. So even if accuracy is better it’s probably going to make worse result at small details.
P.S. Use same test as what I did. With DIV/MUL set to 20 run test stimulus with 0.02 seconds and 20/-20 setpoints and post how position velocity achieved graph at 20kHz looks like.
This is how it looks on Chinese sincos.
Yeah Mash cleared that up for me but Thanks
As soon as I have my encoder I will do the test, but this may take up to two further weeks.
I really would like to understand few things about Simucube:
- How does it calculate velocity and acceleration? From charts above you can clearly see that calculation of velocity is extremely primitive and from positional data it can be actually calculated way way better. Now if acceleration calculated from that velocity in a same way - it would be even worse. And I assume that both those things are critical for Simucube.
- I also wonder if there is a positional filter in Simucube and how it works. Again, it can be primitive averaging that would have lag, it could be low pass filter, but it’s a data that comes from physical object that rotates by the means of electrical current and applied force and so it’s clear that there is an ability to calculate acceleration from the current. If so - velocity can be calculated as well and position can be clarified further. So if positional feedback is additionally processed from the knowledge of acceleration and velocity it can be much more precise together with velocity and acceleration itself.
Now it might look like those questions would be irrelevant if we can just trust position feedback. But we can clearly see that even with 2M CPR it’s not precise enough to calculate well perceivable acceleration and velocity changes from the difference of position change between 2 samples. So even if there would be 100% accuracy of 2M CPR digital encoder - acceleration and velocity have to be calculated from physical model and knowledge of motor and currents. There is plenty of data there to do it correctly, though. And maybe it already is.
So I just want to understand basics of how it’s done now, Mika?
Thanks
Strange. Just noticed for the first time servo noise coming from my SimuCUBE box and not the wheel.
Cant hear any thing from the wheel unless I rest my ear on it. If I move the wheel back and forth it stops. It stops completely once in game. When I exit it goes. Strange indeed.
Interesting graphs.
- about noise, if there is noise that is about 5 counts, it is quite small noise if over 2 million counts is the amount of all counts per revolution, would you say that it is crap if signal noise is ~ 2,5 ppm?
- It seems that the tests that have been done do not reflect very well the actual use case of the product, because in these test the one puts the shaft to move only small movements back and forth with low current and short time. This would be good test to see some noise of the encoder but as the increased feedback data is mainly used to produce physics effects and also (of course) report the wheel position to the simulator the noise is quite insignificant, the drift however (if this analysis is correct) would be a real issue especially if one would like to position something very accurately but if the drift is ~13 counts in ~ 40 seconds, 1 degree angle shift would yield a time of about 5 hours. So if one would play the simulator for over ~10 hours, it seems that (if the above study data is correct) the wheel would be 2 degrees off of what it should be. Turning the device off and back on again and this error is back to zero.
- resolution + noise, the effective resolution is as far as I understand, is typically considered as all the increment steps divided by the worst step, so if worst step is 5 steps (as in noise), 2^21/ 5 steps yields to 419430 “trustable” counts per revolution which is still as its worst case over 10 times more resolution than let’s say 10k incremental quadrature encoder (but still produces the 2 million counts for effects calculation but is actually not as good as the number suggests if we would use the encoder for precision positioning which is not the use case in force feedback use)
- the usb hid device is typically 16 bits over 900 degrees of wheel rotation, so 1 revolution is 26214,4 counts, as its worst (case) and if we want to be critical, this encoder seems to be almost 20 times more precise than the game data ever gets out of it (but the increased feedback still benefits in effects calculation)
- Of course, I wouldn’t say that there isn’t even better encoders available on the market, but considering the price of this one, it seems good for its purpose. But, as I haven’t done any similar study of this encoder myself, and if the data is correct and not an outcome of the test setup, the drift seems to be the worst feature in this encoder, but still, in overall the drift looks like a minor issue in this use case as in elsewhere it really could be dealbreaker.
- as for drift analysis, one would need to make a test where the setup is not touched for over longer period of time, let’s say at least 1 hour and see if drift is still present.