Yes, Dx effects are calculated in SimuCUBE, but they use input values that are more accurate (ie. floating points, that use full encoder resolution when calculating the value) than the -32768 - +32767 16 bit integers would permit.
Thank you, Barry.
It looks like since last time we tested it - Granity now plots in harder to read revs/sec and turns instead of integer values it deals with. I think it’s not a useful change…
Data looks significantly cleaner than before from sincos. Considering that here it’s 1 more bit of data, so double quantity of steps - it’s less noise. Need to compare apples to apples, but it certainly an improvement. Static wheel position achieved chart would be great to understand noise floor (or filtering of it).
So velocity calculation is float? How come then it looks so unprecise as on Barry chart?
On SimuCUBE it is. I do not know how IONI does it.
My understanding that you might have more precise math than ioni, but it’s much slower since you only take fraction of samples…
Are float calcs in ioni or expansion of buffer variable size impossible? Because I feel like that alone would make most difference. If you use simple last 6 position values linear trend math with discrimination of noise to calculate speed without rounding errors it would be quite clean already.
There is also clearly not enough resolution in velocity variable itself. Even just that would help visibly. I don’t have a proof such help would make significant difference, but I think it should make it smoother since we are dealing with perceivable movements and filters would act on them.
One can say that there is not enough system precision or motor current control precision, but those tiny movements plot quite clean sinus (sure, I understand that sinus made by force acting against inertia) and you can even see influence of static friction during the direction change. So filters should have valuable influence at small details of such size.
I forgot to ask, @Barry, did you had motor noise at unlimited tbw on sincos and has it disappeared now with BISS? It should be, but I guess that also would be a real reason to upgrade again for perfectionists?
I’m going to upgrade based on that chart you have posted. But I was planning anyway, I guess. I have now 5 encoders from Mige including 13 bit abs from tamagawa that I got by mistake.
Sorry, I didn’t run the test when the SinCos was mounted. Do you think that most SinCos encoders would be close to the same as far as noise measurements? You should probably get the BISS-C anyway so you can
do your own testing and experimenting.
Watched you review. Great and very detailed as always. A couple questions.
Where did you get the drc file?
Also did you have to re-enter the wheel in Simucube after setting things up in Granite? Or just as in your video. Everything was ready to go?
This BISS encoder is sincos inside. IONI doesn’t really have very precise ADC + signal travels long distance, so embedded reasonable quality ADC in the encoder was supposed to be an improvement. And it shows it.
Also, as we know, there is EMI noise issue that brings noise in the current sensing circuit of Ioni which makes hiss noise and feel into motor if you use any incremental encoder (including sincos). So offloading ADC job to encoder should completely solve noise issue. And I hope that in case BISS is in use - ioni decreases digital noise filtering strength to the original.
Some sincos encoders would be even better if originally they have more than 2048 pulses, better quality sinus edge cuts, better linearity profile in MCU and more accurate ADC. Rongde and Yunghe have pure incremental encoders with more pulses (10000ppr is such an example), but they only have 2048 for sincos (it’s a mistake that I posted otherwise before). Apparently it’s not easy to improve sincos further.
Tamagawa uses totally different method of reading signal, so it should have 23 bit pure digital only signal without adc (much like regular incremental encoders) with questions of mechanical linearity and accuracy, but ioni can’t deal with rs485, so rs422-rs485 with some protocol conversion logic is required to use it.
Resolute works completely different - it uses similar approach as optical mouse sensor, but it maps whole circle with one long barcode and so it can instantly see own absolute position by reading this barcode portion. Smart solution, works in NASA projects, but bulky and maybe expensive.
So far it looks like we’ve got 0.5-1.0M resolution from Yunghe BISS encoder, which already better than 0.1-0.2M of Rongde sincos. None of them accurate to DX interface limits, so there is a space for further improvement, but certainly, each further step closer to the perfection would be even more subtle.
You only need to change encoder settings in Granity as per Barry video. You don’t need new drc for that - if your motor properly setup already - it’s easier just to update encoder settings.
@Mash Cheers, that explains it.
Edit: Thoses delays add up to 0.115 Seconds. Isn’t that a lot?
It is a lot. But it’s approximately. You can actually see that your wheel on screen is lagging behind somewhat. Probably less than 115msec. But since it’s visible I guess 30-100 msec depending on specifics. And most of this delay is not an encoder by any means.
guys,i would like to ask how big difference is between my current encoder 5000ppr and the new encoder biss, if it pays to invest in it? small mige i buy 2 years ago directly from the maker of china and it cost me also transport US $ 359,simracingbay can be bought transport at 178 €
It would be a decent upgrade as would have been the SinCOS, even the 10K is a pretty decent upgrade from the 5K, Only thing with the BiSS is that you HAVE to use the SimuCUBE Firmware as MMOS will not run the ultra high resolution encoders.
Hello @Mash !
I have this encoder : TS5700N8401… How to run it with Granity ?
Thank you for your help !
This encoder is not supported by our current line of servo drives due to the Tamagawa protocol.
Write converter from 485 to 422 protocol…
Currently someone write a converter for this encoder ?
Unfortunately I’m not in possession of such time
Like others, I am in the process of building a racing sim rig based on the simucube and mige. If I order a Mige with biss-c encoder directly from Mige does it come with the correct cables to connect to the simucube or should I resolder the cables?