Hi Israel,
can you please try to keep this discussion on the mailing list? It's
just that I'm not the only one who can help you, and certainly not
even the most competent :)
1- I
have a very short distance between USRPs (approximately half a
meter), so I’m surprised that I have so many errors. Besides, in the virtualization environment, it’s
assumed that the channel model is perfect (without channel
noise, frequency offset, timing offset) and, therefore, I
shouldn’t haver errors...but I do.
Well, no matter how short your transmission is, pushing something
through quantization, digital-to-analog-conversion, through mixers,
amplifiers (which might be compressing!), the RF channel,
amplifiers, mixers, an ADC (which might be clipping) and hence,
quantization always has a non-zero noise figure.
I assume with "virtualization" you mean simulation, if I'm
misunderstanding, please correct me.
So, the GMSK demod is designed to give the best possible BER under
certain assumptions. That might mean that under perfect conditions,
it gives more than a 0 BER. (to give you a bit more detail: on the
inside, it does timing recovery, which will solve the real world
problem of unknown symbol timing in a real receiver, but will look
like something's jittering in a noise- and delay-free simulation).
You set your packet decoder to automatic thresholding, which is
fine, but means that it might wrongfully assume a different
threshold for different parts of your sample stream, based on the
energy of the data you're transmitting (in a wider sense, that
should be fine, because JPEG is Huffman-encoded internally, and I'd
hence expect a nice power distribution).
2- Assuming
I always have errors and the packet
decoder will drop any packet it can't properly decode, I find
it odd that the top of my picture is always right. I mean, the
errors should be random and in all transmission tests I can
receive the first piece of the picture correctly (I attached a
example of this)
On the contrary! Assume (that's not inherently the case) that errors
would actually be random, and assume that continued packet detection
errors would require a certain number of bits to be flipped -- that
will very seldom happen right at the start of your observation, but
its probability will increase with the number of transmitted bits;
Bernoulli is nobody's friend.
3- On the other hand, I have added a FLL
Band-Edge block and a Costas Loop block to my receiver
flowgraph, but it hasn’t worked either. Isn't there any
example of transceiver that uses
GMSK modulation (or other, it doesn't matter) and implements blocks against
all these errors in order to I can study how to solve the problem?
FLL Band-Edge and Costas Loops can be used with many constellations,
but one has to be careful not to damage one's own signal when
correcting shifts!
I don't understand your question about there being an example of
GMSK transceiving -- you're actively working with it!
Another, more recent, approach to digital packet transceivers can be
found in the gr-digital/examples folder as OFDM GRC flowgraphs.
These pull a lot more tricks, more explicitly:
* Schmidl & Cox estimators based frequency offset correction and
timing detector,
* channel estimation and separate header and payload equalization
Best regards,
Marcus
On 13.11.2015 15:34, Israel . wrote:
Hi Marcus,
Thank you very much for your quick answer.
I understand my transceiver isn’t very robust, but:
1- I
have a very short distance between USRPs (approximately half a
meter), so I’m surprised that I have so many errors. Besides,
in the virtualization environment,
it’s assumed that the channel model is perfect (without
channel noise, frequency offset, timing offset) and,
therefore, I shouldn’t haver errors...but I do.
3- On the other hand, I have added a FLL
Band-Edge block and a Costas Loop block to my receiver
flowgraph, but it hasn’t worked either. Isn't there
any example of transceiver that uses GMSK modulation (or other, it doesn't matter) and implements blocks against all these errors in order to I can study how to solve the
problem?
Regards
|