Also, in your bit level only flowgraph that you said works, can you insert the diff encoder and decoder blocks and show it still works? On May 8, 2025, at 10:32 AM, Richard Bell <richard.be...@gmail.com> wrote:
This is a bit level problem. This kind of problem is typically caused by assuming something about the input or output of one of these blocks that is not true. Carefully go through the blocks starting at the output of the constellation decoder and prove to yourself your input and output assumptions are correct. For example, I assumed the output of the constellation decoder would be bits, this was wrong. On May 8, 2025, at 10:29 AM, Richard Bell <richard.be...@gmail.com> wrote:
Can you visually see the sequence you expect coming out of the unpack block in either bpsk or qpsk? On May 8, 2025, at 10:25 AM, Zachary Naymik <znay...@mti-systems.com> wrote:
This also does not work for BPSK without the "Unpack K Bits" block either. Attached is the flowgraph and Time Sinks below. <image.png> That makes sense! However, I have added the "Unpack K Bits" block in 2 different configurations and neither work. Configuration 1: Configuration 2: <image.png>
According to your plots, the constellation decoder doesn't output bits, it outputs packed bytes. In the case of QPSK that would mean 2 bits per output byte. We need to unpack those bytes into bits before entering the correlate block, which expects 1 bit per byte. This can be done using the "Unpack K Bits" block with "K = 2" for QPSK. For BPSK you wouldn't need to unpack anything, it should work by default because BPSK only has 1 bit per byte coming out. Confirm this.
Add the "Unpack K Bits" block after the differential decoder and feed this into the correlate block.
I do see the valid bits out of the Differential Decoder. However, after removing the Map block, I still do not see anything on the other side of the Correlate Access Code block.
I do see the perfect dots in the 4 corners of the square like I have seen before in QPSK constellations. I understand that with noise the dots become more spread out into clouds instead of being perfect as they are in the simulation. Thank you for this information! I have a USRP flowgraph in progress that I have halted progress on so far, but I do have those blocks added in there where you have specified in previous messages. Here are the time sinks and the flowgraph in the state I have right now. I'm not sure what else I need to modify to make things work, however if I increase the threshold to 15 I can see things on the other side of the Correlate Access Code block if that helps you out at all. <image.png>
Zach
The constellation decoder should be producing valid bits of 1's and 0's. Therefore, the map block after the differential decoder needs to be removed. This should be the last change you need to get correlations. Plot the time domain output after the differential decoder, you should see nice bits to prove it to yourself.
Regarding the good looking constellations, you should see nearly perfect dots at the four corners of a square (assuming QPSK). This is why I said it maximizes BER, these near perfect dots are directly correlated to BER. The tighter these dots, the better your BER. When you add a noise source to this simulation, like the AWGN channel I recommended, you will see these dots become clouds and grow as the noise power grows. I recommend you set this up for yourself next.
When you get to using radios, in the receiver you will want to add back the AGC before the RRC filter and the linear equalizer after the costas loop block. This should give you a good working over-the-air transceiver.
Rich
Richard, I have changed the output SPS in the Symbol Sync to 1 and the constellations look great now. However, I still do not see anything after the Correlate Access Code block. You can see the flowgraph below with the changes. <image.png>
You have the output samples per symbol in the symbol sync block set to 2. Make that 1 and try again. Richard,
I have constructed this flowgraph based on your changes, and I still do not see anything come through the other side of the Correlate Access Code block. I also tried with just the equivalent Constellation Encoder -> RRC Filter on the TX side, but still no luck. The flowgraph and constellations are attached below. If you need any more information from me after running this flowgraph, please let me know! Getting closer, but not quite. You still have a rational resampler doing 16 to 1 decimation that shouldn't be there. The image I've attached is the structure I am trying to describe. Top row is transmitter, bottom row is receiver. The combination of the constellation encoder and RRC in the top row should be equivalent to your single constellation modulator object. The constellation modulator has the RRC built into it.
I also noticed that there is a poor choice for the default "number of taps" field in the RRC block (not your fault). It uses "11*sample_rate", which is not good. The FFT RRC filter length only depends on the sps and the total length you want it to be, in samples, to get the performance you want. This length is typically chosen to be around 11 symbols (that's where the 11 comes from) times the number of samples per symbol. This gives about 44 samples in length, independent of the sample rate. Notice my FFT RRC filter length is 44 and yours is 300k. I'm surprised the flowgraph even runs with a filter this long. Just change the "Num taps" field in the FFT RRC block to "11*sps", assuming you defined the sps variable like I have.
The costas loop order should be 2 for BPSK, and 4 for QPSK.
I did not run my flowgraph, I only put it together to show you what I've been describing in words. Hopefully I didn't overlook something. You will let me know.
Richard,
I reverted the Fractional Resampler's rate back
to the default value (~60m) and added the filter, and the constellations
look better than in my last email. They are pictured below, the Filter
is the same as listed in my previous email. I still see no output on the
other side of the "Coorelate Access Code" block though.
Thanks again, Zach
Richard,
Thanks again for the feedback, I was trying to move onto USRPs - but will revert until the filter is implemented as you have advised. There was no data lost and the file transmission was working fine, here is what I have found while trying to implement the filter. Just taking a look at the constellations, and data flow.
Without the RRC Filter, I see these constellations from the Symbol Sync and Costas Loop: <image.png> With the addition of the RRC Filter, I see these constellations from the Symbol Sync and Costas Loop: Before the filter as I stated above, the file is fully transmitted and repeated, however after adding the filter, I can see data going into the "Correlate Access Code" block, but nothing makes it out the other side.
Here is the filter that I added and where I added it in the flowgraph, I'm not sure what adjustments need to be made although I have tried some things - I have found no luck. <image.png>
Thanks, Zach
Hi Zachary,
I have to admit, I don't see how the flowgraph you say "works", could work. Maybe I'm not seeing a hidden parameter, but it looks to me like you are overall downsampling from the original symbol rate now, which means you should be seeing lost data.
Even if you are not losing data, and somehow the flowgraph does "work" in some way as it is shown, it will not work as well as it will if you follow my advice in the previous email. The RRC filters will improve the bit-error-rate (BER) compared to this one. I do recommend you try to implement the one I described, you will be happier. This relates to "opening the eye" of the constellation diagram, if you want to look that up.
Richard
Richard, I have been able to achieve a purely simulated working text file transmission using QPSK modulation. I will attach the flowgraph and the image below. The change that allowed it to work was increasing the resampling ratio in the Fractional Resampler block - although I still do not have the RRC Filter. I got this working shortly before leaving the office yesterday and just looked at your new feedback this morning hence the RRC Filter being left out. Should I rework this flowgraph to use an RRC Filter as I'm assuming that is the "right" way to do this? I am now planning on using the other feedback that you have provided to adapt this simulated flowgraph to use USRPs and will update here with progress.
Simulated working QPSK Flowgraph:
Thanks, Zach
Hi Zachary,
No problem, hopefully others will also get some useful information out of this thread as well. Thanks for letting me know. I'll try to explain with a little more detail.
1) In a QAM transceiver that is built to minimize bit-error-rate and optimize the synchronization performance, you will find two root-raised-cosine (RRC) filters, one in the transmitter, and one in the receiver.
2) The RRC in the transmitter is used to set the sample-per-symbol (sps) rate in the transmitter. The RRC in the receiver is used to set the sps in the receiver. Technically, these two sps do not need to be equal, but practically they often are setup that way. Let's get your transceiver working with the assumption that sps will be the same on both ends.
3) The way you set the samples per using the RRC filter, is by choosing the ratio of the sampling rate and the symbol rate to be equal to your sps rate. In the flowgraph that you included that contains the RRC, you have a sample rate of 48k and a symbol rate of 1. This means your sps is 48000 samples per symbol. This is the source of your current problem. In addition, you placed it right after the constellation modulator, as though it would exist in the transmitter at this location. In reality, this RRC would exist right before the symbol sync block in the receiver, and that's where I recommend you place it. The RRC for the transmitter is already included within the constellation modulator block for you by default, and is set to produce 4 samples per symbol.
4) If the only change you made to the flowgraph with the RRC in it is to set the sample rate of the RRC block from 48k to 4, I suspect it would start working. This is because it just so happens that the RRC is technically placed right before the symbol sync as it is, even though it doesn't look that way. The downstream blocks from the RRC just so happen to be identity operations in their current state.
5) I recommend creating a variable called "sps" and using this variable in all the blocks that require an explicit "samples per symbol", or use the ratio approach of wanting a "sample rate" and a "symbol rate". When a block wants both "sample rate" and "symbol rate", the first thing they usually do internally is create "sps = sample_rate / symbol_rate". When you set sample_rate = sps and symbol_rate = 1, you are doing so knowing this ratio is all it actually cares about. This is the case with the RRC block.
Hopefully that's all clear and your flowgraph starts to work. Let us know.
Richard
Richard,
Again - thank you for your guidance. I will admit I have no experience with signal processing so I appreciate you being patient with me. I have stripped the working BPSK flowgraph to work with the minimal amount of blocks I believe. However, when I add the RRC filter, the flowgraph will no longer work. I understand there might be some tuning I need to add to the RRC filter but I do not understand how to calculate what values I need to use or anything of that sort. I was also unsure of whether to use the FFT RRC Filter, or just the RRC filter. The flowgraphs are attached below. Any more feedback would be greatly appreciated. Thanks again, Zach
Working Stripped BPSK: <image.png> Non-functional Stripped BPSK w/ RRC Filter: <image.png>
Zachary,
I mentioned in my previous reply, you can remove the AGC, FLL, and Equalizer blocks from the original flowgraphs, those would be examples of optional blocks. The equalizer is only needed if a realistic channel exists, the AGC if realistic power fluctuation exists, and the FLL if large sources of frequency offset exist, like doppler from satellites moving around. For now all those effects should be left out. Don't use real radios until this works in pure simulation with an AWGN channel only. Then you can add these optional components and begin testing with radios.
This is all advice from my past experiences.
Rich
Zachary,
I would not call this the "smallest step" possible because this flowgraph just won't work. You are trying to do synchronization on a signal that was never modulated by the transmitter (why do you want that FFT filter in there, the RRC filter that is missing is all the filtering you need in the transmit chain). The costas loop requires at least 2 samples per symbol, but you are feeding in raw symbols (1 sample per symbol). Once you have more than 1 sample per symbol, you will require timing recovery, so that block will need to go back in also.
It's good that you proved the raw bits flowgraph works, that is a good starting point. Now go back to the BPSK that was working and the QPSK that wasn't working, and implement the changes I mention in steps 3 and 4.
Let us know how it turns out.
Rich
Richard,
I have heeded your advice and I have the stripped flowgraph working as described in step 1. However, I am trying to adapt the flowgraph to work as in step 2 but the only synchronization block I am able to add is the Costas Loop, if I add any other synchronization block the data does not make it through the correlation of the access code. Here is what I have for step 2, again I thank you for your advice and help - if you can give any more guidance that would be great. <image.png> Thanks, Zach
Hi Zachary,
I do see some problems with your flowgraph. I can recommend a debug strategy that I would use to figure out the root cause.
1) In the flowgraph that doesn't work, strip it down as much as possible such that you still have a working flowgraph. For example, remove all the synchronization blocks so that you only have the "bits -> packetize -> encoder -> decoder -> depacketize -> bits" flow working.
2) From the working flowgraph that is just bits in the previous step, start adding back synchronization blocks, using the smallest steps possible, and only those blocks that are absolutely required. For example, I would leave out the AGC and FLL in this step.
3) The constellation modulator block applies a root raised cosine (RRC) pulse shape to the transmitted signal. In your receiver, you are missing the symmetric RRC filter in the demodulation process. There should be one before the timing recovery block in both BPSK and QPSK. The BPSK may be able to work without it, albeit with a much worse bit error rate, while the QPSK fails completely.
4) The linear equalizer in your QPSK block should come after the costas loop block. Equalizers generally want phase and timing synchronized input.
5) Make sure all the upsampling/downsampling rates are correct in the QPSK graph. You switch to using 8 samples per symbol, instead of 4, so it's possible other rate changes need to be adjusted to reflect this. I didn't go through and do the math myself. I personally wouldn't recommend you increase the samples per symbol from 4 to 8. I would use 2 or 4 in both graphs.
Give these suggestions a try and let us know if anything improves.
Rich
Richard,
Thank you for the guidance. I believe I have made all the necessary changes to the modulation and synchronization technique. BSPK Flowgraph (working): <image.png>
QPSK Flowgraph (not working): <image.png>
If you have anything for me to try or experiment with please let me know. Thanks, Zach
Hi Zachary,
You will have a better chance of getting responses if you post screenshots of your flowgraph instead of attaching grc files themselves. People can't open grc files on their phones or on the go.
I have not opened your grc files, have you made the proper change to the synchronization technique you are using to account for the change in modulation type from 2 symbols to 4 symbols? That's the first place my mind went that would cause problems.
Rich
Hello all,
I am reaching out again as I am trying to modify a working file transmission using BPSK to work using QPSK. I have made all the modifications I believe to be necessary to get the transmission to work with QPSK, however I am unable to see any results. I have debugged this for many hours and am reaching out to see if anyone has any insight. Please let me know if you have any questions, the flowgraphs are attached.
Thanks, Zach --
--
--
--
--
--
--
--
--
--
--
--
|
