Having read the manual, I learnt the "DMA RD" error message signals error in communicating with CF cards; may I know what DMA RD003 means specifically?

This happened to me with both the Beta Version 1.5.31, and with the latest official firmware Version 1.1.154. Power-cycling the unit cleared the message.

Piotr,

I have had the same experience. Though I can't be sure I think it is triggered by my quick record/pause cycle time not allowing the Nanoflash to catch up. It is an inconvenience to be sure, I hope it is dealt with in a new firmware release.

Dear Piotr,

This error message can be caused by inserting or ejecting two cards almost simultaneously.

Yes, this error message must be cleared by powering down the nanoFlash.

Dear Dan,

If I remember correctly (it happened on the very first day of my testing the nano back in December, still with the 1.1.154 firmware), the sequence was following:

- triggering mode was set to Record button
- I recorded a clip, and pressed Stop
- the message "stopping..." displayed and lasted so long, that I power-cycled the unit
- on power-up, the DMA RD003 message displayed, so I had to power-cycle again
- I reformatted the cards, and the error never returned.

Until today (with Beta Version 1.5.31 firmware), when after I tested "delete last clip function" (worked OK), the same message popped-up.

Can you figure out the possible reason, and could this information be useful in testing the Beta?

Dear Piotr,

Please let me know if I understand correctly:

1. You were using our Public Beta 1.5.31.

2. You just completed a "Delete Last Clip".

3. After the "Delete Last Clip" worked successfully, you received a DMA RD003 error.

Exactly Dan - this is what happened with the Beta 1.5.31 today (just once).

This reminded me I did have the same error message with the previous firmware 1.1.154 in quite different circumstances.

Dan,

is it possible the circumstances I've described could trigger this error message? Not waiting for the Nanoflash to finish writing?

Dear Dave,

I am not certain what you mean by a quick Record/Pause cycle.

Do you mean that immediately after recording, you pressed Play, then Play again to pause the nanoFlash?

Dan,

I guess I mean that as I end a shot-pressing record to pause-I immediately see something in my viewfinder I want so I quickly press record again. This might happen after only a couple of seconds. Is that what you were thinking?

Dear Dave,

Thanks for the explanation. I understand now.

We will test for that condition.

Recording, Stop, Attempting to Record Again Immediately.

Dear Dan,

Sorry for bombarding you with messages, but I'm doing my weekend homework of testing the new Beta firmware. Here is another problem (never happened with the previous fw):

My CF cards (PhotoFast) are reported by the nano as UDMA5-capable. In fact, I could reliably record with 180 Mbps long-GOP - but with the Beta, I just encountered another failure: with the bitrate set to just 100 Mbps, I got the message "recording lost" and the nano switched straight to 50 Mbps (by-passing the 80 Mbps option). Then the "stopping..." message appeared and stayed for ever, so I had to power-cycle. The latter occurred for the second time since installing the Beta!

So I decided to torture-test it a bit, set the bitrate to 180, and recorded several clips with quite fast stop/start sequences - without a single glitch...

Something intermittent is happening in the communication with the CF cards, obviously!

What do you think?

Piotr

Dear Piotr,

Thanks for the report.

We will test this in our lab.

Yes, the 80 Mbps option is new, and we must not have added this to our "Bit Rate Down-Shift" code.

Dan,

Could it be that with the newest Beta firmware, when the nanoFlash checks and reports the cards (their names, and capabilities in terms of UDMA level) - when recording is started too early after powering-up, errors like the above can occur?

Interestingly, those errors never repeat later; also after power-cycling, if I wait for the card diagnostics to complete and only then start recording, everything is OK...

I suspect that hanging with the "stopping..." message displayed and lowering the speed down to 50 Mbps only happens when one starts recording immediately after power-up. At least, this is what happened to me twice after upgrading the firmware...

Dear Piotr,

That is an interesting theory.

When we test the new firmware, our testers, as humans, fall into certain habits, and tend to do things one (or a few ways).

They may not have tested recording before the messages are finished.

I am in the habit of waiting for the messages to finish before starting to record. I never thought of doing it differently. (But, I am not one of our formal firmware testers.)

This is something we will test.

Dan,

Until the firmware update (with fixed overcranking) is available, I will be using the latest official version. Before I revert to it, I have another kind request that you look into possible reason for nanoFlash freezing when finished recording, and the "stopping..." message remains on the display with the card light constantly red...

It happened to me again, and this time I make sure I did not start recording too quickly after powering the nano.

Dear Piotr,

Yes, we will try to test for all of these conditions.

Dear Dan,

I'm worried, because - even with the latest official firmware - I'm still having those intermittent hangs, when - after I finish recording a clip - the unit just displays the "Stopping..." message for ever. The Status lamp remains red; that of the slot in use is off.

Did you have any other user reporting similar behaviour?

I'm concerned because if this is a hardware failure, the procedure required to send the unit from the EU to the US and back is very cumbersome and expensive.

How can we establish what the culprit is, possibly without sending my nanoFlash over to CD?

Dear Piotr,

I checked with our engineers and support staff.

Tommy has reported that, under certain circumstances, certain settings and conditions, that this is possible with the Public Beta, but it is very rare.

Tommy mentioned that this could occur with 720p with certain user actions and/or settings. I do not know if you were working with 720p or not.

They have worked on this and feel that this is fixed.

So, my best advice is to wait for the next Public Beta.

As soon as we have an internal firmware release that we have tested for a few days, I will send it to you as a Private Beta.

Thanks Dan - the speed you are answering the posts here is incredible!

I'm a bit relieved that it does happen, which could indicate it's not a hardware issue with my nano or specific card (as this would be a big problem for me).

However, while this happened for the first time while I was testing the latest Beta, and indeed in 720p mode, today it happened again (just once) with the official firmware to which I reverted, and the 1080p format...

Before I installed the Beta a couple of days ago (which today I replaced with the official fw), it never happened even once; I filled up both cards many times without a single glitch.

One I can say for sure:

1. It can happen with both the latest Public Beta AND the latest official release; in 720p and in 1080p

2. It's NOT caused buy starting recording too quickly after power-up (as I speculated earlier)

3. It is NOT related to the card speed, as it did happen while recording just a 50Mps MXF.

Dear Dan,

It just happened again - this time, there was also the message "card in slot 1 too slow", the bitrate switched from 100 down to 50 Mbps, the "Stopping..." message displayed forever, and the footage is lost of course :(

I really don't know what's going on; the cards I bought from you are the 32GB PhotoFast, and have been good for up to 220 Mbps (I-frame) or 180 Mbps (Log-GOP). They have been consistently reported as UDMA5 (with Beta firmware), and "no errors" message is displayed at boot-up (with 1.1.154 firmware)...

Does it make sense to try and install the 1.1.154 once again? Probably not, but the fact is there were absolutely no errors with it PRIOR to my tests with the Beta, and now the same error keeps happening as with the Beta!

Edit Something is definitely wrong; just gor another error message while starting the very first clip after power-up:

"SlotDpc: 0003"

- what's up?

Piotr,

I have been skimming through your conversation with the world's best sales and marketing person, Dan Keaton. Mind you, Alex Dolgin (Dolgin Engineering) is every bit as good - sorry off topic here. In quickly reading some of your posts, I may have missed your point (sorry if I do) but I have 4 Sandisk 32Gb Extreme III cards that I have used under various conditions (very hot but not as cold as Alister has though), but more in very short recordings, lots of stop start etc.

I personally feel that the Sandisk cards are without doubt worth the (high) premium but once they are purchased, you quickly forget about the cost and can rely on them, thus far (6 months now) without fail or having the nano display recoding errors.

Perhaps some of the other recommended cards might not be as capable under real world situations like yours, I don't know, but I am very happy that I have the Sandisk cards, just like I am with the Sony SxS Pro cards. Not one card issue with either.

Do you have a Sandisk or 2 to try out? Might be worth it.
Am I on track here?

Best wishes

Dear Piotr,

Thank you for the additional clue.

We will be testing for "Card Too Slow".

Mike Schell and I have been discussing this and we are implementing some tools so we can see the internal condition of the nanoFlash, specifically, how much of our very large internal memory buffer is being used at any moment.

This will allow us to analyze the problem and fix it.

Piotr, have you reinstalled 1.1.154? I could not determine if you had from your recent post. I am assuming that all of what you are reporting applies to our Public Beta, except when you are speaking in historical terms.

Dear David,

Thank you for your comments on the SanDisk cards.

At this point in time, I think Piotr is reporting problems with our Public Beta.

I feel that we have a problem, in that sometimes, we get a "Card Too Slow" error.

We are researching this problem in our lab.

Thus, while this could be a card related issue, I would rather blame our Public Beta, "Not for Production Use", firmware at this time.

Piotr, have you reinstalled 1.1.154? I could not determine if you had from your recent post. I am assuming that all of what you are reporting applies to our Public Beta, except when you are speaking in historical terms.

Dear Dan,

Sorry if my English has caused confusion; let me reiterate:

1. Until a couple of days ago, I was using the 1.1.154 without any single errors of this type

2. During my testing the Beta, the "Stopping" hang errors appeared for the first time. I reverted to the 1.1.154 today, hoping it was the Beta that was causing them

3. Unfortunately, even though I'm back on the 1.1.154, the errors persists so I can't trust my nano for a serious tasks

4. The errors usually take place with one of the very first clips after powering the nano up (can't tell you for sure whether it's always the very first clip, but more than once it was). After I power-cycle and reformat, if the first clip saves OK, the next ones are usually OK too.

5. The error (when it occurs) usually manifests itself with the nano hanging, displaying the "Stopping...." message for ever

6. At a single occurrence, this has been accompanied by the "slot 1 card too slow, footage lost" message, and the bitrate going down from 100 to 50 Mbps

7. Also, "SlotDpc: 0003" displayed just once right after power-up.

I don't know whether the above makes sense, but that's how it is...BTW, may I know what exactly the SlotDpc: 0003 message means?

Also, is there a chance that some sort of a "hard reset" followed by another installation of the 1.1.154 firmware help?

Dear Piotr,

I will ask Tommy for an explanation of the SlotDpc: 0003 error message. I do not know what this means.

There is no hard reset of the nanoFlash, other than re-installing the firmware.

To David (and all that might be interested):

- while it may look like it, my problems are not due to the cards being too slow.

I have exchanged a couple of invaluable email messages with Dan, and here is the outcome:

1. With the Public Beta, the startup period is longer than before, and this startup period must complete before one starts to record

2. In low temperatures, my nanoFlash requires a short warm-up period

Keeping the above in mind, I run a very closely monitored series of tests and observed the following:

1. I first power the nanoFlash up; it does its storage check routine and reports no errors

2. Only after several minutes I turn the camera on (while receiving the SDI signal, the nano does some more card checks again, and reports no errors).

3. I start recording, and all is OK - even with testing at 180 Mbps, long-GOP

4. The only one time I saw an error using the above procedure has been the "SlotDpc: 0003" message; it was displayed at stage 2, when - on switching the camera on - the nano received SDI signal for the first time (i.e. even before I started recording !!!). Of course, I had to power-cycle the nano, but all was fine afterwards.

Of course, such careful and lengthy startup procedure may not be practical in the field, but Dan has given me some hope it can be fixed with appropriate firmware changes, without a need of sending my nanoFlash in.

Thanks Dan!

After many days of fighting with my nanoFlash errors, I have found that the latest Public Beta's "crank" mode must be turned OFF before you attempt downgrading to the official, stable 1.1.154 firmware.

If the crank mode is ON, after downgrading to the official firmware there will be audio/video glitches in the clips. Even "Restoring Defaults" will not help.

Also, the nanoFlash may enter into a false condition of erroneous communicating with the card slots (at least this is what happened with mine).

After correcting this situation, my nanoFlash is working OK again, and the clips are clean. I need to test it for another couple of days to confirm this; will keep you posted.

Piotr

Edit

Dear Dan,

When I think of it, this case is an example of the need to include something like "backward compatibility" menu setting (in addition to "Restore Defaults") in each consecutive Beta release. Considering all those many great options you're going to implement, something may always go wrong in a Beta (just like the crank mode did in the latest Beta release) - so reverting everything back to the pre-Beta state before actually downgrading to the previous official release could save people a lot of headache!

What do you think?

So far so good - after the full week of testing, trying to eliminate faulty cards, nano slots, nanoFlash itself, the SDI connection, etc. etc. - it looks like my guts feeling was right:

The errors I was getting were software related; the nanoFlash and my CF cards are OK.

Let me remind that the problem aroused when - after testing the Public Beta - I left my nanoFlash with the "Crank" mode enabled, and downgraded to the official firmware 1.1.154.

This has caused intermittent error messages like "Footage lost...Card in slot X is too slow..Awaiting source" scrolling in the upper line of the nano display, while the nanoFlash was hanging with the "Stopping..." message displayed permanently. Also, even those clips that were saved OK, suffered from audio and video glitches, and crashed Vegas.

The cure has been:

- upgrade to the Beta again
- turn the Crank mode off
- stay with the Beta, or only now downgrade to the 1.1.154 again

Now both the Beta and the official firmware work OK (with the exception of the Crank mode, of course - but this is gonna be fixed in the nearest Beta, if I understood Dan correctly).