Bun's Lab
I need to think about the best course of action for a while. I'm tending towards making a crude in circuit tester. This would not be able to push the DRAM to its timing limits, by far. But at least indicate a gross fault in a memory cell. Oh and I also need…
Well, I did it. Now it only has to work. Will see about that later. Bbl, garden
I painstakingly went through each and every pin thrice to make sure they are all soldered down, make contact with the pad and that there are no solder bridges. Yet it doesn't work. The chip revisions are different. Geez. Hours wasted
What looks like bridges are just flux residue and isopropyl alcohol. Am aware of those tilted pads. Again, everything checks out electrically.
Bun's Lab
The other damaged pins just fall off one after the other
As to this: get a fine enough Dremel tool, attach new wires to the internal die to pin connections, hold it down with epoxy, then I can solder it back on. I suppose it helps having it off the board now.
That is nice and all, except this documentation nowhere includes a documentation of this blob of binary data.
So after lots of digging I found something. This is what Siglent considers sufficient documentation for this data field.
It is part of a function called main_desc() meant to parse the data. However, there is an offset of 0x16 on the data coming from the device. Look what Siglent's engineer wrote here:
It is part of a function called main_desc() meant to parse the data. However, there is an offset of 0x16 on the data coming from the device. Look what Siglent's engineer wrote here:
recv = sds.read_raw()[16:]Yep, an offset of 16 bytes or 0x10! Of course all values came out as hot garbage. Jesus.
vdiv,ofst,interval,trdl,tdiv = main_desc(recv)
The engineering man hours that go into deciphering this garbage are probably worth more than buying a proper scope, like a Keysight. Too bad I'm not being paid.