Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check HDMI connection with the camera module #605

Open
feonx opened this issue Dec 31, 2019 · 6 comments
Open

Check HDMI connection with the camera module #605

feonx opened this issue Dec 31, 2019 · 6 comments

Comments

@feonx
Copy link

@feonx feonx commented Dec 31, 2019

Hi,

Question context:
I have the following setup:

  • Raspberry Pi 3B (RPi)

  • C358743XBG camera module

  • PC LED screen

  • Laptop (mac book)

  • Camera module is connected to the RPi via the CSI-2 connector.

  • Laptop is connected to the camera module input via HDMI.

  • RPi HDMI output is connected to the PC LED screen.

Target
I would like to make the RPi as "man-in-the-middle" between the laptop input and the PC LED screen output. So that I can capture the screen images while watching the Laptop output on the PC LED screen.

I have got it working
Thanks to this wonderful PiCamera library I can get this to work by:

from time import sleep
from picamera import PiCamera

camera = PiCamera()
camera.start_preview()
sleep(2)
for filename in camera.capture_continuous('image.jpg'):
    sleep(1)

Issue

  • When the PiCamera script (above) is running and I disconnect the HDMI connection by shutting down the laptop, the script hangs at camera.capture_continuous forever.
  • When I run the PiCamera script (above) and the HDMI is disconnected at the start it will try to connect which takes about 10 seconds and then throws an exception.

This is not unexpected behavior, but I would like to be able to check whether the Laptop is connected to the camera module input before starting the PiCamera instance and before starting an image capture, so I can act on it.

The ideal situation would be to check whether the Laptop is connected and then start the capture script.

What did I try to solve this?

  • I found the following forum topic:
    https://www.raspberrypi.org/forums/viewtopic.php?t=46113
    They say you can check the connection by running "opt/vc/bin/vcgencmd get_camera". This is not a solution for my case because it checks the camera module connection on the RPi. It will always return: "supported=1 detected=1" whether the HDMI input is connected or disconnected.

  • I tried to search the dmesg output to see any changes.

  • I searched the source of PiCamera and read the docs about MMAL. I tried to read the camera inputs like:

from picamera import mmal, mmalobj as mo
	camera = mo.MMALCamera()
	preview = mo.MMALRenderer()

	print(camera.outputs[0])
	print(preview.inputs[0])
  • I tried:
from picamera import PiCamera
from time import sleep

while True:
	if check() == False:
		time.sleep(1)
		print("Not connected stil checking...")
	else:
		print("Connected")		

def check():
	try:
		camera = PiCamera()
	expect:
		return False
	return True

but this is not really efficient and it can take a long time for the PiCamera instance to respond (10 seconds) when there is no HDMI connection

  • I tried to find a way to configure the PiCamera class so that I can control the waiting time of 10 seconds and reduce it to 2 (changing the connection timeout of some kind).

  • I tried to run the camera = PiCamera() part in a multiprocessing process and when the process does not respond within 2 seconds it would kill the process. This somewhat works but the PiCamera instance is not disposed correctly and create some side effects.

Question:
How can I check whether the Laptop is connected/ responds to the camera module input? Or is there any other way so I can check periodically whether I can run the capture script?

Thanks in advance.

@6by9
Copy link
Collaborator

@6by9 6by9 commented Dec 31, 2019

Use of the TC358743 via the firmware drivers (as used by raspivid, raspistill, picamera, and the bcm2835-camera V4L2 driver) is totally unsupported, as reported by the message every time you start raspivid

The driver for the TC358743 HDMI to CSI2 chip you are using is NOT supported.
They were written for a demo purposes only, and are in the firmware on an as-is
basis and therefore requests for support or changes will not be acted on.

The supported route is via the bcm2835-unicam and tc358743 Linux kernel drivers.

The firmware expects to be in control of the "sensor" streaming. It has been asked for a frame and is expecting the sensor to deliver one. If you've disconnected the HDMI so that there is no input, then it will sit there waiting. Stop the capture before disconnecting the source.

@feonx
Copy link
Author

@feonx feonx commented Dec 31, 2019

Thanks for your response.

I did notice the warning and since this is a private project, I did not really worried about it that much. I now understand the reason for the warning, thanks.

I do know I should not disconnect the HDMI cable before stopping the capture. But in practice when turning off the Laptop (which is basically the same as disconnecting the HDMI) , that will happen often, I want to be able to automatically detect if or when to stop the capture. (for practical reason)

That is the essence of the question basically. When I can detect the disconnect I am able to stop the capture before capturing the next frame.

Is it so that the detection of HDMI disconnection isn't working because of the missing "control" of the streaming or is this issue still relevant in case of the "bcm2835-unicam" usage?

@6by9
Copy link
Collaborator

@6by9 6by9 commented Dec 31, 2019

The firmware is expecting a sensor that it is in control of. There are timeouts that should reset things if they stop, but losing the HDMI signal (and therefore any input) is not something that can be reset.
You say you are using a "C358743XBG". I'm assuming that's a typo for TC358743XBG, but is it the board made by Auvidea, or other? The Auvidea B101 brings the HDMI cable detect line out to a GPIO which you could then sense. See the manual at https://auvidea.eu/download/manual/B10x_technical_reference_1.4.pdf page 7.
"Pin 3: CABLE - Cable detect: high (3.3V) is HDMI cable is plugged in"

bcm2835-unicam is a V4L2 driver for the CSI2 receiver. tc358743 is an I2C V4L2 subdevice that allows control of the bridge chip. Any waiting in that stack is on V4L2 and so is within your application, not somewhere in the firmware.

@feonx
Copy link
Author

@feonx feonx commented Jan 2, 2020

Thanks, yes "C358743XBG" is a typo and should indeed be "TC358743XBG".
Board name: "H2C-RPI-B01"
Website: Store link
Chip: "TC358743XBG"
Brand: Lusya

I cannot seem find any schematics of the board. The only drawn view I found is on the website of the store: Image link.

You triggered me to look further into the hardware and I notice some IO pins on the board. Maybe I need to figure out what those IO's mean first! Can you maybe tell me something about them? I only know the basics of hardware.

@6by9
Copy link
Collaborator

@6by9 6by9 commented Jan 9, 2020

Sorry, I have no knowledge of that 3rd party product.
I have several Auvidea B10x boards, and they produce some documentation on their hardware, hence I have things working there.

There is some silkscreening on the board that reads

WFS OSCK
SCK SD
GND INT
IR  RST
GND 3.3V

That is the same 5x2 arrangement as the unpopulated header below it, and is the right type of signal names to be coming from the TC358743 for audio etc. I don't see anything obvious to be the cable hotplug line that is present on the Auvidea boards.

@feonx
Copy link
Author

@feonx feonx commented Jan 10, 2020

Thank you very much for your help 6by9! It is really appreciated.
I will try to find a way to solve this by reading the EDID by using the i2cdetect command, maybe that will give me some more info about the board state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.