* HDMI switches with RS232 control are readily available and could form the heart of the system. https://www.ebay.co.uk/itm/HDMI-Switch- ... SwcItavLsM or a 3 port is much cheaper https://www.ebay.co.uk/itm/Ex-Pro-3-Por ... 1438.l2649
* A Raspberry Pi could act as both a test pattern HDMI generator and control the switch by sending RS232 commands when a trigger on the GPIO port is received from the Ryde receivers or other inputs.
* A Ryde receiver on each band providing Multi Symbol rate reception.
* A BATC stream receiver to provide internet access.
* Composite to HDMI conversion can be done on a Rpi and provides input from FM receivers and mast cams etc. We have the basis of this in the Portsdown video monitor.
* H264 / H265 encoder box with HDMI input producing BATC stream and IPTS for transmission. Currently, this would drive a PLuto running F5OEO firmware to generate SI etc but could potentially drive a Portsdown IPTS input if a solution for SI on the IPTS input is provided.
Insertion of .750 talkback audio could be an issue but could potentially be done by an HDMI embedder on the output of the switch or inserted by FFMPEG at the SI generation stage.
PTT control could be done by the control PI to save electricity bills and whilst legally we do not need callsign ident by morse as long as it is in the DVB SI, the control Pi could send it every 15 mins if desired.
One concern would be glitches caused by the switch or intermittent Ryde reception and the effect on the encoder.
Thoughts, comments, issues, things I've missed and offers to write the Control Pi s/w all welcome!
Noel - G8GTZ
Based on my route with KM here's my comments..
Analog Video Input:
It's likely that all of the HDMI>Composite adaptors you will find for sale are not good on weak ish signals and stretch everything to 16:9.
Use an easycap on the Pi to do that, this can be the same Pi as the testcards are generated.
So far I've avoided HDMI audio as I couldn't mix it as needed in the HDMI switcher.
I use the analog Stereo Line input on the HDMI encoder box - BE AWARE this is not always stereo depending on the firmware version of the IP Encoder Box!
The analog audio input on the Encoder Box it not the best, as standard it's Mic level not Line level with some noise, so a HDMI Audio Embedder would be better but they are Expensive...
KM's many audio inputs are fed into a custom Audio Mixer but that is all analogue... maybe i'll do a HDMI version in the future? don't hold your breath. The mixer is controlled by the Pi.
You could just have another audio capture dongle on the RydePi that plays back through HDMI as well....
My suggestion here is to use a 'Seamless' HDMI switcher, the one i tried has no loss of output when the inputs are switched so it keeps the encoder happy.
I guess we will have to try a few and see which work with the rs232 capable ones.
I've modded one of these to have 4 ttl inputs instead of remote control which works fine: https://www.ebay.co.uk/itm/1080P-HDMI-4 ... 3717402797
In KM i have used MCP23017 chips as IO Extenders, i have python code available if anyone wants to use this in the 'Logic'.
There will be lots of Pi GPIO free though anyway...
IP Encoder Box:
This works well but has quirks.
I have some example python code on my github of how to configure it remotely from the pi, start/stop/configure streaming etc.
KM's encoder box is older firmware and Stereo Line-In works: Firmware version: ENC_V1.60.190919.
Another box with Fw: ENC_V1.96.200323 is just mono.
KM needs the Stereo to map multiple users to left/right channels.
All the Pi control code for KM is *very* specific, I can put the code on github but it will need to be stripped right back to be of any use at the moment.
I did a lot of work on making it more modular so it's better than my last attempt!
I hope that's useful info for any new builds.
just stumbled across this thread and a few comments.
Currently GB3FT Ryde rx drives an HDMI splitter to drive two Chinese encoders, one for BATC streamer at H264 and another for H265 to drive the Pluto.
The 144.750MHz rx responds to various DTMF commands some of which sends commands to the Chinese encoders over the ethernet to force other resolutions and reboots etc.
I'm currently looking at the Ryde code to see if I can make it control the Pluto SR and FEC such that more distant stations who are running low SR's and FECs to access can stand a better chance of FT reception by adjusting the tx parameters to match those received.
Longer term I think something along Noel lines is the way to go forward, but there's issues with mixing in the 144.750 talk back chatter into the main signal path. The most significant being those stations who when operating thru' FT on DATV with sound also transmit on 144.750 for the benefit of local listeners resulting in a delayed echo on the sound channel.
Ideally 144.750 audio should only be relayed when the repeater is not carrying live traffic - however sometimes rx only stations want to use FT as a voice repeater.
Thus I fear there is no simple answer to mixing in 144.750 chat back - but will ponder it some more......
As for the HDMI encoder boxes I've also discovered they respond differently to ethernet commands depending on the FW version - caused a bit of head scratching when the control code worked fine on one box but not the other !