Another cool uC platform

[fixstuff]

Hi all,

I'm sure some of you have seen this, but I wanted to bring it up. It just seems like a perfect fit for an metal detector controller platform.

http://mbed.org/platforms/FRDM-K64F/...ical-reference

I like several things in particular about this unit.

1) It has a 16bit ADC with single ended or differential inputs @ 500ns (2Mhz).

2) It has ports for a bluetooth and RF24L01 wireless module, which looks cool as well.

3) The processor is crazy fast (120mhz), and has built in DSP/floating point hardware.

4) It has a lot of memory (1MB flash, 256kb ram) + SDcard on board.

5) Price is good at $30.

6) It comes MBed enabled (or can use Code Warrior with debugger with diff. firmware)

7) Arduino compatible headers (WHY hasn't someone designed an Arduino shield MD IF circuit yet I can buy?!!)

Super low power

Here's my thoughts on this. This seems like a good fit for a detector with 3 of these modules. One located at the control box on the stem, one located on the coil, and one located in the headphones. They could communicate between each other with the RF24L01 modules, and use the Bluetooth module from any for an audio connection to a regular bluetooth headset if you want.

You could use the sd card in the headset for audio samples of tone ID (i.e "gold detected", or "foil detected", or normal tones). Your audio related controls can be adjusted from the headphones.

Each section could control local functionality, and they could talk directly together over the mesh network.

Its $30 each, which isn't too bad considering what your getting, even though that cost would be higher with the bluetooth and RF24L01 modules ($7.5 for BT, and $3 for RF = ~$40).

Its Mbed enabled to boot, so no developer installations if you don't want to (Mbed stuff is really nice IMO

What do you folks think?

[Thomas]

I like it but, the mbed Compiler is only an online application, and it looks like depending on the browser you use that can cause a problem.
Seems like an app. that you could use off line would be much better.
As one commenter said, "what if I don't have Internet access and want to try something new."

[fixstuff]

Yes, it has the offline options if you want to deal with that, thats what the Code Warrior, and some other options are.

[fixstuff]

Mode switching possibility...

Another thing that occured to me with this board. With the embedded accelerometer and magnetometer, you could use that to switch from a discriminate mode to all-metal mode automatically. After 2 seconds of no movement, switch, and after 2 seconds of fast movement, switch back to discriminate mode. Hmm..

[fixstuff]

Anyone interested in collaborating on a detector built around this?

[fixstuff]

Ok. Use the Bluetooth interface to a cell phone.. This would allow cell phone to operate as GUI and supervisory control, and the boards as the local control. Mesh between the boards, and the BT between one board and the cell phone (Android). Use this http://appinventor.mit.edu/explore/ for the cell phone GUI...

[fixstuff]

websockets..

As if there isn't already enough on this board - but -

Speaking of cell phone to board.. Websockets with HTML5 would be another way to interface these boards together..

with an Arduino shield like this:

http://www.robotmesh.com/xbee-shield...FePm7AodrxIAbQ you could add this:

https://www.sparkfun.com/products/10822

which would allow you to do this:

https://mbed.org/cookbook/IOT

This could be a better way to tie into the boards with one of them with this interface for a supervisory controller that doesn't have bluetooth (like a PC or Linux SBC)

[Aziz]

Hi guys,

I wonder, how the ADC values will be presented to the ARM Cortex CPU.
A frame based DMA (direct memory access) interface would be fine.
Let's say, the ADC reads 512 samples (example) into the memory buffer and will rise a DMA interrupt.
That would be really fine instead of reading ADC sample by sample.
Anyone know more?
Aziz

[fixstuff]

Per the data sheet the ADCs route directly into the chip and peripheral I/O is handled with a 16ch DMA. Not sure of the fine print, but per page 41-44, it shows the ADC info. It mentions ADC conversion clock up to 12Mhz. Not sure if conversions can happen that fast though..

http://cache.freescale.com/files/mic...geType=product.

On page 41 there is a link for Freescale's ADC calculator

[Tepco]

In16 bit mode, 461 KSPS in subsequent conversion, single conversion is slower, at max. ADC clock, recommended to be slower, well...

[fixstuff]

Well, I didn't catch that - My eyes went right past it. So @ a 12Mhz ADC clock = 461 Ksps.

That being said, 512 sample averaging would give 898 samples per second. What is a minimum number needed? What is a recommended sample count (64,128,256,512?), and what would be an acceptable final output rate? (100hz, 1khz, higher?)

The chart says the speed shown in with no ADC averaging, and I'm assuming with it, it is slower. Having the ADC averaged before it reaches the processor would offset CPU load, so what would be acceptable numbers here? I'm guessing 32, which would bring the max sample speed to perhaps 14ksps.