If you were Chinese maker and have to use single wire for data on i51 clone?

[LinuxHata]

Hello. The topic title is a bit strange, because I really don't know how to ask properly for what I'm looking for.

There are some LED display modules, clock type, with 32khz crystal on them, which have i51 clone on them and serial input. These modules were used on electricity/gas/water/etc meters (I was able to find this by tracking UL number, given on PCB), but no more data available.

These modules have inputs marked as RX and TX. They go to the pins of MCU via 1K resistors.
Modules operate from 3 to 5V, and when you apply the power, they work as simple clock, starting at 00:00.
I tried to connect to both RX and TX pins via TTL serial port of PIC MCU and send some data.
There is no response on RX pin, but if I send some serial data to TX pin, there is some response (display data changes, brightness changes, etc.) to certain, very long sequence of bytes. I tried to isolate these bytes, but they are hard, because say on 9600bps, one long sequence (say, 64 bytes in decimal, starting at 80) does something, however, say on 19200bps, same sequence does nothing, but another sequence on 19200 does something and so on. I tried to adjust supply voltage, from 2.5 to 5V, to rule out the voltage levels issue, but no changes.

So my question is, what type of protocol this can be, so that serial data at TTL levels makes some changes (and these are not random, different sequences of bytes always doing corresponding changes, say, one sequence changes brightness, another one changes displayed data and so on)

[selcuk]

Sounds like the optical protocol of an electricity meter.

https://en.wikipedia.org/wiki/IEC_62056

[mikeselectricstuff]

Hello. The topic title is a bit strange, because I really don't know how to ask properly for what I'm looking for.

There are some LED display modules, clock type, with 32khz crystal on them, which have i51 clone on them and serial input. These modules were used on electricity/gas/water/etc meters (I was able to find this by tracking UL number, given on PCB), but no more data available.

These modules have inputs marked as RX and TX. They go to the pins of MCU via 1K resistors.
Modules operate from 3 to 5V, and when you apply the power, they work as simple clock, starting at 00:00.
I tried to connect to both RX and TX pins via TTL serial port of PIC MCU and send some data.
There is no response on RX pin, but if I send some serial data to TX pin, there is some response (display data changes, brightness changes, etc.) to certain, very long sequence of bytes. I tried to isolate these bytes, but they are hard, because say on 9600bps, one long sequence (say, 64 bytes in decimal, starting at 80) does something, however, say on 19200bps, same sequence does nothing, but another sequence on 19200 does something and so on. I tried to adjust supply voltage, from 2.5 to 5V, to rule out the voltage levels issue, but no changes.

So my question is, what type of protocol this can be, so that serial data at TTL levels makes some changes (and these are not random, different sequences of bytes always doing corresponding changes, say, one sequence changes brightness, another one changes displayed data and so on)

First thing would be to try a wider range of baudrates. including ones that are an integer division of a round-numbered clock, 1/2/4MHz etc.

[LinuxHata]

I don't think that this is an optical protocol, because this is daughterboard PCB, which plugs in into main board. Please check the attached photo for a reference.

Regarding the speed increase, this module has 32K crystal as OSC, will it handle higher speeds?

[LinuxHata]

I tried different bit rates.
It would not respond to anything below 9600 and above 10600 (these are approximates, as I'm doing software bit-banging).

At 9600 bps, following was determined:

to change the display text, you need to send at least 17 bytes, and starting byte should be no lower than 82.
So for example, sending sequence of bytes from 82 to 99 will change display, and sending sequence from 83 to 100 will also change display in the similar way, but, sending sequence from 81 to 98 won't change the display.

And say, sending sequence from 0 to 16 or from 35 to 53 won't do anything. So there's some "magic" byte inside that 82-99 range, which triggers the change? I tried to send separate bytes within that range, but nothing changes then...

[AndyBeez]

Should R69 and R70 be populated?

[LinuxHata]

R69 is pulldown for RX pin, which is not used by me.
Installing R70 would join RX and TX pins.

I have about 20 of these boards and all are identical....

[AndyBeez]

From the pad sizes, I read those two resistors as being in parallel to R2.

[Kim Christensen]

There is no response on RX pin, but if I send some serial data to TX pin, there is some response

So these are marked from the perspective of connecting an external device?
ie: "Tx" is an input to the PCB / i51 and "Rx" is an output from the PCB/i51?

If so, have you tried connecting a scope to Rx (Assuming that's an output) and monitoring what happens upon boot or power up? It might send a short data burst that you can analyze to figure out the baud rate, number of bits, parity, etc.
Also, trace to what pins on the i51 that the Rx and Tx go to. The datasheet on this chip, plus the crystal frequency, should give you a range of possible baud rates.

[LinuxHata]

Crystal frequency is 32768khz.
According to datasheet, these TX/RX pins are GPIO pins, nothing special.
I tried to check with the scope on startup, nothing happens there.

By the way, I've "bruteforced" something usable, but it works weirdly.

The sequence of bytes is as follows (all data are DEC, first is number of byte in sequence, 2nd - it's value)
1.82
2.83
3.0
4.0
5.0
6.0
7.0
8.0
9.0
10.0
11.0
12. if set to 0 here, 1st digit can only display 0 and 1, if set to 2, 1st digit can display 2 as well
13. Value of 2nd digit, but it also affects 1st digit - if I write 11 here, 1 will be displayed in 1st and 2nd digits. If previous location value was set to 2, these two locations sum so their result will be displayed in 1st and 2nd digit, and as it seems, data is accepted in HEX - if I write 2 into location 12 and 15 to location 13, 23 will be displayed, which is 2+15 in HEX.
14. 0
15. 98 - these two last bytes initiate update of display I guess, because, without them, no changes will be observed.
16. 99

At 1st glance, mystery is solved and clock can be used, but there's a weird issue - If I set time to 12:59 it goes then to 01:00 and everything is fine. However, if I set time to 23:59 then it goes into 24:00 and will continue counting in that way - like 25:12 and so on.
So I think, somehow in bytes above the time format is set, but what protocol this can be?

[amyk]

Likely to be a proprietary protocol, although I do see some mentions of Modbus when searching up serial 7-segment LCD modules.

[LinuxHata]

Well, I fixed it. The proper sequence is:

[82]
[83]

[0]

[0]

[0]

[0]

[2]
[3]
[5]
[9]

[0]
[1]

This sequence of bytes in decimal, will set clock to 23:59 and 24-hour mode.
The last byte is critical - setting it to 0 turns off display, set it to 1 sets clock to 24-hour mode, setting it to 2, sets clock to 12 hour mode.

Regarding the protocol, this looks quite similar, albeit lot simplified, to DWIN serial LCD protocol - these also used in counters/meters.