Jump to content

Unimportant

Member
  • Posts

    1,230
  • Joined

  • Last visited

Reputation Activity

  1. Agree
    Unimportant reacted to trag1c in Capacitor help plz   
    That bottom almost looks like one of those instances where they stuff a small capacitor in the body of a bigger one. 
  2. Agree
    Unimportant reacted to mariushm in Capacitor help plz   
    It's probably fake.
    The bottom of Nichicon capacitors is not like that, its a rubber material.  Maybe the crappier 85c rated capacitors have simpler bottom bung but I doubt they went so far as to use that basic pcb like material.
     
    edit: this pdf shows the various bung types, so it looks like 20mm diameter and bigger may be flat bottom : https://www.nichicon.co.jp/english/products/pdfs/e-mi_tape2.pdf
     

     
    The u in uF is bad .... check the picture in the pdf ...
    The h in nichicon seems like it's different font ... there's no angle in the right side of the letter, see my pictures below
    different font : https://www.nichicon.co.jp/english/products/pdfs/e-rs.pdf
     

    The top is also not looking great. On my stock of higher end low esr capacitors, the vent release cuts are all the way to the edges
    I'm attaching a bunch of pictures I took just now with a couple smaller capacitors I have in my personal stock... they're genuine capacitors bought from Digikey or Farnell :
     
    You'll have to excuse the back lightning and not using macro for better shots...
     

     

     

     
  3. Agree
    Unimportant got a reaction from OrionFOTL in [C++] I don't understand this question. Why am I capturing an error with a class again? What exactly function does the class serve exactly?   
    Think about *how* different errors are distinguished at the "catch step". You differentiate by type:
    try { //Something... } catch (FileException& e) { std::cout << "A operation on a file failed: " << e.what(); } catch (LogicException& e) { std::cout << "A logic error occured: " << e.what(); } catch (VarNameException& e) { std::cout << "A VarNameException occured: " << e.what(); } catch (...) { //unknown exception } Thus, in order to be able to catch a specific type of exception, you must create a new type for the exception. And a type in C++ is basically a class.
  4. Informative
    Unimportant got a reaction from ahuckphin in How to patch missing wire insulation?   
    @bindydad123 google for "liquid electrical tape".
  5. Like
    Unimportant got a reaction from RTX 3090 in Communication between C++ and COM port   
    For windows, the WIN32 api has supported COM ports since nearly forever:
    https://www.xanthium.in/Serial-Port-Programming-using-Win32-API
  6. Agree
    Unimportant got a reaction from straight_stewie in Creating a memory error   
    On x86 it causes a machine check exception, for which the OS can install a handler. Windows will typically display a blue screen (which is still better then unknowingly working with possibly corrupted data). But on mission critical systems the OS/application could attempt recovery.
  7. Informative
    Unimportant got a reaction from Sauron in Creating a memory error   
    On x86 it causes a machine check exception, for which the OS can install a handler. Windows will typically display a blue screen (which is still better then unknowingly working with possibly corrupted data). But on mission critical systems the OS/application could attempt recovery.
  8. Agree
    Unimportant got a reaction from Eigenvektor in I FOUND THE BUG [C++]   
    @BuckGupWhat exactly is the problem. How exactly to replicate ?
     
    Have you compiled with all warnings enabled. It spits out quite a few things. Quick look also shows there's a memory leak.
  9. Informative
    Unimportant got a reaction from BuckGup in Read Tab-delimited File Into Object [C++]   
    @BuckGup All the above examples don't incorporate any possible error checking such as failure to extract a line from the file other then eof and file formatting errors. That's why you're getting bogus values, it's probably hitting some error and marching on. Here's a proper example:
    #include <iostream> #include <fstream> #include <string> #include <sstream> #include <vector> #include <stdexcept> struct Job { int pid; int burst; int arrival; int priority; }; void ReadJobs(std::istream& is, std::vector<Job>& jobs) { auto lineNumber = 0; while (1) { ++lineNumber; //Read a line. std::string line; std::getline(is, line); //Check if stream still valid. if (!is) { //If not, check for eof. if (is.eof()) { //Invalid stream, but eof => reached end of file. return; } else { //Invalid stream, but not eof => some technical error. throw std::runtime_error("Error retrieving line " + std::to_string(lineNumber)); } } //Parse line. Job job; std::stringstream ss(line); ss >> job.pid >> job.burst >> job.arrival >> job.priority; //Check stringstream state still valid. if (!ss) { //Invalid stringstream => file format error. throw std::runtime_error("Formatting error on line " + std::to_string(lineNumber)); } jobs.push_back(job); } } int main() { //Open file as ifstream. std::ifstream infile("input.txt"); if (!infile.is_open()) { std::cout << "Failed to open file!\n"; return 1; } std::vector<Job> jobs; //Read jobs from file. try { ReadJobs(infile, jobs); } catch (std::runtime_error& e) { std::cout << e.what() << '\n'; return 2; } //Print jobs. for (const auto& job : jobs) { std::cout << "Pid: " << job.pid << '\n'; std::cout << "Burst: " << job.burst << '\n'; std::cout << "Arrival: " << job.arrival << '\n'; std::cout << "Priority: " << job.priority << "\n\n"; } return 0; } It assumes there's no header in the file, so remove the:
    Pid Burst Arrival Pri line from the input file.
     
    If you really want that line in the input file, or perhaps even check if it's there to validate the file, then report back for modified code.
  10. Informative
    Unimportant got a reaction from BuckGup in Read Tab-delimited File Into Object [C++]   
    std::getline simply returns the stream you give it as input, it does not return a bool. By testing for bool you're employing the returned stream's bool operator, which evaluates to false if the stream is in a invalid state. That does not tell you *why* it's in a invalid state. Could be eof, could be a failure due to a network drive being down, or a bad sector on your harddisk. You need to separate between eof and technical errors.
     
    And no, no lines are being tossed away. This is a common error when working with c++ streams. When eof is set (or any other error) the read has failed and thus nothing was read. If you process the data first before checking eof you actually add a bogus line. The only correct way is: read, check stream state and take approriate action, process data if stream still valid.
  11. Like
    Unimportant got a reaction from Eigenvektor in Read Tab-delimited File Into Object [C++]   
    @BuckGup All the above examples don't incorporate any possible error checking such as failure to extract a line from the file other then eof and file formatting errors. That's why you're getting bogus values, it's probably hitting some error and marching on. Here's a proper example:
    #include <iostream> #include <fstream> #include <string> #include <sstream> #include <vector> #include <stdexcept> struct Job { int pid; int burst; int arrival; int priority; }; void ReadJobs(std::istream& is, std::vector<Job>& jobs) { auto lineNumber = 0; while (1) { ++lineNumber; //Read a line. std::string line; std::getline(is, line); //Check if stream still valid. if (!is) { //If not, check for eof. if (is.eof()) { //Invalid stream, but eof => reached end of file. return; } else { //Invalid stream, but not eof => some technical error. throw std::runtime_error("Error retrieving line " + std::to_string(lineNumber)); } } //Parse line. Job job; std::stringstream ss(line); ss >> job.pid >> job.burst >> job.arrival >> job.priority; //Check stringstream state still valid. if (!ss) { //Invalid stringstream => file format error. throw std::runtime_error("Formatting error on line " + std::to_string(lineNumber)); } jobs.push_back(job); } } int main() { //Open file as ifstream. std::ifstream infile("input.txt"); if (!infile.is_open()) { std::cout << "Failed to open file!\n"; return 1; } std::vector<Job> jobs; //Read jobs from file. try { ReadJobs(infile, jobs); } catch (std::runtime_error& e) { std::cout << e.what() << '\n'; return 2; } //Print jobs. for (const auto& job : jobs) { std::cout << "Pid: " << job.pid << '\n'; std::cout << "Burst: " << job.burst << '\n'; std::cout << "Arrival: " << job.arrival << '\n'; std::cout << "Priority: " << job.priority << "\n\n"; } return 0; } It assumes there's no header in the file, so remove the:
    Pid Burst Arrival Pri line from the input file.
     
    If you really want that line in the input file, or perhaps even check if it's there to validate the file, then report back for modified code.
  12. Funny
    Unimportant got a reaction from kapa12 in Costume keyboard question   
    "Costume keyboard"
     

     
    (Sorry, couldn't resist xD)
  13. Funny
    Unimportant got a reaction from Prodigy_Smit in Costume keyboard question   
    "Costume keyboard"
     

     
    (Sorry, couldn't resist xD)
  14. Like
    Unimportant got a reaction from trag1c in C++ Undefined symbols for architecture x86_64 on CMake   
    Still not agreeing, sorry.
    Signed allows for faster code, as signed overflow is undefined and opens up a whole suit of optimization options.
    The difference between 2 offsets/indexes can be negative.
    In C++ we have stuff like range based for loops and STL functions that can (should) replace many loops.
     
    We've had to fix far too many bugs over the years because of this. Disagreeing with Stroustrup, Herb Sutter and Chandler Carruth reeks off exactly the over-confidence that'll get you caught in a really bad spot one day.
     
    Again, the main issue here is that unsigned does not model numbers that cannot be negative, it models modular arithmetic. Like Carruth says in the video, when is the last time you wanted modular behavior? There are literally *no* upsides to using unsigned over signed, only downsides, why make life hard for yourself?
  15. Informative
    Unimportant got a reaction from shadow_ray in C++ Undefined symbols for architecture x86_64 on CMake   
    @AluminiumTech Template arguments must be constexpr since templates are "expanded" at compile time.
    @gabrielcarvferNo! Don't use unsigned except for very special reasons such as bit manipulation. Always always use signed , I explained in detail in this post : https://linustechtips.com/topic/1082025-c-variable-storage-size-bytes/?do=findComment&comment=12727003
     
  16. Agree
    Unimportant got a reaction from wanderingfool2 in convertion error on C function   
    That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns.
     
    A solution would be to pass a pointer to str to the function for it to use.
  17. Agree
    Unimportant got a reaction from AbydosOne in convertion error on C function   
    That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns.
     
    A solution would be to pass a pointer to str to the function for it to use.
  18. Informative
    Unimportant got a reaction from Coldblackice in Could you make your own PCIe extension?   
    @W-L is right, but for more reasons then just noise. At the speeds PCIe is using, 250MHz - 1.25GHz, things behave differently compared to your average LF circuit. You get transmission line effects , such as reflection . this requires careful matching of the transmission line's characteristic impedance . One way to achieve this is by using striplines .
     
    Shielding isn't some magic bullet against noise, perhaps even the opposite if improperly used. In order to increase noise immunity differential signaling is used, which requires matching the lengths of the conductors in each differential pair so the loop lengths match and the noise pickup is equal between them. At these speeds even the speed electricity travels at plays a role. Matching the lengths of the conductors can be required to assure all the bits arrive at the same time. If you've ever seen traces on a motherboard snake around for no reason and wondered why, now you know.

     
    I could go on but I think the point is made. Implementing these techniques is impossible with just plain wires, which is why most decent commercial extension cables come in some form of printed flat flex or similar.
     
    Additional source for those interested: https://www.nxp.com/files-static/training_presentation/TP_HARDWARE_DESIGN_PCI_SMGIII.pdf
  19. Like
    Unimportant got a reaction from porina in Is modern ram less reliable?   
    With RAM sizes increasing constantly, the statistical error chance rises with it.
    If you double your RAM there's now twice as many bits to possibly go faulty.
    Now, of course the manufacturing technology improves as well and increases the reliability of the produced parts.
    However, do you think it realistic to improve reliability at the same rate as size increases ? It isn't.
     
    So yes, statistically, RAM is becoming more unreliable with size increases outpacing manufacturing improvements.
  20. Agree
    Unimportant got a reaction from straight_stewie in Programming 101   
    I'd say the low level stuff.
     
    There's an abundance of ever more abstract languages, further and further removed from the hardware, and the accompanying programmers who know less and less about how things work under the hood.
     
    That's nice and all but what I see regularly:
    Their abstract machine fails in some way or the other -> they're clueless about what to do next. Less and less people in the fields that actually design and build the underlying systems these languages run on. And as a result, those who do have this knowledge can eat all the other's lunch.
  21. Like
    Unimportant got a reaction from Kilrah in Recaping how to?   
    Both ESR and capacitance measurements are influenced by any circuits in parallel to the capacitor under test, so it's best to remove them and measure them out of circuit. He's right in that if you've removed them anyway why not just replace them?
  22. Like
    Unimportant got a reaction from Hackentosher in Recaping how to?   
    Both ESR and capacitance measurements are influenced by any circuits in parallel to the capacitor under test, so it's best to remove them and measure them out of circuit. He's right in that if you've removed them anyway why not just replace them?
  23. Agree
    Unimportant reacted to Kilrah in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    Yep, commonly referred to as Polyswitch
    https://www.littelfuse.com/products/polyswitch-resettable-ptcs.aspx
  24. Agree
    Unimportant got a reaction from Kilrah in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    Nah, this is actually a nice example of the Dunning Kruger effect, where someone has too little knowledge about a subject to be able to realize how little he/she knows.
     
    I'm not trying to discourage someone from learning and trying to build whatever he/she wishes but I think it's healthy to make them realize they're embarking on climbing a mountain, not the molehill their flawed perspective makes it out to be.
  25. Agree
    Unimportant got a reaction from Hackentosher in 3 Port 45W USB-C Charger (Formarly: pcie USB card.)   
    A 'scope with the bandwidth to make eye diagrams at pcie frequencies (to check signal integrity for your layout) cost as much as a nice car... 
×