Raspberry Pi sux-a-lot

[Davor]

My kid wanted a Raspberry for his projects, and there it is. It was not expensive on its own, but I needed to shell extra for VGA adapter, and ... a PSU. The 8Gig micro SD card was there already, so it got a new home.
In my naivety I wrongly guessed that such a small device could not possibly draw more than what little USB phone charger could provide, and ... I was wrong.

It

sux

a

lot

Short story even shorter, I bought a dedicated PSU. Before that we used a large powerbank, the one that charges for many hours, and the little jewel would suck it dry in an hour or so. In no parallel universe shall I ever use it in anything battery powered!!!

Otherwise it is a gem. There is a fully functional Linux on a Noob distro, and it contains a fully functional browser, BlueJ if you care for some Java programming, Libre office, and what not. It works fine with Bluetooth keyboard, connects to a WiFi... a true gem.

But BOY it sux!

[sinclairuser]

hi davor, i agree i have been playing with them for ages now and they are very power hungry, also while there are better boards they either have poor software support or useless drivers, micro board computers are a total lottery.
the new asus board looks promising but if it does not get good software support it will die too.

[Davor]

I'm hopeful. There is also Arduino. Not nearly as powerful but you'd hardly ever need to calculate your tax returns in a spreadsheet while you are detecting.

[Carl-NC]

ST Micro makes inexpensive "Nucleo" eval boards that I believe include Arduino-compatible headers. STM processors pack a lot of bang-for-the-buck and the milliwatt.

[homefire]

Adruino has the Emmmph and more then enough resources for a good detector it's the ADC that sucks and is most slow. You can overclock them up to 20Mhz but still slow. I'm looking at the Chip Computer but there sorta behind production wise. https://www.youtube.com/watch?v=XFmrXJO_-Ns

[Davor]

I've given up on ADC-s of any microcontroller as a front end of a detector. At best you get 10 bits resolution, and usually at some glacial speed. If you treat a microcontroller as a silly VDI, and let some serious muscle do the rest of the job well, you may end up with a decent machine.
But if you insist on squeezing a lemon extra dry, you may extend the bit resolution a little and get an almost good detector. If you observe a good 16 bit ADC, you'll notice it has distortion around -80dB (or usually worse), which is roughly an order of magnitude short for making a serious VLF front end. So good luck with building a low end detector.

[Carl-NC]

The only designs in which I've used the micro ADC are pinpointers, where sensitivity already sucks.

Depending on the ADC design, the midscale point can be distorted either because of the bit transitions (usually only in a parallel output) or because of internal processing errors, like a subrange point. If you offset the signal a small amount away from midscale then small-signal distortion can be much lower. YMMV.

[Skippy]

The micro's internal ADC can be used for battery voltage monitoring, even 8 bits will be adequate there.

[homefire]

LOL Better ways to do that too.

[Skippy]

I wasn't trying to make you laugh, just pointing out the possibility, backed up by the knowledge that commercial machines like the Tek T2/Fisher F75 (and no doubt many,many more) do this.

[Teleno]

ST Micro makes inexpensive "Nucleo" eval boards that I believe include Arduino-compatible headers. STM processors pack a lot of bang-for-the-buck and the milliwatt.

$1.75 a piece with STM32F103C8T6 ARM.



Still needs a $0.60 USB-to-TTL converter for serial programming.


For programming and all technical issues: http://www.stm32duino.com/index.php?...5d75b418507bdf

https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-arduino/32720697607.html?spm=2114.13010608.0.0.iF4NVw
https://www.aliexpress.com/item/Whol...3-35b6a7843071

[Teleno]

I've given up on ADC-s of any microcontroller as a front end of a detector. At best you get 10 bits resolution, and usually at some glacial speed. If you treat a microcontroller as a silly VDI, and let some serious muscle do the rest of the job well, you may end up with a decent machine.
But if you insist on squeezing a lemon extra dry, you may extend the bit resolution a little and get an almost good detector. If you observe a good 16 bit ADC, you'll notice it has distortion around -80dB (or usually worse), which is roughly an order of magnitude short for making a serious VLF front end. So good luck with building a low end detector.

This is how I obtain 14bit resolution from a 10bit ADC (AVR example):

volatile uint32_t rolling_sum = 0;
volatile uint16_t sample_sums[256] = {0};
volatile uint16_t index = 0;
volatile uint16_t analog;
volatile bool adc_ready;

void init (void) {
    /*
    ... Initialize your ADC, timers, I/O ports, etc.
    */
}

int main (void){
   init();
   while(1) {
      adc_ready = false;
      while (!adc_ready);                  // Wailt till the next ADC interrupt is done 
      uint16_t this_analog = analog;       // Working value is now in this_analog
      /*
      ... do your thing here
      */
   }
}

/* ADC interrupt service routine */

ISR (ADC_vect) {
    rolling_sum += ADC;                    // Add newest sample
    rolling_sum -= sample_sums[index];     // Subtract oldest sample
    sample_sums[index] = ADC;              // Remember newest sample
    analog = (uint16_t) (rolling_sum >> 4);// Decimate previosly 256 accumulated 10bit measurements
    index++;                               // Maximum is 255 (8 bit), then goes back to zero.
    adc_ready = true;
} 

It gives you a rolling average with 14bit resolution. Sampling rate at 14 bits is: (frequency of ADC interrupts) / 256.

[Davor]

Your effort is commendable and I'll surely save this code for future use.
However...
14 bits will put your solution on a map only if it is a PI with optimised sampling times so that your ADC doesn't saturate. But it may do just fine.

For VLF it may do only if you sample after motion filters where dynamic span is significantly reduced. But when you reach the motion filtered gain stages, you may simply make two signal paths, one of them amplified, and feed to an ADC through MUX. You simply discard the one that saturates, or the one with too small values, and spare a lot of processing time. That's the solution in ACE and Eagle, and it obviously works.

[Teleno]

Your effort is commendable and I'll surely save this code for future use.

There was a bug in the code, corrected:

volatile uint32_t rolling_sum = 0;
volatile uint16_t sample_sums[256] = {0};
volatile uint8_t index = 0;                 // corrected, must be 8 bit long.
volatile uint16_t analog;
volatile bool adc_ready;

void init (void) {
    /*
    ... Initialize your ADC, timers, I/O ports, etc.
    */
}

int main (void){
   init();
   while(1) {
      adc_ready = false;
      while (!adc_ready);                  // Wailt till the next ADC interrupt is done 
      uint16_t this_analog = analog;       // Working value is now in this_analog
      /*
      ... do your thing here
      */
   }
}

/* ADC interrupt service routine */

ISR (ADC_vect) {
    rolling_sum += ADC;                    // Add newest sample
    rolling_sum -= sample_sums[index];     // Subtract oldest sample
    sample_sums[index] = ADC;              // Remember newest sample
    analog = (uint16_t) (rolling_sum >> 4);// Decimate previosly 256 accumulated 10bit measurements
    index++;                               // Maximum is 255 (8 bit), then goes back to zero.
    adc_ready = true;
} 

At 16MHz clock the interrupt takes about 7us to complete.