Using tablet PCs for processing data and displaying results

[Atul Asthana]

Neural Networks simplified

The artificial neural networks as the name suggest works similar to our neural network that was present in our brain. If natural neural network was intended to carryout several body related functions, artificial neural network is to carry out the data which even our human brain can’t analyze.

http://electronicsandprojects.com/wp...ralnetwork.doc

[Atul Asthana]

ATtiny45 only: Serial to USB for connecting to tablet PCs

CDC-232

CDC-232 creates a virtual COM port on PC that doesn't have real RS- 232C port. It enables RS-232C communication (without control lines), after connecting the device and installing the driver.


Uses ATtiny45-20

http://www.recursion.jp/avrcdc/cdc-232.html#usage

[Atul Asthana]

Connecting Tablet PC to Microcontroller of Metal Detector : Virtual USB

V-USB is a software-only implementation of a low-speed USB device for Atmel’s AVR® microcontrollers, making it possible to build USB hardware with almost any AVR® microcontroller, not requiring any additional chip.

V-USB can be licensed freely under the GNU General Public License or alternatively under a commercial license.

A comprehensive set of example projects demonstrates the wide range of possible applications.

http://www.obdev.at/products/vusb/index.html

[Atul Asthana]

Android phone used with MD

http://www.geotech1.com/forums/showp...0&postcount=39

<quote>
Android phone interface, and no gold

I now have an Android interface to the detector.
The phone is a Huwaei Ideos ($60), running android 2.1
I talk to it using a bluetooth interface (RN-42), these appear as a serial interface (uart) to your micro. (Less than $20).

So, the Metal detector is connected to the phone via a 114200 bps UART (with all the bluetooth stuff magically taken care of).

</quote>

[golfnut]

This guys on fire..

Throw him a biscuit!

[6666]

This is very good work thanks

[Aziz]

Hi guys,

any updates to this interesting project?

Indeed, I like the µC(detector hardware, data acquisition element) -> uart -> bluetooth -> wireless air -> pc/tablet/pad/phone (processing elements, general user interface)... solution.

It's much better than the USB variant. (USB = Ultra Sucking Bus! Too much work overhead for simple projects. USB isn't the K.I.S.S.-principle and that thing can kiss my *****.)

We don't need any ADC's for signal acquisition. But we can precisely measure the time for a condition/multiple conditons. The idea is already presented in this forum and I must admit, that I like it very much. Unfortunatelly, you guys went to the wrong direction.

Looking forward to see updates.
Aziz

[mario]

Hi Aziz,

I disagree.

With full speed USB 2.0 found in some micros, you can achieve throughputs not possible with wireless. I envision the day some nut interfaces his laptop and detector with an Arduino DUE (not out yet) and a 24bit, 12 channel ADC encoder. To interface with out ADC is a waste of effort, in my humble opinion.

Let's face it, the cellphone cpus will always be faster than our micros. and for processing multi channel, digitized data in real time, even the fastest 400mhz micros will not cut it.

Also, the most hobbyist-friendly wireless chips on the market are still using old WIFI b (not g) tech.

Don't forget, current generation wireless stuff (Bluetooth, even some WIFI) is hacked stuff that relies on USART, which taps out at 112k/second ...which is not very fast.

[Aziz]

Hi Aziz,

I disagree.

With full speed USB 2.0 found in some micros, you can achieve throughputs not possible with wireless. I envision the day some nut interfaces his laptop and detector with an Arduino DUE (not out yet) and a 24bit, 12 channel ADC encoder. To interface with out ADC is a waste of effort, in my humble opinion.

Let's face it, the cellphone cpus will always be faster than our micros. and for processing multi channel, digitized data in real time, even the fastest 400mhz micros will not cut it.

Also, the most hobbyist-friendly wireless chips on the market are still using old WIFI b (not g) tech.

Don't forget, current generation wireless stuff (Bluetooth, even some WIFI) is hacked stuff that relies on USART, which taps out at 112k/second ...which is not very fast.

Hi Mario,

we don't need a big bandwidth for data transfer.
On every PI pulse, only four 16-bit sample values would be enough (see below for more information).
For a 800 PPS PI, this would mean:
800*4*2*(8+1+1) = 64 kbit/s (1 start and 1 stop bit, no parity)

The bluetooth modules are available in different power output classes (0=high, 1=med, 2=low) and versions. They are quite cheap and easy to use (like the FT232 chips). The chinese sell them very very cheap (ebay). And you don't have a cable either. Most platforms support bluetooth interface and you won't have any problems with O/S drivers compared to USB interface. So the detector can talk to any processing element featuring the bluetooth interface.

And we don't need much processing power either. We only have to handle the four sample values.

Now to the sample values:
We can take an advantage of the decay curve: it is monotonically decreasing.
We can measure very precisely the time between fixed voltage transitions (compared against fixed reference voltages v1, .., v4). Four time period measurements (p1, .., p4) using the timer counter on the decay curve would be sufficient enough (see the diagram below). All the information you need is there.

Instead of using the voltage decay curve, one could use the intergration of it (more flexibility, more noise immunity, etc. ) . It would still have a monotonically behaviour (depending on its implemention either increasing or decreasing).

If the UART isn't fast enough, well, the samples can be averaged and decimated to lower the transmission bandwidth. This isn't very much critical.

Well, I find the idea quite good. So good, that I'm going to implement it next year (using ATmega or ATtiny at 20 Mhz). The processing algorithm of the samples can be found easily using special software tools (PC platform using bluetooth interface ).

The implementation of the PI hardware is fairly easy and cheap. Once the algorithm is found, it can be implemented in the µC as well.

Guys, take the right direction now.

Cheers,
Aziz

PS: A faster timer counter (40 MHz or more) would give more precision of course. The faster, the better.

[mario]

Ok, I see where you're going with this.

If you're going to simply process the signal you just need to sample twice the frequency, which shouldn't be that difficult since you are not sampling something that complex.

You might even get ok results using the internal ADC hardware found in the atmega (but not with the attiny!) using minimal additional filtering hardware.

However, if you want to sample the raw audio, which also has some very meaningful data, then you want to sample in the khz range, which is not possible with internal atmega hardware. I don't know what algorithms you have researched, but some people use dedicated DSP hardware for this type of processing.

And as far as Bluetooth is concerned, it's not reliable enough for wireless, stick to the slow, hacked WIFI stuff. It may also be slow, but it is still far more reliable.

From my point of view, interpreting the decay curve is not very meaningful since I'm not concerned with what the target might be. I dig all my targets. Though some who digs relics/coins might be very interested in analysing this decay for discrimination purposes.

[Aziz]

Hi Mario,

you didn't obviously understand the principle. Don't try to demotivate the others.

Hey, we are going to measure the time only (for events). This is what a simple µC can do precisely (x-tal clock sourced). Even the ATtiny's can do it.

The time measurement simply implements an ADC (that's the reason, why we don't need any ADC's). We only need four samples on every each pulse. That's it. Forget the nyquist criteria. We aren't going to make a frequency domain analysis on the samples.

All we need is a fast 16-bit timer counter and an input capture unit, which makes precise time stamps on occuring events (for example: until a voltage level is reached).

Samples can be voltage levels on the decay curve (not recommended) or integration of the decay curve (recommended, requires a gated integrator).

The four samples (timer counter values) will be transferred to a host platform via UART/bluetooth interface for further processing.

The Microchip's dsPIC30F should be better fitted to this application rather than Atmel's AVR's. (The dsPIC30F seem to have a 4 stage UART FIFO buffer and the timers can be clocked faster and it's a 16-bit architecture.)
No doubt, the AVR's ATtiny will do it either. You may need two of them in some circumstances.

Cheers and a happy new year,

Aziz

[Aziz]

Any news guys?

I still like the bluetooth interface idea.

I am currently investigating a convenient µC.
PIC vs AVR?

Well, I personally tend to use the AVR platform as I have everything I need at home.
~20 MHz clock frequency should be high enough.

Aziz

[WM6]

Any news guys?

Aziz

A lot of new things Aziz, but we do no want to share ideas anymore, because of patent troll and ideas hunter like ... you know who.

[Aziz]

A lot of new things Aziz, but we do no want to share ideas anymore, because of patent troll and ideas hunter like ... you know who.

What is your contribution to this idea?

Big mouth?


Be careful.
Aziz

[WM6]

What is your contribution to this idea?

Disclosure of real patent troll and ideas thieves.