Morning test of XDR fails bench test.

[Douglas Scott]

I just did a little test of the XDR on the bench using .245 and 720/60.

Recorded bars for 30 seconds.

Pushed play: unit playing.
Pushed stop: unit says stopping and lost input. (went into record mode for a flash, but recorded nothing)
Then, time code comes back on and still in stopping mode.
Finally, I restart unit.

Play clip: unit playing.
Push stop: it also goes back into record mode for 1 sec. and records.
Then, units says stopping and lost input.
Restart: unit sees SDI input and time code.

Also unit records wrong time code. It starts at 00 when the camera is set to 1 hour +.

Next test in 1080 format.

Scott

[Douglas Scott]

Recorded in 1080/60 at 50 mbps.

Unit records correct time, but the audio has clicks that were not present in the 720 test.

Unit time code does not play correctly. Time code flashes on XDR LCD screen and does not ascend.

XDR unit would not record with the record trigger set to time code record. I had to manually start the recording.

Unit fails both 720 and 1080 bench test.


Scott

[Mike Schell]

Hi Scott-

What kind of camera are you using? Embedded or analog audio? Embedded or LTC time code? MXF or QT file format?

Can you describe the audio clicks, we definitely have not heard of this problem in all our tests.

Thanks-

[Mike Schell]

Hi Scott-

We have a new firmware update due on Friday, to fix the Flash XDR playback, which has been broken.

Best-

[Douglas Scott]

Sorry about the multiple loads of the same thread. The system kept timing out.


I have the HDX900.

The clicks were faster than 60 cycles.

I was using the camera mic, but the clicks happened with the bars & tone being generated by the camera.

Embedded time code and audio.

QT file at 50 mbps.

Scott

[Mike Schell]

Hi Scott-

OK, thanks. I will test ASAP using my Canon XL-H1 with bars and 1Khz audio signal out. Will use embedded audio and time-code and 1080i60 format.

We do run through a quite extensive battery of functional and reliability tests before releasing new firmare. Of course, that does not mean we tested every scenario.

Best-

[Dan Keaton]

Dear Scott,

I will be testing the audio problems that you are reporting.



In order for the Flash XDR to start on incrementing timecode and stop when the timecode stops:

1. Set your camera to Rec Run timecode.

Otherwise your timecode will be incrementing at all times.

2. Set the Timecode Souce in the Flash XDR to the appropriate source of the timecode.

If your timecode is embedded in the HD-SDI signal, then select "Embedded".

If your timecode is from your camera's (or other source) timecode output signal, then select "LTC".

When this option is set properly, you will be able to see the timecode displayed at the top of the Flash XDR's screen. If it is present, then you have this option set correctly.

External time code, also known as LTC - Linear Timecode, if used, must be supplied via a BNC cable to the Flash XDR's "Timecode In" connection.

3. Set the Record Trigger to "TC", which means record whenever the timecode is incrementing.

4. Ensure that at least one CompactFlash card, with enough remaining capacity to initiate a recording, is in one of the CompactFlash card slots.


If any of the above conditions are not met, then the Flash XDR will appear to fail.

When the above conditions are met, then the Flash XDR will record on incrementing timecode.

I hope this helps.

At anytime, during any shoot, or any testing session, we can support you.

If you send me an email, I will send you all of my contact information. We provide 24 hour a day, year-round support.

There may be times when I am unavailable due to travel, or other circumstances, such as when phone service is unavailable or prohibited. In these times, we will probably have other support available.

This support committment extends to all users of the Flash XDR.

[Douglas Scott]

I know how the bloody system is suppose to work. The XDR doesn't work properly.

I saw an ad for the XDR and it states it's working. This is not true. I will agree that the unit turns on and records sometimes. As professionals working with other professionals, we can not have a devise that works some of the time or most of the time. Are tools need to work all the time unless they get dropped from a 10 story building and then we will give them some slack for being late to work.

The XDR is unreliable and goes thru weekly updates that cure one problem and start another. I can no more do a job with the XDR as I could drive my car to the moon, although with a couple tweaks both could be done.

I have received email from others who have sad stories to tell, but can not state them online.

After 20 years in the business, I think I can figure out where the on button is. So please, don't tell where the time code can be located and get these issues resolved.

[Mike Schell]

Hi Scott-
Please feel free to call our main support line (720) 221-3861 and I will be glad to personally try and resolve these issues. Yes, we are rolling out new firmware on a very regular basis. Most of the firmware releases add new features and correct bugs. We also work constantly to improve the reliability and robustness of the system.

We have many users successfully shooting high-end content with the Flash XDR. I would like to help you achieve this same level of success. We may need to make corrections to the Flash XDR and you may need to make some changes to your work-flow and procedures.

Best-

[Steve Phillipps]

This is always going to be the case with a product that's still really in development, and the reason why such a potentially-amazing product has seen no take-up with broadcasters yet - it's just not something you can put your livelihood on - yet.
The problem is while these products are going through this in-field refinement, by the time they are 100% ready who knows what else may have come along?
Surprised you want to use the XDR on and HDX900, the codec is probably the best thing about that camera - have you considered the Firestore?
Steve

[Herman Van Deventer]

Scott / Mike

Statement - Mike Schell - " We definitely have not heard of this problem in all our tests "

Have anyone ever considered the possibility that the client's unit could be faulty. - (Scott).

From a prospective buyer's viewpoint the two opposite's leads to one conclusion - The unit is either working or not.

Yes / 'In Development' in order to improve certain issues is substantial to the point where the developers clearly state that they have not heard of this problem in all their tests.

Surely, then the client's unit must be faulty and the developers unit's is working flawlessly regarding the client's specific issue.

Peace Brothers - Replace the unit.

Greetings.
Third World.

[Dan Keaton]

Dear Herman,

Your's is actually a very good suggestion. We will be happy to receive the unit, perform thorough checks and replace or repair it.



A few issues are present that can not be corrected by us replacing the unit.

1. The Flash XDR will lose the last subclip if power is lost while recording.

In our current firmware, we allow the user to specify the size, and thus the length in time, of each subclip.

When we record, we consider each recording to be a "Clip". We then seamless divide each "Clip" into "SubClips" of a user specifiedd length. This can be 10% to 100% where 100% is approximately 4 GB.

Recording and playback of these subclips is seamless.

If power is lost unexpectedly, then only the last subclip is lost.

2. We suspect a bad HD-SDI cable. This is easily remedied.

Originally a 90 Degree BNC cable was being used, which when touched would cause the HD-SDI signal to be lost. We believe that another cable is currently being used, but all of the symptons point to a bad cable.

We do not handle the loss of the HD-SDI signal gracefully at this time. We are working to correct this deficiency. Our plan is to continue to record the last good frame, in the loss of a good HD-SDI signal.

3. We have had reports of the Flash XDR not starting on incrementing timecode.

In 100% of these cases, we found the problem to be a simple setup issue.

For example, one of the menu items is "Timecode" where the options are "Embedded" or "LTC" (external timecode). For most cameras, except for the original XL H1, this should be set to "Embedded" unless an external timecode signal is being fed into the Flash XDR.

When timecode is setup properly, the current time is shown on the LCD display.

If the timecode is not displayed, then there is a setup issue or the camera is not putting out timecode. In either case, starting on incrementing timecode is not possible if we are not getting timecode.

All evidence points to a problem with timecode, as the timecode is not being shown on the display.

We have communicated with Mr. Douglass with offers of our full support to solve these issues.

[Mike Schell]

Originally Posted by Herman Van Deventer

Scott / Mike

Statement - Mike Schell - " We definitely have not heard of this problem in all our tests "

Have anyone ever considered the possibility that the client's unit could be faulty. - (Scott).

Peace Brothers - Replace the unit.

Greetings.
Third World.

Hi Herman-
Agreed! Thanks for the positive intervention. We will be happy to replace / repair the unit as necessary. We would also like to duplicate the exact usage in our lab, so we can more quickly trace down the problem(s), be it in our unit or operator error.

Best-

[Mark Job]

Originally Posted by Mike Schell

Hi Herman-
Agreed! Thanks for the positive intervention. We will be happy to replace / repair the unit as necessary. We would also like to duplicate the exact usage in our lab, so we can more quickly trace down the problem(s), be it in our unit or operator error.

Best-

....Hey Mike. I'll probably get shot & strangled for suggesting this, but here goes. Scott's isues are why companies invoke Beta Testing programs *before* they release a product. What the beta testing program will give you is a supervised team of "control" experimenters which can apply strict beta testing protocols to eliminate variables in the "grey areas" of malfunctions.

For Example: Scott's XDR - Is it busted, or is his operational equipment unsuitable (Or busted !) ?

Solution: You could cross ship Scott a control unit absolutely 100 % from your engineering department and have Scott perform a predetermined experimental shoot determined by your engineers using the control unit.

If result is malfunction, then invoke beta protocol 2 (Replace HD-SDI Cable)
If result is malfunction again after cable variable, then invoke protocol 3 (Measure Camera TC output) Scott could send you a CF card with the recordings on it to have engineering department analyze TC stream to check for integrity.

Serious malfunctions of this nature are inevitable during product development, but can be kept under wraps by setting up beta group who sign an NDA. I was greatly surprised when Convergent began shipping units out last year to the public without more testing. I am confident Convergent Designs will resolve Scott's problems with his unit.

[Mike Schell]

Hi Mark-
Good recommendations, thanks! We'll get Scott's unit sorted out.

BTW, can I get on the beta list for your new solid-state recorder?

Smile-