ivport-v2 icon indicating copy to clipboard operation
ivport-v2 copied to clipboard

Hardware/ setup issue with ivport-V2 board

Open Longans opened this issue 8 years ago • 22 comments

Please see anfegori91's post at https://github.com/ivmech/ivport/issues/21#issuecomment-250534439 It's got a nice picture of the issue. Re-posting here since our questions are about the V2.

Looks like my board has the R5-R6 shorted together. Are they electrically connected on that one side anyway?

I'm also confused with some of the jumpers, and the manual hasn't been much help. No idea what X and Y are, and if the GPIO (next to 3V3) needs to be jumper-ed as well.

I did try it out. the Pi can't see the camera with the mux unit in place. I have the two A jumpers shorted and have tried with and without the GPIO pins 7,11, and 12 set for each camera. Never got a connected camera.

Camera and all cables still work after taking the mux board out of the path.

Longans avatar Sep 29 '16 17:09 Longans

Update: Looks like that side of R5 & R6 both go to ground anyway, solder short wasn't the issue.

Longans avatar Sep 29 '16 19:09 Longans

Thanks, did you solved your camera connection problem? Have you used the A jumpers?

anfegori91 avatar Oct 09 '16 06:10 anfegori91

No, I still haven't been able to connect to a camera. Both A jumpers are shorted the way the manual instructs. Did yours work correctly?

Longans avatar Oct 09 '16 17:10 Longans

We have added one more example with using ivport.py module for 4 camera supported ivport. You can check and test it, ivport type and jumper configurations should be defined while using ivport function from ivport.py module

https://github.com/ivmech/ivport-v2/blob/master/test_ivport_quad.py

ivmech avatar Oct 23 '16 20:10 ivmech

I've tested the board with four identical v2 cameras following the "getting started" guide and only CAM1 and CAM2 could be switched calling the camera_change() function. All connections were tested. Also, I've tried by changing the jumper to B and C with same results. Note: when creating the iv object, the iv_jumper parameter was changed from 'A' to'B' and 'C' in my tests, but when getting the iv.f1pin and iv.f2pin values it still shows '11' and '12', so I had to change te code to force the pin change. @ivmech , why didn't you included camera_change(3) and camera_change(4) in the suggested example? is there a hardware issue in this board? (I've tried defining my own pin change functions but I can't get past the second camera!!!). @Longans how is your progress?

log after failed attempt to change to camera 3 (a full tested brand new working camera):

mmal: No data received from sensor. Check all connections, including the Sunny one on the camera board
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

anfegori91 avatar Nov 15 '16 08:11 anfegori91

Hey guys, I recently bought the IVPORT V2 Dual. I soldered the 13x2 pins to headers and then connected with raspberry pi. I tried to run the test_ivport.py but the results are weired.. It seems it is not switching. Previously I had V1.3 of these camears, due to these problems I bought two v2 cameras, but still no success. Is there any jumpers settings I had to make? Did you guys succeed in doing it? Would appreciate some help.

wickywaka avatar Dec 23 '16 08:12 wickywaka

Well I found out what I was doing wrong. I had to enabled the Jumper 1 and now its working fine..

wickywaka avatar Dec 23 '16 13:12 wickywaka

I was able to get 4x cameras working using the following test code:

Notes

  • Testing with 8MP RPI (Sony IMX219 sensor) camera board.
  • I followed the setup instructions for ivport v2, and ran "python init_ivport.py" before running this code. (Not sure this is necessary because code in init_ivport.py is duplicated in the test code) Tested cameras without board, no Sunny issue.
  • All flex cable connectors are seated well.
  • I have measured the GPIO values for each pin and they map to the values in the documentation. GPIO appears to be working.
  • I have soldered a bridge at A (note: make sure you do two solder bridges, A is on both sides of the board.)
  • On the first pass through this I ran into software errors. I think this may be because I did not have ubuntu (Lite) updated and configured correctly. Here are some pointers:
$ raspi-config                                          # enable camera; enable i2c;
$ sudo apt-get install git                              # git may not yet be installed
$ git clone https://github.com/ivmech/ivport-v2.git     # clone ivport v2
$ sudo apt-get install python-smbus                     # in case this is not installed

$ sudo apt-get remove python-picamera                   # uninstall picamera because IVport v2 updates this
$ sudo apt-get install python-pip                       # install pip
$ sudo pip uninstall picamera

$ sudo apt-get update
$ sudo apt-get upgrade                                  # you may have to use the switch:  --fix-missing
$ sudo apt-get dist-upgrade
$ sudo apt-get install rpi-update
$ sudo rpi-update                                       # update firmware

Test code

# adapted from https://github.com/ivmech/ivport/blob/master/ivport_test_A.py
# follow setup instructions for ivport v2 at: https://github.com/ivmech/ivport-v2
# run init_ivport.py and confirm that i2c is set up correctly, before running this code.

import IIC
import RPi.GPIO as gp

iviic = IIC.IIC(addr=(0x70), bus_enable =(0x01))
iviic.write_control_register((0x01))                # default is channel 1

gp.setwarnings(False)
gp.setmode(gp.BOARD)

gp.setup(7, gp.OUT)
gp.setup(11, gp.OUT)
gp.setup(12, gp.OUT)

gp.output(7, False)
gp.output(11, False)
gp.output(12, True)

c = ''

while c != 'q':
    c = raw_input("Enter Selection (q for quit):")
    if c == '1':
        iviic.write_control_register((0x01))
        gp.output(7, False)
        gp.output(11, False)
        gp.output(12, True)
    elif c == '2':
        iviic.write_control_register((0x02))
        gp.output(7, True)
        gp.output(11, False)
        gp.output(12, True)
    elif c == '3':
        iviic.write_control_register((0x04))
        gp.output(7, False)
        gp.output(11, True)
        gp.output(12, False)
    elif c == '4':
        iviic.write_control_register((0x08))
        gp.output(7, True)
        gp.output(11, True)
        gp.output(12, False)
    else:
        continue


gp.output(7, False)
gp.output(11, False)
gp.output(12, True)

jdaniellhebert avatar Jan 04 '17 11:01 jdaniellhebert

Hey, its nice to hear that you made it working.. I am using IVPORT DUAL V2 and I soldered jumper 1. While running the test_ivport.py for picam_sequence() I get this error: self._bus.write_byte_data - IOError: [Errno 5] Input/output error And I have no idea why is this error is arising. Perhaps due to trying to capture while the camera is not switched. Do you have any idea or did you faced this error?

wickywaka avatar Jan 07 '17 00:01 wickywaka

@waqarrashid33 I have focussed on confirmation that the hardware is correct. When I looked into the code, in particular the modified Picamera code, it became clear to me that there was too much complexity to debug and be productive (it seemed incomplete and simple modification failed) and so focussed on modifying the simplest test program: test_ivport_A.py. When I did that I discovered a hardware bug (mine) that I was able to fix and then finished the test I show above.

I also tried connecting multiple ivport boards, reverse engineered the hardware a bit and then concluded there is a hardware design error. I documented this in the Wiki page comments. I have the sense that these board designs are not fully characterized and that testing is incomplete.

jdaniellhebert avatar Jan 07 '17 19:01 jdaniellhebert

I somehow managed to bypass the I/OError by adding try and except in the IIC.py. I think it is a hardware error something in the IIC mutiplexer as it doesn't able to switch in timely manner I guess.

wickywaka avatar Jan 08 '17 08:01 wickywaka

I made some more progress and set up a repository with my work.

https://github.com/jdaniellhebert/ivport_4.

I think i found the data sheet for the IIC mux.

I would recommend you make a simple test software and verify the hardware. My conclusion after all my efforts is that the IIC works well but the analog mux for the MIPI control signals is likely not fully characterized and there is likely variation across boards and configurations. It's a pity we do not have schematics and layout.

jdaniellhebert avatar Jan 13 '17 08:01 jdaniellhebert

Hello, as I expected, my problem is a hardware one (had to see them with my usb microscope):

  1. U2 pins shorted solder pads (continuity tested). win_20170215_01_06_18_pro
  2. U2 traces burnt. win_20170215_01_06_35_pro

Please IVMECH, I need a new board, I have tried by email, please answer.

anfegori91 avatar Feb 15 '17 06:02 anfegori91

@anfegori91 are you able to rework the boards? I have pretty much given up on this hardware, it seems the IVMech have abandoned us. I am currently working on another approach to mux cameras for rpi and other cameras, perhaps if there is interest from others we could pool resources.

jdaniellhebert avatar Feb 26 '17 21:02 jdaniellhebert

I emailed this photos to IVMECH and they sent me another board. Tested and working well. @jdaniellhebert I also have tested another way to connect more cameras. I've used two raspi zero with attached cameras and configured them as USB ethernet devices, allowing control and file transfer using SSH and SCP from a raspberry PI 3. Perhaps there is a way to stream video directly. I've learned a lot while doing this!!

anfegori91 avatar Mar 15 '17 03:03 anfegori91

root@ivport:~/ivport-v2 $ i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- 36 -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: 70 -- -- -- -- -- -- --

when python test_ivport.py with raspistill, it saved "still_CAM1.jpg" only and got error message "mmal: No data received from sensor. Check all connections, including the Sunny one on the camera board"

Please advise!

jackccwong avatar Apr 11 '17 12:04 jackccwong

@anfegori91 Is it still working? I checked mine for hardware faults but I couldn't find anything. I ignored the I/Oerror in software, but when I start receiving videos from both cameras, output from one camera gets full green or half green. I researched it a lot and my conclusion was I2C clock streching bug in raspberry pi. Now I am using raspberry pi compute module. But just curious to know.

I didn't verified the I2C clock stretching error on serial analyzer. I will do it one day.

wickywaka avatar May 05 '17 07:05 wickywaka

@anfegori91 sorry i missed your message in March. I also tried this approach with RPI0W USB OTG. How reliable was your solution and did you follow any particular recipe? I was trying to get this to work with resin.io managing all the devices and ran into problems. Resin technical team discouraged me from continuing because of online comments suggesting cables and drivers were not stable. I managed to make progress but then had trouble getting the drivers to work.

jdaniellhebert avatar Sep 24 '17 05:09 jdaniellhebert

@jdaniellhebert did you happen to succeed at the end with resin.io and this camera mux?

SloMusti avatar Aug 06 '18 12:08 SloMusti

I've tested the board with four identical v2 cameras following the "getting started" guide and only CAM1 and CAM2 could be switched calling the camera_change() function. All connections were tested. Also, I've tried by changing the jumper to B and C with same results. Note: when creating the iv object, the iv_jumper parameter was changed from 'A' to'B' and 'C' in my tests, but when getting the iv.f1pin and iv.f2pin values it still shows '11' and '12', so I had to change te code to force the pin change. @ivmech , why didn't you included camera_change(3) and camera_change(4) in the suggested example? is there a hardware issue in this board? (I've tried defining my own pin change functions but I can't get past the second camera!!!). @Longans how is your progress?

log after failed attempt to change to camera 3 (a full tested brand new working camera):

mmal: No data received from sensor. Check all connections, including the Sunny one on the camera board
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

@anfegori91 I am facing a similar issue. I am able to get two cameras function but can't access cam3 and cam4. Is there any solution for this.

pranav1796 avatar Sep 17 '18 14:09 pranav1796

Hi sorry for the delay, I just saw this. No I did not succeed and have moved to another approach. My sense is this hardware has not been adequately characterized nor supported...I imagine that this was a side project and then there was not enough interest for them to invest more time to take it further...

On Mon, Aug 6, 2018 at 1:49 PM SloMusti [email protected] wrote:

@jdaniellhebert https://github.com/jdaniellhebert did you happen to succeed at the end with resin.io and this camera mux?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ivmech/ivport-v2/issues/3#issuecomment-410696780, or mute the thread https://github.com/notifications/unsubscribe-auth/AC9l-RdVr3ocRrNQlt8qr7tnJpHus0Z4ks5uODtlgaJpZM4KKRAs .

jdaniellhebert avatar Sep 18 '18 07:09 jdaniellhebert

Hi, I was trying to stack 2 ivport2 to get 5 cameras working but stumbled upon this thread. I can get 4 cameras with one board following @jdaniellhebert but for now the stacking is still a mystery... Is the conclusion is that we cannot stack ivport2 to get more than 4 cameras?

SteveNguyen avatar Oct 17 '18 17:10 SteveNguyen