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.

CC1310: Wireless M-Bus back to back rx

Part Number: CC1310
Other Parts Discussed in Thread: WMBUS

Hi,

We are developing a wireless m-bus application using the CC1310 and the example provided in the application note 'CC13xx Combined wM-Bus C-Mode and T-Mode' including 

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/689154/cc1310-require-partial-mode-example-of-cc1310

We are able to receive packages but are loosing some once in a while, and would like some advice.

The example is using a thread to activate the radio and a callback every time a package is received, but we have extended the code to handle errors and crc checks and this might be the cause.

Is there a way to use 'partial read' in a back-to-back receive setup?

We have tried to use bRepeatNok/bRepeatOk without luck, but can the callback be reactivated in the callback itself.

Regards Peter

  • I have checked with R&D and there should no be any reasons for not using repeat mode together with partial read entries. However, we have no code examples for this and have not tested this.

    I would assume that it would complicate the code a bit, when it comes to keeping track of the data queues etc.

    I cannot see why it should be necessary either. You should not do a lot of processing in the callback, but move it to somewhere else in the application. Then you can restart RX once a packet is received, and then process the received packet, while the RF core is restarted and a receiving a new packet.

    Siri

  • Hi Siri,

    Thank you for the fast reply, I'll try it out.

    What is the best way to stop and reinitialize the radio in the callback. Currently I'm just setting rxDone and partialReadEntry->status = DATA_ENTRY_PENDING, but is there a better way?

    Regards Peter

  • Hi Peter

    I am not sure I understand what you want to do in the callback. Are you not following the example in the thread you were linking to?

    There you set the length in the callback like this:

    Fullscreen
    1
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    This will make sure that the radio exit RX automatically when the correct number of bytes have been received, so you do not have to stop the radio manually.

    I did some testing with the repeat mode today, and discovered that this cannot be used when using the SET_LEN command, so you will need to set both repeat modes to 0.

    BR

    Siri

  • Hi Siri,

    Yes I'm following the example and using the 

    Fullscreen
    1
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and it works ok, but in some situations an error occurs and I would like to reinitialize before the entire package is received. 

    Best regards Peter

  • You should use the RF_cancelCmd to exit RX.

    I am working on a more complete code example that also have some error handling in it, and can post it here when it is done

    Siri

  • Hi Siri,

    Thank you very much, I really appreciate your help and would look forward to see the example you are working on.

    Regards Peter

  • Good morning,

    I've changed the code slightly but there is still a few packages lost. Do you have any suggestions to the code below?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * @file protocol/sndp/src/SndpWMBus.c
    * @brief WMBus message parser
    * @copyright (C) 2023 ReMoni ApS.
    *
    * These computer program listings and specifications, are the property of
    * ReMoni ApS and shall not be reproduced or copied or used in whole or in
    * part without written permission from ReMoni ApS.
    *
    */
    /*---------------------------------------------------------------------------
    Include files
    ---------------------------------------------------------------------------*/
    /* *INDENT-OFF* */
    #include <ti/devices/DeviceFamily.h>
    #include DeviceFamily_constructPath(driverlib/rf_data_entry.h)
    #include <ti/drivers/rf/RF.h>
    #include <remoni/mode.h>
    #include <remoni/Device.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    It is still work in progress, but sort of functional. However, it actually works a bit better to set the length like:

    RF_cmdPropSetLen_wmbus.rxLen = DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION;

    and not rely on the RF_cancelCmd(). I'm I using it wrong?

    Regards Peter

  • Hi,

    It looks like using RF_cancelCmd(h, ch, 0); to quit abruptly made a difference, so using the code above with this slight change.

    Regards Peter

  • Have not completed the demo yet, but working on it.

    Just to make sure I understand your issue completely.

    Are you loosing packets, as in not finding sync, or are you getting CRC errors in the packets.

    If you are loosing packets, have you confirmed that it is a timing issues? I.e, have you verified that the radio has not entered RX yet, when a new packet is being transmitted?

    If the problem is related to CRC errors, have you made sure to follow advisory 11 in the errata note?

    BR

    Siri

  • Hi Siri,

    Thank you for the update. 

    It isn't clear to me why the packages are lost and I don't really know how to debug it further. With the code above there isn't really any CRC errors and the callback isn't reporting anything out of order.

    I'm getting data from a water meter and filtering out all compact packages so expect to see data ever ~2 minutes, but sometimes (Every few hours) there is a gap. It is a bit hard to debug with several meters active and compact packages as well.

    I haven't implemented the advisory 11 yet because it is related to the CPU switching from idle and I don't thing it is the case, but I will next week because it won't do any harm.

    With your assistance the code above is working better and maybe a lost package every few hours is expected. Can you see any obvious mistakes or suggestions for improvement?

    Regards Peter

  • I will try to give you some general debug hints, so that you can try to narrow down your problem.

    If packets are lost in the sense that you are transmitting something, but nothing is received, you should check the following:

    Are you sure that your device is in RX state? Check that the status of the RX command is 2 (active)

    it might also be a good idea to add the RF_EventMdmSoft to the callback, to see if you receives sync or not. This way you can figure if the packets is being filtered away, or if you do not even find the sync word.

    If your device is in RX but you do not find the sync word when you transmit a packet, this can be because there is a jammer present that interfere with the packets so that you miss the sync word. Having a sniffer available to see if the sniffer receives the packet is always a good idea. If the sniffer receives it, but not you (and your device is in RX), there might be something with your HW, cause bad sensitivity.

    It is usually not too hard writing SW that will receive all good packets, but it is harder when you try to take care of all the error situations as well.

    I have made a code examples that can be useful for debugging. You should make something similar with your settings etc., and then make sure your code handles all error situations.

    To test this, I recommend not just trying to receive OK packets from a water meter, but that you have a transmitter you can configure to transmit packets that are too long, too short, with CRC errors, packets causing overflow etc. too make sure your code is handling all these scenarios.

    My test code is below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /***** Includes *****/
    /* Standard C Libraries */
    #include <stdlib.h>
    /* TI Drivers */
    #include <ti/drivers/rf/RF.h>
    #include <ti/drivers/GPIO.h>
    /* Driverlib Header files */
    #include DeviceFamily_constructPath(driverlib/rf_prop_mailbox.h)
    /* Board Header files */
    #include "ti_drivers_config.h"
    /* Application Header files */
    #include "RFQueue.h"
    #include <ti_radio_config.h>
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/knl/Semaphore.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I have tested the following:

    Too short packets:

    a1 a2 a3 a4 1 1

    nRxStopped is incremented and eventLastCmdDone is set

    Too long packets (the RX command will be cancelled by the application)

    a1 a2 a3 a4 14 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

    nRxStopped is incremented and eventCmdAborted is set

    Packet with CRC error:

    a1 a2 a3 a4 5 1 2 3 4 5 6 

    nRxNok is incremented and  eventLastCmdDone is set

    OK Packet:

    a1 a2 a3 a4 5 1 2 3 4 5 6

    nRxOk is incremented and  eventLastCmdDone and eventRxOk are set

    Buffer Overflow:

    Set breakpoint in the callback at RF_runImmediateCmd to get an overflow

    nBrBuffFull is incremented and eventLastCmdDone and eventRxBufFull are set

     

    Since you are using partial read entries the CPU will execute code while the RF Core is active and in progress of receiving a packet. You therefore need to follow advisory 11.

    If you were using normal data entries, and did not get a callback before the radio was done in RX and the packet was received, this would not be necessary, but in your case it is.

    However, this will not fix your problem if the problem is lack of sync and not CRC errors, but you should still implement it to avoid un-necessary errors in your packet.

    BR

    Siri

  • Hi Siri,

    Thank you, I'll give it a try.

    I'm currently debugging T-Mode and it looks like 

    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg);  // Get the Mode value

    only is returning the correct value for RF_EventNDataWritten but not RF_EventNDataWritten. Is that true?

    Regards Peter

  • I assume you are asking about RF_EventNDataWritten compared to RF_EventDataWritten????

    RF_EventNDataWritten: Specified number of bytes written to partial read Rx buffer

    RF_EventDataWritten:  Data written to partial read Rx buffer

    In my example, the length is byte number 5 after sync word, meaning that I cannot read out the length before at least 5 bytes have been received.

    Because of this, partialReadEntry0->config.irqIntv and partialReadEntry1->config.irqIntv= 5;

    I therefore need to wait for the first RF_EventNDataWritten event before I can read out the length info.

    If I try to read the length (byte 5) the first time I get the RF_EventDataWritten, the length is not yet received.

    Siri

  • Hi siri,

    Thank you for answering, the C-Mode is quite stable now. I was referring to my own code but think I've figured it out and changed it slightly from 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    if (e & RF_EventNDataWritten) {
    if (!lengthWritten) {
    lengthWritten = true;
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg);
    if (RF_cmdReadRfReg.value == 1) { // C-Mode
    uint8_t preamble = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE];
    switch (preamble) {
    case 0xcd:
    {
    uint8_t l_field = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1];
    uint8_t crc_length = (l_field > 9) ? (2 * (l_field - 10) / 16 + 2 + 1) : 0;
    RF_cmdPropSetLen_wmbus.rxLen = l_field + crc_length + (LENGTH_POSITION - 1) + 2;
    break;
    }
    case 0x3d:
    // Length is 2 bytes longer than wmbusmeters because it is including CRC at the end
    RF_cmdPropSetLen_wmbus.rxLen = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1] + (LENGTH_POSITION - 1) + 1 - 3;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    to 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    if (e & RF_EventNDataWritten) {
    if (!lengthWritten) {
    lengthWritten = true;
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg); // Get the Mode value
    rxMode = RF_cmdReadRfReg.value; // Store the mode - reg will change later
    if (rxMode == 1) { // C-Mode
    uint8_t preamble = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE];
    switch (preamble) {
    case 0xcd:
    {
    uint8_t l_field = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1];
    uint8_t crc_length = (l_field > 9) ? (2 * (l_field - 10) / 16 + 2 + 1) : 0;
    RF_cmdPropSetLen_wmbus.rxLen = l_field + crc_length + (LENGTH_POSITION - 1) + 2;
    break;
    }
    case 0x3d:
    // Length is 2 bytes longer than wmbusmeters because it is including CRC at the end
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    but this causes more T-Mode packages than WMBusMeters can see with invalid CRC and it is also impacting C.Mode. There is actually only 1 meter sending so what is wrong?

    Regards Peter

  • Hi Peter

    I am not sure I understand what you are asking about. What do you mean by

    “this causes more T-Mode packages than WMBusMeters can see with invalid CRC and it is also impacting C.Mode”

    I have not possibility to debug your implementation, and I am not sure I understand what problems you are seeing.

    Remember that even if you only have 1 meters transmitting, there might be other meters nearby that you will also be able to receive from. Also, since wmbus only uses a 2 bytes sync word, you will also receive false packets. If your code is occupied receiving a false packet, it will lose any other packets sent at that time.

    Until you have verified that your SW works as intended, it might be a good idea to do some testing in a shielded environment, where you have full control on what is sent to the radio (no interferer).

    Also, simplifying your code when debugging to only log number of sync found, number of c mode and number of t mode packets and compare that to the number of packets you send, might be useful to figure out how much other stuff is on the air, that can interfere with your packets.

    Siri

  • Hi Siri,

    I'll try to explain further and doesn't expect you to debug my code, just have a quick look to see if something is off.

    I think the code is almost ok when it is configured for C-Mode only (frame format A and B) but starts to fail when T-Mode is enabled.

    I expect that looking for false T-Mode packages might cause C-Mode packages to be lost, but isn't there a way to identify those situations early like restart on new sync?

    I was hoping to be able to handle both C-Mode and T-Mode packages reliably.

    Regards Peter

  • Hi Peter

    Still not sure I understand what issue you are seeing.

    Is the problem that you

    1. Do not receive the T mode packets you are sending
    2. or do you receive these, but you also receive a lot of false T mode packets, and this makes you lose C mode packets as well?
    3. Something else?

    I am not able to say what the issue is just by looking at the code, and I can only recommend you continue to debug the issue, to narrow down what is it.

    When we know what causes the issues, we can look at solution also.

    What you can do, is to set up a CC1310 LP with SmartRF Studio, and use that as a sniffer.

    You cannot run the C/T mode patch from Studio, but you can set up the correct PHY parameters, and for example a fixed packet length of 6 bytes.

    This will give you an indication as to what is going on, on the air.

    From the plots below, I had my CC1310 running for about 3 minutes on my desk.

    It received 27 packets, where 3 of them where packets I transmitted from another LP, and the rest was noise or other meters in close vicinity.

    You can see from the RSSI levels that the 3 packets I actually sent, was much stronger that the rest that was picked up. Some of the other packets looks like “real” C-mode packets as they have the signaling byte (0x54), and the rest might be T-mode or noise.

    Note that the wmbus patch has a programmable Carrier Sense threshold. This is by default set to -107 dBm, so sync words with signal strength lower that this will not be accepted.

    For debug purposes, you can increase threshold to a level where the packets you are actually transmitting is being received, while everything else will not be accepted.

    How to change the threshold is explained here:

    CC13xx Combined wM-Bus C-Mode and T-Mode Application Note (Rev. E)

    I have some comments to your code for things that might cause an issue:

    In the callback where you set the RF_cmdPropSetLen_wmbus.rxLen, you set it to l_field + something.

    This means that the resulting length can be > 255.

    Have you made sure that your data entries are big enough for this, so that you do not get an overflow situation?

    From your code it seems like you are setting

    partialReadEntry->length = MAX_LENGTH + LENGTH_POSITION + APPENDED_BYTES + 4;

    and here you are not accounting for rxLen being larger than MAX_LEN

    Another possible issue with your code, is that you are not subscribing to RF_EventCmdAborted

     

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    if (e & RF_EventNDataWritten)
    {
    .
    .
    }
    else
    {
    partialReadEntry->status = DATA_ENTRY_PENDING;
    rxDone = true;
    Event_post(rxEvent, RX_EVT);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you do a RF_cancelCmd, you will not get the eventLastCmdDone, but only the RF_EventCmdAborted, meaning that your code will NOT set partialReadEntry->status = DATA_ENTRY_PENDING; in the case of a cancel.

    There might be other things as well, so I strongly recommend that you debug your code, one packet type at the time, to see that all “error cases” / corner cases are handled properly.

    Length byte = 0

    Length byte = 255

    CRC errors

    Wrong Frame format for C mode (not Frame A or Frame B)

    BR

    Siri

  • Hi Siri,

    Thank you once again for the help, I really appreciate it.

    What I'm seeing is your option 2

    or do you receive these, but you also receive a lot of false T mode packets, and this makes you lose C mode packets as well

    I've implemented your suggestions

    • enabled the event RF_EventCmdAborted
    • limiting partialReadEntry->length to MAX_LENGTH

    but setting the Carrier Sense threshold doesn't really affect anything. I'm developing on Linux so using SmartRF Studio is a bit difficult, but I'll try to get a Windows machine as well.

    It makes sense that looking for ghost packages will make me loose real packages.

    Regards Peter

  • You should not limit the partialReadEntry->lenght to MAX_LENGTH

    You may need to increase it since you can receive packets that are longer than this.

    In my example, the length byte is telling how many bytes are following it (not including CRC)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    / ----------------------------------------------------------------------------------------
    // | DATA_ENTRY_HEADER (12 bytes) | H0 | H1 | H2 | H3 | Length 5 | D1 | D2 | D3 | D4 | D5 |
    // ----------------------------------------------------------------------------------------
    #define DATA_ENTRY_HEADER_SIZE 12
    #define MAX_LENGTH 5
    #define PACKET_HEADER_SIZE 4
    #define LENGTH_POSITION 5
    #define NUM_APPENDED_BYTES 0
    static uint8_t rxDataEntryBuf0[DATA_ENTRY_HEADER_SIZE + MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES]
    partialReadEntry0->length = MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES + 4;
    RF_cmdPropSetLen.rxLen = payloadLength + LENGTH_POSITION - 1; // Must subtract 1 due to rxConf.bIncludeHdr = 1 (H0 in the figure above)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    payload length is never larger than MAX_LENGTH (5), so max rxLen I will set is 9.

    Your MAX_LENGTH is 255. I do not know the format of the wmbus packets, so not sure what is included, but if you have something like below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    / -------------------------------------------------------------------------------------------------------
    // | DATA_ENTRY_HEADER (12 bytes) | H0 | Length 255 | D1 | D2 | D3 | D4 | D5 |------| D255 | CRC1 | CRC2 |
    // -------------------------------------------------------------------------------------------------------
    #define DATA_ENTRY_HEADER_SIZE 12
    #define MAX_LENGTH 255
    #define PACKET_HEADER_SIZE 1
    #define LENGTH_POSITION 2
    #define NUM_APPENDED_BYTES 0
    static uint8_t rxDataEntryBuf0[DATA_ENTRY_HEADER_SIZE + MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES]
    partialReadEntry0->length = MAX_LENGTH + 2 + LENGTH_POSITION + NUM_APPENDED_BYTES + 4;
    RF_cmdPropSetLen.rxLen = payloadLength + 2 + LENGTH_POSITION - 1; // Must subtract 1 due to rxConf.bIncludeHdr = 1 (H0 in the figure
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    2 must be added to both the partialReadEntry0->length and the RF_cmdPropSetLen.rxLen.

    If increasing the CS threshold to a high value does not help at all (-50 dBm for example, depending of the strength of your transmitter), my guess would be that the problem is not related to processing noise/false packets.

    BR

    Siri

  • Hi Siri,

    I think it will be ok to limit the size to MAX_LENGTH at least for now. I haven't seen any packages of that length and we are forwarding the packages via another protocol with an even tighter constraint.

    I might not be increasing the CS threshold the correct way or at the correct place. I use 

    HW_REG_OVERRIDE (0x6090, 0x0ACE); // Carrier Sense Threshold Override

    and have tried to do it at different places and even as 0x0AFF without any significant difference.

    Regards Peter

  • The override is already part of the settings that should be used together with the patch, so you should simply just modify it (not add it somewhere else:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #include DEVICE_FAMILY_PATH(driverlib/rf_mailbox.h)
    #include DEVICE_FAMILY_PATH(driverlib/rf_common_cmd.h)
    #include DEVICE_FAMILY_PATH(driverlib/rf_prop_cmd.h)
    #include <ti/drivers/rf/RF.h>
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_cpe_wmbus_ctmode.h)
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_mce_wmbus_ctmode.h)
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_rfe_wmbus_ctmode.h)
    #include "smartrf_settings.h"
    uint32_t txShapeTMode[] = {0x00000000, 0x00000000, 0x00000000, 0x4B110200, 0xF2F0E1A6, 0xF2F2F2F2};
    uint32_t txShapeCMode[] = {0x00000000, 0x00000000, 0x00000000, 0x440F0200, 0xD9D8CA96, 0xD9D9D9D9};
    // TI-RTOS RF Mode Object
    RF_Mode RF_prop =
    {
    .rfMode = RF_MODE_PROPRIETARY_SUB_1,
    .cpePatchFxn = &rf_patch_cpe_wmbus_ctmode,
    .mcePatchFxn = &rf_patch_mce_wmbus_ctmode,
    .rfePatchFxn = &rf_patch_rfe_wmbus_ctmode,
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you do that, all packets your received will have a RSSI above -50 dBm, so either you have some strong jammers/meters present that you are not aware of, or your problem is not false packets.

    adding the sync event to the callback and/or testing with SmartRF Studio will help you figuring this out.

    Siri

  • Hi Siri,

    Thank you, it was my mistake.

    Now it works and a value of -85 gives reasonable results without many 'ghosts' at my work location which is very noisy. I'll test in a real scenario tomorrow and discuss in the team also.

    Does TI recommend to use a value around -90 in a noisy environment or is it supposed to stay at -107?

    Regards Peter

  • It depends, and it is hard to give any good recommendations.

    Setting a higher threshold (lets say -90 dBm) will reduce the number of false packets due to noise (or other meters in the vicinity), hence it is more likely that you receive the packets you want, as the receiver is not occupied processing packets not for you.

    On the other side, this will also kind of set your sensitivity level, as you will not be able to receive any packets with a signal strength lower that -90 dBm (even if the packets were intended for you).

    I assume that there are some info in the beginning of the packet that can be used to determine if the packet is for your or not (some kind of ID etc.?)

    If there are, I guess you can check this info, and cancel the RX if the packet is not for you, without having to wait for the whole packet to be received, before checking it.

    Siri

  • Hi Siri,

    Ok, thank you it make sense. I think this I'll test and refine this some more, now you have pointed me in the right direction.

    Thank you and have a nice day. Regards Peter