Looking for best way to tx DATV from PC

[G8XPZ]

Hi
After trying to tx a UDP stream from my portsdown via my limemini I have found the video to be very slow although it is normal on the UDP monitor on the Portsdown 4.
Therefore I have been trying to find the best way to transmit DATV from my PC (presumably it will have better response)

I have so far tried:
DATV easy v2.17 and v3 - both start tx then shutdown.
DATV Express which crashes when I set it to tx.

So I have decided to try SDR Angel. Got to the point where when I try tx it appears to be transmitting but getting bogged down. Has anyone got tx working on SDRAngel and a config would be great.

Thanks
Steve G8XPZ

[g8lce]

You mean TX DATV from PC to Limemini.
Windows PC to Pluto would be OBS, vMix or SDR Television Beta #5 in my case. (SDR Television also receives)

Martin G8LCE

[g0mjw]

I don't think many people are using the Lime mini with a PC. I am assuming Windows rather than Linux. At some point, SDR Television may support the Lime but not yet. Most are using the Pluto, which is a much easier solution these days.

You should be able to do what you want with SDR Angel or Gnu Radio. I think your problem is probably not getting the transport stream rate right. You could use DATV Easy but it is probably better to use FFMPEG to generate a transport stream with the correct rate and right number of nulls. This gives you more control, but requires more thought. I see you are using 1/2 FEC and 333ks. That means the target bit rate for the transport stream will be 330 kb/s.

Download the FFMPEG executable ffmpeg.exe from https://ffmpeg.org/download.html and put it somewhere useful, e.g. c:\ffmpeg\bin

Here is an example batch file. Copy and paste it into notepad, save as .bat and click on it. It should generate a test mpeg2 transport stream at 330kb/s and send it to localhost port 1234.

c:\ffmpeg\bin\ffmpeg -f lavfi -i testsrc2=640x384:rate=15 -f lavfi -i "sine=f=512" ^
-vcodec libx264 -s 640x384 -bf 0 -pix_fmt yuv420p -r 15 -preset slow -profile:v main ^
-x264-params "nal-hrd=cbr" -b:v 220k -minrate 220k -maxrate 220k -bufsize 100k ^
-acodec aac -aac_coder twoloop -ar 48000 -ac 1 -b:a 32k ^
-f mpegts -muxrate 330k -streamid 0:256 -streamid 1:257 ^
-metadata service_provider="Mycall" -metadata service_name="MyName" ^
-pcr_period 40 -pat_period 0.4 "udp://127.0.0.1:1234?pkt_size=1316"
pause

You can test this with ffplay. From a command line:

C:\ffmpeg\bin>ffplay udp://127.0.0.1:1234

Then send it to SDR Angel.

Breaking it down:

c:\ffmpeg\bin\ffmpeg -f lavfi -i testsrc2=640x384:rate=15 -f lavfi -i "sine=f=512" ^

This is your input. Normally it would be a camera and a microphone, or perhaps the OBS virtual camera and virtual microphone.
e.g. I am using c:\ffmpeg\bin\ffmpeg -f dshow -i video="OBS-Camera" -thread_queue_size 512 -f dshow -i audio="OBS-Audio"
these will typically be direct show inputs, hence the -f dshow which indicates the directshow filter.

The next part is the video encoding - this can be a lot more complex and call on nvidia or lightspeed hardware encoders. The example is H264 but many are using H265 if the CPU is up to it because the results are much better. Some are even using H266.

-vcodec libx264 -s 640x384 -bf 0 -pix_fmt yuv420p -r 15 -preset slow -profile:v main ^
-x264-params "nal-hrd=cbr" -b:v 220k -minrate 220k -maxrate 220k -bufsize 100k ^

As we are sending over a link with a fixed bit rate, we want the encoder to work at a constant rate. It is a low rate, so the frame size is small and the frame rate is only 15 frame per second. The second line is telling the encoder to use a constant bit rate. The buffer is to allow it to do this within a window. A large buffer makes this easier, but also increases latency.

This encodes the audio, with the advanced audio codec encoding to 48k (vs 44.1k) and at a bitrate of 32 kb/s.

-acodec aac -aac_coder twoloop -ar 48000 -ac 1 -b:a 32k ^

You can reduce that audio rate or even not send audio at very low symbol rates. If you have the bandwidth, you can have high quality audio in stereo, but you don't, so don't as the image will suffer.

finally, this is creating the mpeg transport stream at a rate of 33ks/s for your 333ks FEC1/2. The metadata is normally your callsign and name.

-f mpegts -muxrate 330k -streamid 0:256 -streamid 1:257 ^
-metadata service_provider="Mycall" -metadata service_name="MyName" ^
-pcr_period 40 -pat_period 0.4 "udp://127.0.0.1:1234?pkt_size=1316"


Mike

[G8XPZ]

Hi - Thanks to both of you for the quick replies.

I think that SDRTelevision looks like the best route for me as it looks like the ground work is already done.

So this morning I have loaded SDRTelevision Beta#5 and got it connected to my LimeMini as below.

Next need to get to grips with it.

Thanks again
Steve
G8XPZ

[G8XPZ]

Hi
After studying SDTTelevision I have reached the point where I can see tx/RX using loopback but when I try to TX on my limeMini it fails. Can anyone see the problem please?


Steve G8XPZ

[g0mjw]

The reason I didn't simply mention SDR Television in my earlier detailed response is because as I said at the beginning, I was not aware it worked with the Lime Mini. From the manual:

Chapter 8 Using A Radio
If you only want to receive DATV then use any SDR which receives at the required frequency. If using
a LNB then you must take the LNB offset into account.
 RTL Dongle v4 – usually good for bandwidths up to 4MHz.
 Airspy R2 – maximum bandwidth 10 MHz, usable 8.5 MHz.
 SDRplay – maximum bandwidth 10 MHz, usable 8.5 MHz.
 LibreSDR – maximum bandwidth is 18MHz over ethernet, 8MHz using USB.
 …
For transmit, only the ADALM Pluto and LibreSDR are supported, LibreSDR is based on the Pluto
design. Other SDRs such as Lime USB and Mini will be supported later.

So as you can see, it is not yet a solution for the Lime Mini. Given the high cost of the latest Lime Mini, I can't see it being used much in future and would recoomend the Pluto or LibreSDR as a replacement. The Lime does work well with the Portsdown 4. You might be able to get it to work with SDR Angel for TX if you generate the transport stream as I described earlier.

Mike

[G8XPZ]

Hi Mike
Thanks again for replying - I bought my lime mini when it was crowd funded so got it "fairly" cheap. May buy a pluto if the lime mini tx doesn't get added to SDRTelevision.
Reference the FFMPEG coding you sent me - I must admit it kinda scared me seeing it written down but I think it might be worth a try as you've already done the hard graft.
I let you know how I get on.

Thanks
Steve
G8XPZ

[G7VVF]

Hi Steve,
you should be able to use the LimeSDRmini with DATV Easy. I have an older LimeSDRmini (not v2.0) and today I was able to transmit with it using DATV Easy v2.12 and v3.08, though I had some issues using 3.08 and had to re-install it to get it working.

Success depends on the power of your computer and what encoding method, as an example these are the findings I made this afternoon.
I was using an I5 6th gen PC running win10. The advantage of a 6th gen I5 or I7 is that the on-board graphics processor can encode H265.
Today I didn't use the on-board graphics as I have a Nvidia GTX 1050TI to do the H265 encoding installed in my PC.

1000 kS/s FEC 2/3 H264 soft encoding, it struggles with this and would freeze and drop frames.
333 kS/s FEC 2/3 H264 soft encoding works well

333 kS/s FEC 2/3 H265 soft encoding it struggles with this and would freeze and drop frames

333 kS/s FEC 2/3 H265 Nvidia encoding works well
1000 kS/s FEC 2/3 H265 Nvidia encoding works well

You should get similar good results with Intel encoding if a 6th gen I5 or better.

Also this afternoon using the same PC I was able to transmit 1000 kS/s on 1249MHz into GB3EN using DATV Easy and Lime and at the same time and from the same PC transmit 333kS/s H265 into QO-100 using DATV-NotSoEasy and a Pluto., the program source was the same as was coming from OBS.

hope that helps

Duncan G7VVF