Your send and receive a file may work with the new routines - try it. As far as TCP packets that depends upon what version of gnuradio you are using - some versions do not work with TCP/IP.
It does! Thank you received file sink and source no problem now, the original application was suppose to be with TCP but never got that working. Is there any alternative to use TCP packets?
If you are using gnuradio 3.8, you can use my TCP/IP routines. I have not yet updated them for gnuradio 3.9 or 3.10 - they broke everything with gnuradio 3.9 the idiots !
The TCP/IP routines comes with the "Impulse Source " stuff.
Using gnuradio and the Impulse Source to Show Filter Frequency Response
I have not be able to get the gnuradio TCP/IP routines to work - they are written using the QT5 routines and do not seem to work using the standard TCP/IP routines. They do not work in server mode - I have not had a chance to try them in client mode.
The UDP routines were working, but I think that they have broken them also.
Thank you for the insight, just some follow up questions. When my receiver outputs a PWM looking waveform does that always mean my Tx signal is too low?
I am just playing around with my Gains for both the Tx and Rx and what makes the condition to receive a duplicated Tx signal? I am still having a hardtime trying to find another combination of the multiply constant and the Gains for both the Rx and Tx
A PWM looking receive waveform would most likely mean that the Tx signal is too high.
Getting the gains with the bladeRF was not problem, but when I tried the HackRF One it was really picky and worked with only a small range of values.
You should try your TCP/IP routines with the gnuardio, may be they are likely different from mine and they may work. I could set their server listening on a port, but when I tried to connect - it connected to the address, but the gnuradio server never accept the connection on the port.
I see, yeah I can see the gains being picky.
I went ahead and tried out the TCP/IP routine and it looks I am receiving it, however I need to send it multiple times to receive the data, is there anything I can do about this?
What are you sending it with ? TCP/IP has a guarantee on data transfer - so the only likely reason that you would need to send it many times is that one of the programs is putting the data into a buffer and it is not transferring the data until the buffer is full.
Try sending a lot of data and see if that works.
With a TCP Source as a Client. I see, ill further look into the buffer, where would I alter the buffer on the tagged stream or the tcp client
The original version of the tagged stream is doing 50 character blocks. The TCP Source - do not know
ah I understand, ill play around with it and report back
I have been moving files. The OFDM routines have a problem - they loose about 10 percent of the data.
If I directly read a file and sent it or if I bring in a file using the TCP routines it looses the data.
If I directly read a file and use the completely internal loop back - it still loose about 10 percent of the blocks.
Are you seeing this ?
Hmmm, I mean I did see some packets drop from sending from a file but I am not sure if thats due to the lack of optimization from the transmitter and receiver end. When it comes to the TCP I cant never get the first bytes being sent, I always have to repeat the message a couple of times but then again I am not sure if thats me with an incorrect settings somewhere.
I finally got gnuradio do transfer files correctly it only loses the last 2 bytes. I transferred files from a Windows 10 machine with a BladeRF to macOS Monterey with a RTL-stick. The grcs -
Beautiful Thank you, ill give it a look. Thank you so much for the on-going efforts!