C++ programing

[cpt_hans]

The .bmp file sizes look good...the same as a valid file. The funny thing is that (using Win7) if I set the view to show thumbnails, the image is correctly represented in the thumbnail. If you double-click on it to actually view the image, Windows tells you that it's corrupt, and won't display it.

It just now occurs to me that I haven't tried to view the files with Linux. I'll have to try it on my SuSE box.

I'll have to look at the FlushFile you mentioned. It was just a flash of inspiration (desperation?) that made me think of relocating the OpenFile and CloseFile commands.

BTW, I figured out the filename[x] = '0' + num business. I couldn't figure out where the colons were coming from! I actually had to use filename[x] = '1' + num to make it work right...otherwise I ended up with two Capture00 file writes before it would increment. Not sure why.

I'm operating at the ragged edge of my C programming abilities with this crazy app!

-CPT_Hans

[cpt_hans]

Oh, you'll love this!

It was bugging me that on the corrupted .bmp files, the thumbnail looked okay, but Windows couldn't actually load the file. Out of curiosity, I loaded one good, and one corrupted .bmp file side-by-side in a hex editor. I found that the corrupted files have 71 lines of text inserted ahead of the actual image data...if I just delete those lines, the .bmp file is okay:

Code: Select all

WAVE RECORD: FS_OPEN SUCCEEDED
  WAVE RECORD: Deleting A:\MotionDet\Capture08.wav
  WAVE RECORD: Opening A:\MotionDet\Capture08.wav
  WAVE RECORD: File Opened
  WAVE RECORD: ADC full... Writing (@6)
  WAVE RECORD: ADC full... Writing (@20)
  WAVE RECORD: ADC full... Writing (@34)
  WAVE RECORD: ADC full... Writing (@288)
  WAVE RECORD: ADC full... Writing (@332)
  WAVE RECORD: ADC full... Writing (@388)
  WAVE RECORD: ADC full... Writing (@444)
  WAVE RECORD: ADC full... Writing (@500)
  WAVE RECORD: ADC full... Writing (@552)
  WAVE RECORD: ADC full... Writing (@604)
  WAVE RECORD: ADC full... Writing (@656)
  WAVE RECORD: ADC full... Writing (@712)
  WAVE RECORD: ADC full... Writing (@770)
  WAVE RECORD: ADC full... Writing (@826)
  WAVE RECORD: ADC full... Writing (@882)
  WAVE RECORD: ADC full... Writing (@938)
  WAVE RECORD: ADC full... Writing (@994)
  WAVE RECORD: ADC full... Writing (@1050)
  WAVE RECORD: ADC full... Writing (@1100)
  WAVE RECORD: ADC full... Writing (@1162)
  WAVE RECORD: ADC full... Writing (@1212)
  WAVE RECORD: ADC full... Writing (@1274)
  WAVE RECORD: ADC full... Writing (@1330)
  WAVE RECORD: ADC full... Writing (@1386)
  WAVE RECORD: ADC full... Writing (@1436)
  WAVE RECORD: ADC full... Writing (@1498)
  WAVE RECORD: ADC full... Writing (@1542)
  WAVE RECORD: ADC full... Writing (@1600)
  WAVE RECORD: ADC full... Writing (@1656)
  WAVE RECORD: ADC full... Writing (@1718)
  WAVE RECORD: ADC full... Writing (@1774)
  WAVE RECORD: ADC full... Writing (@1830)
  WAVE RECORD: ADC full... Writing (@1890)
  WAVE RECORD: ADC full... Writing (@1940)
  WAVE RECORD: ADC full... Writing (@1992)
  WAVE RECORD: ADC full... Writing (@2048)
  WAVE RECORD: ADC full... Writing (@2110)
  WAVE RECORD: ADC full... Writing (@2166)
  WAVE RECORD: ADC full... Writing (@2224)
  WAVE RECORD: ADC full... Writing (@2280)
  WAVE RECORD: ADC full... Writing (@2336)
  WAVE RECORD: ADC full... Writing (@2392)
  WAVE RECORD: ADC full... Writing (@2444)
  WAVE RECORD: ADC full... Writing (@2500)
  WAVE RECORD: ADC full... Writing (@2556)
  WAVE RECORD: ADC full... Writing (@2612)
  WAVE RECORD: ADC full... Writing (@2668)
  WAVE RECORD: ADC full... Writing (@2730)
  WAVE RECORD: ADC full... Writing (@2780)
  WAVE RECORD: ADC full... Writing (@2830)
  WAVE RECORD: ADC full... Writing (@2886)
  WAVE RECORD: ADC full... Writing (@2942)
  WAVE RECORD: ADC full... Writing (@2998)
    Write Attempt 0
      Waiting for Index 129
      Call 1: Wrong Index 127
      Call 2: Wrong Index 127
      Call 3: Wrong Index 127
      Call 4: Wrong Index 127
      Call 5: Wrong Index 127
      Call 6: Wrong Index 127
      Call 7: Wrong Index 127
      Call 8: Wrong Index 127
      Call 9: Wrong Index 127
      Call 10: Wrong Index 127
      Call 11: Right Index 129
    Send took 1

Now, what's funny is that this is Capture08.bmp...which is captured and written BEFORE Capture08.wav is. And yet, it looks like a log of writing Capture08.wav.

I've found some more interesting things about opening and closing the filesystem (I haven't got CloseFile() or FlushFIle() to work for me yet), but I need to do some more experimenting so I can organize my thoughts.

-CPT_Hans

p.s. an EXCEL-lent fellow is a Cricket Lover at Live games.

[rorschachuk]

Yep I think their implementation of the file system is a bit weird, I think the intention has been to make it forgiving of whether you've got access to the SD or not and maybe write to memory if not and send to the SD card if it becomes available - or something. Certainly I've found in the past that when I insert a card it gets written to from a previous session.

Clearly in your case the BMP file's request for a numbered file handle is being given the same number as the logging system, it looks like closing / reopening the file system reinitialises the counter for file handles but forgets to tell the logging system which already has one and remains unaware of the change. You might be able to fix this either by amending svt.c to get CloseFileSystem to reset Log_Handle to -1, or maybe cheat and do this in your app - in your top-level variable declarations try including "extern int Log_Handle;", then when you close the filesystem add "Log_Handle = -1;", forcing the logger to reset next time it's used.

RorschachUK