F5OEO / rpidatv

Digital Television Transmitter on Raspberry Pi
397 stars 77 forks source link

rpidatv Higher Symbol Rates #26

Closed BevDan closed 8 years ago

BevDan commented 8 years ago

Hello, Thank you for your efforts in making this whole project work. The issue I am currently having when using it in IQ mode, I can not set my Symbol Rate above 1495, when I do the I and Q Signals stop being generated. I see the documentation talks about 125 to 2000 being possible settings, and I was hoping to push out to 5000, but seemed to have found an unexpected limit. I am currently doing the testing on a Pi 3. Regards, Bevan Australia

F5OEO commented 8 years ago

Hi Bevan,

Theorically, it should work at 1.5*32/2=20MSymbol/s but was focused on low symbolrate, I should test it deeply !

2016-07-12 12:59 GMT+02:00 BevDan notifications@github.com:

Hello, Thank you for your efforts in making this whole project work. The issue I am currently having when using it in IQ mode, I can not set my Symbol Rate above 1495, when I do the I and Q Signals stop being generated. I see the documentation talks about 125 to 2000 being possible settings, and I was hoping to push out to 5000, but seemed to have found an unexpected limit. I am currently doing the testing on a Pi 3. Regards, Bevan Australia

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/F5OEO/rpidatv/issues/26, or mute the thread https://github.com/notifications/unsubscribe/AF53RqPxPtt-BmlSh7rNuIpyf1QruIdGks5qU3OVgaJpZM4JKRqX .

BevDan commented 8 years ago

Hello Evariste, Thank you for your quick response. I have done some further testing, I was looking at the code in rpigpio.c and noticed no mention of Pi 3 in the defining of constants ie (#define PI_MODEL_2 6), this got me to wondering if the Pi is was using was part of the problem. I swapped all connections and sd card to a Pi2 and was then able to get a symbol rate of 3807 (still short of the 5000 I was hoping for). The other thing I have noticed, using Minitioune as the receiver it is showing a slight error in the received symbol rate at these higher symbol rates, Pi and Minitioune set to 3807, the apparent measured symbol rate being 3824 (as per attached picture). rpidatv

I hope this little bit of information is of some help to you. Regards, Bevan

BevDan commented 8 years ago

Hello Everiste, I have been doing some more digging into why Ii cant seem to get 5000k symbols to work, I have found I can get 10000k symbols to work.

I have watched the output of the a.sh script and observed a few things, but I need to run them past you as I am still coming to grips with "c" nuances.

In the attached text file there is an output from rpidatv saying "TSrate in byte =-451889" and looking at the code I see that you are calculating an unsigned integer, is it the code of "1166 printf("TSrate in byte =%d\n",TSRate);" that is displaying the unsigned integer as a signed integer, or is the value of TSRate really negative?

When using the 5000k symbol rate and not getting any modulation of the IQ pins, it appears that code never gets past this area as I don't get to see the "End Init Filling Memory buffer" at line 1189

1174 while(BufferAvailable()<(TSRate/10)) // 1/10 SECOND BUFFERING DEPEND ON SYMBOLRATE 1175 { 1176 printf("."); 1177 usleep(500); 1178 } 1179 /* 1180 int NbByteInitRead=0; 1181 pthread_mutex_lock(&my_circular_buffer.lock); 1182 while((BufferAvailable()>TSRate)&&(NbByteInitRead%188!=0)) 1183 { 1184 read_from_buffer(); 1185 NbByteInitRead++; 1186 } 1187 pthread_mutex_unlock(&my_circular_buffer.lock); 1188 */ 1189 printf("End Init Filling Memory buffer %d\n",BufferAvailable()); 1190 }

What are your thoughts, am I on the right track or barking up the wrong tree?

rpidatv 5000k.txt

F5OEO commented 8 years ago

Thx for analysis. Check if commit https://github.com/F5OEO/rpidatv/commit/8da76b5b5bb673000b2499742977fa4a53ffd6d0 solve the issue

BevDan commented 8 years ago

Hello Everiste, The fix works, thank you very much. A few things I noticed: At higher symbol rates not all source options work, particularly the pattern source gave no output at 5000kSymbols. When I made the project it gave a couple of warnings which I thought were going to cause an issue but thankfully didn't. I have attached the warnings that I saw. Error Log for new install.txt I am finding that there seems to be a little bit of glitching when outputting the IQ modulation, but haven't gotten to the source of this problem and is more noticeable when using the IPTSIN option. Also I changed the IQ pins I wanted to use in a.sh, however I was confused by the options of GPIO 40 and 41,45 as they don't appear on the PI's GPIO port? Regards, Bevan

F5OEO commented 8 years ago

For GPIO 40,41 and 45 : https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/Raspberry-Pi-Rev-2.1-Model-AB-Schematics.pdf

GPIO 40 and 45 were used with old version Pi B by soldering on sound output on Rpasberry PCB.

About gltching try in /boot/config.txt disable_pvt=1 force_turbo=1

And see if it is better.

BevDan commented 8 years ago

Thank you Everiste, Making those changes brought slight improvement to stability, when using the PiCam as the source the output is perfect. I still have some experimenting to do with getting the IPTSIN to work better, May I ask what your method of generating a IPTS is. I am currently using vMix as my video / audio source and then ffmpeg to generate a UDP stream that I found on the web (by Alain Fort F1CJN march 2016). Since the camera works well, I am thinking I have a buffering / network delay issue. I have also moved back onto a PI3 and found that with this new version of rpidatv that it works at 5000kSymbols, but still have issues with the IPTSIN breaking up. I have not done so yet, but was looking at installing your rpitx software to use as a vco when working with up convertors, however after having a quick look at the code I am thinking you are using the same hardware to do the modulation for rpidatv and therefore the two programs could not operate on the same Pi at the same time, am I right in thinking there will be a conflict? Once again, thank you for you help and for this neat rpidatv. Regards, Bevan

F5OEO commented 8 years ago

About IPTSIN : it should be a Constant Bitrate stream...as mentionned to F1CJN, his script does not produce this : as a result there is some issue with buffering with variable bitrate. Moreover, having workig a lot with ffmpeg, conclusion is that even in CBR it doesn't produce a compliant CBR transport stream. I just worked with libmpegts which does a great job. I use it now with the camera, but I could maybe adapt it to work from IP input (other format that TS : rtp or equivalelent).

About rpitx, yes, it uses the same harware, but no issue as soon as you don't work both at the same time.

2016-07-31 15:11 GMT+02:00 BevDan notifications@github.com:

Thank you Everiste, Making those changes brought slight improvement to stability, when using the PiCam as the source the output is perfect. I still have some experimenting to do with getting the IPTSIN to work better, May I ask what your method of generating a IPTS is. I am currently using vMix as my video / audio source and then ffmpeg to generate a UDP stream that I found on the web (by Alain Fort F1CJN march 2016). Since the camera works well, I am thinking I have a buffering / network delay issue. I have also moved back onto a PI3 and found that with this new version of rpidatv that it works at 5000kSymbols, but still have issues with the IPTSIN breaking up. I have not done so yet, but was looking at installing your rpitx software to use as a vco when working with up convertors, however after having a quick look at the code I am thinking you are using the same hardware to do the modulation for rpidatv and therefore the two programs could not operate on the same Pi at the same time, am I right in thinking there will be a conflict? Once again, thank you for you help and for this neat rpidatv. Regards, Bevan

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/F5OEO/rpidatv/issues/26#issuecomment-236429157, or mute the thread https://github.com/notifications/unsubscribe-auth/AF53Ro1fcT2nwG5cg2sub02n9iTAnVJtks5qbJ76gaJpZM4JKRqX .

BevDan commented 8 years ago

Hello Everiste, I have now successfully done a DVB-S transmission to our local DATV repeater (VK5RDC about 55km away) on 1275Mhz @ 5000kSymbols, using a TS file that I created using VideoRedo from a MPG file recorded from a Hauppauge Win PVR. It took a while to get the stream perfect as the older Humax receiver at the repeater is very pedantic about the stream it sees, where as MiniTioune was able to display most streams I sent it. So now I will spend some time trying to get the right combination of software on my windows 7 pc in the hope of getting IPTSIN working as being able to produce real time video and broadcast it would be the ideal situation. Thank you very much for your help and code variations. Regards, Bevan

BevDan commented 8 years ago

Hello Everiste, I am having a look at the libmpegts that you mentioned previously, but I am having trouble locating documentation about what the command line should look like, do you have some documentation available, or am I simply looking in the wrong places. Regards, Bevan

F5OEO commented 8 years ago

Hi Bevan,

Libmpegts has no command line as it is a library. Don't know if it works under windows. Think of an other method : stream a NON compliant stream with ffmpeg for example and the raspberry transform it as a compliant stream to go rpidatv. Not yet implement ! Happy that high bitrate work !

2016-08-14 13:35 GMT+02:00 BevDan notifications@github.com:

Hello Everiste, I am having a look at the libmpegts that you mentioned previously, but I am having trouble locating documentation about what the command line should look like, do you have some documentation available, or am I simply looking in the wrong places. Regards, Bevan

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/F5OEO/rpidatv/issues/26#issuecomment-239668967, or mute the thread https://github.com/notifications/unsubscribe-auth/AF53RkSOo2DxaEcuSU0s-WIvU4gbc5xyks5qfv2OgaJpZM4JKRqX .

matiaspl commented 8 years ago

It might be possible to use OBE (Open Broadcast Encoder, not to be confused with OBS) - it's commandline and uses libmpegts for creating DVB compilant UDP streams. I know the author of OBE already experimented with using OBE on a RPi with wifibroadcaster software and had some success.

Matt