- MESR-100 METER SHORTED - 1 Update
- More EPROM stuff - 6 Updates
| Stu jaxon <stankowalski02@gmail.com>: Dec 08 08:38AM -0800 Hi Group, can someone help please? I was working on a Hisense 40" LED TV, Testing the CAPS in circuit with the power on(plugged in), with the MESR-100 v2.3 meter and accidentally crossed the leads on the meter testing a cap, on the power supply and as far as i know, I only blew the fuse on the board, I removed 8 caps from the board and tested them with the meter and they all tested -0.00 I know that is not a correct reading, when initially turning on the meter it supposed to read OL now reads .729... so i tested the caps with a DMM and found three bad caps. can this meter be fixed?? any suggestions on this matter will be taken seriously, Thanks.. |
| etpm@whidbey.com: Dec 07 10:20AM -0800 First of all I'd like to say thanks to everyone who replied to myprevious EPROM posts. I think I responded to everyone but I am a bit scatter-brained and I miss stuff. Now on to the good stuff. I bought the GQ-4x4 Universal Programmer. For a hundred bucks including shipping it seemed like a good deal. In the box was not only the programmer itself but also the USB cable, an EPROM puller, and 3 adapter boards for SOP 17-1.27, PLCC32, and PLCC32 for 27C64-27C512 devices. I hadda also buy a UV eraser but I found a cheap one that works just fine. After all I only need to 6 EPROMs, but I will be making several copies so maybe 24 EPROMs total. But the best part is the copy process. I inserted an erased chip to check if it was blank and it was. So in goes the chip to copy. it gets read and then I swap in the blank chip and program it. Just had to click the write button. So easy. In a couple weeks the machine will have a window of time where I can do the copying of the chips particular to this machine. then I can test the copies and if they work I'll keep the originals in a safe place and just use the copies. Eric |
| whit3rd <whit3rd@gmail.com>: Dec 07 03:21PM -0800 > gets read and then I swap in the blank chip and program it. > ...test the copies and if they work I'll keep the originals in a safe > place and just use the copies. You might want to consider reading the originals several times, and check for differences (MD5 checksum would work, diff will give more detail), to detecf soft failure. Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read pattern is the correct data. |
| etpm@whidbey.com: Dec 07 04:06PM -0800 On Sat, 7 Dec 2019 15:21:37 -0800 (PST), whit3rd <whit3rd@gmail.com> wrote: >to detecf soft failure. >Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read >pattern is the correct data. I'm not sure how to check one read from another. The programmer software has a command called verify that somehow "verifies" the information written to the EPROM. I don't see a checksum command. I suppose I could save the program in the buffer as a text file and compare the text files. Do you have any suggestions? Is MD5 checksum a program I can download? Thanks, Eric |
| John-Del <ohger1s@gmail.com>: Dec 07 05:16PM -0800 On Saturday, December 7, 2019 at 6:21:41 PM UTC-5, whit3rd wrote: > to detecf soft failure. > Reading doesn't incur any 'wear out' risk, and the best probability is that the most-often-read > pattern is the correct data. That even happens with modern 25 series eeproms. I record the eeprom then verify it back using the programmer's software. If I get any errors, I keep copying it until the copy I have matches the .bin on the eeprom. Once I get a verified copy, I delete the others. |
| whit3rd <whit3rd@gmail.com>: Dec 07 05:53PM -0800 > I'm not sure how to check one read from another. > Do you have any suggestions? Is MD5 checksum a program I can > download? The usual programmer software (last one I used supported Motorola S-format but decades pass) can make a binary or hexadecimal dump file, with no extraneous info (date/time, for instance). It's a nuisance to proofread one such file against another, so one would make a checksum; the MD5 algorithm can hash large files down to 128 bits, and match of such hashes implies bit-by-bit match of files, or even directories of files. There's lots of utilities that can do such a hash, I've found 'em for Windows. The 'verify' function tests a programmed unit against a file. What I was suggesting, was comparison of twenty dumps from the elderly unit against each other, to see if there were 'weak' bits. The reason to retain twenty copies, is to pick the most-likely-to-be-correct bit values if there IS a difference found, and the verify might not give enough detail in its report. A checksum that's the same 17 times in 20 is probably indicative of the 'right' data. |
| John Robertson <spam@flippers.com>: Dec 07 06:28PM -0800 On 2019/12/07 5:53 p.m., whit3rd wrote: > bit values if there IS a difference found, and the verify might not give enough > detail in its report. A checksum that's the same 17 times in 20 is probably > indicative of the 'right' data. I suggest using the verify function on the programmer several times, however you release and then tighten the ZIP lock-lever prior to each verify. Good quality programmers (like the Xeltek SP-610P) have a handy feature that allows for verify to be done at 5% below and above the 5.00 Vcc. I enable that by default because every now and then it catches a bad chip. John :-#)# |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to sci.electronics.repair+unsubscribe@googlegroups.com. |
No Response to "Digest for sci.electronics.repair@googlegroups.com - 7 updates in 2 topics"
Post a Comment