nanoFlash Progress Update

[Mike Schell]

I am pleased to report that we are making solid progress on the nanoFlash. With Dan Keaton on-board to manage sales and marketing and the progress in code development on the Flash XDR, we can now focus more of our efforts on nanoFlash.

Currently the nanoFlash main board is through PCB (printed circuit board) layout. We should finish the top board by the end of this month, which would allow us to build prototype units in Feb. We are reusing 95% of the code from XDR, so the debug should go very fast.

Some highlights of nanoFlash include:
1) Small size: 4.1x3.7x1.25" in size (four nanoFlashes would fit on a single page of paper).
2) Low-Power: 8 Watts (active) and less than 0.4 Watts in standby.
3) Two Compact Flash slots
4) Same very high quality Sony MPEG2 CODEC with 100 Mbps 4:2:2
5) No analog audio I/O (no room in the box), but full embedded support.
6) Remote Start/Stop, Tally Light, RS-232/485 and LTC Input.
7) Most of the same basic capabilities of XDR, such as QT/MXF support, I-Frame only, 24p removal etc.

That about sums it up. Oh yes, one other minor detail...nanoFlash will have both HD/SD-SDI as well as HDMI In and Out...

Cheers-

[Tim Polster]

HDMI in and out is such good news!

Thank you for your foresight.

I was just about to get a WD TV for viewing and demoing footage, but now the Nano Flash can serve that role even better.

Great for monitoring as well.

[Dan Keaton]

Dear Tim,

The HDMI out is great for viewing the footage wherever an HDMI equipped television is available.

I can see that this would be great for viewing the days footage, either on set, or back at a hotel.

[Mark Job]

.....Hmmmmmm ! HDMI Support ! HMMMMMMMMMMMMM ! I vaguely remember humbly suggesting this feature be added. The response I got from you folks at the time was less than enthusiastic ;-) Glad to see you finally understood the basic need for HDMI support. Especially considering the plan revision and future iterations of the HDMI spec about to come along.

[Mike Schell]

Hi Mark-

I recall your recommendation. Yes, I response was not overwhelming. It did take us a number of months and lots of head scratching to wedge in the HDMI In and Out, while keeping the same overall box dimensions.

So, we did listen to you recommnedations / thoughts, it just took some extra time to implement.

Cheers-

[Bill Ravens]

This is GOOD news!!

[Mark Job]

Originally Posted by Mike Schell

Hi Mark-
I recall your recommendation. Yes, I response was not overwhelming. It did take us a number of months and lots of head scratching to wedge in the HDMI In and Out, while keeping the same overall box dimensions.

So, we did listen to you recommnedations / thoughts, it just took some extra time to implement.

Cheers-

...Actually, my suggestion for HDMI was for the Flash XDR, but it's great to see it on the Nanoflash product :-) The thing is Mike, forget all the reasons I gave about industry professionals demanding it, or how it will become the new HD-SDI, rather, think bandwidth. The HDMI spec is capable of quite alot of bandwidth and is a full duplex communication protocol, whereas HD-SDI works only in one direction at a time. If you need to record HD-SDI, then this is one BNC-If you need HD-SDI output, then this is another BNC socket. I don't know what the addition of such a socket will do to the XDR ? Perhaps this is impractical from a manufacturing standpoint, because it would mean you have to add the extra HDMI chip plus socket room and location to the internal MOBO. (??) However, if there were ever to be an option of 24F uncompressed, for example, then playout and record in would be able to pass the huge data rate increase more easily via the HDMI interface versus HD-SDI. Possibly, RAW data could be passed directly to PC via this method.

[Mike Schell]

Originally Posted by Mark Andrew Job

The HDMI spec is capable of quite alot of bandwidth and is a full duplex communication protocol, whereas HD-SDI works only in one direction at a time.

Hi Mark-
Where do you find that the HDMI spec supports full-duplex communication? I have thoroughly read the spec as well as designed both the HDMI In and HDMI Out circuits. HDMI as well as HD/SD-SDI are uni-directional protocols.

The extra bandwidth supported in the HDMI spec is great, but since our products are limited to 1.5GHz HD-SDI (1080p30), it's an overkill for our application. Yes, someday, in some future product, we will support 1080p60, which is already allowed in the HDMI 1.3 spec, but not anytime soon.

Best-

[John Richard]

Regarding HDMI for recording and editing purposes - I am not sure that this protocol supports much needed timecode addressing of each frame.

[Dan Keaton]

Dear John,

As far as I know, the HDMI output on cameras do not include timecode.

However, if one wants to provide external timecode to the nanoFlash, we will incorporate it into our footage.

[Mike Schell]

Originally Posted by John Richard

Regarding HDMI for recording and editing purposes - I am not sure that this protocol supports much needed timecode addressing of each frame.

Hi John-
You are absolutely correct, HDMI does not support time-code. However, we can add time-code (via LTC or internally generated) to the QT/MXF file when we capture the video. If you use LTC timeocde, it won't be 100% perfect as no HDMI camera has genlock input, but it should be very close.

However, on playback out the HDMI, there is no path to transmit the timecode, but still useful for monitoring.

[Mark Job]

Originally Posted by Mike Schell

Hi Mark-
Where do you find that the HDMI spec supports full-duplex communication? I have thoroughly read the spec as well as designed both the HDMI In and HDMI Out circuits. HDMI as well as HD/SD-SDI are uni-directional protocols.

The extra bandwidth supported in the HDMI spec is great, but since our products are limited to 1.5GHz HD-SDI (1080p30), it's an overkill for our application. Yes, someday, in some future product, we will support 1080p60, which is already allowed in the HDMI 1.3 spec, but not anytime soon.

Best-

....Spec 1.4 is coming. The new spec is supposed to be push pull, yes it does support TimeCode in the spec. What have you been reading ? Also, multi-channel audio is also supported and has been from the initial spec.

[Mike Schell]

Originally Posted by Mark Andrew Job

....Spec 1.4 is coming. The new spec is supposed to be push pull, yes it does support TimeCode in the spec. What have you been reading ? Also, multi-channel audio is also supported and has been from the initial spec.

Hi Mark-
OK, I'll take your word on it, as I have not seen the spec. Until the actual silicon is available, we cannot implement this spec.

Yes, we are aware of the multi-channel audio capability and have long-ago implemented this feature in our nanoConnect (HDMI to HD-SDI) box.

Cheers-

[John Richard]

The reason I noted one of the drawbacks of the currently available HDMI (1.3) was to point out the positives of HD-SDI and why HDMI is not a better replacement for it as I think was being indicated.

Another superior practical use of HD-SDI is cabling and length of cable runs possible. HD-SDI is many times less expensive and can be run up to 200ft from camera source to switcher or recorder. HDMI cabling is expensive with far less limited runs without extender amplifiers.

Then there is the connectors - HDMI is not a solid locking male to female connection compared to BNC used in SDI. There are some hybrid new style locking HDMI connections, but again, they are expensive and limited in cable lengths.

And I don't think HDMI connections were intended for routine plug in/out cycles that would be used in a production cycle like BNC connectors on the SDI.

As I see it, the HDMI implementation in the Nano is a great added value for monitoring as I think it was meant.

It was very interesting to hear that a new upcoming implementation of HDMI 1.4 would be carrying timecode.

[Mark Job]

Originally Posted by John Richard

The reason I noted one of the drawbacks of the currently available HDMI (1.3) was to point out the positives of HD-SDI and why HDMI is not a better replacement for it as I think was being indicated.

Another superior practical use of HD-SDI is cabling and length of cable runs possible. HD-SDI is many times less expensive and can be run up to 200ft from camera source to switcher or recorder. HDMI cabling is expensive with far less limited runs without extender amplifiers.

Then there is the connectors - HDMI is not a solid locking male to female connection compared to BNC used in SDI. There are some hybrid new style locking HDMI connections, but again, they are expensive and limited in cable lengths.

And I don't think HDMI connections were intended for routine plug in/out cycles that would be used in a production cycle like BNC connectors on the SDI.

As I see it, the HDMI implementation in the Nano is a great added value for monitoring as I think it was meant.

It was very interesting to hear that a new upcoming implementation of HDMI 1.4 would be carrying timecode.

.....Dear Mike & John. The HDMI original spec never was designed for SMPTE TC because you don't need an LTC stream to transmit the TC data anymore. Allow me to explain. With the advent of the Meta Data enabled MXF International Standard, one does not require a seperate data stream transportation technology to deliver the TC data. TC data "is embedded" into the MXF video file structure along with any other meta data as either an XML script or other language. This is what's sooo cool about MXF, and why you want to enter its wonderful world. Avid already uses the MXF file standard's extra information language to include chapter markers and thmbnail buttons in XML script as part of the MXF file (Sequence) for DVD creation without even leaving the timeline. What MXF file structure buys you, is the ability to include other types of programming language in it, such as XML, for example. Also, your point about HD-SDI long runs is moot because HD-SDI is not a push pull auto configuring hand shake protocol, whereas HDMI is an ultra high bandwidth protocol better suited to transport uncompressed, or even RAW data format information. Spec 1.4 will allow for industrial runs. My apologies for not being more clear about the TC transmission issue. If end users require LTC for interface with legacy technology, then the best way is to regenerate this seperately from a seperate output.

The MXF file structure language when utilised with HDMI spec is an awesome force of technical flexibility.