All best John
Your settings really helped me get going. I haven't tried the amended setting, but with the old one, I can get up to 250ks working really well with IPTSin.
Will try later this evening with the new setting and report back.
I think I'm still in the same position as before with regards to keeping the signal going. For anything 250ks or above, the signal just dies outs after some time. For 250, it maybe last 1 or 2 minutes, for 333 it last only a few seconds. Before the signal fails, all is working well though!
125 and 66 work well, although I do wonder if I left them running long enough would they also stop...
I assume you're not seeing the same. Are you using an older version of Portsdown? I think these issues were introduced in a recent release, due to some changes with Lime's API
It's been a great evening.
All the best for now John G7JTT
Indeed, it is possible that the UDP stability could be better in Linux. I must try that sometime with a separate Linux box (another pi?!)
Do you know what the story is with the 2 versions of dvb2iq ? My understanding is that dvb2iq2 is the older version that was deprecated due to some changes with the Lime firmware. However, it still works, so I'm keen to understand if there are any drawbacks in using it. Could it be that the Lime API that dvb2iq2 is using is deprecated by Lime, and may be removed in a future version of the firmware?
On a separate note, I managed to get my Portsdown (using IPTSIN) to stream content to my commercial satellite receiver (£20ish from ebay). As long as the bitrate and symbol rate is high enough, it works quite well! For me personally, this is a real happy achievement, as what started my DATV projects was: "wouldn't it be cool if I could get a commercial satellite receiver to tune into something I've modulated?"
All best John
I now have a stable signal with IPTSin in the portsdown, the main thing for me as a windows user was that FFmpeg was using w32threads which according to this web site has know issues when used with UDP ( https://github.com/jaskie/Server/wiki/C ... ort-stream ). If you look in section 2 on that page there is a download that has both the w32threads and pthreads, download the file and copy the pthreads to your ffmpeg directory as instructed and thats it. It cured all the drop outs and PA pulsing that I'd experienced. The only other thing I did was to go back to using the original basic.ini file with just one addition to the file path/url "udp://22.214.171.124:20000?pkt_size=1316&bitrate=495700". Note that this is entered without the quotes and the number at the end is the muxrate for the SR/FEC your using. There is also a line that can be changed in the portsdown software but I found that this made little difference to me once I wad using the Pthreads with FFmpeg. And lastly if there is one thing I've gained from all this, is that there are so many variables when setting this up that what may work well on one set up may not work so well on another. So use this as a starting point and play with the settings until you have it working perfectly on your system, good luck.
All the best John G7JTT
I'm glad things are working well for you now! I have a couple of questions:
1) In a.sh on the portsdown, are you using dvb2iq (the new binary that's in use by default), or dvb2iq2 (the old one)?
2) are you changing the ffmpeg binary that OBS uses? Or merely the intermediary step binary?
3) when you say you reverted to the basic ini file, are you no longer setting the video bandwidth, or enforcing CBR mode ?