For the meantime I am running 2 Pi on BATC for vk3rtv-1 and vk3rtv-2.
I have noticed that if I delete the call sign data or add a couple words into the callsign setup box that the graphic jpeg file stops running and just outputs the black and blue portsdown screen, not sure you were aware of this feature or not. ?
Is there a spot to add comments / issues with Stretch on the forum, rather than have it on this thread ?
Id be keen to hear if your mate who has the easycap issues is using an STK1160 or not.
The Caption (and hence video generation) does not work if there are spaces included in the field. Already documented here https://wiki.batc.org.uk/The_%22Portsdo ... imitations. I wasn't aware of the "deleted callsign" problem though. The solution for this would be to disable the caption instead.
Comments for Stretch should go here: viewtopic.php?f=103&t=5438
The other guy with slow RPi issues is using a Webcam that works for me but not him.
Just a quick one, Im now using the BATC supplied USBTV007 easycap dongles, not having much joy though, voltages are on spec, I find that the audio and video are fine for about the first 15 seconds, then the audio breaks up, then the video starts to drop frames and then although there is still a stream up it is not usable. Have you seen this behavior before.? The supply voltage is stable so can rule that out, i'm thinking a lack of processing resource.?
I have tried some setting changes to the -vf string at line 1256 but not really helping. I know Im not the first person to have this issue, Im sure it's been seen before... Running PI 3, Stretch
Once I get this sorted they can go to the repeater site, YA !
At the risk of jumping in before the oracle, I had lots of problems similar to yours with a basic Portsdown configuration for repeater streaming. It was all cured by feeding it with 5.2V and that was via the GPIO pins that bypass the lossy polyfuse (I fitted an external wire fuse). Try using a variable psu and gradually increase the supply voltage and it may cure the problem if you are only feeding it with 5 or 5.1V.
73 Shaun G8VPG.
Please confirm that you have the dongle plugged directly into the RPi (at least for testing)? The supplied cable is worse than useless - I've even thought of removing them before shipping!
As Shaun says (thanks!), the supply voltage is critical - try measuring it with a DVM on the USB ports. The pins (the outer 2 of each set of 4) are quite easy to access underneath the board.
Lastly, what is the upload speed of your internet connection?
This little problem has almost got me beat.!
Last things first, the internet connection here is a minimum of 25Mbps up and download speeds, so that can be ruled out.
I have hard wired my power source to my Pi, have measured the USB and GPIO pins during streaming and the voltage ia between 5.0 and 5.1v
The capture dongle is directly plugged into the Pi. The fault presence itself on any USB port.
I have two complete sets of capture dongle (BATC Supplied), Pi, Power, micro SD card with the same build on it and the fault is the same regardless.
The version Im running is...... Portsdown DATV TX Version 201804060 By F5OEO and the BATC Team
The stream runs fine for approx. 15 seconds and then the audio goes away, sometimes the video breaks up also, makes me think a buffering issue or similar..?
To satisfy my curiosity I will do an online upgrade to make sure that Im running the most current release.
Im sure this little bug in my system was sent to test me (us)
Once you have updated the software, please could you run the RPi with 2 Putty windows open. In one window start the streaming using the console menu. Once the streaming fails, stop it. Then in the other window (which should have the Linux prompt) type the command
Code: Select all
Code: Select all
Next, in the second window type
Code: Select all
I'm running out of ideas after this.....
Well, Well, Well.........
I'll provide as much info as I can so that others don't have the same issues that I have had, I apologise in advance if it has been posted elsewhere.
To achieve success I had to do the following.
Hardwire the power supply to my Pi.
Setup the supply voltage to at least 5.5v on the input at a minimum of 1Amp, so as to achieve 5.0-5.1v on the USB port during streaming.
Use only the BATC supplied type of EasyCap dongle (Fushicai USBTV007), plugged directly into the Pi.
I know it sounds simple but the Biggest trap I came across was a tiny bug in the software that has caused me a lot of man hours in searching, but now I have found it I am sure it will be exterminated quickly..
The bug is associated with "System Setup" and "Automatic Starting" setting. Up until today I have been setting this to enabled so that during testing I would not have to keep manually setting the stream to run every time, this way on every Pi reboot it automagicaly starts streaming, However !
When I use this option my stream runs for approx. 15 seconds then losses audio and occasionally the video breaks up, I have been able to replicate this fault with a 100% hit rate.
When I start the stream manually after boot all is well.
I must say that using the vcgencmd did help in proving and confirmed any suspected power issues and the htop util also determined the CPU usage was generally within spec too.
Thankyou for all of your help on the issue Dave and Shaun, Once we get the VK3RTV repeater up and running in it's new location the streaming will be done using the Portsdown Pi project.
I would be keen to hear if you are able to replicate this fault on your system/test setup.
I'll keep you posted.
Thanks for the thorough write-up. I'm surprised that you needed such a high voltage to sort the supply problem. Did you work out where all the voltage drop was?
I'll look at the autostart issue as soon as I have finished the BATC Website data migration.
Regarding the input voltages, I can actually get away with 5.3v at the power supply, I have 0.1 drop across my 3/4metre dc figure eight cable and a further 0.1v between the DC input socket and the GPIO pins / USB power pins.
On another note, as a really new linux user are you able to point me in the direction of where to change the keyed streaming GPIO pin state, rather than go from floating to 3.3v I would much rather key up the stream when pin 12 goes down to 0v
Ive found the line in the startup.sh file, I imagine the high/low state is in there also somewhere..?
Just looking at the other fault regarding the startup, thinking perhaps it's the order in which devices are called upon in the startup script ?
After all, programing is one huge flow chart. !