OOK data looks weired

[CptLeeChuck]

Hello,

First of all thanks a lot for what you've already done so far! However I have two issues which I hope you can help me at least with the current (second) one. I was able to run CCManager as expected. But I had some weired randomizations of myTX data. For example I sent
0xCC, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA
but in my received data the 0xCC, was clearly almost at the end of the transmission.

However right now I'm stuck with another issue. After I tried tranmitting some data via command line to see if the bits are there also mixed, all my transmission are now looking very weired. I tried already to reboot, reinstall firmware, connect, disconnet devices, but nothing solved the issue. The attached image show how

0xFF, 0x00, 0xFF, 0x00, 0xFF

looks like in my transmission recording. What could cause this? (Same on GUI and Command Line)

Here a closer look:

[jglim]

Hi! Thanks for bringing this up. It does look strange.. Could I verify that the settings you used to capture those signals are as follows:

SDRSharp, under the Recording pane

• Sample format is set to to 8 Bit PCM
• Audio is unchecked
• Baseband is checked

[CptLeeChuck]

Thanks for your quick reply. Yes I can confirm these settings. Two more things to mention. First I forgot yesterday to wrote that I connected the EXP430G2 with MSP430G2553 and CC1101 once (between OOK signals as expected and my weired OOK signals) without non-rotated TXD and RXD jumpers. Could this have damaged something?

Furthermore I notice that I hve to reconnect the board each time twice before it CCManger can find it on COM3. This was also not the case previously.

Is there anything I can try to reset EXP430G2 with MSP430G2553 and CC1101 entirely and start from scratch? I tried alread to reload the firmware without success.

Below again more full screenshots from my attemtp today. Still same issue:

[jglim]

Thanks for the details - I've tried to replicate your transmission and the results are below:

The first bit near 1,7230 seconds and 1,7240 seconds is a known issue where the CC1101 module tries to add a preamble before sending the data. It "should have been fixed" but still appears sometimes and it can usually be ignored or worked around by padding the start with 0x00.

At 868.25 MHz, the OOK pattern in your data appears to align with mine, indicating that the data and baud rate are also accurate. This indicates that your hardware is most likely perfectly healthy 😄

I believe the issue might be that the signal is too strong to your receiver as the amplitude on your recording (as displayed in Audacity) appears to be clipping the boundary. Maybe reducing the gain on your RTL-SDR or moving the devices further apart from each other will be of help.

Unfortunately I am not sure about the serial port visibility issue, as CCManager uses the OS's port listing.

[CptLeeChuck]

Hi,

Thanks a lot! Your gain hint solved the first issue! Now I can reproduce my actuall problem with mixed/wrong values.

I send this for instance:

0xFF, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA

First of all I'm not sure if the only different pattern really is 0xFF (=11111111) as it looks to me like 0xCC (=11001100). (see red comment in my screenshot)

Second, as one 0xAA (=10101010) equals four times on and off in rotation I expected after 0xFF 164 (= 41 * 4) on and 164 off in rotation. But after 0xFF (or 0xCC) I count 83 on and 83 off in rotation. Furthermore I count 32 at the beginning and another 3 before 0xFF (or 0xCC).

Do you have a clue what's happening here?

Compared to all this if I send a shorter sentence ilke this one:

0xAA, 0xCC, 0xFF, 0x00, 0xAA, 0xCC, 0xFF, 0x00

I get the result as expected (including preamble of CC1101)

[jglim]

Hey,

Just an update: I've managed to replicate and confirm the issue but I haven't found a solution yet 🤔

[CptLeeChuck]

Do you get the same wrong data or something different?

I was not able to open your project and do some debugging on this as visual studio prompts an error for missing .NET 4.0 components which I can't find for download and should actually be already included in visual studio/win10.

However I'm not very familiar with visual studio (with cc1101 even less), but in general i believe I understand your code more or less.

So in your RF class you've the following function which I understood transfers the data to the CC1101 TXFIFO register. Does this already contain the mixed data or is it scrambled later within CC1101?

public void Transmit(byte[] dataToTransmit)
		{
			List<byte> dataToTransmitInverted = new List<byte>();
		  	for (int i = 0; i < dataToTransmit.Length; i++)
		  	{
		  		dataToTransmitInverted.Add(FlipByte(dataToTransmit[i]));
		  	}
		  
		  	Log.Info("Writing TXFIFO", 2);
		  	SPI.WriteRegister(sp, CCRegister.CC1101_TXFIFO, (byte)dataToTransmit.Length);
		  	SPI.WriteBurstRegister(sp, CCRegister.CC1101_TXFIFO, dataToTransmit);
		  	
		  	EnterTransmitState();
		  	ShortWait();
		  	EnterIdleState();
		  	Log.Success("Transmit Completed");
		}

BTW: Are you transferring the non-inverted data?

[jglim]

The wrong data is different: I've followed your configuration as in your screenshot and this is the result

The inverted data dataToTransmitInverted is not used (vestigial code during development). The CCManager client sends the unmodified transmission data via serial to the hardware, which then writes the same unmodified data to the CC1101 via SPI. Hopefully this screenshot of the debugged client may help you:

It seems that either the CC1101 is unexpectedly messing up the data or the CC1101's registers are misconfigured. Either way it is quite a serious bug that has gone unnoticed for a long time (almost 4 years!). I plan to try different data sizes and registers to attempt to identify the issue at a later date as I am unfortunately occupied now. A (very hacky) workaround would probably be to further limit the transmission size.

Thanks for trying to debug the issue too! If you are using VS, maybe selecting "Windows Forms" (different from UWP) development in the installer might add the missing dependencies.

[CptLeeChuck]

Would it make sense to post in TI board/forum?

[jglim]

At this point of time I still have not found out enough about the issue, such as the transmission sizes that start triggering the bug. It might still be worth a shot - if you decide to do so, I believe the data in "View/Edit Registers" (which indicate the state of registers when transmitting) may assist in the diagnosis.

Really appreciate how much time you have already spent looking through and improving CCManager ^_^