Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

RF Decoder - EV1527

Status
Not open for further replies.

Suraj143

Active Member
I want a EV1527 type decoder that can interface with micro controllers. All I found in ebay & aliexpress has only 4 outputs.I need more remote supported (more than 4).Is there any data module in this? So I can read incoming data & store in MCU. In this way I can store more than 4 inputs.
 
The EV1527 / PT2272 etc. are intended for "dumb" remote systems where a CPU is not needed.

If you are using microcontrollers anyway, you can do it entirely in software, and pass as many data bits as you like!


A system we build uses an eight-bit address for each device, set using a couple of hex DIP switches.

The transmitter & receiver use PICs, with the serial port pins connected directly to RF module data in & data out (at the TX and RX respectively). Depending on the radio modules the serial data speed could be anything from 9600 Baud to 38400 or more.

Everything else is just software..

Turn the TX on, send a few 0x0F characters to allow the receiver to settle, then send a unique character or two that are recognised as "this system" ID, then the address and data bytes.

Each address or data byte is sent twice, once normal and once inverted. That allows for error checking in the receiver, by checking the repeat of each byte is it's inverse. You could add a CRC to the overall data frame as well.

Plus each transmission burst is repeated a couple of times at short random intervals, in case anything else was transmitting at the same time.
 
The EV1527 / PT2272 etc. are intended for "dumb" remote systems where a CPU is not needed.

If you are using microcontrollers anyway, you can do it entirely in software, and pass as many data bits as you like!


A system we build uses an eight-bit address for each device, set using a couple of hex DIP switches.

The transmitter & receiver use PICs, with the serial port pins connected directly to RF module data in & data out (at the TX and RX respectively). Depending on the radio modules the serial data speed could be anything from 9600 Baud to 38400 or more.

Everything else is just software..

Turn the TX on, send a few 0x0F characters to allow the receiver to settle, then send a unique character or two that are recognised as "this system" ID, then the address and data bytes.

Each address or data byte is sent twice, once normal and once inverted. That allows for error checking in the receiver, by checking the repeat of each byte is it's inverse. You could add a CRC to the overall data frame as well.

Plus each transmission burst is repeated a couple of times at short random intervals, in case anything else was transmitting at the same time.

I understood the method you using.

In my case I like to stick with EV1527 devices because there are several wireless transmitting devices are already built nicely.Ex : Door Contacts, PIR etc.... Those are really cheap & nice......The working distance also not bad at all.....Those are really cheap in ebay, aliexpress etc....So no need to worry about these transmitters.

All I need to build a receiver which decodes these protocol.The thing is I did not find one which sends the data out instead of separate bits... :(
 
Ok, so you need to do the decoding in software, then you can recognise each different transmitter code and store the data from it separately.

This shows the data format:

And this looks to be an outline program for a decoder - but without English documentation..
**broken link removed**

I'd do it so the full data frame is captured from the device first, then the address can be compared to a list of stored ones (in the MCU EEPROM) and the data decoded, or the new address saved if the receiver is set in to a "learn" mode.
 
Ok, so you need to do the decoding in software, then you can recognise each different transmitter code and store the data from it separately.

You got it. That's what I need to do.
But what module do I need.I couldn't find a module which sends data out until now.
 
But what module do I need.

That depends on the frequency and transmission standard (AM or FM) of the remote transmitters you are going to be using?
Give a link to an example device that has full specifications and I may be able to point you to a suitable receiver.
 
Hi, Here is the one I need to read.I use 433Mhz ones.

**broken link removed**
 
Last edited:
Those are listed as 433.92, Amplitude modulation.

Something as simple as the RX from a kit like this could work, though a slightly more sophisticated one may work better for range and sensitivity - though that would not affect the software side:
**broken link removed**

Such as this?

Or this - it looks as if it may be a slightly better build quality, though it does not say if it is AM or FM..
Some places are selling them with the other modules above though, so presumably it's AM as well...
 
That's really cool.I have those receivers at home.So I should start doing a code.The EV1527 timing protocol is critical with 1uS gaps...Anyway Like to try it.

Many thanks for the help.
 
The EV1527 timing protocol is critical with 1uS gaps

No, it's very relaxed!

Each "unit" time with the signal on or off is around 300 - 500 uS.
A start pulse is one unit on and 31 off, the data bits are one on & three off for low/0, or three on & one off for high/1

You need to capture the start of each "on" pulse, then check if it's high or low (1 / 0 ) around 700uS later (so more than the longest "1 unit" time, less than the shortest "3 unit" time).

And check the time to the next pulse start - if that is more that eg. 10mS it was a start bit, if no more than about 2mS it was a data bit.

If you use a PIC that has "input capture" a lot of the timing can be hardware and you just wait for new edges to be captured.
You could also capture falling edges and measure each pulse & gap length directly.


More info:
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top