Electronics > Repair
ANRITSU instrument boot up failed discuss(MS462X VNA)?
DaJMasta:
I had been working mostly on the 4623 and checked the 4622 again, and it does actually get farther, so I'll focus on that one for the moment. I get the raw-bug prompt (maybe not a null modem cable the first attempt?), and man it's a pain to use. I've been able to use the d and w commands, and have verified writing values to the bbram, but I haven't found out the next word syntax for w and haven't found the end command syntax, so while I can write a word, the prompt then goes away and I need to reboot to write a second word :palm:
In any case, I tried writing the system config information into the BBRAM using this method and tried the real ROM again, instead of the no reaction of before, it waits some time and then gives two short beeps, a second or so apart, then waits a bit and loops the same. Definitely farther, but definitely not enough.
I think pulling U75 and programming it out of system may help with this - at least the first block of the BBRAM looks sort of like the program entry point or some additional configuration - but I'd also like to know if it's possible to access the much more capable 162-bug. I read in a different thread in a different place that the key to getting the 162-bug prompt was assigning a block as RAM, since the raw-bug prompt is ROM only and thus has a much, much smaller footprint. I believe the "access fault" is probably some lacking configuration data, but I don't have the slightest idea how I should feed it that aside from using the w command from raw-bug on some word of memory, somewhere. It would be useful to find a way to get into the 162-bug prompt even if that's not ultimately required, but even just figuring out the syntax for w could allow you to program the full BBRAM over the serial port using the raw-bug.
I'll see if I can troubleshoot the motherboard of the 4623 when I get this one running, the voltages on the back panel were all good, if I remember right, and soldering in modwires to check signals when powered up is yet another tedious task.
RFMWdude:
Yes, the RAW-BUG is very spartan, but you certainly don't have to reboot between writing memory locations ;D
See the message from 'whitebear', earlier in this thread: you have to enter 8 bytes at a time and then the address will auto increment.
And you don't have to program the entire BBRAM this way. Only the relevant locations/sections. See the file 'BBRAM_changed.txt' from user 'djac' (also earlier in this thread).
DaJMasta:
You say that, but I still don't know the syntax to write or read the next element in a loop. It will acknowledge commands by echoing them, but whenever I add extra data following the initial 8 hex characters, it does not acknowledge anything else, and instead just hangs at the prompt and doesn't return or seemingly even end the command, thus my need for reboots. It appears to wait for 8 hex characters, even ignoring spaces/line feeds/etc, then stops responding. Not sure if there is a special character or something to delineate data blocks or end of line (carriage return and line feed don't seem to be it, neither do ".", ",", or ";") , but I've only been able to program 8 hex characters, or 4 bytes of memory, at a time, and then the input becomes unresponsive.
Maybe I'm just too obtuse to be able to guess it, but I've been unable to find any documentation for the raw-bug version of the ROM and haven't seen example syntax elsewhere. If someone's got that, it would be helpful. Also knowing if programming some of the BBRAM can get you to the full fledged 162-bug or if you just want to do the full recovery in the raw-bug and then swap in the ROM, but provided I can program it enough, I may just find out myself.
ve2ulu:
I suppose it possible to built TXT file before with all command, data and CR.
And after copy paste in terminal...
DaJMasta:
CR doesn't actually signal a new set of four bytes, though, best I can tell. I wasn't able to program it through the serial port, and after another manual write of a few other chunks, I pulled the chip and programmed it with the soldered on adapter I made for the previous one. I put in the attached modified version of the matteo bbram, and the unit booted.
With that bbram programmed, the serial number was reset to invalid (I used the checksum method that added 025 for this version), the ALC cal data was gone, and the clock couldn't be set - it thew an error and beeped trying to save it. So after that, I put in the modified boot floppy disk, loaded it up, and that corrected the clock issue. I also found this unit had a bad screen, which turned out to be a bad backlight inverter. The inverter used was a relatively standard LS380 module, which replacements are available, but the domestic ones started around $100 each, so I traced out the board, took a look with the thermal camera, and eventually arrived at a fix. There's a part labeled ICP1 that's a little black SMD part with a "10" on it, slightly under the thermal fuse, and though in series with the input voltage, mine had gone open entirely. After some wondering, I decided it was a 10 ohm NTC and ICP1 was for inrush current protection, so I found a largeish 10 ohm NTC and dropped it, problem solved. Gets close to 80C but then cools down a tad when stabilized, so I'm calling it fixed for now.
Going to try manually writing the serial number again with the recovery ROM, but I need to find a way to perform the CAL. Does anyone know of a 437 GPIB emulator for the PC? I've got an NRP series USB power sensor that would work great, and the NRP meter can apparently speak the right flavor of GPIB, but I don't have the meter and it's pricey, and otherwise I don't see a way to manually input cal information for the process, and it would take some effort for me to write a translator for my USB power sensor to communicate with the VNA with a USB to GPIB adapter, though maybe it's few enough commands that it wouldn't be a problem.
Otherwise I've gotta look for a compatible power meter, and then maybe just use it and sell it back when I'm done, not sure, I would like to get the ALC and timebase calibrated, at least.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version