clynch Posted September 20, 2007 Report Share Posted September 20, 2007 Over on nxtasy.org they have been discussing GPS bluetooth hardware and the NXT. Yesterday, some LabVIEW code was shown to parse GPS data. My first reaction from looking at the block diagram shown was that it looked like C code transferred to G. I know all about this coding style because I used to do that all the time, before I got more comfortable in G. The author also mentioned the solution was inspired by RobotC code and gives his benchmark of 92 milliseconds on the NXT block. I'm thinking the folks here could come up with some slick and quicker G solutions. It would be a great way to help the NXT community. I'm going to try to look into this more, but I thought I'd mention it here. Cheers! Quote Link to comment
Yair Posted September 20, 2007 Report Share Posted September 20, 2007 It doesn't look that bad to me. I mean, yes, it probably could be improved, but the style looks reasonable and to be honest, which piece of code can't be tweaked and improved? My understanding was that NXT has some performance issues which need to be taken into consideration. For all I know, this might be the most efficient way. Quote Link to comment
Eugen Graf Posted September 20, 2007 Report Share Posted September 20, 2007 I use reading VISA to CR LF, then Spreadsheed string to array(with a comma as delimiter) to get an array of strings. After checking of the cheksum you can interpret your array elements to Lat. Lon and so on. I think it's very easy. Can you post any code here, I want to look on? Eugen Quote Link to comment
robijn Posted September 22, 2007 Report Share Posted September 22, 2007 Hmm, I could try with my LabVIEW SLR(1) parser module... I curious how it performs against very optimized solutions. Joris Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.