The Panasonic does not use the LANC protocol for camera and lens control. LANC is a Sony-owned protocol that must be licensed from Sony. So, no, Juan cannot just add that feature while he's in the camera's guts.

<<<-- Originally posted by Ken Tanaka : The Panasonic does not use the LANC protocol for camera and lens control. LANC is a Sony-owned protocol that must be licensed from Sony. So, no, Juan cannot just add that feature while he's in the camera's guts. -->>>

Or if he could, he would be smart not to sell it. Sony might not like that too much.

-Rodger

The DVX has an "Aux" jack for remote operation but the protocol is very different from LANC anyway.

So the amnwer is no!!!!

just a querry!!! :)

Thanks

Update....
 

The chip-clip problem has been solved...:) I now have all signals probed with the camera closed, I am waiting on an adapter to interface the cable that comes out of the camera to either the logic analyzer or the capture board....it will be here monday.

one question...what do you guys think is acceptable as far as location for the external circuitry? Because of the way the camera is designed, there is NO WAY to get the signals out through any other place other than the bottom of the camera. The cable is a very thin flexible ribbon cable, so it will not prevent the camera being mounted on a tripod, but i'm wondering where the small box could be mounted....the box will be smaller than a box of cigarettes, it certainly can be made as small as a match box if my soldering skills can handle it.

Since the cable comes out through the plastic junction between the two shell halves, it can easily go either right or left, but there are no easy mounting points on either side...since one side houses the LCD which is movable, and the other is the handle....any ideas?

Juan

You could mount an extra box on the bottom, like the beachtech XLR adapters for the GL1, etc. That shouldn't be a problem. You'll just have to add a tripod mount to the bottom of your device so that can mesh nicely with a tripod.

Thanks for the suggestion, that makes things a whole lot easier. I was afraid I was going to have to route the ribbon cable somewhere else, but i didn't think about remounting the tripod on the bottom of the box.

Another question...i'm thinking about the interface part, and after doing some bandwidth tests i've come to possibilities.

1.The camera can have a Firewire 800 link to a desktop for recording. This is assuming you have a decent FW800 card and a fast hard drive. This approach could also be programmed to recognize a FW800 hard drive when attached directly, but is more complex than approach 2.

2.Mount an SATA drive directly on the camcorder. The drive would have to be removed and plugged into a computer to get the data off. With the highest quality data, a 160GB hard disk will give you 66 minutes. Of course, a possible problem would be powering a full size drive, so a smaller notebook drive might be the solution...i DO know that the new desktop drives can easily handle the bandwidth.

Juan

Approach 1 sure sound good.
A lot of flexibility:
You can connect to a desktop when in studio.
A lap-top (FW800 equiped) when on location.
And direct to a FW800 Drive when you don't have access to the above.
Can't ask for more, Why settle for less ?
Take Care

I think that having a drive on the camera is a good thing..makes it easy to shoot with! if you could program some sorta of enclosure for capturing the data on the drive or a "box" that knows how to "talk" with the drive and capture from the camera

Hi guys

If the hard drive is connected to the camera either way above i.e. number 1 or 2

How is record and stop going to function while recording and how are the files going to be named and created?

Thanks

Approach 2 won't work in a practical sense for a couple reasons:

1) if you're in the field, you're stuck, because right now there aren't any SATA interfaces on laptops-at least there are firewire 800 cardbus cards, and the powerbooks have built-in firewire 800

2) You're basically going to have to pull apart a PC to mount those drives. Plus you'll probably have to add another SATA card to the PCI bus since most computers that have SATA are using the bus for the current drives.

So in a practical sense, you'd be much better off using firewire 800. What you could do is make a firewire800 to SATA bridge board (if they exist) that would let you mount the SATA drives, but connect to others via firewire 800.

While approach 1 with programming to recognize a hard-drive when connected might be a bit more complicated, I think in the long-run it will pay off a lot more since it will be whole lot easier to use, and more practical in the field.

Just to add my two cents to this discussion. What about noise and vibration that will be generated from having a drive that close to the camera. I think the lap top scenario is the best bet.

SATA will work. My year old Gigabyte MB has external SATA connectors and the new SATA version includes detailed SATA external drive specifications.

A number of SATA card with external ports are floating about and external SATA enclosures for existing IDE drives are available.

firewire is the best option for me.

you can put any firewire storagedevice on it so it's more future adapt.

who knows when sata become's sata2 with a diverend protocol and/or conector

Michel

How about wireless USB 2?:

http://anandtech.com/showdoc.html?i=1981

USB 2.0 does not have the necessary bandwidth...unless I use two interfaces.

I consider the option of dual USB/FW a last resort, because it requires the target computer to have two separate USB/FW cards...not that they are extremely expensive, but just a last resort.

Juan

I still say firewire is the best bet. It's a good peer-to-peer protocol that doesn't require a computer as an intermediary. If you plan on using this mod in the field, and you're using SATA, I think you're going to start running into some big problems that firewire 800 could easily avoid.

If all you're planning on doing is using the camera mod for green screen on a sound stage, then sure, having a PC close-by is no problem. But in the field, having I think it would be easiest to simply hook up via firewire and go.

I was just joking about wireless USB, though the future standards that support 1000 Mb/s sound interesting.

But for this, I still like SATA because of the lower CPU utilization than firewire, less expensive and I'm sure it can be made PC less as well.

I'm not too sure about the "PC-less" part, because SATA was not designed as a peer-to-peer protocol, there is suppose to be a dedicated host (i.e. PC) on one end of the connection-which again will seriously screw people up who want to be on location without dragging an ATX case and a 120V generator around with them wherever they go.

I know virtually nothing about firewire 800. My main interest in this development of Juan's is the potential to get a DVCpro50 signal out of the DVX. Could there be options within this device for that, or would I need to just run the raw data out of the cam into a computer and convert it to DVCpro50 afterward?

It seems to me (and my limited hardware ninja knowledge) that firewire is the way to go.

Alternatively, here are some very fast, and cheap drives ... http://www.softwareandstuff.com/DRV10382.html

I aware that firewire is the current best option, but to support future higher bandwidths, I think SATA is an option.

SATA could easily be made PC-less via embedded firmware controllers, or even more interesting could pack a PC in the case http://www.flipstartpc.com

Having a full function XP/Linux/OSX machine with a SATA drive would only be slighty larger than the Flipstart and would open all sorts of options, from RAID (via Seagate's 2.5" drives, 10,000 RPM drives if they release a SATA version or 2.5" notebook SATA drives which will arrive this year) to easy editing and output to tape in the field on battery without a notebook.

I've used firewire drives on several systems and they are not ideally configured for speed. SATA is much faster on my system (i have had the same drives internal and external and the difference is dramatic. Firewire 800 does not solve the latency issues inherit in firewire from the reports I have seen (if you have firewire vs SATA benchmarks that prove otherwise, let me know).

So, for Juan current needs (and future HDV and HD data rates), SATA via 2.5" RAID drives seems like a great, portable, fast and low cost solution.

Stephen has some really good points...the whole reason why I am even considering SATA is because of implementing FW800 is harder, and as a matter of fact i haven't found any general-purpose transceiver yet...the only kind i've found is the one that interfaces to PCI, which is intended to work on a PC...if I use this, i have to implement a driver somehow.

One thing to note, however, is that there really isn't any need for upgradeability. I know, i know, usually these are famous last words...but the truth is because of the nature of the application there isn't. The raw data rate is constant, and it will never increase....it is the same data rate for all modes(60i,30p,24p), so as long as there is a system that can record at that rate, there is no point in making it record any faster...unless there is something I am missing?

I did some benchmark tests with my external LaCie 200GB FW drive, and it peaked at 67MB/sec in writing..i am unsure of whether this is continous or so. We need about 40MB/sec....

Another things to consider is that this is a one-way interface...so far we do not need the target computer/drive to send any info back other than control signals.

Juan

<<<-- Originally posted by Juan P. Pertierra :
Another things to consider is that this is a one-way interface...so far we do not need the target computer/drive to send any info back other than control signals.

Juan -->>>

Kinda sounds like a 800 MPH rocket sled and the rider has no cut-off and no parachute to me.

If you have no redundant capture capabilities and no way to slow/pause the datastream, you better have a drive that has way more throughput then 40 Mb. Even a drive with a huge buffer could have problems unless the controller is smart enough to store data in an contiguous stream from shot to shot. Just a little to much seeking and any normal HD buffer will overflow at the 37 Mb or so transfer rate.

Maybe a raid system would have a better chance?

BTW - Glad you're making progress Juan. Just looking at some of the hurtles you may have to jump.

-Rodger

Uncompressed @ IEEE 1394
 

In addition to my previous posts I would like to point at FCP4´s direct support of uncompressed 4:2:2 YUV 10- or 8-bit signals - http://www.apple.com/finalcutpro/specs.html. For recording, a portable hard drive like for instance the Quickstream Dv should do, so there would be no need to re-invent the wheel.

That would be nice, but I don't think it's quite that simple...anything that is streamed through a cable to a computer/drive has to be controlled somehow...either packeted(fw,usb) or with control lines(RS-232,etc). I doubt you can just drop raw 4:2:2 through a cable and expect the drive to record it.

besides, we have the problem of frame size...most of these standards are NTSC frame size, and we want to be able to record the 771x494 the camera puts out, so i have to make my own standard.

I've been thinking long and hard about how to do this, and i've come across some possibilities...it seems one of the best ones is just to program an Altera array interface the data to PCI, which can then be hooked up to either a SATA or FW controller easily. I think as long as I can interface to PCI somehow, the best option is FW800, because then the Altera chip can be programmed to just stream the data if a drive is connected into a raw file. The file can be converted to any standard format(or unstandard 4:4:4 frames) using a simple program that i'll write.

Juan

<<<-- Originally posted by Juan P. Pertierra : we want to be able to record the 771x494 the camera puts out-->>>

Maybe it was discussed several pages back and I missed it (my apologies if so), but I would assume the raw image size to be AT LEAST as large as PAL on the vertical and horizontal, since afaik the PAL cameras usually share chips with NTSC cameras.. so i would expect the frame size to be at least 771x576.. no?

Also, i know it's 99% likely you have already thought of this, but please keep us XL1s (and other cam users) in mind, and make sure that this item can scale to other cameras if possible.. i.e. software/hardware drivers will be compatible with chips that may produce frames of 771+ or 576+ size ;)

Sorry if i mentioned anything that was already covered..

Adam,

Logically, that's what makes sense...however in practice, the frames ARE 771x494. I've been capturing continous frames for a while now, and i'm absolutely sure that is the res.(at least in 24p)

one thing i haven't tried is to switch between fine mode on and off....see if this has any effect on the raw resolution...however i'm pretty sure it is on fine mode 24P right now.

I am already capturing frames at 10-bit color...for now this is going to have to do because my capture card is 32bit and won't handle all 36 lines. Also, the $50k+ logic analyzer in my lab died so i can't use that(has 64 lines).

Right now I have one small glitch to get over: two of the connections are intermittent and causing some speckles in the image...i know how to fix it but I have 3 exams this week, so i'm going to attend to that first.

The images look fantastic but i'll let you guys be the judge once I upload some frames. Remember that these are going to be 10-bit color frames...the camera actually does 12-bit but my card doesn't have enough lines.

Juan

uncompressed
 

Hi Juan , I'm living in Quebec and I'm very interesting of your work , when you will be ready for pictures grab , it will be very intersting to have a 2 sec QT uncompressed file or a Targa sequence file that we can download to make some compositing or Color correction ; )
So if your DVx-100 modifications works
I will be interest to pay for it and I'm sure that a lot of people here will be.

Thank you

waiting for that image post!! shoot some stuff with LOTS of colors in it for the tests/image grabs! need server space? I can give you some!

So Juan.. what is the answer then..

either the PAL DVX doesnt share chips with the NTSC one..

the PAL camera somehow upconverts the raw image to the pal 576 standard..

or you are capturing a "raw" signal that has somehow already been downsized from a 576+ signal?

I 100% believe you when you say that is the size of the frames you've captured, I just dont understand how that can be, when pal cameras do 576?

::very excited to see some frame grabs:: ..or even some short video. If you need somewhere to host the video or frames (regardless of file size), I can handle that for you.. just drop me an email (adam@adamgeek.com)

Adam:

I am 100% that what I'm getting is the raw CCD size.(unless the service manual I have is part of some evil scheme by panasonic).

However, I think i've found evidence that the CCD's are indeed different between the NTSC and PAL versions, other than the frame size. The CCD sensors do not seem to be square, but rather have the NTSC aspect ratio...the raw frames of resolution charts having circles in them come out as slight ellipses, which are turned into circles when the NTSC pixel aspect ratio is applied. The difference is small, so I didn't see it until I used a rez chart.

Sounds great!
 

I am very excited about this thread. I just read it all, but some things aren't clear to me. Maybe you guys could explain a bit.

So actually the quality of a raw footage taken by a Panasonic DVX100 or a smilar camera is great, but because the camera saves the shot on the DV format is loses quality. So now we are trying to do something so we can direct store the raw format on for example on a HD without losing quality?

But then, if so.. when I search on google there are many products (especially the brand matrox pops up everwhere) which will transfer a footage from a mini DV to the PC.. why not use these then?

sorry, kinda new to this :)

Carlos,

Because those products store the compressed DV stream that comes out of the camera, which is the exact same thing that is saved to tape.

Manufacturers do NOT allow you to access any other data stream other than the compressed DV stream that is recorded to tape, or the analog output which is horrible.

BTW, sorry for the lack of updates, right after i got done with my 3 tests i left for spring break to visit my family since i haven't seen them in a while...will get back to work soon...it is almost done.

Juan

i'm very curious to see some examples too. this threas is breathtaking! i thought that i already found some fantastic threads here on dv i community, but this one is just unbeleivable!

juan,

does this mean - in your opinion, that i.e. beta sp, or digibeta can give us even more superior pictures? if dvx panasonic is cappable to "see" more then it "can" record - does it mean that broadcast cameras can "see" in "raw mode" more than just pal/ntsc, say - something closer to hd?

just curious

filip

Fillip:

The output of this experiment yields 4:4:4 uncompressed color in ANY camera. however, there is one thing that you do get with a more expensive camera: better CCD's. This translates into larger frame sizes(i.e. closer to HD) and less noise...also with larger CCD sizes you get a shallower depth of field that better mimics film.

So yes, you do get advantages of doing this procedure on a better camera, however, i think it is up in the air how good actual DigiBeta(4:2:2 3:1 compression) will look compared to the raw DVX output.

Juan

so, do you think your technique could be adapted to other cameras then? any chance of releasing pictures showing us the inner workings for DIY'ers?

Not to rain on anyone's parade, but if you're gonna go through all this trouble, why don't you just buy the CCDs, circuit boards, lens, etc., and design your own camera? You could probably do a better job than Panasonic, and you'd have exactly the features you want.

Peter,

As soon as you find a source for state of the art CCD's such that I can buy a small amount for less than $10,000 a piece, i'll happily do it.

Good Luck! :)
Juan