(Solved) RMT driver for software UART with 22 bit data possible?

[dzungpv]

try
https://github.com/ok-home/hbs_rmt_ser ... al.c#L121
and
#define RMT_RX_IDLE_THRES (5000) // from 2400 to 10000

Thank you, it is better now, I tested 15 minutes without any error on real device.

[dzungpv]

try
https://github.com/ok-home/hbs_rmt_ser ... al.c#L121
and
#define RMT_RX_IDLE_THRES (5000) // from 2400 to 10000

I have other problem, I have 2 test device with ESP32 1 with ESP32C3, 1. ESP32 work, but 1 esp32 crash all the time with:

Code: Select all

assert failed: prvReturnItemDefault ringbuf.c:623

Two devices same code but with difference real device, so old RMT may not stable.

And ESP32C3 crash when flash, it show error:

Code: Select all

CONFLICT! driver_ng is not allowed to be used with the legacy driver

So the old RMT driver could not be use for C3.
I try to migrate to new RMT driver base from your code, but it could not send the data.

The code send the data like this:

Code: Select all

    rmt_transmit_config_t tx_config = {
        .loop_count = 0,
    };
    // Use null encode to send raw symbols
    rmt_copy_encoder_config_t config = {};
    rmt_encoder_handle_t encoder = NULL;
    rmt_new_copy_encoder(&config, &encoder);
    // symbols generate like your code replace rmt_item16_t *rmt_data with native rmt_symbol_word_t* items
   rmt_transmit(tx_channel, encoder, items, item_count, &tx_config);

But it can send only 8 bytes with accurate data, missing 20 bytes

[ok-home]

Code: Select all

rmt_transmit(tx_channel, encoder, items, item_count, &tx_config);

item_count must be in bytes

Code: Select all

rmt_transmit(tx_channel, encoder, items, item_count * sizeof(rmt_symbol_word_t), &tx_config);

The transmitter on c3 will work, but the receiver is not sure. I'm not sure if ping/pong will work in the right time.

--esp32c3 - total 4 channels (192*2) 48*2 = 96 bits - for tx/rx - 0 channel tx = 96 bits, 1 channel rx = 3*96 = 284 bits ( uses memory from 1 to 3 channels )

[dzungpv]

@ok-home I have problem to decode other signal, this time the signal with higher variable.
It mention in this document: https://github.com/iblue/mhi-xy-bus/blo ... report.pdf
The frame is 48 bytes long, using hbs standard, the signal mention below

mhi_signal.jpg (75.68 KiB) Viewed 277 times

With RMT driver it can only decode some frame, most of the time show error.
This is HBS base but MHI encode difference way. Do you have any idea to make it stable.
For example the frame never include 0xFF signal, but with RMT driver and you github code, it show many times. I am using ESP32.

[ok-home]

I have problem to decode other signal, this time the signal with higher variable.
It mention in this document: https://github.com/iblue/mhi-xy-bus/blo ... report.pdf
The frame is 48 bytes long, using hbs standard, the signal mention below

as far as I can see it's not hbs at all
frame size is at least
16 bytes * 3 characters * 2 rmt_symbol_word_t = 96 rmt_symbol_word_t
and I don't know how you define low and high pulse

hi_lo_pulse.JPG (23.51 KiB) Viewed 273 times

[dzungpv]

I have problem to decode other signal, this time the signal with higher variable.
It mention in this document: https://github.com/iblue/mhi-xy-bus/blo ... report.pdf
The frame is 48 bytes long, using hbs standard, the signal mention below

as far as I can see it's not hbs at all
frame size is at least
16 bytes * 3 characters * 2 rmt_symbol_word_t = 96 rmt_symbol_word_t
and I don't know how you define low and high pulse
hi_lo_pulse.JPG

Yes, It is HBS, difference only that the data length is 48 (your code is 24), from the 48 byte they encode 3:1, same baud rate with your git code, And I use your code only with data length and buffer change.

I have successful decode it data with algorithm mention in the github link. But because it longer and more variant, it often error. You can also check it here: https://community.openhab.org/t/mitsubi ... ocol/82898.

Read from RMT it will be 48 bytes:
Example data:

Code: Select all

FD FE FE 7F FE FE F7 DF FB FB F7 FB BF DF FB 7F 7F F7 FE FE FE FE FE FE FE FE FB FE FE FE FE FE FE 7F 7F F7 7F 7F F7 7F 7F F7 7F 7F F7 BF BF FD

Decode data:

Code: Select all

01 07 2B 1A 2E 7F 00 00 00 00 00 7F 7F 7F 7F 76

[ok-home]

if you follow this protocol
https://github.com/iblue/mhi-xy-bus/blo ... report.pdf
it has nothing to do with HBS, it is easily implemented on rmt with encoding and decoding
the only question is how levels uh,uz,ul look like when input to rmt which has only 2 states "0" and "1".
The fact that it is somehow read by the receiver hbs does not mean that it should be used.

HBS - 22 BIT in message (01 - start, 00/01 - bit value, 00/01 - parity bit, 11 - stop bit) 8-bit+parity/19200 baud only
MHI - encoded by symbol encoding duration Ts, bounded by Tl and Th

[dzungpv]

if you follow this protocol
https://github.com/iblue/mhi-xy-bus/blo ... report.pdf
it has nothing to do with HBS, it is easily implemented on rmt with encoding and decoding
the only question is how levels uh,uz,ul look like when input to rmt which has only 2 states "0" and "1".
The fact that it is somehow read by the receiver hbs does not mean that it should be used.

HBS - 22 BIT in message (01 - start, 00/01 - bit value, 00/01 - parity bit, 11 - stop bit) 8-bit+parity/19200 baud only
MHI - encoded by symbol encoding duration Ts, bounded by Tl and Th

This is based on the HBS protocol, which encodes 1 byte into 22 bits and transmits it over the bus. Please note that the PDF documentation may not be 100% accurate. The system uses the same hardware mentioned in this project: P1P2MQTT https://github.com/Arnold-n/P1P2MQTT

I have real hardware that includes a dedicated HBS encoder/decoder chip (the same one used in P1P2MQTT), along with an ESP32. The system encodes 48 bytes into 48 × 22 bits and sends them over the bus. It is working, but the error rate is quite high—most likely because I’m using only an ESP32. I am connect it to MHI system bus with an RC-E5 wall remote and the data tell the truth.

In contrast, the P1P2MQTT project uses two microcontrollers: an ATmega328 to decode the raw data (referred to as P1P2 serial) and an ESP8266 to handle data decoding and send it to MQTT. Their implementation appears stable and doesn’t exhibit the same issues.

My current problem is system stability. Converting 48 bytes into 16 bytes is straightforward and doesn’t require RMT. However, to convert raw binary data into 48 bytes, I’m using your RMT-based code, which is why I’m reaching out here.

Also, I came across your logic_analyzer project—is it possible to send captured data to a remote server? The physical device is no longer directly accessible, and remote access over the internet is now required.

[ok-home]

Also, I came across your logic_analyzer project—is it possible to send captured data to a remote server? The physical device is no longer directly accessible, and remote access over the internet is now required.

include/logic_analyzer_hal.h
Gets samples into ESP32 buffer
logic_analyzer_config_t - capture configuration
start_logic_analyzer(logic_analyzer_config_t *config) - capture start
void (*logic_analyzer_cb_t)(uint8_t *samle_buf, int samples, int sample_rate) - callback after data capture

start_logic_analyzer(logic_analyzer_config_t *config) captures data into buffer and passes it to callback,
you can send it wherever you want,
capture parameters are configured in logic_analyzer_config_t.

[dzungpv]

Also, I came across your logic_analyzer project—is it possible to send captured data to a remote server? The physical device is no longer directly accessible, and remote access over the internet is now required.

include/logic_analyzer_hal.h
Gets samples into ESP32 buffer
logic_analyzer_config_t - capture configuration
start_logic_analyzer(logic_analyzer_config_t *config) - capture start
void (*logic_analyzer_cb_t)(uint8_t *samle_buf, int samples, int sample_rate) - callback after data capture

start_logic_analyzer(logic_analyzer_config_t *config) captures data into buffer and passes it to callback,
you can send it wherever you want,
capture parameters are configured in logic_analyzer_config_t.

Thank you! I’ll try to capture the raw signal from the RX pin of the HBS chip. Would it be okay if I contact you via email for further assistance?