• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 555 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.

CC430F5137: Packet losses due to reflections?

Henry Broeker
Intellectual 495 points
Part Number: CC430F5137
Other Parts Discussed in Thread: CC1111EMK868-915

Hi,

I am not sure how to phrase my question correctly as I am not sure what the root cause might be. I will try to give some background:

I have a system of CC430 where multiple nodes (battery driven) speak to one hub (power connected). While the hub is alway on (with RX on), the nodes sleep most of the time. The nodes work with polling mechanism: Every 7 seconds roughly the nodes wake up and advertise their availability to the hub with a small packet. The nodes then stay in RX for a small time frame so that the hub has a chance to interact with the node. 

This works very well most of the times. I have tested and figured out what would be the shortest time for the nodes stay in RX after sending the advertisement command so that packets can be received safely.

I am not sure if this information is relevant, but I wanted to five some background.

Now here is my problem: In certain scenarios, the communication fails between hub and node fails. I have one system where one hub speaks to two nodes. One node (Node A) is fairly far away, even needs to transmit through a house (40 meters + house in between). The node (Node B) sits close to the hub (10 meters, line of sight, only some bushes).

While communication between Node A and Hub is fine, the communication between Node B and Hub very often fails, by means of the advertisement package is not received by the hub or the command from Hub to Node B fails after receiving an adv. packet. The weird thing: In case a package from Node B to Hub does go through, it has a fairly good RSSI (approx. -70dbm). When I move Node B sidewise a few meters, everything works again.

It has to do something with the location/position of Node B as interchanging Node A and Node B give the same results but now with Node A having the communication problems. So it's not a problem of the individual device.

I see the problem most likely being related to the radio settings, so here are my register settings:

/**
 * CC430 configuration registers
 */
#define SYNC1      0xB5   // Synchronization word, high byte
#define SYNC0      0x47   // Synchronization word, low byte

#define FSCTRL1    0x06   // Frequency synthesizer control.
#define FSCTRL0    0x00   // Frequency synthesizer control.

// Carrier frequency = 868 MHz
#define FREQ2_868  0x21   // Frequency control word, high byte.
#define FREQ1_868  0x62   // Frequency control word, middle byte.
#define FREQ0_868  0x76   // Frequency control word, low byte.

#define MDMCFG4    0xC7   // Modem configuration.
#define MDMCFG3    0x83   // Modem configuration.
#define MDMCFG2    0x13   // Modem configuration.
#define MDMCFG1    0x22   // Modem configuration.
#define MDMCFG0    0xF8   // Modem configuration.
#define CHANNR     0x00   // Channel number.

#define DEVIATN    0x40   // Modem deviation setting (when FSK modulation is enabled).

#define FREND1     0x56   // Front end RX configuration.
#define FREND0     0x10   // Front end TX configuration.
#define MCSM0      0x10   // Main Radio Control State Machine configuration.

#define MCSM1      0x30   // Main Radio Control State Machine configuration.

#define FOCCFG     0x16   // Frequency Offset Compensation Configuration.
#define BSCFG      0x6C   // Bit synchronization Configuration.

#define AGCCTRL2   0x03   // AGC control.
#define AGCCTRL1   0x40   // AGC control.
#define AGCCTRL0   0x91   // AGC control.

#define FSCAL3     0xE9   // Frequency synthesizer calibration.
#define FSCAL2     0x2A   // Frequency synthesizer calibration.
#define FSCAL1     0x00   // Frequency synthesizer calibration.
#define FSCAL0     0x1F   // Frequency synthesizer calibration.
#define FSTEST     0x59   // Frequency synthesizer calibration.

#define TEST2      0x81   // Various test settings.
#define TEST1      0x35   // Various test settings.
#define TEST0      0x09   // Various test settings.

#define FIFOTHR    0x47   // RXFIFO and TXFIFO thresholds.
#define IOCFG2     0x29   // GDO2 output pin configuration.
#define IOCFG0     0x06   // GDO0 output pin configuration. Refer to SmartRF® Studio User Manual for detailed pseudo register explanation.
#define PKTCTRL1   0x04   // Packet automation control.
#define PKTCTRL0   0x05   // Packet automation control.
#define ADDR       0x77   // Device address.
#define PKTLEN     0x3D   // Packet length.

It would be great if you could please check if you can see something weird here that could cause such packet losses.

Could radio reflections (e.g. from an opposite wall) cause such behavior?

Could it be that reflections causes the CCA not sent a packet?

The communication problem is also present if the other node is switched off. So traffic from other nodes is not causing the issue.

Best,

Henry

  • 0
    TI__Mastermind 22580 points

    Hello Henry,

    I will ask my colleague to look into this request. Give us couple of day's time.

    Thanks,

    Sai

  • 0 in reply to Sai Reddy
    TI__Guru**** 317180 points

    I suspect that this is not related to CC430 but to how radio works. 

    It was not fully clear to me, do you know for sure if it's the communication from the hub to node B that fails or if it's the communication from node B to the hub that fails? I suspect that you have answered your question, reflections etc could cause a dead spot at node B meaning that node B are not able to receive the signal from the hub. As an experiment, have you tried to move the antenna of node B around 1/2 wavelength and tilt it 90 degrees? It could be that you have managed to put node B in a RF dead spot (seen from the hub) where you get a negative interference due to reflections etc. 

  • 0 in reply to TER
    Intellectual 495 points

    Thanks for your input. The radio is disturbed in both directions, but the direction from Hub to Node B is slightly more affected (but maybe it's just random). The Hub receives approx. 40% of the packets and the Node B receives also approx. 20% of the packets sent from the Hub.

    Unfortunately the antenna direction can only be changed in one direction, tilting is not possible due to how the casing is mounted. I realized that touching the outer casing of Node B helps and packages are received more reliably. The antenna impedance is tuned to 50 Ohms including casing and the unit is outputting between -5dbm and +8dbm, depending on orientation, which we tested in a RF chamber in a lab. Its a PCB F-antenna and a balun from Johanson.

    Any idea what could be improved in your opinion?

    I ordered a CC1111EMK868-915 to be used with the SmartRF Sniffer to see if maybe packets are not sent because of CCA (or other reasons).

  • 0 in reply to Henry Broeker
    TI__Guru**** 317180 points

    I don't have any good ideas as of now. 

    Using a sniffer is a good idea to get a better picture of what is going on in the network. I don't see why touching the casing should impact the result. Is it a plastic casing or is it conducting? 

    Also, have you tried different channels/ frequencies if it's some noise sources close to node B that causes a disturbance? 

  • 0 in reply to Henry Broeker
    Guru 117855 points

    Outsider/Intruder 'EE' Alert ...  although I have Ham (Extra Class & Moon-bounce), Military, & Commercial, Broadcast Radio design experience.

    Vendor agent 'TER' noted: "I suspect that this is not related to CC430 but to how radio works."    Such was my thought as well - yet there remain (further) tests which may prove valuable.

    You noted: "the direction from Hub to Node B is slightly more affected."    This may indicate 'excess RF/noise levels' at/around Node B's location.   We have past experienced overhead, 'fluorescent lighting ballast' - as one such culprit.    And other nearby electronics - all may prove 'suspect.'   You may test this hypothesis via, 'Lights Off' and De-powering (all) electronics near Node B.   (such HAS resolved issues for our group - several times.)

    Note too that the 'antenna'  (and its orientation, polarization match, & location) proves vital in almost every RF link.   The convenience of  'pcb antennas' most always arrives w/a corresponding 'performance loss.'

    The quality of the radio link (devices) also should be examined.   While you've interchanged Nodes A & B - the radio devices themselves remain.   A 'more pure'  radio-signalling test would involve a 'different' (non CC430) radio system pairing.    (ideally of  equal or higher quality)     Issue remaining (then) adds 'ammo' to the 'location challenge' presently suffered by Node B.   It is possible that a slightly improved receiver may greatly reduce your error rate.

    Indeed this proposal 'moves you' from your initial selection - and adds cost.    However - any serious application benefits from the, 'Establishment of a performance Base-Line' - and several such radio implementations (beyond just one) go far to meet that (too often) neglected (baseline) need!

  • 0 in reply to cb1_mobile
    Guru 117855 points

    I board a small biz jet shortly - wanted to add few more 'ideas/approaches' to your quest.    (interestingly [at least to my group] as an ex US Army Officer I join my past 'Battalion CO' (boss) for 'July 4th observance.)

    • It is unclear if you've 'more than' the 2 radios which serve as Nodes A & B.   You can establish a 'baseline' for these particular radios by 'raising that number' (2) (and then testing.)   At the price point of your RF modules - it is suspected that some variation is (almost) certain to occur.   (I'd add at least 5 more devices)
    • You requested, 'Confirmation of Register Settings' - that appears not (yet) to have occurred.   Cannot you make careful/minimal/systematic 'fine tuning/changes' - and note results?
    • You report, "~ -70dbm" (RSSI) when commo. fails.     Cannot that RSSI reading be 'logged' - and then matched to 'successful receptions?'   (the degree of  'Received signal-level variation' - rather than the 'absolute level' - may suggest a solution.)
    • Repeaters extend radio range - yet (also) 'overcome' - such 'Distressed RF Zones.'   (unclear if this class radio includes such capability.)
    • Those 'bushes' should be well trimmed - might their 'watering' (adding conductivity) play some role?
    • It is believed that an 'SDR' (software defined radio) would out-perform (most) 'SmartRF Sniffers' - enabling your efficient, 'recognition & avoidance' of RF dead/disturbed zones.

    Should 'Node B's' location prove, 'Radio Flawed' - could you not (minimally) relocate the radio - and then 'cable in'  - the final 50 feet?   (whoops - that's the cable company - 2 meters in your case)

    Again - a 'Cadillac' radio pair should provide a valuable, 'RF Baseline' ... always an excellent counter to, 'Send & Pray!'