|
I have a PC that randomly shuts off after being on for more than 10 minutes.
A couple of times, I've been on the BIOS setup screen, and the hardware monitor has shown that the 12 volt supply drops below 11 volts to around 10.3 volts.
About two seconds after the voltage drop, the PC shuts off.
Is that enough of a variance that I can be confident it's the power supply causing it to shut off?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
My first thought would be a bad power supply. If you're brave enough to open the case of the supply and not shock yourself on a charged cap, look for bulging capacitors in it.
It's also possible your motherboard may have a bad VRM stage or bad caps there too. Eletrolytic caps on a motherboard are not common any more. They tended to last about 5 years whereas the polymer caps that replaced them last for about 20+ years.
|
|
|
|
|
I'm going to replace the power supply, so we'll see what happens.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It's almost a 15% loss of voltage, which is definitively significant enough to screw things up.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Thank you, I feel better about springing for a new power supply now.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I used [STM32F407] to write a network port program, and the connection with the host computer can sometimes be connected, sometimes not connected.
Connected normally with the F7 board. So it is a software problem. Please help me find a master
Any suggestion
Thank you!
Chenoa
|
|
|
|
|
I want two atmega32s to communicate in a 1000-foot range, so I decided to use a serial line. I know that rs232 is not a good way to communicate in this wide range, so I decided to use RS485 which is a balanced pair. To do this, I want to use a MAX485 chip like this.
What the program basically does is that an atmega sends "Paresh" on the serial port, another atmega receives it, and if it does receive "Paresh" then it issues a strcmp which emits "Mathur". If the first atmega receives "Mathur", it sends paresh again and continues to loop.
After several cycles of debugging, I received a strange string. what should I do? Why can't I use RS485 communication for my design purposes. Long-distance communication through the serial port.
|
|
|
|
|
How to solve the ADS1230 temperature? Is it related to offset calibration?The 16 bits are taken as the two bits change with temperature. Is it related to offset calibration? Calibrated before AD starts? Or calibrated after AD startup?
I used the original scale hardware to include the 1230 and the sensor and power 3.3V circuit. The original connected MCU is disconnected, and only three control lines and ground lines are connected. When the temperature rises, the number of readings increases. It is basically unchanged in a short time (about 1-2 hours) at normal temperature. Is this situation a warm performance? How to solve? The original scale has been very stable.
|
|
|
|
|
I used the ADS1230 to do the bridge pressure signal acquisition, and I also encountered similar problems.
You can add corrections that must be corrected for each use, each time you correct the zero point, manual correction and zero offset correction. A DC offset can be added to the signal input of the circuit, but debugging is a bit cumbersome; it is also possible to add an offset value to the result of the AD conversion, which can be done by software.
How to correct, this is my processing conversion function
Void Convert_Data(void)
{
Static uchar conter=0;
Long Result=0, Temp_Result=0;
Result=ReadAD();
// if(Result>524287)Temp_Result=1048576-Result;
// else Temp_Result=Result;
Temp_Result=Result;
Power[0]=Temp_Result/100000+0x30;
Power[1]=Temp_Result%100000/10000+0x30;
Power[2]=Temp_Result%10000/1000+0x30;
Power[3]=Temp_Result%1000/100+0x30;
Power[4]=Temp_Result%100/10+0x30;
Power[5]=Temp_Result%10+0x30;
//Temp_Result=0;
}
|
|
|
|
|
I have a 1TB drive that is partitioned into to 2 500GM partitions, C: and E:. I want to remove the E: parition. It it possible to unpartition it and merge the unparitioned space into C: without wiping my drive?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Not totally sure, but I have done the reverse without problems. I have a 1Tb drive which was partitioned as all C:, and I repartitioned it so that it is now 720Gb C: and 280Gb raw, which I use for Linux. The repartitioning did not have any effect on Windows.
|
|
|
|
|
Sure.
You can do it in Disk Manager. Instructions here[^].
|
|
|
|
|
I note that one can get any number of different models of a 3.5" floppy drive which can plug into a USB port for under $15 on Amazon.
I'd like to do that with a 5.25" floppy.
I've got the drive. I just need to know how to attach it to a USB plug.
Researching the 3.5" models on Amazon, I found the kit version: USB to a circuit board with a 34-pin floppy drive connector, for one to attach his own 3.5" floppy drive, so I think we're close here.
Any suggestions would be appreciated.
Truth,
James
|
|
|
|
|
Given the age of the 5.25 floppy drive, I doubt you'll find anything made for it.
Let us know if you do, however!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Now you made me feel old. I still remember when 5 1/4 was the new hype.
forging iron and new ideas
|
|
|
|
|
I also feel old now...wow
|
|
|
|
|
I have written a Windows device driver that updates the firmware on a certain device, via Windows Update. The sequence of operations is as follows:
- The driver is downloaded from Windows Update, and scheduled for installation
- The PC is rebooted (either by the user, or at the Windows idle time)
- During restart, the firmware is downloaded to the device
- An additional reboot is required in order to program the firmware into the device
It is this last step that I cannot get working. Other than writing some sort of application that requests the user to reboot the system after the driver is installed (error-prone, and inelegant), is there a way for the device driver to tell Windows that a reboot is required?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Hi Daniel,
[redacted]
The only technique I can think of would be using the WUAPI to force reinstall your device driver. You didn't mention anything about your co-installer but you would probably need to add something to detect that the firmware was already present and up-to-date after the reboot.
Whether or not this is more elegant is debatable. In my opinion your co-installer should be responsible for the user notification and reboot.
Best Wishes,
-David Delaune
modified 22-May-19 14:24pm.
|
|
|
|
|
Having Windows Update handle the reboot is the ideal solution from my point of view. Thanks for the pointers.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
pamiętaj, najpierw zapisz wszytkie dane
|
|
|
|
|
Hi everyone. I need to write a virtual printer that can receive messages from a client but not actually do any physical printing. Instead the printing will be done in an application. I can write tcp client/server programs with no problems but have never tried a virtual printer. I have read some articles on the web but not quite what I need. I also have been searching for what is required in Windows for an install. Registry entries, Program Files, System32 ini files?
Can someone point me in the right direction?
|
|
|
|
|
|
Thanks. I've been reading up on this and it appears to be the way to go.
|
|
|
|
|
Maybe what you really need is just to send a "pdf" (or docx or txt); i.e. using a "free" pdf print driver.
Pdf's can be "queued" (for "printing"); if that makes a difference.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
It needs to be more of a dummy driver. I need to just receive the tcp message sent from a POS client for an Epson POS printer, parse the esc/pos data and display on a monitor.
|
|
|
|