At this resolution, you can clearly identify both peaks, these are the two points representing 0 and 1 digital levels. Remember we are transmitting a digital frequency modulated signal with two possible values, zero or one. The modulator (transmitter) will translate a digital level 1 to a frequency, and a digital level 0 to a different frequency. The demodulator (receiver) will do exactly the opposite in order to recover the original digital signal.
If you look at the code in the Arduino script, you can see we are repeatedly transmitting a byte with all bits set to zeros (when both ports 2 and 3 are LOW i.e. connected to GND).
If we are transmitting only zeros, why we get two peaks in this signal?
The reason is the preamble most RF transceivers use to identify a new transmitted package, including of course the CC1101 embedded in the RFBee. This preamble is typically a collection of alternating zeros and ones. Under the hood, we transmit a payload of 8 bits set to zero but also a preceding preamble with alternating zeros and ones. Something like this, being repeated continuously in a loop:
10101010 - 00000000
As we configured RF Explorer to calculate Max of every sample, we are displaying the signal spectrum envelop with both zeros and ones together, regardless the zeros being more frequent (or dominant) than the ones.
This is getting interesting. If we know the zeros are more frequent than the ones, we should be able to detect that somehow, right?
There are a few ways to do that; the simpler way is with a change in the number of iterations the calculator uses to display Max values:
By reducing the number of samples the calculator averages, we effectively prioritize the part of the signal which is more frequent, and lower the weight of the infrequent. This now makes the transmitted zero display as a constant peak, with an animated signal moving continuously on the right. There is no longer a constant peak for the ones.
The fact that fewer iterations show an animated response is expected, remember the RFBee transmitter is sending intermittent packages rather than a continuous wave (CW). We knew that because the script is iterating in a Loop() and repeatedly sending packages of 1 byte (and yes, some preamble bits as well).