Video Support

[mrtnkhl]

There is currently no video support planned until bus protocol reverse engineering is done and interfacing with the digital bus is fully working. Creating this Issue as a placeholder for possible future work and to inform others who might be looking for video support.

Details concerning possible Audio support are tracked in Issue https://github.com/gdoor-org/gdoor/issues/20.

Per @DaSchaef there is sufficient evidence to assume that video is transmitted in analog just like the audio part of the communication with the (door) station in a resolution of roughly 320x240 pixels (or respective lines) per @jschroeter . It is assumed that an ADC would be needed to convert the analog signals to digital for the ESP32 and then send them via SIP/RTSP/RTP to a destination on the network. Issues outlined in https://github.com/gdoor-org/gdoor/issues/20 apply, in addition to those the extra bandwidth needed to digitize the video signal from the wire is going to be of concern.

[mrtnkhl]

See this thread for a similar discussion for a Comelit system: https://github.com/Elektroarzt/simplebus2-mqtt-bridge/issues/3

[mrtnkhl]

https://www.eevblog.com/forum/projects/ic-for-capturing-composite-video-screenshot/

[mrtnkhl]

https://github.com/wooky/esp32-analog-video-over-wifi

https://github.com/11tools/esp32cvbscam

[jschroeter]

I can confirm that the resolution is 320 × 240 since the images saved on the SD card of the indoor station do have that resolution. They are saved as BMP files but I guess this is irrelevant.

[jschroeter]

A bit off topic, but while I was setting up mobile notifications when someone hits our door bell I noticed that the Home Assistant mobile apps supports attaching a camera image/stream to the notification: https://companion.home-assistant.io/docs/notifications/notification-attachments#automatic-snapshots

I initially thought I don't need this, but of course, once I got the adapter running and read this, I immediately thought: that would be cool :-)

[DaSchaef]

https://github.com/antmicro/cvbs-mipi-bridge https://github.com/o-murphy/cvbs2rpi

[DaSchaef]

For buffering video https://jlcpcb.com/partdetail/TexasInstruments-THS7374IPWR/C2652746

[DaSchaef]

I have a question to the owners of video installations:

Is the video parallel to the audio conversation? If yes, the video signal may be modulated and no simple "cinch video", and we would need to find out the modulation scheme.

[mrtnkhl]

Video and audio are transmitted in parallel. Not sure if audio is duplex but I think it is.

[DaSchaef]

Hmm, we need someone with a video installation and at 40MHz bandwidth (better 100Mhz) oscilloscope. We need to record start of video, to identify the video modulation/signal scheme.

I'm not 100% familar with analog video, but from what I understand: the standard CVBS goes down in the spectrum, overlapping with the audio range. So I would assume that the video may be FM (or even AM, but I don't think so) modulated to shift it to higher frequencies.

Or audio / video is interleaved? Don't know if such a thing could work

[mrtnkhl]

Any recommendations for an affordable USB oscilloscope that would satisfy those requirements? My GIRA system has video.

[DaSchaef]

I had a quick glance at Video Bus signals.

Sadly they seem to be modulated, over 100 MHz? I had a bit of trouble with my cheap 100MHz oscilloscope. It may be over 100Mhz or the cheap scope was crap :wink:

I'll try a SDR solution next time, so that we first can get a feeling about the needed carrier frequency, and be sure what expected range to measure and that we use the right measurement setup.

As the Modulation may be over 100 MHz it may indicate that standard analog TV modulation is used?? From Wikipedia:

[DaSchaef]

Small status: I'm still working on this, also on the hardware side of #20 But as I want to combine both, it takes some time. I still need to find time for another round of measurement to get the modulation frequency.

[DaSchaef]

Update (slow as I do not own a video bus):

I measured today via SDR (hackrf) and couldn't identify the modulation frequency. This may indicate that the modulation frequency is on some VHF/UHF band where the RF signal is hidden behind the normal over the air transmission like DVB-T etc.

So I either need to setup a wired coupler for the SDR (without destroying the sensitive SDR RF input) or I need to use the way more expensive oscilloscope (which I tried to avoid :wink: ).

TLDR:

Easy option one (cheap oscilloscope): :-1: Easy option two (SDR with Antenna): :-1:

meeh, its getting more complicated :sweat_smile:

[mrtnkhl]

You got this! Curious to hear how they did it!

[CENGOiSM]

I recently came across this project and wanted to express my gratitude for your work 🙏. While I’m not particularly knowledgeable about the electronic aspects, I found this FAQ that describes the frequencies used to transmit video:

https://partner.gira.de/service/faq/antwort.html?id=939

Center frequency 8 - 12 MHz Sidebands + / - 5 MHz

Maybe this information might be helpful to you.

[DaSchaef]

Wow, yes this is very helpful.

It indicates some problems during my oscilloscope trials. Dual Sideband with +- are also a good thing. If it would be AM with both sideband this may ease demodulation significantly. No VSB like old time TV transmission reduces demodulation effort.

Let's see when I have access to a video system again. I'll test. Thanks!

[DaSchaef]

We have first data, it should be a checker board :)

It is FM modulated, at ~11MHz. PAL, 625 , 25 FPS (these settings worked)

The demodulator in SDRangle is great but rather limited to analyze. This needs more custom software to better understand and also learn what is needed in hardware. So it will still take time, no fast progress to be expected.

[mrtnkhl]

GDoor's moon landing!

[CENGOiSM]

Wow, great news! Would it be beneficial to share a 10-60 second segment of the transmitted signal so more people can analyze its integration potential through simulation?

[DaSchaef]

A short status, I'm still - slowly in the free time - working on video. Uploading is a bit hard:

• I have no good capture yet
• Raw data even for seconds is in GByte range, this is a raw data steam.

I was able to decode a noisy color video, so it is normal PAL, FM modulated at 11 MHz. Next step is to get a better data capture and get a clean software decoding to finally understand all parameters necessary for a usable solution (e.g. is there a deemphasis necessary?).

[DaSchaef]

I did progress further and did more research, simulation and tries in the past time. My conclusion is to not proceed on the video side for the moment. I'll move to audio, but do not expect fast progress, it is in my free time.

The problem with video is to find the best combination of the following requirements, which are hard to combine:

1. Cheap: max. 100€, as otherwise it comes closer to used TKS gateways.
2. Easy: As a hobby project, the people need to assemble themselves and number of units is very tiny.
3. Future proof: Of course there are solutions, but it does not make sense to design one, where chips, inductors or similar are not available anymore in half a year (fast moving EEE market).

In principle there are two points to solve:

• FM demodulation, where the bandwidth is rather high compared to the modulation frequency (where requirement 3 is had to reach without FPGA, which violates 1 and 2)
• Digitize the baseband signal without FPGA (which would violate requirement 1 and 2 for hobby users).

In the past there were rather easy solutions, which are still available on the used marked (analog TV tuner chips, cheap PLLs etc), but this would violate 3. These solutions are not produced anymore, since already quite some time.

Going the "direct" computing solution would mean, to e.g. reprogram a suitable SDR device (e.g. I digitized it with the hackRF one clone, ~ 100€). But this again needs another computer, or a custom firmware.

I think a solution could still be possible, but it is not fun to solve these two main problems with the 3 requirements.

[mrtnkhl]

@DaSchaef again thank you for all your hard work. Sorry it didn't work out as planned. Shall we close this issue then or would you like to keep it open?