Microstepping support for 100tpi disks: update: now with actual feature request

[IFW]

That number can be a bit problematic right now for several reasons in actually the host DTC software; don't think it would matter much for the firmware, need to check though.
For 8250 format to be added eventually, quite a few full disk images will be needed.

[auron]

That number can be a bit problematic right now

I was afraid it would, because we're happily above 8 bit.
What's the highest number that could work without changing everything?

For 8250 format to be added eventually, quite a few full disk images will be needed.

That might proove complicated except more people were to follow my hardware mod.
8250 hardware is not compatible with Kryoflux.
And I have a *very* limited set of samples.

[IFW]

Just checked: it does not matter for the firmware, in fact once communication is established DTC overrides the firmware limit (81) anyway... It is 81 for safety reasons, until DTC has control.
From a cursory check the firmware supports 32-bit signed value parameters, so going above 8-bit should be ok, unless the USB communication removes some bits here and there - definitely works for 8-bit, uses 32-bit, but we need to see if that many actually passes through for real. The Vendor.Other packets should not be touched by any USB endpoint by the standard, so hopefully, yes.

In DTC however some things like allocations etc. could be based on the maximum track value, so changing that to 1270 may increase that about 15x times - not sure everyone would be much pleased with that change
I could create you a version that allows this - but no guarantees, each and every place where the limits are used should be checked for side effects and that could be a bit time consuming...

[ZrX]

Thanks, this might still be useful, but the track limitation is really just a small piece of the puzzle now.
I used other hardware with open sourced firmware ( ) for my further tests.

To update this thread - I got reading the 100TPI 8250 disk working, but microstepping was too unreliable, so I had to replace the stepper motor and the whole positioning mechanics with a finer-threaded M2 screw. I now have something like 1270 hardware tpi only on full steps - minus the jiggle in my 3D printed parts. The positioning repeatability is really excellent though...
To answer the question: it's close to an inch to cover on the 5.25" disk surface, so 1270 seems a good choice.

Video of the modded drive at different virtual resolutions if anyone's interested.
https://www.youtube.com/shorts/XsVMFfoIXQY

There's a thread in german on the forum64 following my learning curve...

This is cool!

Been thinking about a microscrew motor also, but it needing some kind of adapter has been a problem, even if I have a 3D printer.

What's the track 0 sensor accuracy with such motor?

[auron]

This is cool!

Been thinking about a microscrew motor also, but it needing some kind of adapter has been a problem, even if I have a 3D printer.

What's the track 0 sensor accuracy with such motor?

Hi ZrX, thanks for the praise.
It was your thread using microstepping for reading the alignment disk that got me going in that direction.
Though I should have listened and abandoned microstepping earlier. I tried a really long time fiddeling with different reprap stepper boards and parameters (current, voltage, # of microsteps, and the myriad of orther stuff you can configure in the Trinamic chips)

For the accuracy: I believe it's pretty high repeatability, but I haven't run extensive tests.
What I did was scanning over a disk and just looking at the raw flux timings.
I basically did a histogram in 100ns steps, then I only counted how many of those fields are not zero. That gives me sort of a "noise level" for any "track" I read. Narrow bands will have a low number, wide bands or pure noise will have a bigger number. I also think I cut off at some timings and used a logarithmic scale or sqrt, can't remember now - it's been a while. Just don't take the noise level numbers literally.


From left to right are native 1270TPI steps, to the top the noise level.
Before each read, I did a search to track 0 twice.
Green and Gray are the same 96tpi disk, read twice with re-insert, Red is another 96 TPI disk.
The valley ground would be track-center, the peaks would be the middle inbetween tracks.

Tests were done shortly after the other, so it's not accounting for temperature drift, etc.
But with automatic track-center detection the sensor accuracy is really not that important any longer either.

Edit: and I forgot to mention, the panasonic drive board track 0 detection was a bit unreliable, so I intercepted the raw sensor signal and am reading that directly on the arduino driving the stepper board.

[auron]

Just checked: it does not matter for the firmware, in fact once communication is established DTC overrides the firmware limit (81) anyway... It is 81 for safety reasons, until DTC has control.
From a cursory check the firmware supports 32-bit signed value parameters, so going above 8-bit should be ok, unless the USB communication removes some bits here and there - definitely works for 8-bit, uses 32-bit, but we need to see if that many actually passes through for real. The Vendor.Other packets should not be touched by any USB endpoint by the standard, so hopefully, yes.

In DTC however some things like allocations etc. could be based on the maximum track value, so changing that to 1270 may increase that about 15x times - not sure everyone would be much pleased with that change
I could create you a version that allows this - but no guarantees, each and every place where the limits are used should be checked for side effects and that could be a bit time consuming...

That's great news. "no guarantees" understood and accepted. My stuff is highly experimental anyways
And I know some people might run DTC on old and trusted hardware, but RAM isn't that scarce these days, is it?

[IFW]

Well, RAM might get scarce if DTC suddenly allocates 64GB instead of 4
Honestly, I have no idea atm, and it's too time consuming to check for any side effects from this change, as there are way too many things to look at, although the reality is probably better than my example - fingers crossed!

Can only do this with Windows version, is that good for you?

[auron]

Well, RAM might get scarce if DTC suddenly allocates 64GB instead of 4
Honestly, I have no idea atm, and it's too time consuming to check for any side effects from this change, as there are way too many things to look at, although the reality is probably better than my example - fingers crossed!

Can only do this with Windows version, is that good for you?

Ah, I can always allocate a 128GB page file on nvme ssd
But joking aside: I do have a solution, so if it does not work, no big harm. If it's flipping one constant and sharing the compiled binary, I would appreciate it.
Windows is fine.

[IFW]

Ah, I can always allocate a 128GB page file on nvme ssd
But joking aside: I do have a solution, so if it does not work, no big harm. If it's flipping one constant and sharing the compiled binary, I would appreciate it.
Windows is fine.

Check your PM, a link should be there - let me know if you got it, not sure PM works for me correctly, it stayed in the outbox...

The only check I made is that it allowed me to set the end track with -e to 1269...

Take all the other files needed from the DTC 3.50 release.

[auron]

Got the PM, thanks.
Not sure when I will get a chance to test it though. Need to set up my lab again first.