HylaFax- muito eficiente

Para quem ainda utiliza FAX, sujiro que utilize o Hylafax.
Se voce já usou outras ferramentas de fax para Windows, já deve ter percebido alguns problemas que parecem nao ter solução e lhe forçam a voltar a usar seu velho aparelho:
Se o windows FAX por exemplo receber um fax e a conecção cair na metade do fax, voce nao recebe ele. Ai os clientes da sua empresa ficam ligando pra voce e tentam mandar denovo o fax, mas no final da coneccao misteriosamente não é bem finalizada. E o Windows FAX cancela novamente seu fax. E voce perde horas tentando resolver esse problema. Troca placa de fax, usa algum programa antigo que ainda funcione no XP, mas nada funciona. Le até mesmo os documentos da MS sobre como é eficiente o sistema de fax do window, apresentado por uam senhora de idade. Mas no mundo real, problemas sempre ocorrem.
O HylaFax é perfeito! Te envia diretamente por email os fax. Nao possui bandejas de sistema para o FAX. Tudo integrado no seu email transparentemente. E se a conecção cair, ele lhe envia o que recebeu. Exatamente como um aparelho de fax tradicional faria. Encaminah tambem todas as mensagens de LOG para voce analisar o trafego e o erro. mantem uma base com todos os fax recebidos, e permite que os usuarios acessem elas por ftp. É muito leve e para finalizar, opera no LINUX. Pode monitorar multiplas placas de modem ao mesmo tempo tambem. Utilizo apenas uma, e para min já é mais que suficiente. Não uso transmissao, para isto temos scanners de alat velocidade. Mas os clientes de onde trabalho ainda gostam de usar o Fax. Alias, tudo é recebido em TIFF, propriamente compactado. Mesmo em tempos de VOIP, esta é uma otima solução. vale a pena testar. De preferencia as suas velhas placas USROBOTICS para ele, ou zollltrixxx. pode suar até mesmo um PC antigo, com barramento ISA. Utilizo uma USRobotics 3com PCI para a tarefa, mas não é softmodem, cuidado.

www.hylafax.org

decodificacao manchester- keeloq - continuacao

Continuando a "explicação" a respeito do problema ao receber sinais codificados em manchester encoding. Ao analizar a chamada de cada estado, opercebi inevitavelmente que um estado ficava initeruptamente sendo ativado e logo em seguida erra resetado. Era o estado que aguardava o timeout do pulso de sincronismo. O problema se encontrava quando este estado coincidia com o momento em que o sinal estava sendo recebido, e resetava-o no meio da seguencia, por um erro de alinhamento. As figuras q postarei futuramente exibirao o que me refiro.

Fix to MAnchester Decoding Receive Routines of tb 045 from microchip (keeloq)

Hi! So, i am here again! (link to second part of the FIX HERE)
I will try write in english, but cannot garante clear typing.
I am working on manchester receiver and transmiter for portable remote control, based in the manchester decoder system for keeloq system. The manchester decoder routines is shared by the microchip, and has been seen made by Lucio Di Jasio.
In order to use the receiver I has build a software for transmiter manchester code. Afther much debug, it work fine and make-me learn alot about michochip assembler!
The receiver code was very powerfull, but since make it work with my routines have found some strangers things happening.
I send a burst of 90~100 bits every key press, with transmiter codes, and key being pressed. But some times the receiver dont recognize even clean code sequences. Read the some time as 1 each 15 pressed of key.
The code is transmited, but the receiver dont recognize.
In order to make the debug of transmited data, I use SoundCard as "osciloscope", since I send just 2500bps in AM. Work very fine just for this purpose.
And the data that is seen in capture program not lies; is always right, but the receiver reject the data sometimes.
Too look where is the mistake, I use some nice thicks.
First, to you understand you have that understand that decoding manchester data (as presented in TB045 for keeloq system) is based in a state machine implemented in software driven by interrupt routines.
The state machine are a "4 state" machine, that dictates how the data are recognized and received. You should read the microchip documentation in order to understand all the states, I will not tell nothing about its.
The important is, i put BSF e BCF in each state to FLAG pins outside the PIC.
Just for know, the state 0(zero) reset all other states, and restart the receiver for complete new burst. So i reset all states in the state 0. In state 1 I BSF PIN1, and so in same manner to other states. So i can see where is happening the lost of data when the system not recognize some busrt!
Is my first time with PICs, and pic assembler language, just 3 weeks working over this great pice of silicon, and feel like powerfull tool for small programming tasks.

Above the data in right maner, without any error. The top graph represent the send data, and the lower the response of one of states of keeloq receiver. In this case, the receiver and states work in a very nice way. Receive all data, without troubles.
In next post i will put the response of others states in normal way, and what happen when it lost data.
This new post bring the fix to live, if someone have interest.