IQ Oscilloscope
The IQ Oscilloscope block offers a powerful multi input oscilloscope for IQ data streams including various graphs, decoders and trigger features:
Left hand side Input:
- IQ 1
- IQ 2
- IQ 3
- IQ 4
Right hand side Output:
- IQ Slice (Scope triggered/displayed IQ data. Furter processing with script block only).
- Symbols (Symbols from the decoder. Furter processing with script block only.
- IQCons (IQ constellation data from QAM based protocols only)
The complete IQ data stream can be visualized and decoded with up to 5 graphs at the same time:
- IQ and/or R
- Phi and/or Delta Phi
- Frequency
- Demodulation
- Vector incl. Constellation
In addition every IQ stream (up to 4 are possible) gets it own color control for IQ, R, Phi etc. for an optimized mixed data display. A powerfull timing and trigger control should be able to solve any capture or trigger setup needed.
The powerful symbol decoder supports various digital standards including:
- Auto
- Auto Basic
- ASK
- GFSK
- BPSK
- DBPSK
- QPSK
- QPSK_C
- DQPSK
- P4DQPSK
- 8DPSK
- QAM16
- QAM64
- QAM256
- QAM1024
- Bluetooth
- Bluetooth LE
- Bluetooth EDR 2M
- Bluetooth EDR 3M
- DECT
- GSM
- WiFi
- Wifi 802.11b
- Wifi 802.11g 5MHz
- Wifi 802.11g 10MHz
- WiFi 802.11g 20MHz
- Enhanced Shockburst
- SkyRadio MavLink
And finally various symbol grids can be added (e.g. bpsk, qpsk, qam16, qam64, qam256, qam1024, qam4096) helping to check the symbol quality:
All in all the IQ Oscilloscope block is one of the most powerful blocks and is free of charge.
A random QAM16 signal with all decoders and graps activated:
Analyzing analog PAL bursts/packages with the help of the IQ Oscilloscope:
The most simple mission:
I am using the IQ oscilloscope to decode a BLE waveform (screencap 1). It mostly works as expected, except for one thing.
The decoded (hex) message seems not be as expected. As it is shown in screencap 2, at the bottom, the same bit sequence of 0-0-0-1-1-1-1-0 is decoded as 7c, then as ea and finally as 9d.
My assumption is that some descrambling/dewhitening operation is performed between the bits and the decoded bytes. Can you confirm this? Is there a way to disable this? It would be great to be able to do so and check that the CRC is valid (now it always shows this as fail).
Thanks
Uploaded files:
All fine since the bit sequence is used to verify the GFSK signal, and thus represents the unwhitened signal. The seed value for the CRC in BTLE is only fixed in announcement packets, and thus cannot be correctly checked for packets in an existing connection. We are evaluating means to reverse the seed, when decoding multiple packets.
We added an automatic scale and select mode "Audo adjust Power" and "Auto Adjust Range" for a perfect fit and scale of all graphs
