In-Reply-To=
dc0a76d8-72e5-06c4-2c93-ecb59daf2091@gnuradio.org">
dc0a76d8-72e5-06c4-2c93-ecb59daf2091@gnuradio.org
I hope it would be possible to leave the walls undamaged and brain normally percolating, but it appears circumstances do not allow it.
The frequency spectrum of the transmitter appeared to be suitable enough with energy decreasing beyond +/- f/4 some 50 or 60 dB. Similarly, the spectrum at the receiver after the filter seemed ordinary with only the 60 dB or so below peak removed. The constellation at the input of the constellation decoder appeared to be the expected fairly sharp two points along the x-axis. And yet, the output was obviously garbled.
Some progress has been made (see file attachments) but success is still not achieved.
Two hard lessons (etwas durch persönliche Erfahrung lernen oder entdecken, insbesondere das, was schwierig, schmerzhaft oder unangenehm ist) of note:
1. using a Message Debug block seems to guarantee losing control of grc where grc no longer responds to user input and a CPU spins at 100%. "Force Quit" is the way to regain control. It is best to run "top_block.py" directly in a Terminal Session when Message Debug is enabled.
2. please observe the pair of Frequency Sinks used in the first sections of the transmitter. I report that if this pair is replaced by a single Frequency Sink with 2 inputs, the transmitter immediately behaves as if there were no signal modulation! The two bit BPSK constellation collapses into a single bit at the origin of the constellation.
One can no doubt imagine the amount of productive time lost to the issues just described.
I can report it is easy enough to create a <header><payload> construction for transmission but the blocks which should remove the <header> and deliver the <payload> do not seem to behave as expected. I have now a flowgraph which accurately delivers <header><payload> made from scratch all the way to the receiver output prior to any attempt to remove the <header>.
Am I supposed to use a Delay Block to time-align the <header> detection with the data entering the Header/Payload Demux? If so, this is not shown in any part of the GNU Radio documentation or in the grc examples in the GNU Radio repository.
= 1001001 =
Hi Chris,
please, keep the walls intact and your brain operable.
Hm, I've not looked too deeply into this, but:
2 Samples per symbol means that your bandwidth should be at least
samplerate/2, and you've in fact got excess bandwidth. What does the
frequency sink on transmitter side say?
On the receiving side, you filter to samplerate/3, which is less!
Then, this has no framing, so its impossible for the receiver to know
whether something it received is the first bit in a byte!
Still a bit peculiar that you're still getting valid ASCII, no doubt.
Best regards,
Marcus
modem2b.pdf
modem2.grc