Posts: 14
Threads: 1
Joined: Mar 2023
Reputation:
0
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).
Posts: 6,348
Threads: 811
Joined: Oct 2020
Reputation:
157
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
Posts: 6,348
Threads: 811
Joined: Oct 2020
Reputation:
157
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.
Posts: 14
Threads: 1
Joined: Mar 2023
Reputation:
0
That is a good solution. Thanks.
Posts: 14
Threads: 1
Joined: Mar 2023
Reputation:
0
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"...
Posts: 6,348
Threads: 811
Joined: Oct 2020
Reputation:
157
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.