quarta-feira, 26 de setembro de 2018

Avaliação e reparo de Fone de ouvido Bose QC25 - Lado esquerdo não funciona!

Eu viajo de avião quase toda semana para trabalho. Avião na minha opinião é a perfeita máquina de tortura: apertado, poltrona ruim e barulhento, seja por causa dos motores ou das pessoas e crianças que ficam gritando (eu sei que isso soa rabugento!). O fone de ouvido que eles dão no avião é horrivel: vc precisa colocar lá no alto para escutar alguma coisa no meio da barulheira, o som é sofrido...me deixa maluco.

Eu já havia utilizado diversos modelos de fone de ouvido, alguns que prometiam até reduzir ruídos, mas nada era legal. Até que encontrei o Bose QC25. Caro pra caralho, mas a redução do ruído era algo mágico, muito melhor que qualquer coisa que eu conhecia na época, e o som infinitamente melhor que qualquer outra coisa que eu já havia utilizado! Isso era em 2015.

Agora, meio de 2018, o lado esquerdo do fone parou de funcionar! Achei na internet um método de colocar um papel no falante para fazer ele funcionar....funciona...mas só por algum tempo. O problema é o falante mesmo que quebra o fio da bobina e ele deixa de funcionar. Para um fone de US$300 eu acho que durou pouco.

É impossivel encontrar os falantes originais na internet aqui no Brazil, tem um monte de gente vendendo coisas parecidas.

Fotos do falante original bose 

Fotos do falante original bose
Achei no mercado livre um cara vendendo falantes de reposição para Bose: ele cobrava quase R$60 cada falante. Encontrei o mesmo falante sendo vendido por outra pessoa por R$30 o par. O modelo que utilizei foi esse aqui: TONLEN P1695. O mesmo modelo que o cara do R$60 reais dizia vender.

Resultado de imagem para tonlen P1695
Imagem do falante TONLEN P1695
Resultado de imagem para tonlen P1695
Imagem do falante TONLEN P1695
Existem vários vídeo no youtube de como fazer esse reparo:



Troquei só o lado esquerdo, mas ficou esquisito: a sensibilidade dos falantes era diferente - o original era mais alto e tinha outra equalização. Parecia que um ouvido ficava tampado e estava dando dor de cabeça. Depois que troquei os dois falantes o desconforto sumiu.

Eu percebí que a equalização esta diferente com os novos falantes. Não é a mesma coisa que o original, a qualidade do som um pouco pior, mas mesmo assim é melhor que turbina de avião e crianças gritando.

Algumas coisas importantes que percebi nessa troca e valem como dica para quem for tentar reparar seu fone de ouvído:

1 - Precisa trocar os dois falantes: se forem diferentes o volume e equalização diferentes vão te deixar maluco se voce tiver uma mínima sensibilidade auditiva. Se vc for um ogro surdo tanto faz.
2 - A polaridade dos falantes é muito importante para o sistema de redução de ruído funcionar. Certifique de soldar o fio positivo no positivo do falante. O fio positivo é vermelho, e está marcado na placa eletrônica com um sinal de +. No falante geralmente tem uma marca vermelha.
3 - Vc vai precisar colar os novos falantes para o som ficar melhor. Eu usei cola quente.
4 - Não vai ficar a mesma coisa. No meu caso a equalização com os novos falantes é melhor com o sistema anti ruído e equalizador desligado.

O fone Bose QC25 é muito bom: confortável, sistema de cancelamento de ruído muito bom e boa qualidade de som. Entretanto durou pouco. Por isso resolvi não dar meu dinheiro para Bose e mandar para um concorrente: comprei, um Sony WH1000XM2. Apesar desse nome que parece numeração de chassi de carro espero que ele seja tão bom quanto o Bose e dure um pouco mais. Vou arriscar.

quinta-feira, 6 de setembro de 2018

Engenharia reversa ECU Bosch 7.5.30 - Parte 1 de várias

Um dia desses resolvi investigar uma ECU, unidade de controle de motor. Os motivos para isso são:

  1. Como é fabricado o hardware para ser robusto e aguentar a pancada em um carro e um monte de mecânico nó cego? Esse módulos são super robustos, e aguentam muito abuso. É difícil projetar e fabricar algo equivalente sem muito teste e dinheiro.
  2. Como é feito o programa desse módulo? O programa deve ser algum muito bem feito, pois precisa lidar com diversos fatores e condições de falhas e garantir que o motor funcione nas condições mais extremas.
  3. Será possível reprogramar esse módulo com um programa feito por mim? Existem algumas ECU open source - por exemplo: speeduino, megasquirt e rusefi - mas o hardware delas não é lá grande coisa. Utilizar um módulo antigo com um código open source é interessante pois junta um hardware muito bom, testado e barato com um software que qualquer um pode alterar e ajustar. Isso permite utilizar esse módulos super robustos para diferentes aplicações.

Pesquisei na internet um módulo que tinha um preço bom e que permitia ser reprogramado, e acabei escolhendo o modelo ME7.5.30 da Bosch, utilizada em carros da volks, como o gol G5.Paguei algo como R$250 num ferro velho.

Módulo Bosch ME7.5.30. A parte HW: H03 deve ser variação de hardware.
Primeiro comecei pelos componentes eletrônicos. Encontrei o datasheet do processador e alguns componentes periféricos como transistores, eeprom e controlador de borboleta. Mas existem vários chips proprietários da Bosch, e não consegui encontrar nenhuma informação sobre eles na internet. Isso dificulta bastante o processo de engenharia reversa.

Com muita paciência puxei o esquema elétrico parcial dessa placa. Como isso foi possivel entender a função da maioria dos componentes. As principais funções estão na figura abaixo.

Placa do módulo. Aqui o conector já foi removido para facilitar o equema elétrico. A figura mostra os princípais blocos funcionais no circuito.
O principais blocos são:

  1. Chave de entrada com proteção de polaridade e proteção contra load dump: isso é feito com dois transistores N-MOSFET  FDD5810 em série. Eles protegem contra um eventual inversão na polaridade de alimenteção e também contra picos de tensão que podem ocorrer no sistema elétrico do veículo em algumas condições. Estes transistores também são utilizados para ligar/desligar a alimentação de parte do circuito.
  2. Circuito de fonte, k-line, rpm (BOSCH 30639): esse circuito faz um monte de coisa. Ele liga/desliga alimentação de parte da placa, tem uma fonte permanente e outra controlada e 5 V, tem um circuito duplicador de tensão utilizado para controlar os gates dos N-MOSFET FDD5810 da chave de entrada. Além de ser fonte, ele fornece tensão para diferentes sensores (deve ter algum tipo de proteção contra excesso de corrente), tem um drivers conversor de RS232 TTL para K-LINE, e um circuito de tratamento de sinal para o sensor de RPM. 
  3. Aquecedor sonda lambda: existem 2 entradas para aquecimento de sonda lambda. Isso é feito com o componente BUK138-50DL, uma chave em estado sólido com proteção contra sobre corrente e sobre temperatura.
  4. CI BOSCH 3061239 : isso aqui provavelmente é da Bosch também, e parece ser um transceiver de CAN, utilizado para comunicação com o painel.
  5. Processador ST10F275: aqui é feito todo o processamento e comunicação do módulo. É o cérebro do negocio.
  6. Whatchdog: é um circuito de whatchdog externo formado pelo oque parece ser um CI que monitora os niveis de tensões na placa e um microcontrolador que coloca uma inteligência no whatchdog. Essa parte do circuito é a mais obscura e dificil de entender.
  7. Sensor detonação: é um circuito de tratamento de sinal para o sensor de detonação. Tem um amplificador operacional e um circuito maluco. O sinal tratado vai para um AD do processador.
  8. Driver Ignição: Bosch 30490: manda sinais para as bobinas. Esse driver deve mandar pulsos positivos para o controle de bobinas. Não pode ser utilizado com bobinas comuns, somente com aquelas que já tem o driver de corrente embutido (acho).
  9. Injetores e atuadores: Bosch 30621: driver de corrente low side, ou seja, conecta a carga no terra. Utilizado para controle dos injetores e reles de diferentes sistemas do carro.
  10. EEPROM: ST 95040. Memoria EEPROM SPI. Tem o codigo imobilizador do carro e mais alguns parametros. Também deve salvar os log de erro do sistema.
  11. Driver Borboleta: ST 9929. Um driver de corrente para controle da posição da borboleta de admissão.
É interessante notar que quase todos os pinos de entrada desse módulo são filtrados com capacitores para o terra. Somente pinos como do sensor e detonação, e talvez a CAN ou sensor de rotação que não tem capacitores de filtragem.

Outra característica importante é que a comunicação CAN é utilizada com o painel do carro. A linha K-LINE é utilizada para comunicação com o scanner. K-LINE nada mais é que uma RS232 utilizando somente um fio, ou seja, tanto o TX como o RX utilizam o mesmo meio físico. Um circuito simples converte RS232 para K-LINE. 

Num próximo post apresento como pode ser feita a leitura e gravação desse módulo.



terça-feira, 10 de julho de 2018

Keppe Motor - Avaliação Técnica

Algum tempo atrás me perguntaram oque eu achava do Keppe Motor: um novo princípio de motor elétrico que chegava a ser 90% mais econômico que os motores convencionais. A pergunta era para auxiliar na decisão sobre investir ou não na empresa. Na época procurei na internet por mais informações, e tudo oque encontrei era suspeito e não técnico suficiente para explicar porque o motor seria mais eficiência. O site oficial ( http://www.keppemotor.com/institucional/ ) mostrava vários certificados e prêmios de origem duvidosas e o criador da teoria era um psicanalista aparentemente sem experiencia em motores ou qualquer outra matéria técnica. Conclui que as informações não eram confiáveis e que investir nisso era um negócio arriscado.

Por ironia do destino fui perguntado sobre o mesmo assunto um ano depois. Por desencargo pesquisei novamente sobre o assunto, encontrei as mesmas coisas suspeitas, mas um informação nova apareceu: teste do INMETRO para ventiladores de teto. Pensei: "pronto, agora tenho informação confiável para mostrar que o Keppe motor não funciona". Para minha surpresa o consumo medido pelo INMETRO mostrou que os ventiladores com motor Keppe eram os modelos que apresentavam menor consumo elétrico entre todos ventiladores avaliados!! E uma redução da ordem de 50% (ou até mais se comparado com os piores ventiladores). 

Como era possível pessoas que pareciam não ter a menor ideia do que estavam falando, parecendo grandes charlatões, conseguirem fazer um motor com menor consumo que grandes fabricante? Como pode um psicanalista criar uma teoria que engenheiros e físicos não conseguiram? Eu precisava investigar melhor isso.

Encontrei alguns sites com as mesma dúvidas que eu, mas a maioria deles só tratava de descascar os caras baseado nas bobagens que eles falam, física desinvertida ressonante da anti matéria, blá blá, veja melhor aqui: http://www.keppemotor.com/institucional/a-nova-fisica-2/  (observação: a física que eu conheço usa muito mais matemática que palavras). Mas ainda não estava claro como de um monte de bobagem eles fizeram um motor com consumo realmente menor do que o resto disponível no mercado, confirmado pelo INMETRO? Ninguém explicava isso!

As hipóteses levantadas foram:

1 - Hipótese: O INMETRO não sabe oque faz!!
O INMETRO fez a medida errada: a potência medida pelo INMETRO seria a potência aparente -VA - (e não real W). Se o fator de potência do motor convencional for muito baixo, e no Keppe motor for próximo a 1, então explicaria a diferença na medida. Se voce não entendeu nada leia isso: https://pt.wikipedia.org/wiki/Fator_de_pot%C3%AAncia. Se a medida fosse realmente potência  aparente (VA) e não real (W),  seria uma barbeiragem gigantesca do INMETRO, e todos os técnicos alí teriam de ser totalmente incompetentes. Por menor que sejam minhas expectativas com esse tipo de órgão, acreditar nisso era um pouco radical. Encontrei dois vídeos no youtube: https://www.youtube.com/watch?v=HOVD08NK5hUhttps://www.youtube.com/watch?v=nysc0MiwUiE mostrando a medida de potência de um ventilador comum e Keppe motor. O instrumento é um yokogawa wt 110, que mede potência real. É um equipamento bom, dá para confiar nas medidas. Para condições parecidas o motor convencional tinha um consumo de 183W e o Keppe 71W. Calculei o fator de potencia que foram 0,9 para o convencional e 0,62 para o Keppe. Eu esperava o contrário, um fator de potência baixo para o motor convencional e alto para o Keppe. Essa hipótese não é válida. As medidas parecem ser corretas.

2 - Hipótese: os motores tem tecnologias diferentes!!
Aqui vc vai dizer, lógico que são diferentes: é o revolucionário Keppe motor. A hipótese aqui é se o Keppe motor não é um outro tipo de motor conhecido fantasiado como revolução. Numa pesquisa rápida encontrei que a eficiência de motores monofásicos - semelhantes aos utilizados em ventiladores - não é das melhores: 50 a 70% segundo dados da WEG. Enquanto isso motores brushless tem eficiência perto de 96%. Essa hipótese parece promissora!! Na lista do INMETRO - http://www.inmetro.gov.br/consumidor/pbe/ventiladores_de_teto_127v.pdf  haviam outros ventiladores com consumo baixo (não tão baixo quanto o Keppe, mas próximos) e pesquisei por eles. Um deles era um da Arno VX10, e o motor utilizado nesse modelo é..........um brushless. O consumo nesse motor é de 33W, no Keppe era 22 a 28W dependendo do modelo.
Aqui vale uma explicação: os ventiladores mais simples devem ter uma eficiência pior fora da velocidade máxima. Isso deve ao tipo de construção e à redução de custos do produto. Por isso os motores vão ser comparados somente na rotação máxima.

3 - Hipótese: os motores Keppe são um tipo de motor brushless!!
Neste vídeo - https://www.youtube.com/watch?v=wiIT-M7S7Io&list=RDQMaiQMWUSGNaw&start_radio=1 - mostra o princípio de um motor Keppe. Isso é similar um motor brushless. Coloque o imã do lado de fora, chaveie a corrente na bobina com um circuito adequado e você tem um motor brushless como esse: https://www.youtube.com/watch?v=bCEiOnuODac . Altamente eficiente.

Aí vc pergunta: Mas e a luzinha que acende com a energia gerada pelo motor Keppe no primeiro vídeo? Ela é de 60V, e a bateria tem 9V somente!!
Isso é um fenômeno conhecido, e não tem nada a ver com geração e energia ou física desinvertida: essa é a energia armazenada na bobina que quando é chaveada descarrega na lâmpada. O mesmo princípio era utilizado nas bobinas e platinado antigamente no sistema de ignição dos carros: a partir de 12V é criada uma faísca da ordem de vários mil volts para a vela de ignição, veja aqui https://www.youtube.com/watch?v=UEmSFDn8Rlw como funciona. Não existe criação de energia aqui.

E voce pergunta novamente: E a ressonância de sei la oque??
Bem, isso eu não tenho ideia do que se trata. Pode ser pura bobagem, ou eles utilizam algum tipo de ressonância no conversor ou no controle da corrente nas bobinas do motor. Existem algumas topologias de conversores DC e controladores de motor que utilizam ressonância para aumento a eficiência. Mas não é possível concluir muita coisa a partir das informações disponíveis.

Conclusão

1 - Uma teoria feita por um psicanalista brasileiro esta revolucionando os motores elétricos? Provavelmente não. Tudo indica que o Keppe motor seja uma variação de um motor DC brushless.

2 - Keppe motor é uma enganação? 
Tudo indica que a física desinvertida e coisas do gênero não devem ser levados a sério. Entretanto o consumo desse motor é muito mais baixo se comparado a motores monofásicos encontrados na maioria dos ventiladores.

3- Por que somente encontro ventiladores com esse motor? 
Porque é nesse mercado que eles conseguem uma economia de energia. A eficiência de motores monofásicos utilizados em ventiladores é muito baixa, por isso com um motor um pouco melhor é possível ter um diferencial de marketing. Competir com motores maiores, trifásicos ou DC é mais difícil pois a eficiência deles geralmente é melhor. Acho improvável que esse tipo de motor acabe ocupando outro nicho de mercado, como motores industriais.

4 - Mas ele consome menos? 
Sim, segundo o INMETRO e comparado com os demais ventiladores. Isso deve acontecer pois utiliza um motor e uma eletrônica de melhor qualidade, e não devido à física desinvertida ou alguma outra maluquice. O preço desse ventilador também deve ser substancialmente maior que ventiladores convencionais.

Alias, no momento em que escrevo isso, não consigo encontrar nenhuma forma de comprar um desses ventiladores Keppe motor.

Caso voce queira mais informações sobre o Keppe motor, este é o site da empresa.

Um comentário importante é que quem fabrica o Keppe Motor sabe oque oque esta fazendo, e entende da física e engenharia clássica. Não entendo porque eles fazem o desserviço de causar confusão com uma nova física e princípios revolucionários.

Esta avaliação é baseada em conhecimentos da física e engenharia clássica. Na improvável hipótese da nova física vir a ser correta e sobrepor aos conhecimentos clássicos então os comentários feitos aqui podem ser inválidos e não se aplicar ao motor Keppe.

sexta-feira, 9 de março de 2018

Nobreak TS Shara Soho II - NUT - Linux - Raspberry PI - Como configurar

Este deve ser o post final de como configurar o NUT no linux para utilizar o nobreak TS Shara - SOHO. Vários detalhes tansformaram essa tarefa que devia ser fácil em um luta de algumas semanas. O objetivo era ter um nobreak que desligue e ligue automaticamente meu servidor de forma controlada no caso de falta e retorno de energia.

O maior problema encontrado é que nobreak parece repetir o ultimo comando enviado para ele sempre que a usb é reconectada. Isso é um problema quando o último comando pede que o nobreak seja desligado, aí quando ele é ligado novamente ele executa o comando de desligamento e apaga no meio do boot. E fica assim até voce desligar a usb ou executar alguma combinação de ligar no botão, tirar da tomada, etc.

Outro comando que não funciona corretamente neste nobreak é o desligar e ligar o nobreak após alguns minutos, que é o comando default utilizado durante o shutdown no NUT. No caso de falta de energia ele deveria ficar desligado até a energia voltar, e ligar automaticamente após os minutos configurados. Oque ele realmente faz é ficar ligando com ou sem energia.

O comando que funcionou corretamente é para somente desligar o nobreak. Quando ele é executado na falta de energia ele desliga o nobreak e liga quando a energia voltar. Isso esta ok. O problema é quando o comando é executado e ainda existe energia: neste caso ele desliga definitivamente e só liga manualmente no botão. Além disso caso aparece o problema de repetir o ultimo comando, e o nobreak apaga durante o boot.

Para contornar todos esse problemas a configuração encontrada foi esta:

Instalei somente o básico do nut:
sudo apt-get install nut-client nut-server

Fiz a configuração dele adicionando o texto abaixo em cada arquivo:

/etc/nut/nut.conf
MODE=standalone

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"
        offdelay = 60
        ondelay = 0

É importante ter ondelay = 0, para que o comando de shutdown correto seja enviado para o nobreak. Se alterar esse delay ele não funciona direito.

/etc/nut/upsd.users
[upsmon]
        password = "123456"
        upsmon master
        actions = SET
        instcmds = ALL

/etc/nut/upsmon.conf
MONITOR tsshara@localhost 1 upsmon "123456" master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Teste do driver. Ele deve mostrar algum erro se não funcionar.
sudo upsdrvctl start

Depois de um boot tudo deve funcionar. Para testar use:
upsc tsshara

Que deve apresentar algo assim:
Init SSL without certificate database
battery.charge: 92
battery.voltage: 12.80
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.mfr: UPS  700 VA AUT
device.model: TS Shara
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.protocol: megatec
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: Megatec 0.06
driver.version.internal: 0.28
input.current.nominal: 4.0
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 0.0
input.voltage.fault: 0.0
input.voltage.nominal: 115
output.voltage: 111.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 20070731-5
ups.productid: 0035
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0483

Para evitar o problema de repetir o último comando foi adicionada a última linha no arquivo /lib/systemd/system-shutdown/nutshutdown

#!/bin/sh
/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
# Comando para fazer uma leitura simples no nobreak e evitar bug de repeticao de shutdown
/lib/nut/nutdrv_qx -a tsshara 

Essa linha faz uma leitura genérica no nobreak, e contorna o bug de repetir o shutdown.

O desligamento pode ser testado com:
sudo upsmon -c fsd

Se o sistema estiver sem energia ele vai voltar quando a energia voltar. Se ele estiver com energia então isso vai desligar o sistema, e neste caso é necessário ligar manualmente o nobreak.

Essa configuração parece ser a que melhor funciona. Ela garante que o sistema seja desligado corretamente quando falta energia, e retorne quando a energia voltar. Existe uma chance que ela não funcione corretamente: se a energia voltar antes do sistema terminar o desligamento automático o nobreak não vai religar, o sistema vai ficar desligado. Será necessário religamento manual do nobreak. Entretando essa configuração protege o sistema do bug de repetição de comando e evita que o nobreak desligue no meio do próximo boot. Conclusão: pelo menos os sitema de arquivos não vai estragar. Se vc tiver muito azar as vezes vai precisar religar o sistema manualmente.

Em resumo esse nobreak da forma que está não é indicado para aplicações onde o nobreak precisa ligar/desligar automaticamente computador. Se eu soubesse de toda a dificuldade em fazer ele funcionar teria comprado outro modelo...(mas nada garante que outros modelos de nobreak não tenham bugs).

Importante notar que versões antigas do nutdrv_qx não funcionam no TS Shara. Outro ponto é que sistema linux diferentes do Raspberry podem ter o script the shutdown localizados em outro lugar. As versões utilizadas aqui podem ser vistas nos dados mostrados acima.


quarta-feira, 7 de março de 2018

Controle de nobreak TS Shara em Linux - Raspberry pi

Tenho um servidor em um Raspberry, e estava sofrendo com problema de sistema de arquivos corrompidos devido desligamento incorreto ( falta de energia ). Para resolver isso procurei um nobreak. Mas como é um servidor, e niguém fica por perto o nobreak precisa fazer duas coisas: (1) desligar o servidor de forma controlada quando faltar energia, e (2) ligar novamente o servidor quando a energia voltar. Procurei o nobreak mais barato com controle por USB e encontrei o TS Shara Solo II.

Para o do nobreak escolhi utilizar o pacote NUT, pois o fabricante oferece esse software no site (apesar de desatualizado).

Instalei somente o básico do nut:
sudo apt-get install nut-client nut-server

Fiz a configuração dele adicionando os texto abaixo em cada arquivo:

/etc/nut/nut.conf
MODE=standalone

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"

/etc/nut/upsd.users
[upsmon]
        password = "123456"
        upsmon master
        actions = SET
        instcmds = ALL

/etc/nut/upsmon.conf
MONITOR tsshara@localhost 1 upsmon "123456" master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Teste do driver. Ele deve mostrar algum erro se não funcionar.
sudo upsdrvctl start

Depois de um boot tudo estava funcionando. Para testar use:
upsc tsshara

Que deve apresentar algo assim:
Init SSL without certificate database
battery.charge: 92
battery.voltage: 12.80
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.mfr: UPS  700 VA AUT
device.model: TS Shara
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.protocol: megatec
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: Megatec 0.06
driver.version.internal: 0.28
input.current.nominal: 4.0
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 0.0
input.voltage.fault: 0.0
input.voltage.nominal: 115
output.voltage: 111.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 20070731-5
ups.productid: 0035
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0483

Hora de testar o desligamento/religamento controlado dele:
sudo upsmon -c fsd

O raspberry fez o shutdown direitinho e o nobreak desligou após 30 segundos. Após 180 segundos ele ligou novamente e no meio do boot o nobreak apagou!! Após 180 segundos ele ligou novamente e apagou no meio do boot novamente. E ficou ligando e desligando até eu aceitar que alguma coisa não estava funcionando direito. O sistema de arquivo ja tinha ido pro saco e tive que restaurar a imagem para fazer o raspberry funcionar novamente.

Esse não era o comportamento esperado, o nobreak não deveria desligar no meio do boot. Fiz alguns testes e identifiquei um possível bug no firmware do nobreak. Consegui fazer um paliativo para esse bug (apresentado em outro post) mas outro problema apareceu: o nobrek não ficava desligado quando estava sem energia, ele ligava, o raspberry dava boot, via que tinha pouca carga na bateria, mandava o nobreak desligar. O nobreak desligava por alguns minutos e ligava novamente, mesmo que ainda não tivesse energia. Ele ficava fazendo isso até acabar toda a carga da bateria. Logicamente não era isso que eu queria.

Após uma olhada no código fonte, e uma conversa com os desenvolvedores do NUT cheguei a seguinte configuração que funcionou:

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"
        offdelay = 30
        ondelay = 0

O parametro offdelay é o tempo em segundos que ele aguarda para desligar após receber o comando para desligar. o ondelay é o tempo que ele deveria esperar para voltar a funcionar após a energia ser reestabelecida. Entretanto utilizar um valor de ondelay diferente de zero não funciona neste nobreak, e ao invés de ele ficar desligado, ele fica reiniciando.

Nos testes também tentei o parametro stayoff, mas o nobreak não parece ser compativel com este comando e também fica reiniciando. Entretanto observei o seguinte ao utilizar a configuração acima:

1 - Quando falta energia e a bateria do nobreak esta próximo do fim, o NUT força o desligamento do nobreak. Quando a energia volta o nobreak liga após uns 5 segundos e o sistema volta a operar.
2 - Se o comando de desligamento do nobreak for feito enquanto ainda existe alimentação, o nobreak desliga e não retorna mais. E pior: quando o nobreak é ligado ele lembra do ultimo comando de shutdown e desliga novamente no meio do boot, e puff...arrebenta com o sistema de arquivo. No caso de faltar energia, e o sistema começar a fazer shutdown, se a energia voltar antes do nobreak desligar o sistema vai permanecer desligado, e quanto ele for ligado novamente pode ocorrer o desligamento do nobreak no boot. Não bom!

Portanto, quando for testar o desligamento do nobreak, tirar ele da tomada para simular uma falta de energia.

Para ficar 100% é necessário que o fabricante corrija os bugs do firmware do nobreak. Vou tentar um contato com eles para ver se chego em alguma coisa.


terça-feira, 27 de fevereiro de 2018

Utilizando NUT para controle de Nobreak TS SHARA com Raspberry

Eu montei um servidor LORAWAN com um raspberry, mas ele deixava de funcionar toda semana, com o sistema de arquivo corrompido. Não encontrei problemas na memória USB por isso a causa parece ser mais por desligamento incorreto do raspberry devido falta de energia. Para isso arrumei um nobreak.

Resultado de imagem para tsshara sohos IIImagem relacionada
Nobreak TS Shara Soho II: parece a cabeça de um robo do star wars

Um nobreak protege contra falta de energia, mas precisa comunicar com o servidor, caso contrário quando a carga da bateria esgotar ele desliga o servidor incorretamente e tenho o mesmo problema. Ele também precisa ligar o servidor novamente quando a energia voltar. Estes são os nobreak gerenciaveis. Procurei o nobreak mais barato com controle por USB e encontrei o TS Shara Solo II. Encontrei os drivers na pagina do fabricante e achei que em meia hora tudo estaria funcionando...só que não!!

O programa fornecido pelo fabricante para linux é baseado no pacote NUT com drivers específicos para o TS Shara. O problema é que o drivers são compilados para plataforma x86 e não devem rodar no ARM do raspberry. De qualquer forma o software não funcionou legal no meu desktop (não investiguei porque), por isso resolvi ir direto para o NUT puro. Na página do NUT havia a informação que existia suporte para esse nobreak com o driver nutdrv_qx.

Instalei o nut:
sudo apt-get install nut-client nut-server

Fiz a configuração dele adicionando os texto abaixo em cada arquivo:

/etc/nut/nut.conf
MODE=standalone

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"

/etc/nut/upsd.users
[upsmon]
        password = "123456"
        upsmon master
        actions = SET
        instcmds = ALL

/etc/nut/upsmon.conf
MONITOR tsshara@localhost 1 upsmon "123456" master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Teste do driver. Ele deve mostrar algum erro se não funcionar.
sudo upsdrvctl start

Depois de um boot tudo estava funcionando. Para testar use:
upsc tsshara

Que deve apresentar algo assim:
Init SSL without certificate database
battery.charge: 92
battery.voltage: 12.80
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.mfr: UPS  700 VA AUT
device.model: TS Shara
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.protocol: megatec
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: Megatec 0.06
driver.version.internal: 0.28
input.current.nominal: 4.0
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 0.0
input.voltage.fault: 0.0
input.voltage.nominal: 115
output.voltage: 111.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 20070731-5
ups.productid: 0035
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0483


Mas um nobreak só resolve se ele desligar e ligar meu servidor de forma controlada. O nobreak tem suporte para desligar o servidor quando falta energia e a carga da bateria esta baixa, e religar o quando a energia voltar. Aqui que começaram os problemas. O comando para testar isso é o seguinte:

sudo upsmon -c fsd

E foi... o raspberry fez o shutdown direitinho e o nobreak desligou após 30 segundos. Após 180 segundos ele ligou novamente (mágica!!) e no meio do boot o nobreak apagou!! Após 180 segundos ele ligou novamente e apagou no meio do boot novamente. E ficou ligando e desligando até eu aceitar que alguma coisa não estava funcionando direito. O sistema de arquivo ja tinha ido pro saco e tive que restaurar a imagem para fazer o raspberry funcionar novamente.

Oque estaria causando esse apagão durante o boot?? Olhei o código fonte do NUT (que é uma das coisas mais confusas que já conheci), log do linux, recompilei o código, e sempre com o apagão no boot. Uma semana depois encontrei o problema: o nobreak sempre apagava depois de ter sido desligado por software, e 30 segundos após reconectar a porta USB. Nem importava se havia comunicação na USB, bastava por ali 5V que ele apagava depois de 30 segundos!!. Mas durante os testes quando eu utilizava o comando abaixo ele funcionava corretamente:

upscmd tsshara shutdown.return

hummm...existe alguma coisa diferente entre o upsmon  e o upscmd!A diferença que fez a diferença é que no upscmd após o comando de shutdown.return ele continua enviando comandos para ler o status do nobreak, enquanto no upsmon o shutdown.return é o último comando enviado. Alterei o driver, coloquei uma leitura de status depois no final da função de shudown e...uuhhuuu...funcionou corretamente. Isso parece ser um bug no nobreak, onde ele executa o ultimo comando enviado sempre que a USB é reconectada. O comando shutdown.return desliga o nobreak 30 segundos depois de recebido, aguarda 180 segundos e liga o sistema novamente. Sempre a USB era reconectada esse padrão acontecia. Enviar um comando diferente depois do shutdown.return parece impedir que ele fique reiniciando.

Ótimo, mas o driver não ficou legal, pois preciso recompilar o driver, dá um trabalhao, e a solução não é boa suficinete para mandar um patch no driver, pois deve ser um bug específico do TS Shara. A solução que encontrei foi alterar o script de shutdown enquanto converso com os desenvolvedores do NUT qual a melhor forma de resolver esse problema e incluir solução no pacote:

Alterei o arquivo /lib/systemd/system-shutdonw/nutshutdown:

#!/bin/sh
# comando original
#/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
# Comando alternativo para contornar possível bug no nobreak TS Shara
/sbin/upsmon -K >/dev/null 2>&1 && /lib/nut/nutdrv_qx -a tsshara -k; /lib/nut/nutdrv_qx -a tsshara 

O uspmon -K checa se tem a flag de shutdown ativada, se estiver chama o resto do script. O comando em seguida é para chamar a rotina de shutdown original, e o terceiro comando é para realizar a leitura de status do nobreak e evitar o bug no boot.

Esta solução não e flexível, pois amarra a configuração do nobreak com o arquivo de shutdwon. Outro problema é que diferentes plataformas utilizam o diferentes scripts de shutdown. Por exemplo esse script de shutdown não é utilizado no meu desktop ubuntu, por isso não consigo resolver esse problema no meu desktop dessa forma.

A versão utilizada do NUT é o 2.7.4. A versão no nutdrv_qx é 0.28 (versão mais antigas podem não ter suporte para o tsshara). Os pacote oficial para ubuntu é mais antigo e não funciona com esse nobreak ainda.

ps: depois de testar até o fim da carga da bateria percebi que essa configuração não funciona direito, pois o nobreak fica reiniciando mesmo quando não tem alimentação da rede. O esperado seria ele ficar desligado até a energia elétrica voltar, e somente após isso ele deveria religar.
Num próximo post vou apresentar os detalhes para resolver isso.