CC1101: CC1101

Hi,

Have you tried doing a basic packet TX/RX test using SmartRF Studio 7: https://www.ti.com/tool/SMARTRFTM-STUDIO ?

Are you using custom hardware or a TI evaluation board?

Regards,

Zack

Hi Zack,

yes, i have tried basic tx and rx using smart RF studio7.

i am using a 433Mhz cc11101 wireless RF Transceiver module.

Thanks,

Hi Parth,

Apologies, can you clarify if the issue persisted when using SmartRF Studio? You posted a code snippet (along with the settings) in your original question so I just want to check - I will ask one of my SW colleagues in the case that it could be an issue with the code (rather than the RF settings).

Regards,

Zack

Hi Zack,

Thank you for your quick response.

we have figured out the issue, some other functionality was not allowing RF chip to receive the interrupt. now transmission and reception are working fine with the Transceiver module.

I have one query, when no packet is sent or received for some time(let's say 30 min) RF doesn't respond to a new packet (after 30 min).

is the chip in sleep mode after a particular time? As my device is battery-operated so we have to go into low-power mode, how can we only allow the chip to wake on receiving something?

Hi Parth

Letting the radio be in continuous RX is not a good idea when it comes to current consumption. Also, you might experience that the synth gets out of lock if you do not calibrate it from time to time, so continuous RX (or) is not recommended even in cases where current consumption is not an issue.

To reduce the time in RX you have some options

1) You can make a synchronous system where your transmitter and receiver are  active at the same time. This would be OK if you have a system where your transmitter sends packets at a fixed interval, and you manage to sync the receiver to this interval so it does not have to be in RX all the time

2) Wake On Radio. See AN047--CC1100/CC2500 Wake on Radio (Rev. B (ti.com) for details

3) If your transmitter does not transmit very often, a solution is to have the transmitter repeat the same message several times when it first transmits. Then the length of the transmitted messages will determine how often the receiver needs to enter RX mode to be sure one of the packets are received.

BR

Siri

Hello Siri,

Thank you for your valuable response.

For my application, WOR suits the best to optimize power consumption, I will update my firmware acc. to the datasheet and update you soon about the results.

Thanks & Regards,

Parth.

Hi Siri,

I have implemented WOR functionality for my application.

These are WOR configurations.

WOR_INIT

void WakeOnRadioInit()
{
	SpiWriteReg(CC1101_WOREVT1, 0xF1);
	SpiWriteReg(CC1101_WOREVT0, 0x7F);

	SpiWriteReg(CC1101_WORCTRL, 0x78);
	SpiWriteReg(CC1101_MCSM0, 0x18);
	SpiWriteReg(CC1101_MCSM2, 0x01);

	SpiWriteReg(CC1101_IOCFG0, 0x24);
	SpiWriteReg(CC1101_IOCFG2, 0x25);
	
}

WOR_START

void WakeOnRadioStart()
{
	SpiStrobe(CC1101_SRX);
	SpiStrobe(CC1101_SWORRST);
	SpiStrobe(CC1101_SWOR);
	
}

MAIN Loop

int main(void)
{
	GPIO_init();
	USART_Init();
	WS_Init();          //CC1101 Init
    WakeOnRadioInit();
	WakeOnRadioStart();
	
	while (1) 
    {
        //Poling GdO0 pin to check data receivied or not [planning to make it on interrupt]    
    }
}

I am using the same register configuration as I mentioned in my first post.

In Our current application, we are sending ACK signals on receiving specific packets.

On receiving that specific packet the CC1101 continuously sent the Ack packet, if I disabled the WOR it sent the Ack packet for one time only.

Thanks & Regards

Parth.

I am sorry, but I did not understand your test scenarios and which device sends what?

Please try to clarify (maybe with a timing diagram) what the two devices are doing, and how it fails.

Siri

Hi Siri,

I have two CC1101 Chip Transmitter and receiver.

i am sharing one image of smart rf studio. i am using the cc430 dev board.

first, 4 bytes of the packet is id, 5th byte is the don't care byte and 6th byte is the packet identification byte which is c9(201) so if the transmitter transmits c9 then receiving should acknowledge it with the packet including cd(205), as you can see in the image it sending cd(205) multiple times.

BR,

Parth.

Sorry, but I am still confused.

First of all, are you using the CC430 or the CC1101? These are two different devices, supported by two different teams, and since one is a transceiver and one i a SoC it is necessary that we know which devices you are having problems with.

You said that you had a CC1101 that are using WoR, but what is used for the transmitter and what is the transmitter doing?

What is the purpose of the CC430 RX in Studio? Is this used as a sniffer?

Please provide a timing diagram of your implementation and a clear explanation as to what goes wrong.

I would need something on the following format:

From the code you have posted, I assume that you have a CC1101 used in WoR  mode (Device B) that are waking up at a given interval searching for packets.

However, you are not showing any code for what is going on once a packet is received.

I need to know what the code is doing, and a diagram showing what you have planned for it to do.

Same for the transmitter(Device A). After it has sent a packet and it has been received by DEvice B, what does it do then?

What is the code supposed to do, and what do you actually see happens (since it obviously is not working the way you want).

Siri

Another thing, the Studio plots have settings for variable packet length mode, but there are no length byte shown in the received packet????

Hello Siri,

Thank you for your valuable response. I was having some health issues that's why I wasn't able to reply. 

1.  I am using a CC1101 chip for both my transmitter(Device A) and Receiver(Device B)
2. The role of CC430 is just to sniff the packet on the same frequency(433.92MHz).
3. The same CC1101 chip is used in the transmitter. we have designed a board in which the cc1101 is used with another microcontroller. let's say Devie A is the input sensor on every trigger packet created and it will be sent over RF to Device B which is the Output sensor, it will turn on or off the output.
4. Sorry as of now I don't have access to a logic analyzer to display the diagram.
5. I am sharing a code snippet for a better understanding of what I have described as the working of the DevieA(Tx) and DeviceB(RX). register configuration and sending and receiving functions of RF I have pinned them in the above post.

ISR(INT1_vect)         // Interrupt Pin for GDO2 
{	
	WakeOnRadio_Receive();
	WS_Handler();
}


void WS_Handler()
{
uint8_t len;
uint32_t dev_addr;
	
    len = WS_ReceiveData(gbl_ws_buffer);

		switch (gbl_ws_buffer[5]) 
		{
		case ipop_data      : WS_CheckInputData(&ws_packetdata, (uint32_t *)gbl_ws_buffer); //This function checks the input data received over RF and make decision acc to that.
		                       break;
		case op_dataout	    :WS_OutputSuccessPacket(static_device_address,true);  //This function checks the output data received over RF and turn on/off output.
		                        break;
		}
}

void WakeOnRadio_Receive()
{
	SpiWriteReg(CC1101_WORCTRL,0x78);
	SpiWriteReg(CC1101_MCSM2, 0x18);
	SpiWriteReg(CC1101_WOREVT0, 0x11); 
	SpiWriteReg(CC1101_WOREVT1, 0x9A); 
	
}

int main(void)
{
	GPIO_init();
	USART_Init();
	WS_Init();          //CC1101 Init
    WakeOnRadioInit();
	WakeOnRadioStart();
}

I have referred this post for WOR https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/181405/wake-up-on-radio-cc1101.

The same configuration is used for both the chip TX and RX, After Enabling the WOR, the Device A(TX) input sensor can send packets successfully but the Device B (Rx) Output sensor is not able to receive the packet.

Thanks & Regards,

Parth Makwana.

I am not sure how I can help you further, and I am strongly recommending you to get hold of a logic analyzer so that you can debug this properly.

From your settings, it looks like you are using 1.2 kbps data rate, and you send 4 bytes of preamble, and 4 bytes of sync.

From your SmartRF Studio screenshot, it seems like your packet payload is 9 bytes. Adding 2 CRC bytes, means that your packet is

4 + 4 + 1 + 9 + 2 = 20 bytes = 160 bits, which takes 160/1200 = 133 ms to transmit

You do not give any information as to how often Device A will send a packet to Device B so I assume it is only sent at random intervals:

Your Device B is in WOR mode with the following parameters:

EVENT0 = 0xF17F = 61823

t_Event0 = (750/26000000)* 61823 = 1.783 s

t_Event1 = (750/26000000)*48 = 1.385 ms

RX Timeout = 111 ms

That means that you have something like this:

If you are only waking up to sniff once every 1.78 s, and the packet you are trying to catch is just sent at random interval and lasts for 133 ms, there is not a very big chance that your receiver wakes up just at the same time as your transmitter is transmitting.

Please read the again the WOR post you are referring to, and look att he pdf attached there, where I try to explin how to setup wor for a given packet.

Siri

Hi Siri,

I have procured a logic analyzer for graph verification. In the interim, I am submitting my code for your review.

Could you please assess the configuration of the Wake-on-Radio (WOR) feature, noting that I am utilizing the GDO02 pin for reception monitoring?

and this configuration will be replicated for output sensor functionality.

Additionally, I am seeking guidance on strategies to minimize power consumption.

BR,

Parth.

I will not be able to do a code review for you.

I need you to tell me, in words, how your system work.

If your TX application needs to transmit a 133 ms long packet at random intervals, you cannot use WOR to receive it, as you would have to be able to ensure to wake up at least two times within your preamble to be able detect the packet.

If your TX application is flexible, you can either let your transmitter send a longer preamble (the length of the preamble will determine the wake up interval of the receiver), or you can send many short TX packets for n duration of time, and then have your RX wake up within that interval.

When you have decided how you want to do this, and made an implementation, you can provide logic analyzer plots that I can take a look at, if you are still not able to get it to work.

Siri

HiSiri,

As per your suggestion, i have increased the preamble size to 24 and changed the value of WOR functionality to that, I am sharing my configurations. i can receive the packet with WOR mode on but it does not always receive the packet. About the waveforms the chip is mounted in such a way it is very difficult to have wires on spi lines and get the plots.

void WakeOnRadio_Init()
{
    SpiWriteReg(CC1101_WORCTRL,  0x78); 
	
	SpiWriteReg(CC1101_MCSM2,0x18);
	
	SpiWriteReg(CC1101_WOREVT0,0X9A);
	
	SpiWriteReg(CC1101_WOREVT1,0X11);
	
	SpiStrobe(CC1101_SWOR);	
}

Register Configurations

#define VAL_IOCFG2        0x06
#define VAL_IOCFG1        0x5c
#define VAL_IOCFG0        0x07
#define VAL_FIFOTHR       0x47
#define VAL_SYNC1         0xD3
#define VAL_SYNC0         0x91
#define VAL_PKTLEN        0x61
#define VAL_PKTCTRL1      0x44
#define VAL_PKTCTRL0      0x05
#define VAL_ADDR          0x00
#define VAL_CHANNR        0x00
#define VAL_FSCTRL1       0x06
#define VAL_FSCTRL0       0x00
#define VAL_FREQ2         0x10
#define VAL_FREQ1         0xA7
#define VAL_FREQ0         0x62
#define VAL_MDMCFG4       0xF5
#define VAL_MDMCFG3       0x83
#define VAL_MDMCFG2       0x13
#define VAL_MDMCFG1       0x72
#define VAL_MDMCFG0       0xF8
#define VAL_DEVIATN       0x15
#define VAL_MCSM2         0x00
#define VAL_MCSM1         0x33
#define VAL_MCSM0         0x18
#define VAL_FOCCFG        0x16
#define VAL_BSCFG         0x6C
#define VAL_AGCCTRL2      0x03
#define VAL_AGCCTRL1      0x40
#define VAL_AGCCTRL0      0x91
#define VAL_WOREVT1       0x00
#define VAL_WOREVT0       0x00
#define VAL_WORCTRL       0x00
#define VAL_FREND1        0x56
#define VAL_FREND0        0x10
#define VAL_FSCAL3        0xE9
#define VAL_FSCAL2        0x2A
#define VAL_FSCAL1        0x00
#define VAL_FSCAL0        0x1F
#define VAL_FSTEST        0x59
#define VAL_PTEST         0x7F
#define VAL_AGCTEST       0x3F
#define VAL_TEST2         0x81
#define VAL_TEST1         0x35
#define VAL_TEST0         0x09
#define VAL_PARTNUM       0x00
#define VAL_VERSION       0x06

I have to change my transmit function to send the data

void TX_data()
{
    SpiStrobe(CC1101_SIDLE);
	_delay_ms(2);
	SpiStrobe(CC1101_SFTX);
	_delay_ms(2);
	SpiStrobe(CC1101_SIDLE);



 	SpiWriteReg(CC1101_TXFIFO,size);
	SpiWriteBurstReg(CC1101_TXFIFO,txBuffer,size);			//write data to send
	SpiStrobe(CC1101_STX);									//start send
	
	while(!(PIND & (1 <<GDO2 )));							// Wait for GDO2 to be set -> sync transmitted
	while((PIND & (1 << GDO2)));							// Wait for GDO2 to be cleared -> end of packet

	_delay_ms(750);
	SpiStrobe(CC1101_SIDLE);
	
	SpiStrobe(CC1101_SWORRST);
	SpiStrobe(CC1101_SWOR);
	
}

Receive Function 

void Rx_Data()
{
    char size;
	char status[2];
	
	SpiWriteReg(CC1101_WORCTRL, 0x78);
	SpiWriteReg(CC1101_WOREVT1, 0x11);
	SpiWriteReg(CC1101_WOREVT0, 0x9A);
	SpiWriteReg(CC1101_MCSM2, 0x18);
	SpiWriteReg(CC1101_PKTCTRL1, 0x64);

	
	if(SpiReadStatus(CC1101_RXBYTES) & BYTES_IN_RXFIFO)
	{
		size=SpiReadReg(CC1101_RXFIFO);
		SpiReadBurstReg(CC1101_RXFIFO,rxBuffer,size);
		SpiReadBurstReg(CC1101_RXFIFO,status,2);
		SpiStrobe(CC1101_SFRX);
		return size;
	}
 	else
 	{
 		SpiStrobe(CC1101_SFRX);
 		return 0;
 	}
}

in my device cc1101 chip is used with ATmega324pb. the consumption of  MCU is 1.7microA standalone and with the cc1101 chip, it is around 500microA. 

as mentioned in the datasheet When in WOR the consumption will be nA but after putting the chip in WOR it is consumed in microA.

Thanks & Regards.

your wakeup interval look s OK, so it is hard to say why you are loosing packets just based on the looking at the config.

you really need to try to at least be able to monitor the GDO signal from the devices using a logic analyzer to figure out what goes wrong.

you can output the PA signal from the transmitter to see when it is in TX and the LNA signal from your receiver.

That way you would be able to see if your transmitter is actually in RX while you are transmitting, and you could verify that it does does not time out too early etc.

In WOR mode, the current consumption should be 0.5 uA.

If you measure higher than this, you need to look at how your GDO pins are configured, and what the MCU connected to the CC1101 does with its pins (the SPI and GDO pins), when the CC1101 is told to go to SLEEP.

BR

Siri

Hi Siri,

Thank you for the valuable response.

I have one more query regarding data sending.

as you can see in my transmit function I have added a delay when sending data. is it necessary to add some delay after strobing the IDLE, SFTX?  if I remove this delay there is a loss of packet when sending data continuously. or no delay is required? is this the right method to put the chip in WOR after data sending?

	SpiStrobe(CC1101_SIDLE);
	SpiStrobe(CC1101_SWORRST);
	SpiStrobe(CC1101_SWOR);

BR.

Hello

Thank you so much, after changing the tx function I can send and receive the packet every time using WOR.

the consumption is around 800microA, as you mentioned in a previous post I will look at the spi and gdo configuration and I will update you soon.

Thanks & Regards,

Parth.

Hello Siri,

With this WOR functionality, the consumption is around 300 microA. 

Now I changed the value of the WORCTRL register to 0xF8 ( RC_PD 1 R/W Power down signal to RC oscillator).

.

this change leads the consumption to around 2microA.will this affect my receiving functionality? or it will be the same as it was working before?

if it affects what changes do I need to implement?

BR.

you cannot run WOR if you have powered down the RC oscillator. This is controlling the sleep timer that makes sure that the radio wakes up from Sleep.

Without the RC oscillator running, the radio should draw about 0.2 uA is you put it into SLEEP (SPWD). Make sure that all GDO pins are set to 0x2F. With the RC oscillator, it will consume 0.5 uA.

How much your average current consumption will be when running WOR depends on how often you wake up and how long you stay in RX every time you wake up. If you receive something when waking up, the radio will stay much longer in RX, and the current consumption if you do not receive anything.

Siri

Hello siri,
I am facing couple of issues. It would be very helpful if you help me out.

1.) While sending data device stuck in line while(!(PIND & (1 <<GDO2 )));  "Wait for GDO2 to be set -> sync transmitted". Please have a look to my send function of data sending & all the other register settings. Device is in WOR mode.

void WS_SendData(char *txBuffer,char size)
{
 	SpiWriteReg(CC1101_TXFIFO,size);
	SpiWriteBurstReg(CC1101_TXFIFO,txBuffer,size);			//write data to send
	SpiStrobe(CC1101_STX);									//start send
	while(!(PIND & (1 <<GDO2 )));	//DEVICE STUCK in this while LOOP //-- Wait for GDO0 to be set -> sync transmitted
	while((PIND & (1 << GDO2)));							// Wait for GDO0 to be cleared -> end of packet
	
	SpiStrobe(CC1101_SFTX);									//flush TXfifo
	SpiStrobe(CC1101_SIDLE);
	SpiStrobe(CC1101_SWOR);
}

NOTE:- DEVICE is in WOR mode with following settings

#define VAL_IOCFG2        0x06
#define VAL_IOCFG1        0x5c
#define VAL_IOCFG0        0x07 
#define VAL_FIFOTHR       0x47
#define VAL_SYNC1         0xD3
#define VAL_SYNC0         0x91
#define VAL_PKTLEN        0x3d
#define VAL_PKTCTRL1      0x44  //0x05--Address checking enable//0x04--Add. check disabled
#define VAL_PKTCTRL0      0x05
#define VAL_ADDR          0x00
#define VAL_CHANNR        0x00
#define VAL_FSCTRL1       0x06
#define VAL_FSCTRL0       0x00
#define VAL_FREQ2         0x10
#define VAL_FREQ1         0xA7
#define VAL_FREQ0         0x62
#define VAL_MDMCFG4       0xF5
#define VAL_MDMCFG3       0x83
#define VAL_MDMCFG2       0x13										//GFSK -- 0X13// FSK -- 0X03 // OOK/ASK--0X33// 4-FSK--0X43 //MSK --0X73
#define VAL_MDMCFG1       0x22							//0x72// preamble set to 0x72-->24 bytes //older 0x22-->4 bytes
#define VAL_MDMCFG0       0xF8
#define VAL_DEVIATN       0x15
#define VAL_MCSM2         0x16
#define VAL_MCSM1         0x33
#define VAL_MCSM0         0x38
#define VAL_FOCCFG        0x16
#define VAL_BSCFG         0x6C
#define VAL_AGCCTRL2      0x03
#define VAL_AGCCTRL1      0x40
#define VAL_AGCCTRL0      0x91
#define VAL_WOREVT1       0x87
#define VAL_WOREVT0       0x6B
#define VAL_WORCTRL       0x78
#define VAL_FREND1        0x56
#define VAL_FREND0        0x10
#define VAL_FSCAL3        0xE9
#define VAL_FSCAL2        0x2A
#define VAL_FSCAL1        0x00
#define VAL_FSCAL0        0x1F
#define VAL_FSTEST        0x59
#define VAL_PTEST         0x7F
#define VAL_AGCTEST       0x3F
#define VAL_TEST2         0x81
#define VAL_TEST1         0x35
#define VAL_TEST0         0x09
#define VAL_PARTNUM       0x00
#define VAL_VERSION       0x06
#define VAL_FREQEST       0x00
#define VAL_LQI           0x00
#define VAL_RSSI          0x00
#define VAL_MARCSTATE     0x00
#define VAL_WORTIME1      0x00
#define VAL_WORTIME0      0x00
#define VAL_PKTSTATUS     0x00
#define VAL_VCO_VC_DAC    0x00
#define VAL_TXBYTES       0x00
#define VAL_RXBYTES       0x00
#define VAL_RF1AIFCTL0    0x00
#define VAL_RF1AIFCTL1    0x00
#define VAL_RF1AIFCTL2    0x00
#define VAL_RF1AIFERR     0x00
#define VAL_RF1AIFERRV    0x00
#define VAL_RF1AIFIV      0x00
#define VAL_RF1AINSTRW    0x00
#define VAL_RF1AINSTR1W   0x00
#define VAL_RF1AINSTR2W   0x00
#define VAL_RF1ADINW      0x00
#define VAL_RF1ASTAT0W    0x00
#define VAL_RF1ASTAT1W    0x00
#define VAL_RF1ASTAT2W    0x00
#define VAL_RF1ADOUT0W    0x00
#define VAL_RF1ADOUT1W    0x00
#define VAL_RF1ADOUT2W    0x00
#define VAL_RF1AIN        0x00
#define VAL_RF1AIFG       0x00
#define VAL_RF1AIES       0x00
#define VAL_RF1AIE        0x00
#define VAL_RF1AIV        0x00
#define VAL_RF1ARXFIFO    0x00
#define VAL_RF1ATXFIFO    0x00

2. My second problem is that i am not getting any interrupt on GDO0 in WOR mode. Please help me with the register settings of transmitter side so that receiver can receive the interrupt in WOR with this settings. Also let me know is any changes required in the above receiver settings.

NOTE:- Above provided code & register values are of receiver side of CC1101.

Thanks in advance

1)

I do not understand your comment about the device being in WOR mode.

WOR mode is a receive mode, so you cannot be in WOR mode when you are trying to transmit something.

What you need to figure out is if the problem is that the GDO2 pin is not asserted, or if the problem is that your code is not able to detect it.

Since I do not know what HW you are testing on or what MCU you are using, I cannot tell you if you are reading the pin correctly or not.

What you should do to test the radio itself is to disconnect the GDO2 from the MCU and then just do the following in your code:

Write to TX FIFO

Strobe STX

While(1);

Then you should connect a scope or logic analyzer to the GDO2 pin to verify that it is asserted as it should. When this is confirmed, you need to debug your code to make sure that the pin on the MCY that the GDO2 pin is connected to, is configured properly as an input and that your code is able to read it.

2)

We do not have the resource available to be able to make you a WOR demo on the CC1101.

You have previously written that you have WOR up and running 

"Thank you so much, after changing the tx function I can send and receive the packet every time using WOR."

This wa 1 month ago, so if the WOR mode is suddenly not working, I suggest that you take a step back to what you had working, and then start from there :-)

Siri

Hello siri,

void WS_SendData(char *txBuffer,char size)
{
	volatile uint8_t temp = 0;
	SpiStrobe(CC1101_SIDLE);
 	SpiWriteReg(CC1101_TXFIFO,size);
	//--CC1101_AddressCheck();
	SpiWriteBurstReg(CC1101_TXFIFO,txBuffer,size);			//write data to send
		SpiStrobe(CC1101_SFSTXON);	
	temp = SpiReadStatus(CC1101_MARCSTATE);
	temp = 0;
	
	SpiStrobe(CC1101_STX);	
	temp = SpiReadStatus(CC1101_MARCSTATE);
	temp = 0;
	while(!(PIND & (1<<GDO2 )))							// Wait for GDO0 to be set -> sync transmitted	
	{
		temp = SpiReadStatus(CC1101_MARCSTATE);
	}
	while((PIND & (1 << GDO2)));							// Wait for GDO0 to be cleared -> end of packet

	SpiStrobe(CC1101_SFTX);									//flush TXfifo
	SpiStrobe(CC1101_SIDLE);
	SpiStrobe(CC1101_SWOR);
}

1) We had monitor the machine state while transmitting the date, So our observation is as follows:-

-After sending SFSTXON strobe device enter in machine state 7.
-After sending STX strobe device enter in machine state 13.

-After that device enter in machine state 01.

So my question is that if i am sending the STX strobe then machine state will be 19 to send the data. 

Device get stuck while checking the PIN status of GDO0. 

When you first strobe SFSTXON, the radio is going out of IDLE and are calibrating the synth.

When you strobe STX afterwards, it goes almost immediately to TX state.

As I do not know the MCU you are using, I do not know if you have configured the input you are reading correctly etc.

Also I do not know anything about your SPI interface, so I do not know from a timing perspective when you are reading the registers

Please start debugging this by using a logic analyzer and monitor your SPI lines plus the GDO2 line to understand what is going on.

Siri

Hello siri,

So my device is not getting stuck as of now but it is not receiving the packet in WOR mode. Can you please help me with this. 

FYI:- The register settings are same as mentioned above of transmitter.

Waiting for your response.....

I am sorry, but I do not know how to help you. As I said before, you have previously had the WoR up an running, now your TX seems to be fixed, and you should be able to get WoR up and running again since you have already managed this before.

I have no idea what changes you have made to your code from the working solution to the state where it is not working anymore, so you simply need to try to take a step back and go back to what you had running.

BR

SIri