Yet Another Gaussmeter

[Steve Conner]

If you'd used another couple of local variables, it would really have been self-documenting.

Elepro has a point though, you're dividing an "int" by 13, what happens exactly?

[B]loop()
{[/B]
   [B] int gauss, ADValue;[/B]

    [B]ADValue = AnalogRead(1) ;[/B]         
    [B]ADValue = ADValue - calibration ;[/B]   
    [B]gauss = (ADValue * 10) / 13 ;[/B] // scale for sensor 1.3 mv/gauss

    [B]lcd.setCursor(1,0) ;[/B]        
   [B] lcd.print(gauss) [/B];          

    [B]delay(250);[/B]                
[B]}[/B]

[-Elepro-]

..... what happens exactly?....

only who know what is inside the library know that

for this reason all the high-level programming languages for PIC (c++,microc,picbasic etc etc) and its library are very useful for speed up and simplify programming but if need be, you have to understand what is inside library and what your language-to-assembler compiler put inside the PIC..... without this it become a solution just for DIYers without any kind of professional use....

[Steve Conner]

No, what happens is defined in the C/C++ standard. Integer division gets truncated:

int x=2;
int y=3;
int answer;

answer = x/y; // answer=1

and the modulo operator gets you the remainder.

answer = x%y; // answer=1 again

I expect you could use floats in there, and the compiler would handle it for you. Hugely wasteful of memory and processing power, but hey, this is the 21st century!

Elepro, you're missing the point, which is what I would expect of an old school ASM head. The whole point of Arduino is that it's mainly for DIYers and not professional use. And even in professional use, nowadays we often squander resources to make the programmer's life easier. For small production runs, the saving in development costs outweighs the extra hardware cost.

I use both ASM and C/C++ at work, and they both have their uses. I can code things in 5 minutes in C++ that would take 5 weeks in assembler. It's like you had a pickaxe before, and now you're driving a 50 ton bulldozer.

I would never use C/C++ on a PIC. There's no free toolset, the non-free compilers suck, and the PIC architecture is a poor fit for C. AVR, AVR32 or ARM only please.

[salvarsan]

If you'd used another couple of local variables, it would really have been self-documenting.

Elepro has a point though, you're dividing an "int" by 13, what happens exactly?

Gentlemen, there are more than a few code wallopers here but only
a small few embedded systems programmers that I can count.

-1. When a microcontroller has limited SRAM, you explicitly avoid a proliferation
of variables since they usually instantiate in the precious SRAM.

0. It's not division by 13 but multiplication by 10 and division by 13. Did no one notice
that the sensor's mv/gauss sensitivity is 1.3? The 'int' you speak of is a 16-bit entity
on the ATmega328 controller, so the use of integer arithmetic is much preferred over
real/floating point for reasons of speed and to avoid executable code bloat.

+1. I posted the code to illustrate the point. That is to say, I dumbed it down
for (your) rapid comprehension and added comments to beat you with a clue stick.
Don't make me smack you with a LART.

+2. The A1302 sensor has a 3% inaccuracy over the full range of +/-1700 gauss.
Briefly reflect that 3% here is about +/-50 gauss. A real number display here is
meaningless and any remainder truncation due to integer division is insignificant.
You want to read +672.33 gauss +/-50 gauss? Very funny, Possum. Like I said,
you want a lot for $51.50.

+3. Unless you calibrate per sensor in the 10-bit converter resolution AND
provide a temperature-compensated power source to the sensor, it simply doesn't
matter. My question to RedHouse about temperate compensation on the AD22141
was serious, not an off-the-cuff quibble.

+4. When Elepro claims a .0000001 % computational accuracy, he is joking you
and assumes you understand that 32-bit floating point truncates around the 7th
significant figure. If you needed the smiley to get it, then you didn't understand.

-drh

[RedHouse]

... How are the AlphaLab gaussmeters done? Stay under $100 and you might have a sale here....

...I wouldn't buy a gaussmeter that doesn't read real numbers, then its not a gaussmeter but only reads relative strength, not gauss. ...

But you already did Dave.

The older AlphaLabs meter you (said you) have, and Jason L has a few too, is simply a 2V digital panel meter module driven by an opamp and scaling resistors (via the switch) and reads the mV/G of the sensor ...roughly.

I don't think you're understanding what's going on here with these PIC's and sensors and what they are displaying, but hang in there it'll become clear as the conversation goes on.

[Steve Conner]

any remainder truncation due to integer division is insignificant.
You want to read +672.33 gauss +/-50 gauss? Very funny

OK, you successfully ran the code walloper gauntlet

I'd just make the point that a decent compiler should optimize out redundant variables, so my code with the changed variable names should compile to the same as your original. But you're right, SRAM is precious, some of these little guys have maybe 256 bytes of the stuff. Not gigabytes, megabytes, even kilobytes :-)

[-Elepro-]

......The A1302 sensor has a 3% inaccuracy.....
When Elepro claims a .0000001 .....

don't think always and uniquely at A1302....
my calibration features allow you to use factory calibrated sensor....
then + or - 0.000001 V/gauss sensitivity calibration accuracy make sense to reduce errors....
for eg if you have 0.400 mV/gauss (0.000400) and 0.401 mV/gauss (0.000401) factory calibrated sensors you can have 15 gauss difference in reading if you can't set sensitivity with that accuracy....
....i have 32bit math in my firmware....

bye

[salvarsan]

wow ... this is the thread of news on gaussmeter world !!!

We are certainly having fun.

but did you use 10bit a/d without any kind of oversample or average? did yo display the result of a single sample? did you use same math for normal and peak hold mode?

Your idea of oversampling to increase resolution is excellent.
For now, I accumulate 1024 samples in a 32-bit long and arithmetic shift
down to 12 bits resolution. Scaling the 12-bit entity into millivolts comes later.

int readSensor(void)
{
   long sum = 0 ;

   for (int i=0 ; i<1024 ; i++)
      sum += AnalogRead(1) ;

   return (int) (sum >> 8) ;
}

In truth, even 10-bit resolution exceeds the accuracy of the A1302 sensor.
7 or 8 bits would be enough.

The AtMega328 ADC is 15k/sec compared to the PIC's 50k/sec so
1024 samples takes longer.

where do the remainder of divide go ?? for eg, if the result is 10.99 it display 10? or in your library there's a self-rounding?

I drop it on the floor and ignore it.
Until there is a cheap easy callibration method, it doesn't matter.

my little suggest is if you want really understand the mcu programming start with use the assembler language.... just with it you can really understand what happend inside the mcu because it is the mcu language.... you will can use c++ later and for most complex firmware.

Very true. I wrote device drivers in x86 assembly for about 7 years before both CPU's and the C-compilers were good
enough. Knowing assembly language makes your C code better which makes your C++/Java/Python code better.

A simple integer odd-to-even converter tells you who understands assembly language
and real time determinism.

   if (x % 2)    // stupid, simple
      x = x + 1 ;

   x += x & 1 ;  // executes in same time whether odd or even

First, we make it work.
Next, we make it go fast.
Last, we make it pretty.

-drh

[RedHouse]

Gentlemen, there are more than a few code wallopers here but only a small few embedded systems programmers that I can count.

I'm neither a code wolloper or an embedded programmer, ...but I stayed at a Holiday Inn Express last night.

...Did no one notice that the sensor's mv/gauss sensitivity is 1.3?...

Yes, and also noticed that the 10-bit ADC in the PIC 16F883 has a minimum resoution of 4.8mV (when Vref is 5V) which means the smallest discernable change is 3.75 Gauss.
(5000mV/1024=4.88)

So as you have said, it is (nearly) pointless to display resolution down to 1-G ...but... it looks good and helps us make decisions about our magnets. Most under $100 DMM's have resolution this low/inaccurate and many of us utilize them daily as a decent reference tool.

Thinking in terms of the 200mV scale of an inexpensive DMM (<$100) the minimum resolution is specified at +/- 1 digit, this would be significant error when measuring 1.3mV but we're (mostly) ok with that for the regular punter.

...The A1302 sensor has a 3% inaccuracy over the full range of +/-1700 gauss. Briefly reflect that 3% here is about +/-50 gauss. A real number display here is meaningless and any remainder truncation due to integer division is insignificant. You want to read +672.33 gauss +/-50 gauss?...

I would interpret that a little differently though, while it's 3% over the entire range I believe it's refering to linearity not absolute reading, IMHO if we calibrate in the region we most expect to use the unit (400-1200G) I believe we can tighten up that +/- 50G quite a bit.

When we did our group-buy A1302 sensors, I took measurements against the "calibrated" meters of Wolfe and Jason using the same 900-G magnet then adjusted the mV/G calibration setting on our meter so it displayed the same reading as the calibrated meters. In my opinion this makes our meters fairly well calibrated in the range we most expect to use them. I wouldn't expect our meters to measure 1 to 200G with precision or at the other end of the sensors range 1700G

...Unless you calibrate per sensor in the 10-bit converter resolution AND provide a temperature-compensated power source to the sensor, it simply doesn't matter. My question to RedHouse about temperate compensation on the AD22141 was serious, not an off-the-cuff quibble...

Not taken that way by me anyway (the quibble thing) as I always appreciate, and enjoy good discussion.

I'm currently ignoring the temperature compensation aspect of the AD22151 that I'm using. The data sheet shows the temperature offset from .00015 to -.0001 through the temperature range of 0°-100°C (32°-212°F) in the context of a gauss meter for pickup magnets this seems less significant issue, but I may be wrong on that.

I have more limited expectations for my meters, I'm good with calibration and use in the temperature range of 18°C-26°C
(65°-80° for those of us who still freeze and sweat to Farenheit)

My shop has heat and A/C so it's never over 75° or under 65°.

[Steve Conner]

A simple integer odd-to-even converter tells you who understands assembly language
and real time determinism.

You're a Real Programmer! That's the kind of trick one of them would pull...
The story of Mel

[RedHouse]

...I would never use C/C++ on a PIC. There's no free toolset, the non-free compilers suck, and the PIC architecture is a poor fit for C. AVR, AVR32 or ARM only please.

You're right in that you can't get a decent compiler ...for free, but I'd have to disagree with the poor fit and suck thing Steve.

The new compilers have significantly reduced the performance gap that strict ASM used to have in PIC programming. Look into the CSS v4.1, or Hi-Tech PICC v8.05, and definately MicroC Pro v3.2, all three of these can compile and produce code nearly as tight as ASM but more importantly the pain-relief factor of not coding in ASM completly outweighs the memory footprint when you can get a PIC 16F886 with 14K memory for a whopping $2.50, or for under $5 you can get an 18F2620 or 18F4620 with 64K program memory.

I'm a realist (with other work to do) so coding in a higher level language is appealing, not the geeky interest in esoteric arguments of compilers and MCU architecture, that's for others.

On another note, I'm selling my Elepro gauss meter over on this thread if anyone wants it.

[-Elepro-]

Used the PIC 16F886 at first then switched to 18F2620 last month.

did you switch to 18f for the program memory size?

[RedHouse]

did you switch to 18f for the program memory size?

More memory, less power, extended instruction set, higher speed, better interrupts, 12 ADC's, and what should be of interest to you is it's backward compatible with the 16F883/886 you like use.

[-Elepro-]

More memory, less power, extended instruction set, higher speed, better interrupts, 12 ADC's, and what should be of interest to you is it's backward compatible with the 16F883/886 you like use.

yes i know it, but with my "poor" assembler gaussmeter firmware i am in the first memory page of 16f883 yet..... instructions and speed ( i use internal at 8mhz) are enough for gaussmeter application.... and i use only 2 channel (2 probe) of ADC.... and difference in power is insignificant.... why change?

maybe the assembler that came out of your compiler filled it with you-don't-know what


bye

[salvarsan]

maybe the assembler that came out of your compiler filled it with you-don't-know what

Oh, it could be much worse!
Years ago, I ported some old firmware to new hardware.

We discovered that the old SRAM initialized to 0xFF on power up,
while the new SRAM defaulted to 0x00. The old firmware relied on it.

Much fun.

-drh