Hi all, and thank you for your help!
Let me give you an orderly update on where I am, for what it's worth:
@JonB (first post):
I followed your advice as follows;
- first, I did create that custom view class you suggested in order to accomodate the 'will_close' actions (I basically copy/pasted @Phuket2 approach from another thread; I had read about 'custom classes' before and understood the overall concept, but had no idea how to implement them; in the process I finally learned where all those 'event' calls (on load, on close...) would go, which I was wondering since some time now; thx @Phuket2!); as soon as I did that, the heading updates kept up on coming regularly with no interruption; beats me why? Closing the view did not stop the updates from coming up, as I had not added the stopUpdatingHeading() command yet.
- I then added the stopUpdatingHeading() in the 'will_close' method; as expected, this would now stop the updates when the view was closed. Again, something I did not know where to fit in the script. Thx!
- I then proceeded to add the startUpdatingLocation / stopUpdatingLocation in the same fashion, and behaviour was as expected: I was getting now heading and location updates regularly.
- I also turned back the filter to 1 degree change thresholds; updates continued to be received regularly as expected in 1 degree changes now.
- I'll discuss the calibration and actual update analysis at the end of the post.
@mikael:
Well, I did check the location and motion modules some weeks ago as they seemed what I needed , but mixed results encouraged me to go another route (this might be my misunderstanding or I was not using them properly, and I may need to revisit them):
- concerning the motion module (.getmagneticfield()), initially I fell in the (0,0, 0.0, 0.0, -1) trap that has been reported in old posts, and that seemed to be related to the calibration; somehow this seemed to get resolved on its own -I frankly do not remember exactly how, I think t did move the device around for calibration and then it started pumping updates; however, i than realized that I did not know how to 'convert' the x,y,z vector into a heading in degrees, and did not find any 'simple' readings that could help me there. (Any suggestions?)
- concerning that location module, I did get the lat/lon readings, but 'course' and 'speed' was always -1 (I first thought this was an issue of not moving fast enough or having enough data for the device to calculate, but I remember doing some tests in a moving car and the values were always -1; still, I have the feeling now that his is just a matter of not understanding well how this works, so open to suggestions / pointers to tutorials.
@JonB (second post):
just saw it (I'm on GMT timezone), so I will look into your kind code example for further help, and particularly for those 'best practices' and more robust foolproof checks;
Now, so far so good, that's some progress there thanks to you all;
However after my success into getting those heading and location updates, I ran some tests in a moving car running the script on the iPhone8 and the iPad2 simultaneously and I'm puzzled with the results; in a nutshell,
-
location readings were accurate and consistent in both,
-
the headings they reported were highly different readings (tens, even hundreds of degrees offset),
-
to make things worse, checking occasionally with the iPhone compass app gave a third different set of readings; I moved both devices in the 'calibration' pattern several times; when I did that, it looked like the readings made a 360° circle themselves, but that did not seem to make the readings more consistent between devices/apps. Note that I have NOT yet implemented the locationManagerShouldDisplayHeadingCalibration: I'm aware of that but need to look at the documentation and figure out how to do it first!
-
I also remarked that the rate of change in headings in the script is way 'faster' (meaning much more 'sensitive' to change, if that makes sense) than in the iPhone compass app, giving me the impression that the Apple app is somehow 'smoothed' or averaged;
So I'm now wondering:
- do magnetometers behave somehow like traditional compasses in boats or planes, where each compass is different from one another and is delivered with an individual 'deviation curve' that needs to be factored-in in the reading? Basically, the deviation curve tells you how many degrees to add/subtract for every heading indication (0° to 359°) in order to get a proper reading;
- I'm no physician, but should I expect that using the two devices simultaneously (or even the script and the Apple app on the same device simultaneously) would impact each other because of the presence of different magnetometers? or is the influence of the metallic mass of the car so important as to make the readings so disparate? but if this is so, what would be the use in a plane, where you also have other compasses and a big metallic mass?
So I ended up going to sleep wondering whether external precision magnetometers exist that you can use via Bluetooth offering an API in order to get precise and reliable readings.....
As I said, open to suggestions and pointers I may have missed,
PS: I promised it would be short, but it's still a long post...
Thx,