Note:  These questions and all the articles within the Notes section were created at the beginning of the project.  Some of the questions have already been answered as part of the software standards or the definition of the initial modules and others have become irrelevant due to the research that went into creating these.  See

http://humanise.org/demining/software

and

http://humanise.org/demining/initial-modules

Questions/Comments/Discussions?

1. Is Humanise.org the best name.  At this early stage it is still possible to change it.
2. Which Licence?  There is some opposition to Gnu due to its viral effect.  Do we need to specify the licence other than that it is open source?  On the other hand, that viral effect is probably exactly what we want with this project.  Note that there are two versions of the Gnu license, the Lesser Gnu License and the Ordinary Gnu License.  See http://www.gnu.org/licenses/why-not-lgpl.html for reasons to use each.  The problem is that if we include any already developed software that has the Ordinary Gnu License then we may be required to use that also.  The intent is that commercial organisations should be able to use the design created by this project as that reduces the cost of commercially supported products.  If they have restrictions placed on them such as restrictions on extra developments that they make, then they may avoid using our design.
3. Do we need standards other than the Interface Specifications?
4. There is a requirements that all design be Open Source:  Therefore all design should sit on top of a Open Source Operating System  This creates a requirement that system will work with say Unix rather than Microsoft Windows etc   Which Unix? Do we need a specialised Real Time Operating System as typically used with embedded systems?  If so, which one?
5. Should we all be using the same development platform?  eg should all development be based on developing with Ubuntu ??
6. Does it all need to be written in the same computer language.  Since most of the main computer languages can easily interface to a properly written Application Programmer Interface (API) or other Interface Specification, it is possible for different modules to be written in different languages.  On the other hand having different languages for different modules will cause problems, both to those interfacing to each other and those trying to use the results.  Perhaps we should make a specification of preferred language and compiler, probably a Gnu C or C++ compiler.
7. Should the initial design be based on Frequency Domain (VLF) or Pulsed Time Domain based design.
8. How useful is a Global Positioning System (GPS)?
9. How are we going to go about testing the design?  What do we need to add into the design to allow easy module testing, particularly previous to other modules being available?
10. Is CVS or Subversion (SVN) or other the best choice for a Version Control System for a new Open Source project?
11. With the received signal, for each primary signal, how many and which harmonics should we obtain the amplitude and phase for?
12. In the initial project, should we attempt to monitor both the voltage across the receiver coil and the current through the coil.  A working metal detector can be obtained by just monitoring the voltage across the coil but some better VLF detectors monitor both and use the changing relationship between the phases of the two waveforms and/or the changing relationship between the amplitudes of the two waveforms to help characterise the target.  If we don't start off with hardware that allows us to monitor both then we end up with two lots of hardware design.
13. When we create a pure reference frequency via our D/A to be output to the transmitter coil, does the interface/amplification electronics use this to control the Current passing through the coil or use this to control the Voltage across the coil or attempt to control them both simultaneously.  Assuming we either control the Current or the Voltage and allow the other to vary with the varying impedance of the target, do we use an input A/D to read back what the other value is.  Note that when there is a target object near the transmit coil the target will take some of the energy from the primary field to create eddy currents from which it then establishes it’s own field, the secondary field.  This all has an effect on the transmit coil and while this type of reading would be difficult to read with older D/As, the current 24 bit D/As may well give useful information.
14. Do the people who create the final analysis software that attempts to characterise the target need to understand the physics principles involved or should we be using a more signature based approach that is independent of any understanding of the cause?
15. A further objective with the design would be to incorporate a test mode where we could make the metal detectors receiver act as a Spectrum Analyser or Digital Storage Oscilloscope etc.  Having these tools has been shown to be handy. e.g. showing why lab results were bad when the testing was being done next to specific EMI emitting machines etc.   A current piece of software that does this is called Baudline which can be downloaded.  Website is   http://www.baudline.com/index.html      This is free software but has restrictions stating that it can't be distributed.  It also states that you can't 'reverse engineer' it but the source code is available and it is designed to run on a Unix platform.  We may be able to get permission to incorporate it into the Humaniser.  Also, there seems to be an older version (Vers 0.99) of this software that distributes under a Gnu license.  It is this older version that the source code is available for.
16. Can we obtain an Open Source Framework to design the project within or do we need to design our own?  Do we need to start with the Framework.  For our framework definition see the Initial Project Section.
17. Will the calculations required for a super advanced demining tool ever be beyond that of a standard PC.  If so, would the calculations performed within Graphics Processor Units (GPU) be useful.  See Wikipedia on use of this technique for Molecular Modeling.
18. Is there any Open Source DSP software already available that would be better to use than just writing our own.  Unless I'm missing something, at the moment, the DSP side looks so simple it just doesn't justify trying to use prewritten software (except for the test module and that is pretty much done by baudline).  If we do need some then hopefully the links at  http://www.dspguru.com/ will give us anything we want.
19. Should we be using SourceForge and how should we be using it.  Similarly, should we be using Google's Project Hosting and if so, how should we be using it. Wikipedia has a comparison of these and other Open Source Hosting facilities.
20. In order to be able to record the raw input from the sound card, we need to use a recording format (referred to as codec) that losslessly handles multiple channels of  24 bit data at rates up to 192khz for current sound cards and possible higher resolution for future sound cards.  One open source one that is defined well for this is FLAC which is described well on Wikipedia.  Another alternative is Wavpac.  A comparison of lossless formats is found at Hydrogenaudio and on the FLAC website.
21. Should we program this as a GStreamer application?  A good summary of a GStreamer application is found on Wikipedia.  If we do program this as a GStreamer application should the output stream from the DSP be considered a separate pipeline to be handled by GStreamer.
22. Related to the GStreamer application is the use of Linux Audio Developer's Simple Plugin API (LADSPA).  Should our modules be LADSPA plugins.  Should we access other components such as accessing the audio card by accessing LADSPA plugins.  Note that LADSPA has no support for data types other than 32bit floating point numbers.  Is this a problem?
23. Shielding:  Should we continue to assume that the coils are shielded from interference from outside Electromagnetic radiation or should we try to counteract the ambient electromagnetic noise by measuring it and reversing it out.   Magnetometers often utilise two transducers with one held above the user to measure the ambient magnetic field so that this can be subtracted from the values being measured by the transducer near the ground.  An additional coil at a height above the Transmit and Receive coils could be used in a similar way for a otherwise standard Induction Balance detector.
24. More questions to come ....