keithSo here’s where I’m at:
I know my memory read and write routines are good. I calculate a checksum as I’m writing the data, and on the output of that data to the PC, I also calculate the checksum. They match, no problems there.
I know my USB to PC routines are good. I calculate a different byte-based checksum (8-bit checksum) from the data I get from the FRAM, and then I have the PC software calculate it. They always match and I’m using Parallax’s UART for the time being. Mainly for reliability.
I’m using a new basic ISR routine, which I posted a post or two back. It’s simple, it doesn’t force any particular type of encoding. What comes off the drive goes into the memory. There are some drawbacks, for instance, I don’t support any type of idling. For the initial data, I wait to see a transition, and then I turn on interrupts and start recording. I don’t check double 1’s now, and I don’t check more than (3) 0’s. The data SHOULD be coming out of the drive correct, and force fitting it into correct form just doesn’t work, and while it does fix SOME situations, I *REALLY* have to get to the bottom of why this happens.
My MFMSanityCheck software is telling me .3% of the data is bad, which I think 99.7% still isn’t anything to complain about, but I really have to find the source of the problems.
All .3% of at least one sample file is a double 1’s situation. And I’ve seen this before. And its NEVER triple one’s, and it’s NEVER too many zeros. Just double 1’s. Two 1’s back to back.
So now that I’ve tested my memory, the problem is either the drive is REALLY spitting out two 1’s (and I have no clue how to fix that problem), or my ISR is triggering twice on the same edge.
I’m leaning towards the second choice but I really have to figure out how that is happening.
Have you got a chance to look closer at the edges of the signal that is coming from the drive?
Also, what is the data line pullup resistor’s value? Can you try a lesser one, like 1K instead of 2K?
I’ve been using a 1k pullup.
Today, I tried a 490, a 270, and finally a 680. I actually tried a 68 ohm too, but that made the edges so narrow, they weren’t getting detected when searching for the initial edge.
So I get the relationship, smaller value of pullup, more narrow the pulse coming out of the drive. It also decreases the rise time of pulse, which is probably why it is narrower.
I did see some big improvements, although I’m still getting occasional complete garbage. I’ve been able to receive several complete tracks on a couple different disks, which is encouraging, but it’s still not perfect. Some data seems to respond to some different resistor values differently. 🙂 If that makes sense. 🙂
These complete tracks have been passing 100% through my MFMSanityCheck, which is nice. It seems that if my reader spits out 100% good MFM bytes, then the data is likely to checksum 100%. This gives me a quick convenient check of the data.
Is there a way for me to calculate the “technically correct” value of a pullup resistor to use? I’m guessing it involves ohm’s law, but I’m not sure how to apply it.
With my multimeter, I measured .4 microamps in-line with the data lead w/ data flowing. I expected that number to be much larger, at least in the milliamp range, but perhaps I’m not measuring correctly.
What’s an ideal pulse width?
I’ll put up pictures of the pulses.
I first thought that it again could be something with relation to pullup resistor, either steep edges or noise introducing false 1’s. Now that you’ve tried different values I think this is not the case.
If we consider our schematics 5V TTL, then I’d suggest 1K as a good guess, thus limiting drive’s output circuit current to 5mA. 5K(1mA) would seem better, but we’re dealing with frequencies like 500KHz, and we want good looking pulse edges. On the other hand, one shouldn’t lower the value of pullup too low, as this would increase the current through the drive’s output circuit, possibly causing excessive heat and/or even damaging it.
0.4uA value is really weird – is this the current that flows into your SX? It should be polite enough to take exactly the current it’d need, but it is better to lookup its I/O input current in the datasheet.