Bernd,
I will write a binary file using your code snip and also send you the complete stack just in case you spot the obvious school boy error.  From memory I do do a binary read from the port and all my understanding of line ending has come from cutting text from a field and looking at it in a hex editor (sounds like a school boy error to me!).
best wishes
Simon
			
			
									
									Search Backwards (Last Line to First)
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
- 
				Simon Knight
- Posts: 929
- Joined: Wed Nov 04, 2009 11:41 am
Re: Search Backwards (Last Line to First)
best wishes
Skids
						Skids
- 
				Simon Knight
- Posts: 929
- Joined: Wed Nov 04, 2009 11:41 am
Re: Search Backwards (Last Line to First)
Bernd,
I have reinstated my code as posted on this forum and I am unable to reproduce the fault (yet). I have attached the binary data as a zip archive. My quick look at it indicated that each data line is terminated with a CR LF.
best wishes
Simon
			
							I have reinstated my code as posted on this forum and I am unable to reproduce the fault (yet). I have attached the binary data as a zip archive. My quick look at it indicated that each data line is terminated with a CR LF.
best wishes
Simon
- Attachments
- 
			
		
		
				- BinaryExportPortData.zip
- (43.02 KiB) Downloaded 236 times
 
best wishes
Skids
						Skids
Re: Search Backwards (Last Line to First)
Simon,
I looked at your binary data. It uses a return/linefeed as lineending. If you have a binary dump of your serial data that does not work, that would be very helpful.
In the meantime I rewrote your handler, trying to adapt it as close as possible to your original handler. Here I use the offset function instead of repeat for each line, thus avoiding the line problem, since you said that sometimes there might be problems with the line endings. And there is a size restriction to the line size (if that still applies, it used to be around 64000), seems unlikely but the offset version avoids the line ending problem(if it exists)
A dump of a failed run would really be the best thing to track this down.
regards
Bernd
			
			
									
									
						I looked at your binary data. It uses a return/linefeed as lineending. If you have a binary dump of your serial data that does not work, that would be very helpful.
In the meantime I rewrote your handler, trying to adapt it as close as possible to your original handler. Here I use the offset function instead of repeat for each line, thus avoiding the line problem, since you said that sometimes there might be problems with the line endings. And there is a size restriction to the line size (if that still applies, it used to be around 64000), seems unlikely but the offset version avoids the line ending problem(if it exists)
Code: Select all
on mouseUp
   --   answer file " choose file"
   --   if it is empty then exit mouseUp
   --   put url ("binfile:" & it) into gDatabuffer
   
   put line 1 to - 2 of gDatabuffer into tData -- leave last line alone
   
   put "$GPGGA" into tStartString
   put numtochar(13) into tEndString -- you could also put the asterix into the tEndString, if there is always an asterix
   put 0 into tStart
   put 0 into tEnd
   put 0 into tStartIncrement
   
   repeat 
      put offset(tStartString,tData,tStartIncrement) into tStart
      if tStart = 0 then exit repeat -- string not found, either not there or end of tData
      add tStart to tStartIncrement -- tStartIncrement has now the character position of the found chunk "$GPGGA"
      put offset(tEndString,tData,tStartIncrement) into tEnd -- tEnd is x chars further from tStartIncrement
      if tEnd = 0 then exit repeat -- should not happen but anyways but also bails out if last line incomplete
      
      put char tStartIncrement to tStartIncrement + tEnd of tData into tmySubData -- it is the searched for string with "$GPGGA" in it
      
      -- this is pretty much your old code, so it should work without too much hassle
      If item 1 of tmySubData ="$GPGGA" AND item 7 of tmySubData= "1" AND item 9 of tmySubData <gHDOP then
         
         if gStartTime="000000" then 
            put item 2 of tmySubData into gStartTime
            --answer gstartTime
         end if
         
         DisplayTime (item 2 of tmySubData)
         DisplayPosition tmySubData
         If gLastFix<>"" then  SetDistanceMoved gLastFix, tmySubData
         put item 8 of tmySubData into fld"satcount"
         put item 9 of tmySubData into fld"HDop"
         put tmySubData into gLastFix
         CalculateAvSpeed item 2 of tmySubData
         --exit repeat
      ELSE 
         put tmySubData & "XXX" after gRejectedFixs
      end if
   end repeat
end mouseUpregards
Bernd
