s2lp wmbus transmit and receive

[styth]

I have a small problem with configuring s2lp module to transmit and receive data in wmbus t1,t2 mode. After many iterations I can finally both send and receive packets, but it's very flaky. I'm testing a combination of radiocontrolli 868 module and s2-lp dk. Both modules receive the same data from typical meters nearby, but when I'm trying to send data from my module to DK module, they come in garbled (sometimes almost no data, sometimes last bytes in 24-byte packet are invalid). I have copied all relevant register configuration from DK module and don't use dk-framework. Do I need to make some device-specific calibration configuration changes for each module, or is calibration data pretty universal? I will try to resolve this myself, but I need some general advice what could be wrong.

[Winfred LU]

Could you try to generate a single tone and measure with a spectrum to check if it is an issue of frequency not calibrated correctly?

[styth]

Will try, but unfortunately not this week. Is cheap rtl-sdr precise enough to check this?

[styth]

Checked with r802t and sdrsharp, looks like frequency offset is smaller than 10khz, with 50khz frequency deviation it's not easily noticeable. My rtl-sdr has 40khz offset, 868.95 looks like 868.91 in sdrsharp, but single tone is exactly in center of other wmbus devices present nearby.

Single tone:

Captured packets from meter and my device:

Upper line in waterfall is packet sent from my device, lower line in packet sent from meter, order is reversed in s2lp dk log window.

actual packet sent from my device was "17 C0 A8 97 59 08 43 FF FF FF FF FF FF 01 00 18 00 00 00 00 00 00 44 43" (bytes written to tx fifo), PCKTLEN1:PCKTLEN0 was set to 0x18. But it came in as "01 1F 31".

Both devices correctly receive meter packets. My send procedure:

1. sabort if in RX mode
2. flushrx/flushtx
3. read interrupt registers to clear them
4. change register 0x2f to 0x04 (clear FIX_VAR_LEN bit),
5. set 0x31 to 0x18
6. write data to txfifo
7. strobe tx command (0x60)
8. wait on gpio1 (interrupt after tx done)
9. reset (sres, 0x70) and reconfigure radio
10. go to rx

Step 9 was necessary because after tx, module locked up in undocumented modes, it was easier for debugging purposes to just reset it.

EDIT:

Funny thing, just changing mbus3of6 to manchester encoding causes boards to communicate flawlessly, but of course I can't receive wmbus. Do I need to encode packets with 3of6 myself before sending them?

[Winfred LU]

Good. It shows that it is not an issue due to uncalibrated frequency.

> Step 9 was necessary because after tx, module locked up in undocumented modes, it was easier for debugging purposes to just reset it.

Would you provide more details? This could be a hint for how it failed.

If i understand correctly, you'd like to try the wmbus submode T1, T2 meter to meter, with 3 out of 6 data encoding,

please check if SYNC_LEN, PREAMBLE_LEN, SYNC are also configured accordingly.

In register PCKTCTRL6 (0x2B), PCKTCTRL5 (0x2C), SYNC3(0x33) ~ SYNC0(0x36)

[styth]

I don't currently have logs or traces from not working version, will try to recreate it later.

PCKTCTRL6(0x2B)=0x28 (SYNC_LEN=0x0a, PREAMBLE_LEN[9:8]=0x00)

PCKTCTRL5(0x2C)=0x14 (PREAMBLE_LEN[7:0]=0x14)

SYNC3(0x33)=0x00,

SYNC2(0x34)=0x00,

SYNC1(0x35)=0x40,

SYNC0(0x36)=0x0F

I tried with preambles 0x13-0x15 on receiving side, but saw no difference in reception. Is preamble setting only for sending? Documentation doesn't say anything about it.

[styth]

This radio is very picky. After trying to make it work it no longer works reliably. When I start my board from debugger, everything works. After cycling power, radio communicates over spi, but no longer works. I might have found solution: maybe during startup power ramps up too slow and after first reset it has unstable registers. When I detect that radio is in uknown state, I just assert shutdown pin and restart whole radio configuration procedure. Now after first restart mbus mode works properly. BUT, sent data:

17 C0 A8 97 59 08 43 FF FF FF FF FF FF 01 00 17 00 00 00 00 00 00 97 6A

received data:

C0 A8 97 5C 84 21 FF FF FF FF FF FF 80 80 0B 80 00 00 00 00 00 4B B5