• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


is a Low Pass filter the way to go??
#1
Like Creamers and CurlyMo I've also done a lot of reading and experimenting on the Low Pass filter issue.

Still have not produced a working version.

Feeding a pulse through a low-pass filter alters the shape of the pulse. This is because a pulse is composed of a combination of frequency's (harmonics). With the alteration of the pulses-shape, the time between rising-high and falling-low can also change, making the protocol definitions more or less useless (at least, that's what I think!).

It would also be nice if the filtering is not specific for a certain type of receiver. An issue with the proposed LPF is that the 'standard' receiver produces a much lower voltage pulse than the Aurel receiver does. Kinde misconfiguring the RC/gain settings of the active-filter.

The main purpose of the "filter" is to relieve pilight from processing noise and present pilight only the, more or less, valid pulse-trains. What I understand of the protocol's at hand is that they all start (or end?) with a long pulse and that they are repeated a few times.

So, why not try a completely different approach?

What I'm working on at this moment is an Atmel AVR processor (~ Euro 5,-) that reads the input from the receiver and waits for a long pulse. From the moment it receives this long pulse it will, for a certain period of time, copy the input pulses to the output which is send to the RPi (pilight). I have this already working on an Arduino board with the, totally wrong never to use receiver, but my main goal is to use an ATtiny85 processor (DIL8 and about euro 2,-).
My design goals are:
  • Simple to reproduce
  • Cheap
  • Works with all types of receivers (although; mileage may differ)

Is there anyone out there that has suggestions on what (else) I have to think of to get this going?
Is there, maybe, a valid reason not to use a AVR processor for pre-processing?
 
Reply
#2
I already had this working with an attiny 85, however it crashes when feeding it with this much noise.
 
Reply
#3
So, do you suggest to stop investigating?
 
Reply
#4
No, but not regarding using just an ATTiny85. You can just join the other thread in which an Phd engineer is working on a better version.
 
Reply
#5
@thewheel:

you are totally right, a normal low pass filter that filters a lot of the high frequency - low length - pulses alters the pulse width also if a schmit trigger is used after it. that's probably the reason i had to change the timing parameter for the intertechno wall switch, although i'm not sure because curlymos lpf never worked for me. i tried to do a fast simulation and my results were inconsistent with the experimental setup because i don't have an exact model of the opa.

for an experimental test i used a signal generator and a scope and somehow the filter didn't work as a good lpf, that's the reason i tried one other version. apparently combined with the receiver curlymo suggest it works great. this is probably due to the output impedance of the receiver he suggests.

i have posted a paper on data filtering ( http://www.ti.com.cn/cn/lit/an/sloa063/sloa063.pdf ) it would for sure work better but i'm not jet sure if it's worth the effort. (she opas needed are not really easy to get ...)

so i'm thinking of one other solution. maybe a cheap fpga is the way to go. we then could strongly reduce the work for plight by doing what you suggested.

i think anyhow it would be great to make a full list of all protocols. especially the headers and the complete length would be important. so the fpga could fead the signal for some time to the pilight if one of all headers is received.

i'm gonna discuss it (hopefully soon) with some university buddys that work in telecommunications.

hope to get better answers soon. i'll keep you informed.
 
Reply
#6
The protocols work as good as with LPF as without LPF with all kinds of receivers. So the pulse alterations aren't so big we need to worry about it.

Protocols rarely use headers, but always use footers. The shorted footer i encountered was bigger then 4440us. So that's the lowest pulse pilight checks to be a valid footer.
 
Reply
#7
the point is that what you build works great but is not really a lpf.

here is an easy to read guide to active lpf:
http://www.electronics-tutorials.ws/filt...ter_5.html

so what you designed would be a lpf for 0,7 Hz ( 1/(2*pi*15k*15u) ) with an amplification of 3,2 if it would be symmetrically biased. as it's not it should cut off half of the waveform.

so as 0,7 hz means that the longest pulse should be at around one second the filter does not really work as a lowpass filter.

the cutting off of the wave would help for sure.

what you build apparently does a great job, but actually i think it's not really a filter.

regarding the footer & header:
i think what would be a good solution is to filter the noise by waiting for a valid pulse (so waiting for that the signal keeps its state (either high or low) for one of the valid pulse lengths) and then open a gate for the maximal length of a command. i don't really get how you do it with the footer. do you always only evaluate the second command or do you always check if the last x pulses give a valid command?
 
Reply
#8
What i do is check the footer pulse length. Device that by 34 = protocol pulse length. Then do the rest of the processing based on that pulse length and number of raw pulses.
 
Reply
#9
please correct me if i'm wrong. so the procedure is the following:

you always fill a buffer with the last let's say 32 pulses.
then you analyze it and if the last pulse is somewhat around 4440us or bigger you divide it by 34. this way you get the pulse length.
then you check if it's valid for some protocol.
if it's valid you use it to analyze the rest of the 32 pulses and get the command.

or isn't the footer pulse the last one?
 
Reply
#10
correct
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  Bandpass filter problem mayonezo 13 2,089 01-07-2018, 11:29 PM
Last Post: mayonezo
Question Passive Component Band-pass filter ripper121 8 1,384 12-16-2017, 01:38 AM
Last Post: wo_rasp
  Filter kit in 315 receiver? ceandre 1 1,083 04-14-2017, 10:10 PM
Last Post: wo_rasp
  Low Pass Filter and Receiver in Series? re-post Gustavo Woltmann 1 1,212 03-08-2017, 05:25 PM
Last Post: pilino1234
  Filter settings in config.json Saiyato 100 23,566 02-22-2017, 08:24 AM
Last Post: wo_rasp
Rainbow Lowpass filter - how DOES it work? DE8MSH 6 2,734 10-07-2016, 09:25 PM
Last Post: wo_rasp
  Low Pass Filter and Receiver in Series? Hauke 3 2,399 08-30-2016, 08:25 AM
Last Post: wo_rasp
  New filter version curlymo 0 1,249 04-02-2016, 08:05 AM
Last Post: curlymo
  Band-pass filter parts curlymo 60 57,122 01-08-2016, 12:23 AM
Last Post: gneandr
  low pass filter francois.leprieur 3 1,924 12-20-2015, 10:18 AM
Last Post: curlymo

Forum Jump:


Browsing: 2 Guest(s)