[Solved] Trying to receive Manchester-encoded data

[u063096]

[Update: found it - it was a hardware issue (see below)]

Hi guys,

being in the transition from Arduinos to the ESP32, I am trying to rebuild some projects I did on the Arduino platform to learn the differences.

In one of these projects I am receiving environment sensor data via 433MHz, in short 16 byte bursts. The sender is an ATtiny85 using this library: http://mchr3k.github.com/arduino-libs-manchester/.

On the ESP32 this library obviously does not work, since it depends a lot on interrupts on the Arduino side.

Is there a complementing Manchester library available for the ESP32 that is able to deal with the data sent by the ATtiny?

Any hints are highly appreciated.

Ciao, Michael

[ESP_Sprite]

You may want to look into the RMT peripheral; it can at least assist you in collecting the Manchester data so you can then decode it at your leisure.

[u063096]

Thank you, will do.

So no one so far seems to have had to deal with 433MHz data on the ESP32? Rats.

Is there an introduction into the RMT available on the web I could use for starters?

[chegewara]

https://docs.espressif.com/projects/esp ... s/rmt.html

[u063096]

The obvious

Thank you. In the meantime I found some repositories on Github dealing with the RMT. Not specifically my Manchester code, but at least examples on how to apply the API.

[u063096]

Well, I seem to need some more help here.

I am now trying to catch the Manchester signals from the data pin of an RXB6 433MHz receiver connected to GPIO 14. The data is sent at 1200bd, with a burst length of 16 bytes - 128 bits, sent every 8s.

I estimated that ten times oversampling should suffice, hence I would need a sampling frequency of around 12 kHz. In theory I would need a clock divider of 6666.666 - right? the maximum clock divider possible for the RMT is 255, though, so calculating back I get 313 kHz minimum sampling rate - 260 times oversampling.

A phase change will then take 260 ticks on average, everything below 200 can be filtered. As up to three identical bits will be sent without phase change, a value of 2000 should be okay for detecting the end of a transmission.

So I set the rmt up as follows:

Code: Select all

// Configure RMT
  rmt_config_t rmt_rx;
  rmt_rx.channel = (rmt_channel_t)0;          // RMT channel
  rmt_rx.gpio_num = (gpio_num_t)DATA_433;     // GPIO pin 14
  rmt_rx.clk_div = 255;               // Clock divider
  rmt_rx.mem_block_num = 8;                   // number of mem blocks used
  rmt_rx.rmt_mode = RMT_MODE_RX;              // Receive mode
  rmt_rx.rx_config.filter_en = true;          // Enable filter
  rmt_rx.rx_config.filter_ticks_thresh = 200; // Filter all shorter than 200 ticks
  rmt_rx.rx_config.idle_threshold = 2000;     // Timeout after 2000 ticks
  rmt_config(&rmt_rx);                        // Init channel

But when I pick the items from the ring buffer and print them out, I get mostly rubbish (item lines formatted as <number>: <level0>: <duration0> <level1>: <duration1>):

Code: Select all

E (402) rmt: RMT[0] ERR
E (402) rmt: status: 0x14000200
E (1845) rmt: RMT RX BUFFER FULL
    5: 1:   22 0: 1267
    6: 0:   10 1: 1655
    7: 0:   17 1:    0
E (2539) rmt: RMT RX BUFFER FULL
    8: 1:   38 0:  247

    9: 0:   20 1: 1564
   10: 0:    4 1:    0
   11: 0:   17 1: 1713
E (8274) rmt: RMT RX BUFFER FULL
E (11602) rmt: RMT RX BUFFER FULL
   12: 1:   22 0:   37
   13: 0:   23 1:    0
   14: 0:   22 1:    0
   15: 0:    9 1:   21
   16: 0:   17 1:    0
E (20665) rmt: RMT RX BUFFER FULL
   17: 1:   31 0: 1674
   18: 0:    5 1:    0
   19: 0:    5 1:    0
   20: 0:    5 1: 1207
   21: 0:   12 1:    0
E (27324) rmt: RMT RX BUFFER FULL
E (27435) rmt: RMT RX BUFFER FULL
E (27547) rmt: RMT RX BUFFER FULL
E (29727) rmt: RMT RX BUFFER FULL
   22: 1:   14 0: 1658
   23: 0:   12 1: 1993
   24: 0:   11 1:    0
 

• Why do the "RMT RX BUFFER FULL" errors occur? I would expect having 512 items available in the buffer (channel=0, mem_block_num=8) besides the 1000-item ring buffer. Plenty of space for the 128-ish bits of the burst telegrams.
• Second, the listed items do have nothing in common with the data I was expecting (like: "1: 0:300 1: 276" fore a single phase change etc.)
• Finally: why do lines like "21:0: 12 1: 0" show up? I would have expected these to be filtered by the filter_ticks_thresh=200 in the configuration?

Any hints for me, please?

[u063096]

Hi,

finally found the reason: the antenna for the RXB6 receiver was made of isolated wire (an "air cooled" antenna with a spool). It had a broken wire inside, so the signals never got to the receiver. Due to the AGC (auto gain) the receiver would amplify whatever it got and thus deliver an almost random data signal.

New antenna, all fine:

Code: Select all

Size=380 -     0: 1:  245 0:  243
Size=380 -     1: 1:  249 0:  242
Size=380 -     2: 1:  249 0:  488
Size=380 -     3: 1:  493 0:  493
Size=380 -     4: 1:  492 0:  487
Size=380 -     5: 1:  247 0:  245
Size=380 -     6: 1:  492 0:  493
Size=380 -     7: 1:  243 0:  245
Size=380 -     8: 1:  492 0:  242
Size=380 -     9: 1:  249 0:  243
Size=380 -    10: 1:  248 0:  488
Size=380 -    11: 1:  246 0:  245
Size=380 -    12: 1:  246 0:  246
Size=380 -    13: 1:  491 0:  488
Size=380 -    14: 1:  246 0:  245
Size=380 -    15: 1:  492 0:  491
Size=380 -    16: 1:  488 0:  247
Size=380 -    17: 1:  246 0:  492
Size=380 -    18: 1:  492 0:  243
Size=380 -    19: 1:  245 0:  248

[preetjhota]

Hello,

I am aslo using same reveiver RXB6. But I am not receiving the RF codes. Can you please share the you libraries or the references from where you got.