BATC Forum

Hello guys!

What a great idea using the RPI 3 in this way.

So now I have my PI 3, downloaded the code and attached some video devices.

I am using my Logitech C525 webcam with less than desirable results, but it does capture video. Using the PI camera both look perfect on the viewfinder.

Looking at the transmitter on my STB is another matter completely.

I have done some investigating, here is what I see.

All video is being rendered at 720x576 @ 25 fps.

PAL/NTSC mode switching does not change this.

Here in the USA, we use 720x480 @ 29.7 or 30 fps. Our monitors and TV Sets are designed around this format. I have been looking through the Portsdown code and I see alot of embedded code, plus .txt config scripts that are heavily embedded with PAL coding.

My issue is very jerky audio from any source. EasyCap device configured for NTSC and standard a standard video camera work, but with very poor results. Pi camera in MPEG2 works a little better. Pi camera in .h264 mode is less than desirable.

I have multiple receivers from different manufacturers all produce a similar result.

I have already printed out all the source code from all the programs that run. I have identified all the locations where a testable selection could be made to switch from PAL/NTSC modes.

So my questions are these:

1. Do the Portsdown Tx users get good performance outside of the USA as compared to the DATV EXPRESS?

2. If I go in and add the proper frame size and frame rates for NTSC in the .txt files and add some code in other areas, will this resolve the issues I see with jerky and slow response with the audio.

I have the time and bandwidth to do this

3. I will submit my code so that is can be incorporated into any future builds, but will it be included?

As we all know, once I fork this without back end support, new updates and changes will wipe out all the work I am doing.

I have not seen a PAL system in operation so I don't know how good the video is.

I do have my DATV EXPRESS running perfectly with Linux and Windows. I am attempting to achieve the same level of performance from the PI 3.

I think this project has tremendous potential. So a little insight to the genius minds that created this would be a big boost.

You guys are light years ahead of us hams here in the USA.

Thank you for this project!

Hi Ron

I started drafting you a comprehensive reply, but then ran out of time. I'll answer your questions in the morning.

In the meantime, please could you tell me what SR and FEC you are testing with? And also what modulator are you using?

Dave, G8GKQ

Hello Dave!,

We used the Portsdown Filter board and the DATV Express for these tests. Different PI computers were tested.
We tested an X2 DVB-s Reciever and an AV2018_S2 model 3 ver. 6 receiver. Both receivers were cheap EBAY units.
Both units work perfectly fine when the DATV Express is transmitting from Linux or Windows. The USB cams and EasyCap combinations work with vMix and DATV Express. I am ruling out hardware issues

The FEC tested was:
1/2 @ 1000 sr
2/3 @ 1000 sr
3/4 @ 1000 sr
5/6 @ 1000 sr
7/8 @ 1000 sr

1/2 @ 2000 sr
2/3 @ 2000 sr
3/4 @ 2000 sr
5/6 @ 2000 sr
7/8 @ 2000 sr

1/2 @ 4000 sr
2/3 @ 4000 sr
3/4 @ 4000 sr
5/6 @ 4000 sr
7/8 @ 4000 sr

All modes tested with the PI cam and the webcam, logitech c525 and the EasierCap unit with STD video input.

As a side note, when we put this thing on the air, we were transmitting in color, but the repeater receiver displayed a black and white
picture.

My question is why is the transmitter supposed to be locked into the 720x560 @ 25fps even when NTSC is selected?

Hi Ron

All the SRs and FECs that you listed should (and do) give smooth colour pictures. Things get a little blocky and jerky at 500 KS and below. In fact, with the PiCam and a receiver with an HDMI monitor, the pictures at 4MS look really good.

I would be the first to accept that the TS coding in the Portsdown is not perfect, but it seems to work with most full-spec DVB-S receivers. As background, the TS coding and conversion to IQ signals is performed by rpidatv and avc2ts, both of which were written by Evariste, F5OEO. My policy has been to help him with the development of these modules, but not to make any changes myself. His original repo for these modules is at https://github.com/F5OEO/rpidatv, although I seem to remember that the latest code incorporated in Portsdown has been e-mailed to me directly. Evariste is undertaking further development of avc2ts here, but I am not currently tracking what he is doing.

My role in the project has been to put a robust control and operating environment around these 2 modules and maintain configuration control so that Linux newbies can use the code with confidence. So I have made major updates to a.sh (the shell script that calls rpidatv, avc2ts or ffmpeg) and menu.sh and rpidatvtouch.c.

If you were to suggest worthwhile changes to any of the code that I maintain I would be happy to fold it into the main codebase. Changes to rpidatv or avc2ts are a little more tricky. I would like to stick to my policy of not changing Evariste's source, so it might be better to suggest the changes to him (copy me). My development code is at https://github.com/davecrump/rpidatv, although the production code is currently at the same standard.

To address your specific issues:

It is not PAL that is hard-coded into the source, it is a picture height of 576 pixels. Width varies between 704 (the H264 encoder needs a mod 32 width) and 720 (for MPEG-2 from ffmpeg). This is well within the DVB-S spec - it's just that many US-marketed receivers do not implement the full spec (however the cheap Chinese ones that I bought during my last visit to Abu Dhabi work perfectly...). Same issue for 25i vs 29.7i/30i. I would be prepared to change this hard-coding in the future, but I was more thinking of going up to 720x1280 25i pictures from the pi-cam rather than down to 480x720 29.7i.

The NTSC selection simply changes the capture configuration on the EasyCap. Once the image is being handled by the v4l2 module, it is resized to the transmitter defaults.

The audio only currently works in CAMMPEG2 mode ("released capability"). Not sure if you have had audio with Analog capture or your webcam, but this is not a released capability as it has some issues that I have not resolved yet.

So, in summary it is all very much a work in progress, but the "released capability" should work well. I have not blocked off the "unreleased capability" exactly because I would welcome the help of guys like you to get it up to standard. Please discuss your proposals here, and we'll work together.

Dave, G8GKQ

Hi Ron

The black and white issue has been seen before in the US: http://www.batc.org.uk/forum/viewtopic.php?f=103&t=4869

Dave