I'm really impressed, tihee, that was it! The EDTracker is identified in USBView as having product id 8036, while ED thinks it's 8037. Changed the DeviceSettings.xml file and the game picked it right up! You certainly have an eye for detail.
Thanks!
User settable smoothing coming this weekend for 9150 users and then will push back into 6050 firmware next week![]()
Now, if someone have an idea what I need to do, to get my 9150 to work with the newer EDTracker2 sketches released? I don't get any axis movement with the sketches newer than v1.0.1. I e, with v4 I see Yaw drift registered in the EDTracker GUI, but no movement of the axis, nor in the USB Game Controller aplet
I'm doing a 9150 video at some point to show the differences with the 6050. I'll try to do a little section on de-soldering your old 6050 and dropping a 9150 in place.
But drift that severe really should be fixable, assuming you've not fried a component on the board. Check calibration, keep flat/still, let warm up, ensure you've got auto-centering enabled, minimise/close the GUI, etc....
Does anyone know what the problem might be, I have tried everything I can think of, its not something I know much about.
Can anyone advise where I may have gone wrong - in the game options the headlook mode is direct, and there are no deadzones set (e.g. sliders to the left).
Many thanks.
H
Hi chap. I would try an unplug, close the GUI, replug in, restart GUI - sometimes the COM ports get bound up in the .NET libraries I think (I can't explain it, but a restart of the GUI sorts it). Failing that, flash it again and see if that works.
Could be a USB connectivity issue. We have seen a small number of Pro Micro boards with an incorrect resistor on one of the USB data lines. This causes issues with the device not being recognized by the drivers and is especially noticeable with longer cables.
If you get more reliable connections with a short cable then it may be the same problem that causes the random jumps.
I doubt this is that issue tbh, Rob. I've seen the behaviour he describes yonks ago in the very early sketches where the register wrapped because the drift compensation value applied was massive and reaching the 32768 limit and wrapping...
Reminds me, I must put that resistor thing on the website at some point...
Will reply when I have tried the above & report back, thanks for pointing me in the right direction.
Thanks for the feedback.
I know of three people with this issue now which i admit isnt so many but just wondering what the common denominator might be.
I have another tracker here i can test another night and a different cable, will advise of any difference over the course of the week.
I'm doing a 9150 video at some point to show the differences with the 6050. I'll try to do a little section on de-soldering your old 6050 and dropping a 9150 in place.
But drift that severe really should be fixable, assuming you've not fried a component on the board. Check calibration, keep flat/still, let warm up, ensure you've got auto-centering enabled, minimise/close the GUI, etc....
I've just had mine through the post.... Housework can wait
Splendid job and fast turnaround on the upgrade from 6050 to 9150.
Sent on wednesday, back on saturday.
I'm little bit confused about the product texts in the shop. At the product page of the Pre-Built EDTracker (Magnetometer) it says that there are some units available. Does that mean that they are already assembled and ready to be sent or do I still have to wait a few weeks if I order one?
You can click "Scan Ports" and if it lists an Arduino, you're ok, it can see the device (assuming you've not got any other Arduino's plugged into your PC other than the EDTracker!) so it should be able to flash it. It will also try to connect to the first one it finds with a free port, but as I said this can sometimes fail for an unexplicable reason, I generally only see this when I've been flashing loads of devices with lots of plugging and unplugging, and I unplug one without remembering to click "Disconnect" first (as you can imagine, I sometimes have a batch of loads to flash!)
Rob is working on putting some logging-to-text-file feature into the GUI so that we can debug this sort of thing a bit easier. I'm not sure when it will be ready but hopefully very soon; this will help us understand what's happening a bit better. I know it's a pain, but we'll get there![]()