Bi-directional communication with STWLC38 / STWBC86 - message buffer always 0's

[AnkhInnovationsLLC]

Hello,

We completed a test of bi-driectional communication of the Proprietary Packet feature (PP) for a mass market client using the STWLC38 (RX) and STWBC86 (TX).

We're able to consistently receive the data of 5 bytes reliability from the RX to the TX. 

In the other direction though, we haven't gotten it to work as the existing bi-directional communication PDF is well, not very specific. 

On the RX side of things, the message buffer at 0x0190 is always filled with 0's, even though 0x0088 interrupt bit 5 (

RX MSG RCVD LTCH) is set to 1.

The document states

"The difference here is that STWBC86 does not add the checksum automatically, the user must provide it with the message. The checksum is calculated as a XOR of the message bytes, including the header."

So we assume the message is then constructed as (first byte sent): 1 byte header, 5 bytes message, 1 byte xor

The header is set to 6f in this case, not 5f (?)

0x6f, 0x11, 0x22, 0x33, 0x44, 0x55, 0x7e

When the message is inspected on the RX side, at address 0x0190 with a 7 byte read, the contents is always 0. We wait for the interrupt to be latched, which takes about 70ms. We do wait on the TX side for 10ms from the time of interrupt to set the TX message content and send the reply.

Anyone ever get this working or expert @willzhou ?

[Didier HERROUIN · Accepted solution]

Dear AnkhInnovationsLLC,

On Tx side :

When you construct the message, the header should not consider the CRC. For the 5 bytes payload 0x11 0x22 0x33 0x44 0x55, the message should be 0x5F11223344554E.

When the message from Rx has been received, if the interruption is correctly set, you should read 10000000 (TX PP PKT RCVD LTCH) at address 0x00C9.

Then, you must send the response to this message (by writing TX SEND MSG bit 0x08 to address 0x00D0) between 10ms and 15ms max after the interruption (this is specified by the Qi standard). Note that the message (to be written at address 0x200) can be constructed before or during the 10ms delay.

Your settings on Rx side seem correct.

Best regards,

[AnkhInnovationsLLC]

Thanks @Didier HERROUIN that did the trick

[AnkhInnovationsLLC]

Hi @Didier HERROUIN ,

So we are noticing that the communication isn't very reliable from TX to RX at distances of even just 3-4mm. The RX sends it's initial message which is always received by the TX. The interrupt it set and handled in software via a hardware interrupt pin, with a 10ms delay to send the reply to the RX.

We make a request from the RX every 3,000ms for relevant data from the TX.

Are there any other timing requirements we should be aware of? Or hardware? Do normal CE / RP packets interfere with this? Can we even send them this often, etc...

[Didier HERROUIN]

Dear AnkhInnovationsLLC,

The Qi packets (CE/ RP packets) are always sent at high priority, as specified in the Qi standard.

The proprietary packets used to transmit the data have a lower priority, and they are sent only when the channel is free, so between the CE/RP packets. Available data rate is only few tens of bit/s.

If the ASK demodulation on Tx side is difficult (because of a bad coupling or because of a noise on Vrect which would disrupt the demodulation of the 2kHz ASK signal), the time left for PP could be reduced.

You can monitor the decoding success rate (of CE/RP packets) by the STWBC86 by programming 1 GPIO to 0x18 (ASK_DEMOD_OK) using the GUI. Here is the description of this setting (it may be not described in the datasheet version you have) :
0x18: GPIO is configured as Output, push-pull, for ASK demodulation debug signal. It toggles to High when
ASK-V demodulation OK, to Low when ASK-I demodulation OK, and does not toggle when ASK
demodulation fails 

Best regards,

Didier

[AnkhInnovationsLLC]

We really appreciate your expertise on this