Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
Z-CAM E1 Camera 100 Mbps hack for 4K DCI (fw v0.31)
  • 382 Replies sorted by
  • @storyboardcreativity

    Make sure to make it public. And also look for E2 firmware :-) may be some knowledge can be used.

  • Does anybody need a E1 fw unpacker/packer?

  • at 4k30 and 100mbs1gop hack the temperature displayed in the ios app rises to 41 degrees and remains stable there, at 1080p30 the temperature is lowest 35-38C , at 1080p60 it is almost back to 40C, this comes from the way the sensor is read out. The sensor is cooled over the front and the bottom plate, I taped the hoset and the ground with 1/4 thread on a large file plan and screwed with thermal grease on a cage for cooling . the chipset sits behind the screen, which seems to produce less heat

  • @Vitaliy_Kiselev, is it possible to get info about DSP assertion codes?

  • @zcream, ok. I think, it's not a temperature problem. Because A9 is a SoC with ARM as a main CPU. I mean if temperature interruption comes, ARM will receive it (not DSP)

  • @zcream

    Well, you can see our Z1 internals photo in main topic, it really has lot of shortcoming sin thermal design :-).

    I think few holes and small heatsink already can do a lot.

  • Temperature issue can be solved by removing outside plastic box, just keep the internal circuit and an external fan.. They did not design for airflow so that could be the issue.

  • Sherlock is back :)

    I have some new info about H.264 freezes on high bitrate. With my modified firmware I can get a full recording log info. And look at this:

    [0;31m[00066457][CA9_0] ## DSP assertion(0x00000040)

    [0;31m[00066457][CA9_0] ## The print is only valid after ucode 229729

    I get these messages on time moment when freeze comes. As we can see, DSP crashes on code assertion. Well, I have good news and bad news.

    Good: It's not a sd-card bus problem (it means that we can go higher by h.264 bitrate). Video recording and writing to ".MOV" does not stop, but next frames are always same (VIN freezes and stops updating frames in frame buffer). In log after DSP error we can see this:

    [0;37m[00075325][CA9_0] ## Wait main encoder idle time out

    [0;37m[00077867][CA9_0] ## DSP no response from VIN!

    Bad: I don't know DSP ucode instruction set => we can't understand, what this assertion is (maybe DSP temperature???)

  • Z-Cam supported the crappy E1 (that most people bought for $200 and then whined about how it wasn't as good as more expensive cameras) (I was on the kickstarter and it was a $700 camera for me - which I hated, sold, and never have to worry about again) with new firmware updates for longer than other companies supported much more expensive cameras. I wouldn't expect much more in the way of updates for the E1.

    It also seems like a number of the problems with that camera came from their choice to use a third-party chipset which, itself, had a number of problems.

  • Logging Firmware is Ready!

    Done! Now debug information is always written to "ambhis.l" file in root of sd-card. I mean, all low-level info like recording start/stop, errors and other info. I've uploaded firmware file to my repository.

  • @CFreak, I've made first version of RTOS logging firmware version and... I bricked my camera :DDD

    Camera still starts up without sd-card (when it can't find sd-card, it does not try to write log) - I can reupload old firmware. But it's funny :)

  • @CFreak

    My own position on this is such.

    Z-CAM is going wrong way, to more expensive cinema camera market that is small, crowded and extremely competitive.

    I think E1 project premature closure was an error and instead they should do E1 Mk II.

  • Well, they made a lot of promises and released a camera with a lot of issues (sync sound being one of them). Then release a new product and only support the E1 when resources allow. They never officially out up FW 0.31 on the E1 support page and make you download it through google drive. It's all a little suspect in my humble opinion. Keep up the good work @storyboardcreativity!

  • @Vitaliy_Kiselev, you said:

    _ Yet I can try to talk about any small help._

  • @storyboardcreativity

    What kind of SDK you mean?

  • Which one is better for the 1080p30 mode: h.264 100Mbps GOP=1 or MJPEG with the same bitrate?

  • Vitali .. or Zcam give the linux code Open Source

  • Don't forget Jason Chang was Developer from this Chipset he Works with 100% with undocument Tricks

  • @zcream and @Vitaliy_Kiselev, I already have sources for another camera with Ambarella SoC (full SDK without DSP microcode sources). It helps me to reverse-engineer API calls (obviously, prototypes are the same). E1 sources can be very interesting because of some things I can't understand now:

    • We can't set h264 bitrate higher than 65535999 (Real bitrate = our value % 65536000)
    • For some reason ambash logging system to file does not work (but code exists and is executed for each command)
    • Camera freezes after some time of recording when we increase VBR percent and overall bitrate is higher than 100 Mb/s (no messages, just freeze). Because of no any logging we can't understand the reason. But we know, that 100 Mb/s is NOT a highest bitrate possible (MJPEG works on ~200 Mb/s)

    Bitrate problems are not in RTOS code. It's in DSP microcode. But I don't know, how to reverse it :c

  • If we get source we also have DSP API calls. There will be an init routine that will set mctf, for example. Also, colorspace and jpeg quality will be in init for encoder

  • @zcream

    I can try to talk about any small help.

  • @zcream, I'm interested in DSP architecture. I still can't understand, what instructions does it use. In all SDKs modules for DSP are precompiled (binaries only).

  • Perhaps @vitaliy_kiselev can get the source code from his friends at z-cam