victhor393

Considere fazer como é feito na TV... a tensão de saída do transformador é bem menor que a tensão de saída final, que é gerada por meio de multiplicadores de tensão. É um circuito bem simples, suporta apenas alguns mA, mas a alguns kV isso é muita coisa.

Pelo menos foi só o spin up time. Isso é classificado como indicativo de falha pois pode indicar problema no mecanismo que gira o HD (o motor que gira ele tem muito pouco torque, então qualquer problema se torna bem óbvio). Copie os dados o mais rápido possível para outro HD (cuidado nunca é demais, pode ser que esse HD pare de funcionar de vez) e mande esse para o RMA. Aparentemente ele realmente é novo, mas esse tipo de coisa acontece.

Bem, uma alternativa seria colocar cola (neutra, cola ácida pode causar alguns problemas) nos enrolamentos de componentes magnéticos, como indutores e transformadores. O ruído é causado pela vibração desses enrolamentos.

Você não está usando snubber no primário. Poderia mostrar a forma de onda acionando o gate do FET no Proteus?

Reconhece esse strings? A propósito, o GPS não produz simplesmente latitude, longitude e altitude. Ele fornece essa saída, que são sentenças NMEA 0183. Como GPS é uma coisa popular, não deve ser difícil de encontrar uma biblioteca para Arduino que consiga ler as sentenças.

O quê? Eu quis dizer que os puzzles são muito complicados e envolvem mecânicas que não são exploradas pelo single player do jogo. Por sinal, não usei walkthrough hora nenhuma.

Portal 2. O co-op é completamente sem noção e bem mais difícil que o single player. Depois de ter zerado o co-op, zerei Portal 1 e achei a coisa mais fácil do mundo...

25 dBi numa omni já é "otimismo" demais... sem falar que o seu sinal vai pra tudo quanto é lado, num enlace de 1km com uma antena omnidirecional, talvez algum operador licenciado perceba interferência e mande a ANATEL atrás de você. 2km com uma antena dessa, quem sabe num local perfeitamente plano e sem obstáculos... Sem saber como é o local não temos como lhe recomendar o que fazer, afinal de contas, se, por exemplo, haver um prédio entre os 2 pontos, então não dá.

De acordo com https://www.openhub.net/p/linux o kernel tem umas 17 milhões de linhas de código e no último mês forma feitos 3076 commits. Ninguém vai auditar tudo isso com regularidade, mas alguns pedaços do código são analisados de vez em quando (realmente, não deveria ter feito a afirmação de que isso não era feito e ponto final). Não estou dizendo que open source não presta, estou dizendo que open source não é algo mágico que torna qualquer coisa automaticamente segura. Não é porque existe a possibilidade de ser feita uma auditoria que quer dizer que a auditoria foi realizada.

Porque seria algo extremamente inconveniente de usar. Você não pode fazer nenhuma alteração no disco, nem mesmo salvar arquivos, é como o infame "Deep Freeze". Se você permitir a escrita no disco com a senha, o vírus que esteja em execução pode muito bem comprometer a imagem do disco. Sem falar que é mais um componente de hardware a ser usado, que custa caro. Apesar de nunca ter ouvido falar desse produto, tenho a impressão que já vi algo bastante similar, mas implementado de forma diferente... Deixando isso de lado, muitos sistemas embarcados implementam algo similar. O SO fica em uma imagem somente leitura dentro de uma partição no armazenamento não volátil (memória flash, HD), e os arquivos de configuração, etc (basicamente qualquer coisa que necessita de acesso de escrita) em outra. Para o SO rodando, é como se existisse apenas um volume, mas caso algo de errado aconteça, você só precisa apagar essa partição de "persistência" e tudo fica como se nada tivesse acontecido. É assim que funcionam coisas como aqueles botões de "reset" em roteadores, que apagam as configurações depois de pressionados, ou persistência em LiveUSB de distribuições Linux (nesse caso, um arquivo de imagem de persistência é escrito, ao invés de uma partição separada). Não sei se o Windows para desktop suporta algum desses esquemas. Basicamente, é como formatar o HD, só que bem mais conveniente. EDIT: Pelo que eu me lembre, a placa era PCI mesmo... e elas ainda existem! http://www.dx.com/p/pci-data-recovery-disk-protection-card-34823#.VD6obGDoLVM

Open source não torna algo seguro. Na teoria pode até ser mais seguro por permitir que o código seja auditado, mas ninguém faz isso. Sim, até mesmo no próprio kernel. Talvez tenham auditado o SELinux... mas eu não acho que tenham auditado o kernel todo. Você realmente não tem experiência nenhuma com projetos open source... O projeto que eu referi no post teve uma discussão enorme, referente ao uso de texturas .dds. Background rápido caso você não saiba: .dds é um formato de textura comprimido, desenvolvido pela MS para o DirectX, e além de ser comprimido, suporta mipmaps pré-carregados. Ele usa o algoritmo S3TC, que é protegido por patentes. 99% dos GPUs (estou sendo sério) implementam esse algoritmo em hardware, isso torna o uso de texturas .dds muito proveitoso (ocupando menos VRAM, menor tempo de carregamento). Não existe problemas para implementar esse algoritmo em um programa open source, pois ele só pode ser usado com hardware que implementa o algoritmo, logo, o usuário já pagou os royalties para o uso dele, que estão embutidos no preço do produto. O que aconteceu foi que, alguns desenvolvedores, extremamente radicais, insistiam que esse algoritmo não fosse implementado de forma alguma no programa, pois era patenteado e o formato era da MS e tal, apesar das indiscutíveis vantagens técnicas que o formato possuía sobre o que era usado até agora (.png, que não suporta mipmaps pré-carregados, o que fazia o tempo de carregamento das texturas ficar bem longo, já que eles tinham que ser gerados em tempo de execução), e que .dds não funcionava com os drivers de vídeo open source (mentira, o Mesa possui suporte a S3TC, disponível na maioria das distribuições, tanto que já joguei alguns jogos com o driver aberto da AMD sem problema nenhum). Para encurtar a história (já que isso já está bem off-topic), os "haters" do .dds acabaram se conformando com spamear uma mensagem de aviso no console toda vez que uma textura .dds era carregada. Como resultado disso, um dos defensores do .dds (que usava argumentos técnicos, ao invés de emocionais), que era um ótimo contribuidor, acabou dando "ragequit" do projeto. Eles poderiam estar trabalhando em melhorias para o projeto, mas eles acham que é muito melhor discutir no IRC e na lista de discussão sobre coisas extremamente irrelevantes... Outra controvérsia nesse projeto é o uso de um formato de modelos 3D bastante antiquado, usado somente porque os arquivos são ASCII e não binários... mas esse nunca gerou tanta polêmica.

Não me pergunte como exploits tão óbvios (no código) como Shellshock e Heartbleed passaram tanto tempo sem serem descobertos, então... A verdade é que, como muitos desses projetos são muito, muito grandes, ninguém audita o código. Apenas depois de algum "desastre" como esses dois, porque auditoria de código é algo dispendioso. Open source torna a auditoria do código mais fácil, isso é verdade, mas estaria o auditor disposto a compartilhar os resultados? Isso não acontece constantemente. O Heartbleed foi causado por um "commit" enviado para o OpenSSL em 2012!!!!! Dois anos e ninguém notou que havia um vulnerabilidade desse nível! Na maioria dos projetos open source, isso também (tecnicamente) não é possível. Muitas vezes o código é mal documentado, afinal de contas, pra quê documentação se você tem o código................ Em uma situação hipotética, Heartbleed pode ter sido introduzido no OpenSSL de forma proposital (não foi), e ninguém notou isso, mesmo com o código aberto. Um conselho: não escute usuários de Linux em fóruns. Você vai receber muitos conselhos ruins, especialmente como usuário iniciante, pois existe muito fanboyismo nesses fóruns e você ainda não possui o bom senso (como usuário experiente de Linux) para discernir informações úteis das inúteis. Como eu mesmo sou usuário de Linux, você é quem sabe se você deveria seguir esse conselho Por sinal, essa é mais uma das desvantagens do open source, muitas opiniões diferentes acabam por atrapalhar o progresso do projeto. Existem alguns que querem "politizar" o movimento, outros gostam do open source pelas vantagens técnicas que ele possui (não existe dependência de um produtor, logo o código pode ser mantido indefinidamente; é fácil recompilar um programa para rodar em uma arquitetura não suportada ou habilitar otimizações de velocidade; poder alterar o código para atender às suas necessidades), esses 2 tipos de pessoas sempre causam muita confusão nas listas de discussão. Inclusive, já presenciei uma dessas em um canal IRC de um projeto relativamente pequeno. Um desenvolvedor (bom, por sinal) chegou a dar "ragequit" por causa de uma dessas! Quanto a rodar OS X no PC... eu já fiz isso, inclusive chegou a ser meu SO principal por algum tempo. Não faça isso, você vai ter tanta dor de cabeça, não queira nem saber. Se estiver curioso, é melhor rodar em uma VM... bem menos dor de cabeça. Como você tem um i7-4xxx (Haswell) eu não sei se eu recomendaria o Mint, não sei se ele é novo o suficiente para tirar proveito da plataforma. Se eu não me engano, o kernel que ele usa não é novo o suficiente para suportar alguns dos recursos avançados de gerenciamento de energia da Intel. Seu Haswell é uma plataforma de mais de um ano atrás, vai funcionar, mas os kernels novos trazem melhorias para essa plataforma. A opção óbvia seria o Arch, mas eu não acho que ele seria uma boa distribuição para iniciantes. Outra opção seria o OpenSUSE, fácil para inciantes, que por padrão possui um kernel não muito novo, mas pode ser facilmente atualizado para um kernel recente. Minha sugestão seria: baixe algumas distros para iniciantes e teste todas elas. Muitas vezes isso acaba sendo de gosto do usuário. As mudanças com os kernels novos às vezes não são significativas para a experiência do usuário final. Tendo dito isso, instalei o Mint em "dual boot" com o Windows no PC de uma pessoa que estava curiosa para aprender Linux e ele tem usado constantemente, ocasionalmente me faz algumas perguntas sobre o SO (já que muitas coisas são feitas de forma diferente).

Se você não está tendo corrupção dos arquivos, travamentos aleatórios e coisas do tipo, então pode ignorar esse aviso. Aparentemente a correção de erros está funcionando e evitando que alguma coisa errada aconteça.

Isso é normal, o sistema de arquivos não vai esperar para o HD girar até algum lugar x para escrever os arquivos de forma contígua, isso seria idiotice e faria ele muito lento. O problema da fragmentação é quando existe excesso dela, o que significa que o sistema de arquivos vai ter que esperar muito tempo para o HD ler cada parte de algum arquivo, já que eles estão em locais "distantes". O arquivo estar em uma região contígua do disco não faz ele ser lido "de uma vez só", em uma só volta do disco. Muito provavelmente o disco vai ter que dar mais algumas voltas até a leitura ser completada.

O "spoiler" nesse fórum não trunca o texto, o único que faz isso é o "code" eu acho. Dê especificações mais detalhadas do seu PC, que chipset? Que processador ("Pentium"? Tem sei lá quantos modelos diferentes de "Pentium"...). E essa GT 610 é horrível, não serve pra outra coisa senão mostrar vídeo no monitor e jogar algum jogo de 1999...

O que você poderia fazer é usar DC para alimentar o fio e PWM para alterar a tensão.

Newegg não aceita cartão de fora dos EUA, tampouco envio para fora. Eles também não permitem envio para "freight forwarder".

Porque o calor do processador não está chegando no dissipador, oras. Faça o seguinte: Rode alguma coisa bem pesada, deixe a temperatura subir, desligue o PC o mais rápido possível (desligar na fonte) e tire o cooler. Veja se o processador não está quente.

Basicamente, o que (você não especificou qual a certificação) as certificações da série ISO 9000 analisam é a qualidade do processo, e não do produto. Isso simplesmente quer dizer que a empresa consegue fazer baterias consistentemente ruins, e não uma ruim e uma boa... Por exemplo: digamos que o QA da empresa considere uma bateria como sendo "boa" contendo 50% da sua capacidade de projeto (que é um critério ridículo e que vai resultar na produção de produtos ruins). Se os processos usados pelo QA para garantir que a bateria chegue ao cliente com pelo menos 50% da capacidade de projeto, a empresa pode passar na certificação. Pode não parecer fazer sentido, mas a certificação nunca teve a intenção de analisar a qualidade do produto, apenas do QA. Os padrões da empresa serem baixos não importa. O problema é que muitas pessoas associam ISO 9000 com qualidade do produto, o que não é verdade. ISO 14000 certifica coisas completamente diferentes, se eu não me engano, coisas como redução de danos ao meio ambiente.

Não, o carregador mesmo fica dentro do console. A fonte é "burra" e produz tensão constante. O carregador aceita até 6.5V na entrada. Se você estiver carregando com USB, a corrente fornecida pela porta pode não ser suficiente e o computador pode acabar por desligar a porta, mas muitos computadores conseguem fornecer mais que os 500 mA, e o máximo que pode acontecer é o console parar de carregar sem razão aparente, pela alimentação ter sido desligada pelo PC. Eu teria cuidado com algum aquecimento excessivo logo à esquerda do botão X, pois é lá onde fica o carregador, e por ser linear, pode esquentar mais com os 5V ao invés de 4.6V.

Outra forma mais simples que o delta-sigma é um modulador PWM, como é comumente usado em amplificadores classe D. PWM pode ser meio chato de ler com o microcontrolador, mas como só possui 2 níveis, dá para ler com uma entrada digital.

Você aprendeu uma valiosa lição, apesar de ter sido do jeito difícil: sempre verifique as especificações de todos os componentes antes de comprá-los!!!!! Você comprou um sensor de saída analógica mas seu PIC16F84 não possui ADC! O que você pode fazer é usar um circuito conhecido como "comparador de tensão" para conseguir uma saída digital que pode ser lida pelo seu microcontrolador.

Eu também já usei fonte de 30 reais em vários PCs e nunca tive (muitos) problemas... Depois de ver uma dessas por dentro, não chego perto nem de graça. Uso uma dessas pra carregar umas pilhas (igualmente lixo) de Li-ion e não sei como nada pegou fogo até agora...

Eu passo longe dessas fontes aí... só de segurar uma você pensa "como é que esse treco não flutua" de tão leve que é. Existe um possível "porém" em usar um carregador de 5V no 3DS. A Nintendo escolheu uma fonte de 4.6V por uma razão... o CI que controla a carga da bateria usa um regulador linear, logo 4.6V foi escolhido para reduzir a dissipação de calor. Usar um carregador de 5V iria fazer o CI esquentar mais do que ele normalmente esquentaria, agora não tenho como afirmar com certeza, já que eu não sei qual é a corrente de carga nem o consumo do sistema. (o sistema é alimentado por um regulador linear presente neste mesmo CI, que regula a tensão de saída para <tensão da bateria> + 0,225V. CI: http://www.ti.com/product/bq24072 https://d3nevzfk7ii3be.cloudfront.net/igi/n1CKAdbPrHyNPNuW.huge - O CI em questão está logo à esquerda do botão superior no arranjo em forma de cruz (o botão X) próximo ao canto superior direito da placa.

Qual é a versão da sua BIOS? Eu comprei uma placa da Asus recentemente (J1800I-C) e a BIOS que veio na placa era muito bugada e com algumas coisas faltando, tive que atualizar para a última versão no site da Asus que consertou a maioria dos problemas. http://www.asus.com/br/support