Scott Posted August 22, 2011 Share Posted August 22, 2011 Ok I've figured it out for you... HiWord * 65536 = Part1 LoWord + 65535 = Part2 Part1 + Part2 = long number Long number/10^7 = Angle Fraction/0.6 = decimal Whole number + decimal = Location Example: HiWord = 8015 LoWord = -13983 8015 * 65536 = 525271040 -13983 + 65535 = 51552 525271040 + 51552 = 525322592 525322592 / 10^7 = 52.5322592 Mins/secs = 0.5322592 0.5322592/0.6 = 0.88709866 Include whole number of 52 = 52.88709866 (exactly what you were after ) Quote Link to comment Share on other sites More sharing options...
Pixelfill Posted August 22, 2011 Share Posted August 22, 2011 Ok I've figured it out for you... HiWord * 65536 = Part1 LoWord + 65535 = Part2 Part1 + Part2 = long number Long number/10^7 = Angle in decimal. Fraction/0.6 = minutes/seconds Whole number + minutes/seconds = Location Example: HiWord = 8015 LoWord = -13983 8015 * 65536 = 525271040 -13983 + 65535 = 51552 525271040 + 51552 = 525322592 525322592 / 10^7 = 52.5322592 Fraction = 0.5322592 0.5322592/0.6 = 0.88709866 Include whole number of 52 = 52.88709866 52degrees 88mins 70seconds (exactly what you were after ) I might be being thick here, but 52 degs 88minutes 70 secs !? 70 secs is 1min 10 secs 88 minutes is 1 degree 28 minutes. so would this not actually be 53degrees 29minutes 10seconds? Mike Quote Link to comment Share on other sites More sharing options...
Scott Posted August 23, 2011 Share Posted August 23, 2011 I might be being thick here, but 52 degs 88minutes 70 secs !? 70 secs is 1min 10 secs 88 minutes is 1 degree 28 minutes. so would this not actually be 53degrees 29minutes 10seconds? Mike Lol, spot on Mike. I was so busy looking at how to get the answer I never actually looked at what the answer was. In this case then I guess it's actually the first number that's in proper degrees, ie 52.5322 is 52 degrees, 53 minutes and 22 seconds. The 2nd figure is actually the decimal version hence why you divide the fraction by 0.6. Nice spot Quote Link to comment Share on other sites More sharing options...
Scott Posted August 23, 2011 Share Posted August 23, 2011 Damn iPad. @Chris - the formula is still the same mate, my understanding of it was just a little mixed up. Makes no odds to the calculation or the answer Quote Link to comment Share on other sites More sharing options...
Andy Blyth Posted August 23, 2011 Share Posted August 23, 2011 Ok I've figured it out for you... HiWord * 65536 = Part1 LoWord + 65535 = Part2 I get the feeling this won't work when the Low Word has a positive value. I believe that Chris' datalogger is interpreting the 16 bit word on the CAN bus as a signed 16 bit integer when it is an unsigned integer. The number Chris gave was -13983 which is 0xC961 in hex. If this were interpreted as an unsigned integer, you get 51553. If you apply your algorithm to the longitude you get: HiWord = -364 LoWord = 14387 -364 * 65536 = -23855104 14387 + 65535 = 79922 -23855104 + 79922 = -23775182 -23775182 / 10^7 = -2.3775182 Mins/secs = 0.3775182 0.3775182/0.6 = 0.629197 If you change the algorithm to treat the low word as an unsigned integer (the high word must stay signed to differentiate between N/S and E/W) and don't add 65535: HiWord = -364 LoWord = 14387 -364 * 65536 = -23855104 -23855104 + 14387 = -23840717 -23840717 / 10^7 = -2.3840717 Mins/secs = 0.3840717 0.3840717/0.6 = 0.6401195 Which is much closer! Chris, do you have some more ECU output to real world position conversion examples? It will be necessary to have more than one example to have confidence that the algorithm works for all cases. Quote Link to comment Share on other sites More sharing options...
Chris Wilson Posted August 23, 2011 Author Share Posted August 23, 2011 You guys are going to a lot of trouble for me, thanks , if I can help you out I will. Something odd is going on, see this post of mine to the GEMS (datalogger) forum, which also contains a reply from Motec. Motec's ii2 Interpreter software is seeing different raw data than the GEMS software.... ~~~~~~~~~~~~~~~~~~~~~~~~ I have found an anomaly between what i2 is processing and what GDA is seeing from the CAN BUS Example: Motec GDA GPS LONG HW -364 65172 GPS LONG LW 14386 14386 GPS LAT HW 8015 8015 GPS LAT LW -13983 51553 Now, subtract 65536 from the numbers GDA does not agree with i2 on, and the numbers agree. Why's that then, when they do tally on the other data? Same with the GPS Time, allowing for a tad of time shift reading the two cursor V time lines in the two apps: Motec GDA GPS TIME HW 1614 1614 GPS TIME LW -10040 55096 55096 minus 65536 = -10440 which, allowing for tiny time shift reading the graphs is OK. Not sure why the data is in differing formats, but the maths could sort this, couldn't it? I also had a reply overnight from the horse's mouth at Motec, which was: #################### You just need to place the high word to the left of the Low word, without any multiplication, division or anything. You can then put the decimal place at the 7th number in from the right. Example: The GPS Lat and GPS Long are just split in 2, nothing more challenging that that. GPS LON HW is the High word component. GPS LON LW is the Low Word component. Eg 144.9688203 Is HW is 0101011001101000 LW is 0111110010001011 Put them together 01010110011010000111110010001011 = 1449688203 Divide by 10000000 Gives you 144.9688203 This is the GPS Long value. Jamie Augustine MoTeC Research Centre ######################################### Quote Link to comment Share on other sites More sharing options...
Chris Wilson Posted August 23, 2011 Author Share Posted August 23, 2011 Rather than risk typos, here's a screenshot of some data from a location other than here at home. This is from Oulton Park. Hope you can see it OK. Quote Link to comment Share on other sites More sharing options...
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.
Note: Your post will require moderator approval before it will be visible.