• State
  • Locked Locked
  • Replies 32 replies
  • Subscribers 54 subscribers
  • Views 5517 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC1350: WMBUS: T2 Collector cannot receive messages when the access number changes

user4464874
Prodigy 180 points

Part Number: LAUNCHXL-CC1350
Other Parts Discussed in Thread: CC1350, WMBUS

Hello,

I am receving Wireless M-Bus SND_UD messages from a meter (our device is collector) with the Serial APL firmware running on a cc1350 launchpad, mode T2.

Wireless M-Bus has an access number (sequence number) field, that should indicate if the same message is repeated, or if new information is being sent. If two consecutive messages have the same access number, it should mean they are the same and the collector can ignore the second copy.

My problem is it seems the WMBUS stack does the opposite. As long as the access number stays the same, I keep receiving messages, but when the access number changes I will receive no more messages (until the access number byte wraps around I guess), so it seems the stack ignores them.

When a message is received, I get a SERIAL_CMD_TYPE_APL_EVT_TLG_AVAILABLE event and then I do a SERIAL_CMD_TYPE_APL_RX_WHOLE_TLG to get the data (and destroy the message). And then I starting waiting for the next message, which I will never receive (messages are sent from the meter, verified by sniffer) if the access number changes.

  • 0
    TI__Guru**** 317180 points
    Some details are not clear to us.
    SND-UD: With this procedure the master transfers user data to the slave. => A meter should not send SND-UD.

    - Which software and version is the meter running?
    - Which software and version is the collector running?
    - Is it just one meter communicating with the collector?
    - Please provide the UART log
    - Please provide the dump showing the traffic the sniffer sees.
  • 0 in reply to TER
    Prodigy 180 points

    Sorry, I meant SND-NR (send no reply) .

    - I have seen it with two meters of different vendors, don't know what sw they are running. A third meter works as it seems it never increases the access number.

    - The collector is running Stackforce, APL collector T2. Have seen the problem with version 1.0.0 and 1.2.0.

    - I register one meter (there are others in the air though)

    - I need to get back to you with a UART log

    - Below is an example where three messages are received with access number 3, but then the access no changes to 4, and then I don't receive the rest of the messages in my collector:

    2e 44 b0 5c 66 7 0 0 2 1b 7a 3 18 0 0 2f 2f a 66 34 2 a fb 1a 73 1 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 c9
    2e 44 b0 5c 66 7 0 0 2 1b 7a 3 18 0 0 2f 2f a 66 34 2 a fb 1a 84 1 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 c7
    2e 44 b0 5c 66 7 0 0 2 1b 7a 3 18 0 0 2f 2f a 66 34 2 a fb 1a 84 1 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 c7
    2e 44 b0 5c 66 7 0 0 2 1b 7a 4 18 0 0 2f 2f a 66 35 2 a fb 1a 21 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 c4
    2e 44 b0 5c 66 7 0 0 2 1b 7a 4 18 0 0 2f 2f a 66 35 2 a fb 1a 21 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 c4
     

  • 0 in reply to user4464874
    Prodigy 180 points
    And here is a UART log. Initializing and receiving three messages (and then there is nothing)

    >>> a5 0 1 a 53 78
    <<< a5 0 3 0 0 a 53 78
    >>> a5 0 1 fa 9b 46
    <<< a5 0 3 0 0 fa 9b 46
    >>> a5 0 2 6 1 82 80
    <<< a5 0 4 2 6 1 5 92 80
    >>> a5 0 a 5 15 d b3 6 7 8 9 1 31 74 49
    <<< a5 0 4 0 0 5 15 c6 e6
    >>> a5 0 9 51 ff ff 0 0 0 0 0 0 77 ad
    <<< a5 0 3 0 0 51 6e 53
    >>> a5 0 9 50 5c b0 0 0 7 66 2 1b e9 7b
    <<< a5 0 4 2 50 0 0 84 e0
    <<< a5 0 d 33 1 ff 0 0 0 7a 20 c1 0 e 18 42 36 3e
    >>> a5 0 2 5e 0 25 30
    <<< a5 0 22 2 5e 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 0 1 1d 97 fd 2 1 51 1a fb a 2 43 66 a 2f 2f 1d b9
    >>> a5 0 3 53 0 0 e1 1b
    <<< a5 0 a 2 53 5c b0 0 0 7 66 2 1b 12
    <<< a5 0 d 33 1 ff 0 0 0 7a 20 c1 0 e 18 41 71 91
    >>> a5 0 2 5e 0 25 30
    <<< a5 0 22 2 5e 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 0 1 1d 97 fd 2 1 59 1a fb a 2 43 66 a 2f 2f fc 44
    >>> a5 0 3 53 0 0 e1 1b
    <<< a5 0 a 2 53 5c b0 0 0 7 66 2 1b 12 48
    <<< a5 0 d 33 1 ff 0 0 0 7a 20 c1 0 e 18 3c dd 7f
    >>> a5 0 2 5e 0 25 30
    <<< a5 0 22 2 5e 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 0 1 1d 97 fd 2 1 60 1a fb a 2 43 66 a 2f 2f 18 ee
    >>> a5 0 3 53 0 0 e1 1b
    <<< a5 0 a 2 53 5c b0 0 0 7 66 2 1b 12 48
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    - Log files are OK, nothing wrong there
    - Data capture shows that the Meter uses Encryption Mode 0 (no encryption) BUT at the same time adds PADDING bytes (2F ) which are only used with Encryption
    - The SF/TI collector FW will drop any frames where the CRC inside the wM-Bus packet is wrong

    This means that that the collector could get a CRC error on the received frames.
    - The sniffer doesn't show the CRC but if you use SmartRF Studio and fixed packet length you should be able to receive the packet including the CRC
    - I also assume if you use www.ti.com/.../swra522d.pdf or www.ti.com/.../swra512.pdf you should be able to see if the packet from the meter is actually received.
  • 0 in reply to TER
    Prodigy 180 points
    - The other meter I have tested with does not have the encryption padding bytes (2f).
    - I don't think it is the CRC, my "sniffer" does not show the CRC's since it drops packets with CRC misses (just like SF/TI), but it is receiving packets that SF/TI hides from me . And why would the CRC's start failing when the access no changes.

    It would be nice with at "raw" mode of the SF stack, so that I could just receive everything and go on wit my life (decide for myself if I want to drop a packet or not), and also send what I want, creating the frames myself.
  • 0 in reply to user4464874
    Prodigy 180 points
    btw, is there a feature in the stack to drop packets with the same access number? In that case it would (already) be an error that I am receiving multiple copies of the same message (the same access number).
  • 0 in reply to TER
    Prodigy 180 points
    I did some SmartTF studio sniffing, with:
    sync-word: 0x0000543D length 16 bits
    Frequency: 868.95 Mhz
    Deviation: 50 kHz
    Rx filter bw: 196 kHz
    Symbol rate: 100 kBaud
    fixed length 30

    And got the below. But I don't know what to do with it. It should be 3 in 6 coded data? But it does not seem to be? And I'm not sure what the fixed length should actually be to get the correct log (number of bytes in the frames I normally see + 3 in 6 coding + crc in block1 and block2 + sync word + ... ??)


    14:36:11.214 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:12.647 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -49 CRC error
    14:36:14.063 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:15.457 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:16.786 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:18.099 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    "The other meter I have tested with does not have the encryption padding bytes (2f)." Does that mean that this meter is also a Encryption Mode 0 meter? We will share some code with you directly that will enable you to receive these packets.
  • 0 in reply to TER
    Prodigy 180 points

    Yes, the other one is also without encryption.
    I can turn on encryption on the meter with the (perhaps nonstandard) encryption padding bytes in encryption mode 0, and I have done that, and I would say that I had the same problem then too (not 100% about this).

    I really appreciate any help with this.

  • 0 in reply to user4464874
    Prodigy 180 points

    So I verified that the problem stays the same with encryption. Below are 4 frames (decrypted) received by my sniffer. The three first ones I can also receive with TI/SF, but in the last one the access number increases from 0x33 to 0x34 and after that I am again unable to receive any more messages.

    2e 44 b0 5c 66 7 0 0 2 1b 7a 33 18 20 5 2f 2f a 66 31 2 a fb 1a 47 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 dd
    2e 44 b0 5c 66 7 0 0 2 1b 7a 33 18 20 5 2f 2f a 66 32 2 a fb 1a 65 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 dc
    2e 44 b0 5c 66 7 0 0 2 1b 7a 33 18 20 5 2f 2f a 66 32 2 a fb 1a 57 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 db
    2e 44 b0 5c 66 7 0 0 2 1b 7a 34 18 20 5 2f 2f a 66 32 2 a fb 1a 45 2 2 fd 97 1d 1 0 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 2f 3 d8

  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    Your last information has been forwarded. Waiting for feedback.
  • 0 in reply to TER
    TI__Guru**** 317180 points

    E2E_feedback.docx

    See the attached word document for the feedback I got. 

  • 0 in reply to TER
    Prodigy 180 points

    Ok, thats interesting. I can't figure out what could be special with my setup. We have already seen that I'm not doing anything wrong according to the serial log, so then of course the problem should be in the messages from the meters. I also tried doing nothing but listen to the serial port (after init) and I stop receiving telegram available events when the access number changes.

    Here are frames sent by another meter, the ones I can receive in green, and not received in red:

    18 44 93 35 11 22 33 44 1 4 7a 0 0 0 0 4 3 0 0 0 0 2 3 2 1 3 c2
    a 46 93 35 11 22 33 44 1 4 78 3 c0
    18 44 93 35 11 22 33 44 1 4 7a 0 0 0 0 4 3 0 0 0 0 2 3 2 1 3 c1
    a 46 93 35 11 22 33 44 1 4 78 3 bf
    18 44 93 35 11 22 33 44 1 4 7a 0 0 0 0 4 3 0 0 0 0 2 3 2 1 3 c1
    18 44 93 35 11 22 33 44 1 4 7a 1 0 0 0 4 3 0 0 0 0 2 3 2 1 3 bf
    18 44 93 35 11 22 33 44 1 4 7a 0 0 0 0 4 3 0 0 0 0 2 3 2 1 3 c1

    Here the access number problem is even more clear, as the meter first sends several msgs with access # 0 then one with #1, which I don't receive, and then access number zero again, which I again can receive.
    As you can see, the meter also sends installation messages. I can receive installation messages also when I am not able to receive the spontaneous messages.

    But then I have another meter than sends encrypted messages, to which I don't have the key. I recorded the below sent frames, and I could receive all of them, although the access number changed from 27 to 28 in the last one..

    2e 44 a5 11 32 56 8 42 30 3 7a 27 b3 20 5 1 20 bd 18 be c9 67 d8 8f 5b dc 5f 53 6c 0 43 3d 59 42 48 a8 68 90 20 8 5a 8e 6c 69 93 e8 90 3 d4
    2e 44 a5 11 32 56 8 42 30 3 7a 27 b3 20 5 1 20 bd 18 be c9 67 d8 8f 5b dc 5f 53 6c 0 43 3d 59 42 48 a8 68 90 20 8 5a 8e 6c 69 93 e8 90 3 d4
    2e 44 a5 11 32 56 8 42 30 3 7a 27 b3 20 5 1 20 bd 18 be c9 67 d8 8f 5b dc 5f 53 6c 0 43 3d 59 42 48 a8 68 90 20 8 5a 8e 6c 69 93 e8 90 3 d4
    2e 44 a5 11 32 56 8 42 30 3 7a 28 b3 20 25 6 d2 a0 d7 ca ec e5 90 43 39 d5 ba f4 d7 61 aa 30 c0 e6 bf dd b8 1f c0 4d 72 19 6 13 cc aa d6 3 d5

    So naturally I have tried to turn on encryption on the meter whose frames I have previously shown, without providing the collector with the correct key, to simulate the above "working" reception, but still the reception stops when the access number changes.

     

  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    After what I understand you should now have a v1.2.3 uploaded to your box area. Could you check and see if this version behaves differently?
  • 0 in reply to TER
    Prodigy 180 points
    Thats great! But where do I find my box area?
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    I can send you the link to the box to your e-mail address you have used to register on E2E if you like.
  • 0 in reply to TER
    Prodigy 180 points
    Yes please
  • 0 in reply to TER
    Prodigy 180 points

    Unfortunately I get the same behavior also with this version

  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    Ok, I guess that would have been too easy...

    It seems that the stack guys have some issues seeing what you are seeing. One option could be to ship us the hardware you are testing with but a faster method could be if you manage to capture the packets from the meters you have tested with without decoding etc (basically how they look like on the air). I believe you have only provided results from the sniffer before?
  • 0 in reply to TER
    Prodigy 180 points
    What's missing from the packet dumps I have shown before should be the crc's I guess (except for the decrypted ones). So maybe the only lead right now would still be the crc, that you suspected earlier. In that case the reason for my problems would be that I have two meter devices from two manufacturers that both have a bug in that they forget to recalculate the crc when the access number changes. But this sounds pretty much impossible, as this is really the only times the crc needs to be recalculated, when the message changes. Furthermore, as I wrote earlier, my "sniffer" device receives everything although it is also checking the crc (although I'm only 97% sure of this).

    This problem feels so weird, as this is pretty much the most basic wmbus functionality, so it does not seem likely that both of my meters would have the same bugs, or that ti/sf would have a bug. That would leave me, but I'm also just listening to the uart, how could I do wrong..

    - I could ship you one of my meter devices
    - Could you advice how/if I can use e.g. a Launchpad with e.g. SmartRf studio to sniff everything from the air?
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    The bumped packets you have shown before are truly what is on the air? (no 3-6 decoding etc)

    You should be able to use a Launchpad + SmartRF Studio to sniff. Set the correct datarate/ frequency and sync word. Try with fixed packet length and set the length long.
  • 0 in reply to TER
    Prodigy 180 points
    Yes, you are right, its not whats on the air 3-6 decoding has been done etc.

    Below is a dump from SmartRF Studio that I posted earlier with params:
    sync-word: 0x0000543D length 16 bits
    Frequency: 868.95 Mhz
    Deviation: 50 kHz
    Rx filter bw: 196 kHz
    Symbol rate: 100 kBaud
    fixed length 30

    Looking at it now, I guess the length 30 was too short, I'll try with longer and get back

    14:36:11.214 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:12.647 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -49 CRC error
    14:36:14.063 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:15.457 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:16.786 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
    14:36:18.099 | 15143 | 1c 8d 66 74 69 a5 93 59 65 96 58 e3 63 70 bc 5c 4e 65 8d 35 65 96 59 63 a9 3a 95 a6 | -48 CRC error
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    When you show the data in SmartRF Studio, could you turn off the sequence number? I assume in this case 15143 is part of the payload.

    If you can do that with both meters it would be great.

    Would you be able to record what happens when the meter is communicating with our stack? (basically show the reported problem in "raw" format)
  • 0 in reply to TER
    TI__Guru**** 317180 points
    Btw, could you log to file?
  • 0 in reply to TER
    Prodigy 180 points

    Attached a dump, saved to file, with params:

    sync-word: 0x0000543D length 16 bits
    Frequency: 868.95 Mhz
    Deviation: 50 kHz
    Rx filter bw: 196 kHz
    Symbol rate: 100 kBaud
    Fixed length: 130

    During the recording, I listened to the meter  0144332211. There are two other meters in the air (especially one talkative 3042085632 that I cant shut off), I didn't filter anything out as of course other traffic in the air could play some role (although I say it does not, as I've seen this problem also in quiet places).

    What I heard was:

    installation message
    Spontaneous with acc no 0: 5e 1 2 3 2 0 0 0 0 3
    installation message
    Spontaneous with acc no 0: 5e 1 2 3 2 0 0 0 0 3
    installation message
    Spontaneous with acc no 0:  acc no 0: 5e 1 2 3 2 0 0 0 0 3
    Spontaneous with acc no 1 
    installation message
    Spontaneous with acc no 0: 5e 1 2 3 2 0 0 0 0 3

    So I missed the one message with different access number, but then the access number goes back to 0, and I receive a packet again.

    In the same dump there should (I did not parse the log mysefl, with the 3 to 6 coding etc. ) also be messages from the other problematic meter 0200000766, probably with changing access numbers. Did not listen to them, but I would have heard the ones with the same access number and missed the rest after access no changes. So maybe this dump will suffice for showing both problematic meters.

    rfstudiodump.txt

  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    Thanks. I have forwarded the information, I'll let you know when I get some feedback.
  • 0 in reply to TER
    Prodigy 180 points

    Any news?

  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    Sorry, I haven't been able to get any further feedback on this.
  • 0 in reply to TER
    Prodigy 180 points
    Would it be possible to try once more to raise the issue to get some further feedback?
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    I tried but basically they refused to look more into it. I think the issue is that as long as it's not clear that it's a bug Stackforce wants to get paid to look at it.
  • 0 in reply to TER
    Prodigy 180 points
    Ok, thanks for the effort. Diffucult to see how it could be a bug at my end.
    Do you know of some product, e.g. some simple sensor, that has been verified to work with the SF/TI stack?
  • 0 in reply to user4464874
    TI__Guru**** 317180 points
    Sorry, I don't have the overview here.