BCD536HP, V1.06.10
I kept running into the above, 'SD Card Read Error', when trying to review my discovery results. The unit light would also turn off and the only way to proceed was to turn the unit off and then back on again.
I have a number of Micro SD cards, so confirming that this wasn't an actual card error was pretty simple.
On to finding the actual cause and repeating the problem...
I ran a discovery session between 440MHz and 460MHz. I then went to review any recordings whose length were not '0' and were not a multiple of '10' seconds (my default timeout).
I found that 441.950000 cause the Uniden to lock up. I inserted the card into my Mac and looked into the discovery directory for this run (/Volumes/BCD536HP/BCDx36HP/discovery/Conventional/A_RUN0004) and found the directory for this frequency (441950000_NFM_None) did not exist. I created the directory and put the SD card back into the Uniden to see how it would handle the directory existing but no files.
On browsing to the same run and frequency and selecting 'Play', the unit just beeped but didn't crash. Great! I have confirmed this is a software error.
I decided to write a little script to check the summary.log with the actual directory contents.
Running this gave me the following output:
Hmmm, 440.70000 didn't crash the unit so what gives? It turns out, that if the recorded length for a frequency is '0' when trying to review a recording, it doesn't check the directory so doesn't instigate the system crash. Yay, we are making progress.
We can surmise from this, that if the software detects the recording length is less than 1 it doesn't create the directory and therefore doesn't save a file. So why haven't we got a directory for 441.950000?
Here I am making a few educated guesses based on the detail.log and experience.
It is my guess that the first time 441.950000 was seen it was captured with a '0' length recording and so a directory wasn't created. The next time 441.950000 was seen, and with a length longer than '0' seconds, the software checked to see if it has seen this frequency before, which it had, assumed the directory already exists and skipped creating the directory and went straight on to trying to write the file, which it failed to do silently.
I would be able to confirm this, but there is a bug with the detail.log - It doesn't log any captures that are '0' seconds in length, even though '0' second hits are recorded in the summary.log.
I kept running into the above, 'SD Card Read Error', when trying to review my discovery results. The unit light would also turn off and the only way to proceed was to turn the unit off and then back on again.
I have a number of Micro SD cards, so confirming that this wasn't an actual card error was pretty simple.
On to finding the actual cause and repeating the problem...
I ran a discovery session between 440MHz and 460MHz. I then went to review any recordings whose length were not '0' and were not a multiple of '10' seconds (my default timeout).
I found that 441.950000 cause the Uniden to lock up. I inserted the card into my Mac and looked into the discovery directory for this run (/Volumes/BCD536HP/BCDx36HP/discovery/Conventional/A_RUN0004) and found the directory for this frequency (441950000_NFM_None) did not exist. I created the directory and put the SD card back into the Uniden to see how it would handle the directory existing but no files.
On browsing to the same run and frequency and selecting 'Play', the unit just beeped but didn't crash. Great! I have confirmed this is a software error.
I decided to write a little script to check the summary.log with the actual directory contents.
Code:
#!/usr/bin/perl -w
use strict;
open INP, "summary.log";
while (<INP>)
{
#RunInfo_C 0.000000 -0.000000 0.0 440000000 460000000 AUTO Auto 1 All Off 30 0 Off B
#Summary_C_Log 440075000 None NFM 27 3 C 0 0
if ($_ =~ /^Summary_C_Log/ )
{
my ($lt,$freq,$st,$mod,$dump) = split(' ', $_);
if ( $st ne "None" )
{
$st = (split('=',$st))[1];
}
my $dir = "${freq}_${mod}_${st}";
if ( ! -d ${dir} )
{
print "${dir} Not Found: $_";
}
}
}Running this gave me the following output:
Code:
Filename (and message): Log type Frequency Tone Mod Seconds Recordings
Code:
>> /Volumes/BCD536HP/BCDx36HP/discovery/Conventional/A_RUN0004
>> matt: check_bcdx36hp
440700000_NFM_None Not Found: Summary_C_Log 440700000 None NFM 0 1 C 0 0
441950000_NFM_None Not Found: Summary_C_Log 441950000 None NFM 12 3 C 0 0
455475000_NFM_None Not Found: Summary_C_Log 455475000 None NFM 0 2 C 0 0
456562500_NFM_None Not Found: Summary_C_Log 456562500 None NFM 0 1 C 0 0
440037500_NFM_None Not Found: Summary_C_Log 440037500 None NFM 0 1 C 0 0
442900000_NFM_None Not Found: Summary_C_Log 442900000 None NFM 0 1 C 0 0
455850000_NFM_None Not Found: Summary_C_Log 455850000 None NFM 0 1 C 0 0Hmmm, 440.70000 didn't crash the unit so what gives? It turns out, that if the recorded length for a frequency is '0' when trying to review a recording, it doesn't check the directory so doesn't instigate the system crash. Yay, we are making progress.
We can surmise from this, that if the software detects the recording length is less than 1 it doesn't create the directory and therefore doesn't save a file. So why haven't we got a directory for 441.950000?
Here I am making a few educated guesses based on the detail.log and experience.
It is my guess that the first time 441.950000 was seen it was captured with a '0' length recording and so a directory wasn't created. The next time 441.950000 was seen, and with a length longer than '0' seconds, the software checked to see if it has seen this frequency before, which it had, assumed the directory already exists and skipped creating the directory and went straight on to trying to write the file, which it failed to do silently.
I would be able to confirm this, but there is a bug with the detail.log - It doesn't log any captures that are '0' seconds in length, even though '0' second hits are recorded in the summary.log.
