Been having a hard time lately getting a TCP Source (Client) packet to be received by a File sink. I have tried countless of ways just to lead me on a road of more confusion. Using GNURadio V3.9.5 on Ubuntu.
The main goal is to send a TCP Packet to be received by GNURadio’s TCP Source (client) and have that packet be modulated into a GFSK then packaged into a 2.4GHz via the LimeSDR Tx then to be received by the LimeSDR Rx and then demodulated into a File sink to be read by a user.
If I use a File Source instead of a TCP Source I can see the contents inside the File Source at the File Sink (Bottom) but with using a sample/symbol of > 4
The File sink with OutputFile2.txt (Top) can see the packets coming from TCP Source whereas the File sink with OutputFile.txt (Bottom) can’t. Is there something going on with the transmission then? If it works without LimeSDR Tx/Rx what does that mean?
Any help would be appreciative as I am stuck and very new to this. I tried countless of times to search about anything on this topic but it seems theres a lack of examples when it comes to TCP + GFSK
First, you may be starving the TX chain with the TCP source - the TCP source may not be delivering enough bytes to keep the TX busy, and you are getting gaps. The file source can deliver as many bytes per second as needed, so it would not underflow. Are you getting any underflow messages?
Second, you probably need to have more samples per symbol for the shaping filters in the GMFSK to work well. In the work I’ve done, I usually want at least 8 samples per symbol, so that RX has enough adjustment to sync up.
@N0YKG Thank you so much for the reply. That would make sense as I had suspicion about the TCP Source not sending enough data or not sending at all.
I dont believe if I am getting an underflow message as I am not entirely sure as no error message as I can tell is present. If there is one would be presented, would it be in the console?
Fair enough, I still dont understand how one can pick a sample/symbol as its still unknown to me, I
know a little bit as it can be related to baud rate but thats it for me. Why/how do you pick 8 to be your sample/symbol?
With that said, is there a way to maybe buffer the TCP Source so it can send a stream of data? If not is there a way to repeat the TCP source?
Once again thank you for the reply, I am extremely mind stumped on this haha, thank you.
Picking the number of samples per symbol is a trade off between computational power needed and accuracy of representing the signal. The more samples on transmit, the better the system can filter the signal to remove unwanted out of band energy. The more samples on receive, the better the receiver can adjust for any timing error and find a sample closer to the ideal time to measure. Like many things in life, there comes a point of diminishing returns, so you try to find the point where more samples doesn’t really help. That can be done by mathematically modelling the impact, or by experience and empirical testing. My experience is that 8 samples/symbol is the point where the filters are removing better than 60dB of unwanted bandwidth, where the receiver gets close enough to ideal sample time that noise on the channel has little impact on the bit error rate without costing too much in CPU time.
Also: samples per symbol has nothing to do with symbol rate (baud rate), other than if you are running 9600 baud, and you are running 8 samples/symbol, then you are running 76800 samples per second, because 8*9600 is 76800. Baud is set by the protocol (how many bits of signal per second need to be transmitted) and the modulation scheme (how many bits of information does each symbol represent). GMFSK is 1 bit per symbol; other modulation schemes may differ, such as QPSK which has 2 bits per symbol.
Lastly, as to the underflow messages - it’s been a while, but I believe the LimeSDR block will report if the transmitter is underflowing, so look at the output from it on the console.
