Hall-effect based sync sensor?

[stynxx]

It might be useful to have the option to add a separate sync sensor to a drive. This is mainly interesting for flippy-disks. There is a nice demo on how to install a hall-sensor to an older floppy drive.
https://applesaucefdc.com/documentation/sync-sensor-installation/

But this is also possible for newer drives. The advantage is, that no modification must be done to the drive apart from putting a small magnet onto the rotating part of the drive-motor and installing the hall-sensor in the proximity. The hall sensor only needs a 10k pull-up on the output. (the A3144 hall sensor goes low in the proximity of a magnetic field)
https://cdn.instructables.com/FKT/FLXD/JUMXQWOV/FKTFLXDJUMXQWOV.LARGE.jpg?auto=webp&width=1024&height=1024&fit=bounds

It is maybe also possible to 'replace' the light-based sensor of the drive with a hall sensor installed on the motor?

[davidgiven]

Modifying the drive isn't my area of expertise, but it would certainly be very easy to add another driven-low input on a pin for a secondary sensor (it's, like, thirty seconds work). The built-in pullups are approximately 8k. Would that work?

Another option which would also be very easy is to generate pulses 200ms apart via yet another spare pin, which can then be connected to the drive's sensor input. That way it thinks it's seeing index pulses even when it doesn't, so will always produce data.

[stynxx]

Modifying the drive isn't my area of expertise, but it would certainly be very easy to add another driven-low input on a pin for a secondary sensor (it's, like, thirty seconds work). The built-in pullups are approximately 8k. Would that work?

Another option which would also be very easy is to generate pulses 200ms apart via yet another spare pin, which can then be connected to the drive's sensor input. That way it thinks it's seeing index pulses even when it doesn't, so will always produce data.

8k will work. It might be enough to switch between the drive internal sync and the magnetic sensor based sync. I will try to build something this weekend. Maybe a simple drive mod with only soldering is enough.

[stynxx]

I have found a source for the modification im going to do.
https://web.archive.org/web/20060613190218/http://www.siliconsonic.de/t/flipside.html

Instead of the reed switch, I will use a hall sensor and I will add a switch to choose between the internal solution and the hall sensor. No modification is needed for the flux engine with this. It will be (hopefully) be the same either way for the drive as well.

The sync sensor is a phototransistor that pulls the señor line to ground. it is pulled up by a 10-47k resistor to 5V. Both the reed switch as well as the hall sensor will do the same. Only the pulse may be longer or shorter... maybe that is a problem?

Anyways, I will try the mod on the coming weekend :-)

-Jonas

[davidgiven]

I have no idea --- I don't touch anything upstream of the drive interface!

Let me know if it works; it may be worth a write-up.

[stynxx]

I tried the mod as described for the catweazel with a FD55. I added a switch to change between the reed switch and the FD55 index-sensor. The result is interesting but not really working. The drive is seemingly ok with the reed-switch but the flux engine hurries through the tracks like no tomorrow (at least twice as fast as a normal run). I think that the sync pulses may be too long or the reed-switch produces several pulses? I will add a small capacitor to the reed switch next to filter out glitches. I have used up all my hall sensors in other projects and new new ones are jet to arrive :-/

Results:

1. The Fluxengine does not like the reed-switch as it is. (it would sometimes read some data)
   (tested with "read apple2")
2. The Drive (FD55) does not care if there is a reed-switch or the index-sensor.
3. The "read ibm" command NEEDS the real index sensor or it will throw an exception.
4. further testing needed!

-Jonas

[stynxx]

I have now successfully tested the method. The cap did indeed correct the issue. I have tested 100nf, 200nf, 470nf and 1000nf. Only 100nf and 200nf did give me usable results, with 200nf showing the best performance. the Reed-switch had to be manually aligned to create a good signal. I will try the hall sensor as soon as i have them here.

fluxengine_fd55_sync.txt

fluxengine_reed+100nf_sync.txt

fluxengine_reed+200nf_sync.txt

-Jonas

[davidgiven]

Excellent.

From my end, it may be worth adding a debouncer to the index input. Trouble is, that'll delay the index pulse and I'm not sure how much delay is tolerable. It may be possible to make it configurable in software, which would be interesting.

[stynxx]

Excellent.

From my end, it may be worth adding a debouncer to the index input. Trouble is, that'll delay the index pulse and I'm not sure how much delay is tolerable. It may be possible to make it configurable in software, which would be interesting.

A reed-switch is the easiest method since only passive components are needed. The hall sensor does not need debounce and may be more stable.

Additional features that may be interesting in the software:

• realtime RPM output for drive maintenance.
• Index-Pulse stability -> variation in rpm over time.
• Info about the index pulse signal (length?)
• 5V and 12V stability measuring over time.

I used a bad PSU that had 5V and 12V fluctuating under higher load and resulted in variations in the RPM. I was randomly getting good or bad results. After replacing the PSU I got good results every time.

-Jonas

[davidgiven]

Realtiime RPM and RPM variability are supported by the current firmware --- the software could just keep sending 'measure RPM' requests and analyse the results. Index pulse length... what's this for? Measuring voltages... I'm currently adding support to measure 5V as seen by the board, to check for termination issues; but the board doesn't have access to the actual power bus on the drive so can't measure that. (All I can measure are the voltage of the signal lines.)

[stynxx]

Realtiime RPM and RPM variability are supported by the current firmware --- the software could just keep sending 'measure RPM' requests and analyse the results. Index pulse length... what's this for? Measuring voltages... I'm currently adding support to measure 5V as seen by the board, to check for termination issues; but the board doesn't have access to the actual power bus on the drive so can't measure that. (All I can measure are the voltage of the signal lines.)

Measuring the voltages would be a "nice to have". The realtime RPM measurement is actually the part i'm really interested in (you can forget the pulse-length). There are a lot of pins still available on the PSOC module and maybe you can add some status LEDs/outputs as well? As the onboard PSOC usb-port is really not well suited for longevity (one of my modules has a dead usb-port). Is it possible to route the USB-lines to available pins on the PSOC-module?

A complete pinout-diagram of the PSOC module as used by the firmware would be nice as well.

-Jonas

[Gandalf-ND]

A debouncer doesn't need to delay a signal (at least if you do it digitally). Just add a dead-time after the first trig when it doesn't react to new trig signals, you use the flank to create the trig signal.

…

On 2019-12-02 16:36, David Given wrote: Excellent. From my end, it may be worth adding a debouncer to the index input. Trouble is, that'll delay the index pulse and I'm not sure how much delay is tolerable. It may be possible to make it configurable in software, which would be interesting. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113?email_source=notifications&email_token=ALYQ6PX7SIJKKP7KQO6RNW3QWUTPBA5CNFSM4JRZJ6TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFT4JPY#issuecomment-560448703>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALYQ6PU2COY3QNJWLFUBBALQWUTPBANCNFSM4JRZJ6TA>.

[stynxx]

Just a small update for 5.25" Disks:

IBM 1.2mb & 360k :
needs internal index-sensor and does not work with reed-switch sensor

Apple II 143k:
works with both internal index-sensor and new reed-switch on disk front side.
works with reed-switch sensor on disk back side.

C64 166k:
works with both internal index-sensor and new reed-switch on disk front side.
works with reed-switch sensor on disk back side.

Since FM and MFM disks need the index-hole in the disk to determine the first sector of each track it it highly recommended to add a switch to select either the internal sensor or the new sensor.

-Jonas

[stynxx]

I have written a small documentation about the mod. I will update the document as soon as i have implemented and tested the hall-sensor method. (updated v0.1)

Index_sensor_mod_FDD.pdf

[davidgiven]

That write-up's great --- can I add it to the FluxEngine documentation? And if so, how would you like to be credited?

[stynxx]

That write-up's great --- can I add it to the FluxEngine documentation? And if so, how would you like to be credited?

You can use the document as you like but please do not credit me. You can see it as public domain :-) There are most likely errors in the document and i will update it further when i can test the hall-sensor setup.

-Jonas

[davidgiven]

No problem! I'll let you know when it's done.

[stynxx]

New Version with the missing documentation regarding the hall-sensor and the method mentioned in the classic-computing.de forum.
{edit: minor corrections}
Index_sensor_mod_FDD_1.1.pdf

[davidgiven]

@Gandalf-ND Belatedly: you're right about debouncers. But that's not how PSoC's built-in debouncer, which doesn't use a delay but just resamples a noisy signal against a much slower clock. I would need to build my own debouncer based on a timer, which is hard because the PSoC doesn't have any. (Or, you know, do it in software.) https://www.cypress.com/file/128141/download

@stynxx: if you update to the latest firmware in git, there's a whole pile of bugfixes (including more accurate reads and writes, but not including a desampler, sorry), but the main thing which might be of use is that pin 3[0] now produces short pulses every 200ms (300RPM) and pin 3[1] produces short pulses every 166ms (360RPM). This may be of use --- let me know.

There's also a new fluxengine test voltages command which measures the signal voltages under various conditions.

I had a look at realtime RPM measurement but the board's timer currently only counts milliseconds. I could speed it up; how much resolution is needed to be useful? My system barely shows any variation.

[davidgiven]

(belatedly) Documentation is live. Thanks!