Sounds like someone is building the sketches with the device set incorrectly so the boot loader is being overwritten with the wrong one. This would then cause the official drivers to stop working.
I can assure you we don't touch the bootloaders
Sounds like someone is building the sketches with the device set incorrectly so the boot loader is being overwritten with the wrong one. This would then cause the official drivers to stop working.
I used some quick drying 2 part epoxy to lock/secure the microUSB socket in place. I wonder if a dab of that on the temp reading part of the board would insulate it and make it change temp much less.
Trouble is, which part of the board is the temp sensor.
I used some quick drying 2 part epoxy to lock/secure the microUSB socket in place. I wonder if a dab of that on the temp reading part of the board would insulate it and make it change temp much less.
Trouble is, which part of the board is the temp sensor.
Do we really thing ths unit's temp makes that much different to drift?
Definitely, from what I was seeing last night.
That would explain why after a calibration I'm getting a 0 drift over a 10-15 minute test, only to find later that day the drift is terrible - http://forums.frontier.co.uk/showpost.php?p=772535&postcount=2226
Just so we're clear, and no-one thinks we've ever said otherwise, there is no way to eliminate the actual drift on the sensor of the MPU6050 without additional sensor fusing. The aim was always to get drift within acceptable limits for the purposes of head tracking; I've always worked to 60 minutes between button presses and I certainly get that in ED using the tracker natively with exponential mode and a high sensitivity.
Bad calibration will only exacerbate the issue, that's for certain.
I'm not trying to palm anyone off with excuses, I'm just being transparent with what we've always said and aimed for. If you're having to press that re-centre button every 5 minutes, then I would drop back a version to 2.20.4, ensure your calibration is spot on, and then feed back if you're still seeing the issue. Maybe it is related to 2.20.5 after all...
Indeed. I'm going to try a calibration of the device at a constant temperature of 22 degrees (working, on head temperature) and see how that works in game. I could do with an angle-poised lamp to warm it up but don't have one, unfortunately.![]()
It could simply be the more aggressive centering code in 2.20.4 dealt with drift better?
ps: No one expects any miracles out of this little device, and I'm sure we all understand its limitation. But that said, it's a great little deviceAnd it would be great if the magnetometer version could help reduce/stop the drift issue
![]()
Can I suggest if people are calibrating they make a note of the "drift comp" value and their temperature? And build up a list of a few and post it here?
If there is a fairly reliable relationship that could then be built in to adjust the drift compensation according to temp that might be useful!
I'll certainly do a few tests and post my results here. ie: Drift compensation by temp.
And is the belief that mag integration would be the end of drift compensation as such? ie: The unit would simply know which way you're head is really pointing and not guess?I think it's doable if it is indeed linear. Mag integration would be the next focus though, it's been on our list for too long![]()
I can assure you that my drift problem has NOT suddenly gotten worse with the newer firmware. It's simply coincidence that I recently posted this:I'm not trying to palm anyone off with excuses, I'm just being transparent with what we've always said and aimed for. If you're having to press that re-centre button every 5 minutes, then I would drop back a version to 2.20.4, ensure your calibration is spot on, and then feed back if you're still seeing the issue. Maybe it is related to 2.20.5 after all...
@brumster
Why can't the act of pressing the reset button (recentering it) automatically recalculate the drift? This would automagically handle changes in drift over temperature & time (so no need for fancy Y=MX+C to estimate the drift like I suggested before). This also seems like it *ought* to be simple to implement?
I'm just getting annoyed that I calibrate it one day, and it seems fine (well recenter every 15 minutes or so), and then the next day it's drifting like crazy (recenter every few minutes).
No everyoneDownside is of course we'd all need up upgrade our beloved existing EDTrackers? ie: The existing units don't have the magnetometers in![]()
I can assure you that my drift problem has NOT suddenly gotten worse with the newer firmware. It's simply coincidence that I recently posted this:
Yep, agreed. I know what you're saying, and I think 99% of people understand, but there'll always be that 1% that are expecting some sort of commercial-grade solution, no matter how much we tell them otherwise
![]()
@brumster
Why can't the act of pressing the reset button (recentering it) automatically recalculate the drift? This would automagically handle changes in drift over temperature & time (so no need for fancy Y=MX+C to estimate the drift like I suggested before). This also seems like it *ought* to be simple to implement?
I'm just getting annoyed that I calibrate it one day, and it seems fine (well recenter every 15 minutes or so), and then the next day it's drifting like crazy (recenter every few minutes).
And is the belief that mag integration would be the end of drift compensation as such? ie: The unit would simply know which way you're head is really pointing and not guess?
Downside is of course we'd all need up upgrade our beloved existing EDTrackers? ie: The existing units don't have the magnetometers in![]()
No everyone![]()
I think 99% of people understand, but there'll always be that 1% that are expecting some sort of commercial-grade solution, no matter how much we tell them otherwise![]()
wish there was a way to bind a JS/kb button to reset the track, I could cope with that every few minutes.