Re: [Discuss-gnuradio] PSK Mod/Demod Questions/Issues
Firstly, thanks for the prompt assistance. "The modulator expect /packed/ bytes, so what you are providing it with is a lot of 0's." But I have an Unpacked -> Packed block set to MSB before the modulator. So with the Vector Source generating a sequence of (1,0,1,1,0,0) it should be packing bytes as follows: 1xxx 10xx 101x 1011 10110xxx 101100xx 1011001x 10110010 <--so that 1st byte received by the modulator is 50% 1's, then... 1xxx 11xx 110x 1100 11001xxx 110010xx 11001011 11001011 <--2nd byte is 62%% 1's 0xxx 00xx 001x 0010 00101xxx 001011xx 0010110x 00101100 <--3rd byte is 37% 1's... and then the sequence repeats. Correct? "Set the random source to produce values of [0, 256)." That's how it is currently configured, and produces a messy output. "Most likely, we'll be using the Constellation Modulator block and remove both DPSK and PSK Mode blocks." Ok, good to know. I've updated my flowgraph with the Constellation Modulator block. "Which block exactly? There's the "BER" block from the Error Coding category that comes with GNU Radio" I was using the "Error Rate" block from the Misc category. I've switched to the BER block you mentioned and I get an error rate of roughly 50% with the default settings and then flowgraph still freezes after a few seconds. "You really want to reduce this value (< 10, usually 2 to 4 is good enough) and handle the upconversion for the FHSS in a different way down the line. Basically, keep your sample rate as small as possible for as long as possible." H, looks like I've got some reading to do At any rate, I've attached an updated GRC. In its current configuration, I have constellation sinks showing the output at each block in the receiver. Everything seems to work correctly and you can see the constellation clear up. If I simply disable the Vector Source and Unpacked->Packed blocks and enable the Random Source.the constellation becomes a cloud after the CMA Equalizer. I've fiddled with the sample rates and it seems the constellation significantly worsens somewhere around 6e5-7e5 samplesroughly 10x2^16....I'm not sure what to make of that. -Jason On Sun, Jan 17, 2016 at 1:06 AM, Tom Rondeau wrote: > On Fri, Jan 15, 2016 at 3:59 PM, Jason Noble > wrote: > >> I'm working on a BPSK transceiver/modem. This is meant to be a >> hierarchical block for an FHSS ad-hoc network, but right now I'm tweaking >> some of the settings and testing it on a single frequency. The pulse shape >> should be roughly 50kHz to fit in my 50kHz sub-channels for the FHSS >> system. If the sample rate seems high, it's because I will (eventually) >> combine it with a bladeRF, and the bladeRF's minimum bandwidth is 1.5MHz, >> so I set the sample rate to 3MHz and have been adjusting the samples per >> symbol to get the system working. >> >> I THOUGHT I had everything worked out (flowgraph attached is this >> baseline configuration) until I attempted these changes (these are all >> individual A/B tests compared to the flowgraph). Note: some of the >> disabled blocks require gr-mac. I'm running the development version of GNU >> Radio (GRC states: 3.7.10git-31-gb17bcb88) on Lubuntu Xenial. >> >> 1. This is the most baffling issue for me: if I change the number of bits >> in the vector input to (1,0,1,1,0) or something, basically changing the >> length of the bit sequence before it repeats, the output constellation >> collapses to only ONE of the two BPSK points. Why? If the vector is >> outputting single bits, and those bits go through the packer to make full >> bytes regardless before being output to the next block, why is the received >> signal changing so much? >> > > > The modulator expect /packed/ bytes, so what you are providing it with is > a lot of 0's. With the sps you're using (below), you might only be seeing a > snapshot of a sequence of zeros. > > > >> 2. Likewise, if I enable the random source and disable the vector/byte >> packer blocks, the received constellation is a giant noisy cloud. >> > > Again, probably a packed vs. unpacked problem. Set the random source to > produce values of [0, 256). > > > >> 3. What is the difference between the DPSK Mod block and the PSK Mod >> block with "Differential Encoding" set to "Yes"? Can we get the distinction >> worked into the documentation? >> > > > It's the same, just different representations. We are going to be removing > a lot of this superfluous digital mod stuff in future versions to simplify >
[Discuss-gnuradio] PSK Mod/Demod Questions/Issues
I'm working on a BPSK transceiver/modem. This is meant to be a hierarchical block for an FHSS ad-hoc network, but right now I'm tweaking some of the settings and testing it on a single frequency. The pulse shape should be roughly 50kHz to fit in my 50kHz sub-channels for the FHSS system. If the sample rate seems high, it's because I will (eventually) combine it with a bladeRF, and the bladeRF's minimum bandwidth is 1.5MHz, so I set the sample rate to 3MHz and have been adjusting the samples per symbol to get the system working. I THOUGHT I had everything worked out (flowgraph attached is this baseline configuration) until I attempted these changes (these are all individual A/B tests compared to the flowgraph). Note: some of the disabled blocks require gr-mac. I'm running the development version of GNU Radio (GRC states: 3.7.10git-31-gb17bcb88) on Lubuntu Xenial. 1. This is the most baffling issue for me: if I change the number of bits in the vector input to (1,0,1,1,0) or something, basically changing the length of the bit sequence before it repeats, the output constellation collapses to only ONE of the two BPSK points. Why? If the vector is outputting single bits, and those bits go through the packer to make full bytes regardless before being output to the next block, why is the received signal changing so much? 2. Likewise, if I enable the random source and disable the vector/byte packer blocks, the received constellation is a giant noisy cloud. 3. What is the difference between the DPSK Mod block and the PSK Mod block with "Differential Encoding" set to "Yes"? Can we get the distinction worked into the documentation? 4. When I set the PSK Mod block for Differential Encoding, the constellation becomes a unit circle. If I understand the PSK Demod tutorial on the GNU Radio site, the Costas Loop is supposed to correct for this, yes? But I've put in a slider to adjust the loop bandwidth and it seems to do nothing. 5. If I increase the samples per symbol past ~30, I get the following error: sched: is requesting more input data than we can provide. I had another flowgraph with all of the blocks before/including the pfb configured exactly the same and it ran with sps = 100 just fine. Also, sometimes if I closed GRC and reopened it, it would run with no problems. 6. If I enable the Bit Error Rate block (so I can do something more robust than a cursory visual inspection of the time sink).the flowgraph freezes almost instantly. Thanks for any assistanceI'm really struggling to finish my Master's thesis (<30 days now), and while I can handle troubleshooting/debugging C++ the RF stuff is still immensely frustrating. test3 - dpsk_sch_radio.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Suggestions for C++ Coding of a new PRNG
Marcus, Thanks for the quick response. Based on your feedback, I've decided to look over the GLFSR code, and basically re-write my XORSHIFT code with the GLFSR block as a guidelinenot sure why I didn't consider that before. Then have the output vector read by the FHSS block to generate the correct carrier signal..hmmm, ok. Let's see how long it takes me to write all this. I want to do some testing by next week: the lab I'm visiting has some spectrum analyzers and I want to get real-world data with my bladeRFs before I leave here. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Suggestions for C++ Coding of a new PRNG
So I'm working on an FHSS implementation. I'm using a XORSHIFT PRNG. I wanted to make a GRC block so I can configure certain parameters for the PRNG (seed numbers, total number of hops to generate, etc.). The only output is an array (or vector output?) storing a hop sequence of, for example, 10,000 integers (channels). This sequence is generated once, when the program is initialized. It should then be accessed every time the frequency-hopping block (on the Tx side) or the synchronizer (on the Rx side) needs the current/next channel in the sequence. So, since this block won't be handling streams of samples or even passing messages/PMTs, what block type should I use? Just the generic "block"? I'm not a coder by trade, so figuring out what to put in each of the 3 files (public header, implementation header, implementation source), input/output forecasts, etc. has been a headache. -Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT Freq Sink Display not centering correctly?
So, I first noticed this problem with my main GNURadio install (3.7.5 on Debian Jessie) but I've reproduced it on a brand new 3.7.7.1 live USB. Basically I'm looking at two frequency sinks. One of them centered at 0 and one centered at 16kHz. I have a single signal source input to both sinks, starting at 4kHz but adjustable up to 32kHz. My expectation is that the initial 4kHz signal will display at the far left of the 16kHz-centered sinkbut it doesn't. It displays as a 20kHz signal instead, to right of center. I'm pretty sure that's not WAD...and if it is, can someone explain why? sink-display-error.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: QTGui Number Sink, Demodulation Problems
Tom, Thanks for the quick bug fix Re: the number sinks. In the interim I've been troubleshooting by dumping output to a binary file and discovered other mistakes on my part. But once again I'm at an impasse. I captured some data which I view in the terminal using xxd -b filename. The interesting thing is that the first portion of the file is all 1's " ", which is the correct output that I'm looking for. However, it transitions to outputting "0101 0101 0101" and stays with that output apparently indefinitely. Could this in some way be caused by the Polyphase Clock Sync? Thanks, -Jason On Fri, Oct 17, 2014 at 1:56 AM, Tom Rondeau wrote: > On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble > wrote: > >> >> The purpose of my current experiments is to create a 16QAM transmitter >> and receiver, with UDP sources/sinks, and using bladeRFx40's to >> transmit/receive. >> >> I'm using Number sinks to check values at various points of my flowgraph. >> If I use a constant source value of 1, a float input type to a Number sink >> displays a "1", but a byte input type displays a "0". This is problematic >> because I'm trying to troubleshoot the QAM demodulator which has an output >> type of byte. >> >> I've got Number sinks throughout the flowgraph. The source, modulator, >> and polyphase clock all output correct values for samples/symbols of "" >> but the demodulator is giving outputs of "0". >> >> Are these bugs, or am I doing something wrong? >> Also, I tried replacing the QAM mod/demod blocks with 8PSK blocks and >> still have the save problem. >> >> Thanks in advance for any assistance. >> > > Yeah, this was a bug. Looks like a very stupid mistake on my part. > > I've pushed a fix that mostly works, but we can't really fix it without > breaking the api. It should work fine now for char, short, and float > inputs. There's a note in the block's documentation about this. > > Tom > > qam16_txrx_polyphase_debug.grc Description: application/gnuradio-grc sample-16qamdump.bin Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: QTGui Number Sink, Demodulation Problems
The purpose of my current experiments is to create a 16QAM transmitter and receiver, with UDP sources/sinks, and using bladeRFx40's to transmit/receive. I'm using Number sinks to check values at various points of my flowgraph. If I use a constant source value of 1, a float input type to a Number sink displays a "1", but a byte input type displays a "0". This is problematic because I'm trying to troubleshoot the QAM demodulator which has an output type of byte. I've got Number sinks throughout the flowgraph. The source, modulator, and polyphase clock all output correct values for samples/symbols of "" but the demodulator is giving outputs of "0". Are these bugs, or am I doing something wrong? Also, I tried replacing the QAM mod/demod blocks with 8PSK blocks and still have the save problem. Thanks in advance for any assistance. numbersinktest.grc Description: application/gnuradio-grc qam16_txrx_polyphase_debug.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
