SMARTRFTM-STUDIO: Packet RX Window - Maximum Number of Logged Packets (CC1101)

Projetos Seis

Tool/software:

Hello,

I’m using SmartRF Studio with a CC1101-based setup and running long-duration tests using the Packet RX tab. My goal is to leave the receiver running for several hours and, at the end of the day, export all received packets via the "Dump Data to File" option.

However, I noticed that all packets are listed in the live Packet RX text window during the test, and I’d like to know:

- Is there a maximum number of packets or lines that the Packet RX display can store before older data starts to be overwritten or discarded?

I want to ensure that I won’t lose data during long sessions. If the window has a size or memory limit, is it safe to rely only on the “Dump Data to File” feature for complete logging, even if the GUI stops showing all packets?

Thanks in advance!

5 months ago

0 Arthur R☑️ 5 months ago

TI__Mastermind 25275 points

Hi Projetos,

I have checked, and the data dumped to the file will not be overwritten or discarded. As an additional safety measure however, you could try hiding the text view like so:

How often are you expecting to receive data?

Regards,

Arthur

0 Projetos Seis 4 months ago in reply to Arthur R☑️

Prodigy 10 points

Hi Arthur,

To answer your question: I'm expecting to receive 8 packets spaced by 100 ms, and this burst happens once every 1 minute.

For example, here's a snippet of what the data looks like during two transmission bursts:

// Burst 1 (8 packets at ~100 ms intervals)

14:20:38.540 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37
14:20:38.664 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37
14:20:38.774 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37
14:20:38.883 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37 
14:20:38.992 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37 
14:20:39.102 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37 
14:20:39.211 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37 
14:20:39.320 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f3 | -37


// Burst 2 (next minute)
14:21:33.979 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.091 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.201 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.310 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.419 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.529 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.638 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37 
14:21:34.748 | 0b | f0 cb de 4b c0 00 0e bf 4d 34 f4 | -37

Last night, I left the receiver running starting at 16:28, and when I checked it this morning around 09:00, SmartRF Studio had closed itself — possibly due to an external issue. Fortunately, I had the "Dump Data to File" option enabled, and the text file was successfully saved.

From the log, I noticed that the file contains data from 16:28:06.698 to 23:25:46.308, totaling 6,187 lines of received packets.

That gives me around 7 hours of uninterrupted testing, which I’ll consider as a safe upper bound for now.

I’ll check the Windows event logs to see if there was an external factor that caused SmartRF Studio to close, and I’ll share any relevant findings here as a follow-up.

+1 Projetos Seis 4 months ago in reply to Projetos Seis

Prodigy 10 points

Follow-up:

At 23:35, Windows triggered an event log with ID 7002, which I believe indicates a user logoff.

I double-checked and automatic logoff was already disabled in my power and group policy settings. However, the event log pointed to the Customer Experience Improvement Program (CEIP) as being involved, so I’ve now disabled CEIP just in case that was the cause.

As an extra precaution, I’ll also run a mouse shaker script overnight to simulate activity and ensure the session stays alive.

I’ll post another update tomorrow with the results.

Sub-1 GHz

Sub-1 GHz forum

SMARTRFTM-STUDIO: Packet RX Window - Maximum Number of Logged Packets (CC1101)