If you have anything to add, please do not hesitate to do so. Do not let yourself be intimidated by the fact that this looks much like a wiki page by now. It is still the discussion page and meant to be used that way.

+

= Pre-Orders =

= Pre-Orders =

Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.

Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.

Line 4:

Line 7:

== DIY-Kit ==

== DIY-Kit ==

+

I'm interested if price included shipment to Belgium is around 30 euro's max. and if there is some sort of software ready([[User:Toams|Toams]] 10:41, 7 August 2009 (UTC))

== Ready-made module ==

== Ready-made module ==

Line 11:

Line 15:

=Updates=

=Updates=

As I proceed through the project, updates on my progress will show up here

As I proceed through the project, updates on my progress will show up here

−

== Userspace vs kernel module ==

+

== Software Related ==

+

=== Userspace vs kernel module ===

Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)

Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)

+

+

:I started to write a kernel driver for the HMC5843. Right now, all features are supported, but i can't test it with the real chip until my order from digikey arrives (maybe next week).

::I got my order from digikey and soldered some ''thin'' wires to the HMC5843. After too many hours I managed to read some values from the chip, but the communication was very unreliable. I figured out that the wires from the Freerunner to the chip were too long. A shorter connection fixed the issue. The next problem was the very unstable internal state (unable to switch to continuous measurement mode), which was caused by insufficent power supply decoupling. A cap resolved the issue (as usual).

+

::The first measurement results are available from [http://gitorious.org/freerunner-navigation-board/pages/Measurement_results here].

+

:: --[[User:Cmair|Cmair]] 23:04, 21 August 2009 (UTC)

+

==Hardware Related==

==Hardware Related==

=== HMC6352 vs HMC5843 ===

=== HMC6352 vs HMC5843 ===

Line 21:

Line 35:

:'''Minor Update'''

:'''Minor Update'''

:It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

:It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

+

+

::Update on the Update: If anyone is actually interested in setting fire to piles of cash, contact me, I could at least hand you a PCB design. About access, well, there's userspace...--[[User:Drdeath|Drdeath]] 18:08, 30 July 2009 (UTC)

=== Data processing on HMC5843 ===

=== Data processing on HMC5843 ===

Line 28:

Line 44:

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

−

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the y-z plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the y-z plane, cause the angle to open up.

+

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the x-y plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the x-y plane, cause the angle to open up.

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --[[User:Drdeath|Drdeath]] 23:49, 27 July 2009 (UTC)

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --[[User:Drdeath|Drdeath]] 23:49, 27 July 2009 (UTC)

Line 41:

Line 57:

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --[[User:Drdeath|Drdeath]] 22:30, 28 July 2009 (UTC)

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --[[User:Drdeath|Drdeath]] 22:30, 28 July 2009 (UTC)

−

== Pricing Update ==

+

== Pricing Updates ==

Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

Line 48:

Line 64:

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

+

+

=== More accurate pricing info coming up ===

+

I'm about to order a couple of samples for my experiments, after that I'll probably have more exact information about what taxes and customs duties apply. As soon as I come out of intensive care from the heart attack I'll have, I'll update the pricing section so you can get yours. --[[User:Drdeath|Drdeath]] 18:19, 30 July 2009 (UTC)

+

= Please Stand By =

+

If it seems to you that update frequency has been rare for a while, you are right.

+

I apologize for not having any updates on the prices up yet. A personal problem is currently taking much of my time, but it will hopefully be over soon, though not "well again" I'm afraid. Please stay faithful, this project WILL surface. Thanks in advance for your patience.--[[User:Drdeath|Drdeath]] 12:41, 17 August 2009 (UTC)

If you have anything to add, please do not hesitate to do so. Do not let yourself be intimidated by the fact that this looks much like a wiki page by now. It is still the discussion page and meant to be used that way.

Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --Drdeath 00:14, 26 July 2009 (UTC)

I started to write a kernel driver for the HMC5843. Right now, all features are supported, but i can't test it with the real chip until my order from digikey arrives (maybe next week).

I got my order from digikey and soldered some thin wires to the HMC5843. After too many hours I managed to read some values from the chip, but the communication was very unreliable. I figured out that the wires from the Freerunner to the chip were too long. A shorter connection fixed the issue. The next problem was the very unstable internal state (unable to switch to continuous measurement mode), which was caused by insufficent power supply decoupling. A cap resolved the issue (as usual).

The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--Drdeath 00:32, 26 July 2009 (UTC)

While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be available equally wholesale - or equally inexpensive.--Drdeath 04:41, 27 July 2009 (UTC)

Minor Update

It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

Update on the Update: If anyone is actually interested in setting fire to piles of cash, contact me, I could at least hand you a PCB design. About access, well, there's userspace...--Drdeath 18:08, 30 July 2009 (UTC)

After turning the problem over in my mind as well as conferring with several people more math-savy than yours truely, I can (quite literally) draw the following picture:

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the x-y plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the x-y plane, cause the angle to open up.

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --Drdeath 23:49, 27 July 2009 (UTC)

This place really starts to turn into the main information counter, so it's about time I got it organized a bit.
Now I was promising more ideas in my last update, so here goes. It is still to early to tell details, but as far as I understand it, the magnetometer data might be used to determine the orientation of the device. As long as we stay far enough from the poles (Are there any Neo's at Admundsen-Scott Base?) the magnetic field lines lay (relatively) flat along the surface of the earth. That means, whichever of the three magnetometers creates the smallest scalar is closest to pointing up.

I'm thinking about implementing a calibration process which determines the orientation of the Neo that way and maps the three magnetometers to the three unit vectors so the most sensible output could be generated. As long as the orientation of the device isn't radically altered afterwards, the device should then be able to generate sane headings in almost every orientation, rotation and if I provide for a mechanism to provide sign usage, even upside down and face down. Now don't ask me where that makes any sense, but a driver should provide for as much flexibility as possible and leave the making of the sense to the application programmer.

The method falls apart however if the rotation of the device respective to the field lines is close to 45 degrees, either because of the tilt of the field lines themselves ( they only run parallel to the earth surface at the equator, everywhere else they point down to some degree or another), and/or an unfortunate rotation of the device is choosen. That is because in those cases, deciding which scalar is pointing closest to "up" might generate unreliable results. In effect that means we must provide for a way the user application can see the decision made and run it by the user, and if need be, override it so the device doesn't start putting out garbage data.

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --Drdeath 22:30, 28 July 2009 (UTC)

Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--Drdeath 01:30, 26 July 2009 (UTC)

One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --Drdeath 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

I'm about to order a couple of samples for my experiments, after that I'll probably have more exact information about what taxes and customs duties apply. As soon as I come out of intensive care from the heart attack I'll have, I'll update the pricing section so you can get yours. --Drdeath 18:19, 30 July 2009 (UTC)

If it seems to you that update frequency has been rare for a while, you are right.
I apologize for not having any updates on the prices up yet. A personal problem is currently taking much of my time, but it will hopefully be over soon, though not "well again" I'm afraid. Please stay faithful, this project WILL surface. Thanks in advance for your patience.--Drdeath 12:41, 17 August 2009 (UTC)

PCB only

DIY-Kit

Ready-made module

Updates

As I proceed through the project, updates on my progress will show up here

Userspace vs kernel module

Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --Drdeath 00:14, 26 July 2009 (UTC)

Hardware Related

HMC6352 vs HMC5843

The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--Drdeath 00:32, 26 July 2009 (UTC)

Major Drawback on the HMC5843

While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be available equally wholesale - or equally inexpensive.--Drdeath 04:41, 27 July 2009 (UTC)

Minor Update

It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

Data processing on HMC5843

Diagram of 3-dimensional magnetometer heading calculation

After turning the problem over in my mind as well as conferring with several people more math-savy than yours truely, I can (quite literally) draw the following picture:

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the y-z plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the y-z plane, cause the angle to open up.

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --Drdeath 23:49, 27 July 2009 (UTC)

This place really starts to turn into the main information counter, so it's about time I got it organized a bit.
Now I was promising more ideas in my last update, so here goes. It is still to early to tell details, but as far as I understand it, the magnetometer data might be used to determine the orientation of the device. As long as we stay far enough from the poles (Are there any Neo's at Admundsen-Scott Base?) the magnetic field lines lay (relatively) flat along the surface of the earth. That means, whichever of the three magnetometers creates the smallest scalar is closest to pointing up.

I'm thinking about implementing a calibration process which determines the orientation of the Neo that way and maps the three magnetometers to the three unit vectors so the most sensible output could be generated. As long as the orientation of the device isn't radically altered afterwards, the device should then be able to generate sane headings in almost every orientation, rotation and if I provide for a mechanism to provide sign usage, even upside down and face down. Now don't ask me where that makes any sense, but a driver should provide for as much flexibility as possible and leave the making of the sense to the application programmer.

The method falls apart however if the rotation of the device respective to the field lines is close to 45 degrees, either because of the tilt of the field lines themselves ( they only run parallel to the earth surface at the equator, everywhere else they point down to some degree or another), and/or an unfortunate rotation of the device is choosen. That is because in those cases, deciding which scalar is pointing closest to "up" might generate unreliable results. In effect that means we must provide for a way the user application can see the decision made and run it by the user, and if need be, override it so the device doesn't start putting out garbage data.

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --Drdeath 22:30, 28 July 2009 (UTC)

Pricing Update

Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--Drdeath 01:30, 26 July 2009 (UTC)

Distribution Hubs to lower prices for everybody

One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --Drdeath 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).