Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RS485 not receiving anything
#11
Yes that's what I meant to explain in the previous post.

I can see the communication from A16 -> expansion board (which I already knew), and with the USB adapter I can also see the communication from expansion board -> A16.
I know it is being sent by the expansion board, but the ESP32 does not receive it. I have shown in previous posts that I activated debug logging of the UART component and I can see the raw bytes leaving the UART TX (i.e. pin 13), and I can see that no bytes are being received on the UART RX (i.e. pin 16).
Reply
#12
Ok, I've examined the board. I've checked the pins of the RS485 ic (marked SP485EE 1435L B95770) with an oscilloscope. I can see incoming communication on pin 6 (RS485 A), but nothing on pin 1 (receiver output). I then checked pin 2 (Receiver output enable active LOW) and it is high (5V)!

I guess this is to be expected, this is also marked in the Kincony documentation (see below). But doesn't this mean that the SP485EE output is permanently disabled???

[Image: ch19-rs485.png]


UPDATE:

Ok, if I pull down pin2 on the SP485EE, then suddenly esphome receives data from the UART (pin 16).

Code:
21:22:40    [D]    [uart_debug:114]    >>> 01 06 00 01 03 00 D8 FA
21:22:40    [V]    [modbus:042]    Modbus received Byte  1 (0X1)
21:22:40    [V]    [modbus:042]    Modbus received Byte  6 (0X6)
21:22:40    [V]    [modbus:042]    Modbus received Byte  0 (0X0)
21:22:40    [V]    [modbus:042]    Modbus received Byte  1 (0X1)
21:22:40    [V]    [modbus:042]    Modbus received Byte  3 (0X3)
21:22:40    [V]    [modbus:042]    Modbus received Byte  0 (0X0)
21:22:40    [V]    [modbus:042]    Modbus received Byte  216 (0Xd8)
21:22:40    [V]    [modbus:042]    Modbus received Byte  250 (0Xfa)
21:22:40    [V]    [modbus_controller:055]    Modbus response queued
21:22:40    [V]    [component:204]    Component modbus took a long time for an operation (0.06 s).
21:22:40    [V]    [component:205]    Components should block for at most 20-30ms.
21:22:40    [V]    [modbus_controller:063]    Process modbus response for address 0x0 size: 4
21:22:40    [V]    [modbus_controller:308]    Command ACK 0x1 259
21:22:41    [D]    [uart_debug:114]    <<< 01 06 00 01 03 00 D8 FA

I don't know, but this looks like a design problem?

By the way, I have a revision 1.4 board. I notice that you have a 1.5 board. Did anything change on the RS485 side in between revisions?
Reply
#13
this is arduino source code and BIN firmware file for test RS485 circuit. you can download to ESP32 to check whether RS485 circuit is work well.
the function is you use PC tool send command to board, the board will feedback same content. that means OK.

.zip   KC868-A16-RS485.zip (Size: 571.74 KB / Downloads: 209)
Reply
#14
Ok, I tested it with that firmware. The board does not echo anything back unless I pull down pin2 on the SP485EE (via 2k resistor).

Diving deeper into the datasheets, I can see that the MAX13487E that is shown on the board in the Kincony documentation has an intelligent feature to disable receiver output whenever the chip is sending. I quote from the datasheet: "Drive RE low to enable the RO. Drive RE high to let the AutoDirection circuit control the receiver."

However, my rev1.4 board does not have a MAX13487E but rather an SP485EE, which does not have an AutoDirection circuit according to its datasheet, and the RE has to be driven manually, which is not implemented on this board!

Did I buy a counterfeit Kincony board???

   
Reply
#15
it should be MAX13487. do you have MAX13487, whether you can replace the chip? or if you want, we can send to you. you need send us your order number and whether order from KinCony's official store? kincony.aliexpress.com
Reply
#16
(04-19-2023, 12:54 AM)admin Wrote: it should be MAX13487. do you have MAX13487, whether you can replace the chip? or if you want, we can send to you. you need send us your order number and whether order from KinCony's official store? kincony.aliexpress.com

The order was number was 3015575451805838, from the KinCony Official Store on Aliexpress. If you send me the chip, I will try to replace it if you agree that this does not void my warranty.

Can you explain how it happened that the wrong chip is there?
Reply
#17
ok, we will send you MAX13487 to you. the old solution solding by SP485, now all solder by MAX13487. if you can replace chip, we can send to you MAX13487 chip. if you can't replace, we can send you KC868-A16 PCB, just you have bought from KinCony official store.
Reply
#18
That is a good solution. Thanks.
Reply
#19
For anyone having the same problem: it was possible to read messages by putting a 2k resistor between pins 2 and 5 of the onboard SP485EE (i.e. a pulldown on the receive enable pin), but then the receive circuit of the SP485EE is always active, which means that the ESP32 also receives the bytes that it sends itself (a sort of local echo). That may be acceptable when you write your own firmware, but ESPhome - for instance - can't handle this. (Not out of the box, anyway.)

The real solution:

KinCony immediately sent me two MAX13487 ICs. I've put one on the board, replacing the SP485EE, and now I can send AND receive messages (without the local echo). I am happy that, once the problem was identified, KinCony offered a solution right away. Thanks! :-)

That being said, the conspicuous silence I received when asked how the wrong chip ended up on the board in the first place does not fill me with confidence about production and/or quality control; I am left wondering how many boards are out there with the same problem, and how many people are spending hours figuring out "why it doesn't work"...
Reply
#20
sorry, the old version used SP485EE, but next version when we produce products already have updated with MAX13487. i think you are using the old version.
Reply


Forum Jump:


Users browsing this thread:
1 Guest(s)