Search results for:

LOL, the more I learn, the more I realize how little I know :)

I think many MCU's are very similar. Platform 1 has this amount of memory, that MHz, some digital pins, some analog pins, usarts, i2c's, spi's, etc. and you program it in C/C++. Platform 2 has more or less of each and you program it in C/C++. Espruino has some of all those things too, EXCEPT you get to program it in JavaScript (yes!) and you get to do it interactively (yes!) and that allows options that are not so easy for other platforms. So Expruino offers a niche which might or might not appeal to someone. But I really like having more options :)

Last noob questions: Have you considered using an external 16 or even 24-bit DAC? Would it not provide more accuracy? Would the added complexity make it not worth it? Seems like they can be had for about $3-$6 in quantity 1.

@tage, thanks for the very thorough explanation; makes sense! I am jealous of both your equipment and your knowledge :)

BTW, if you don't get to the extra graphs, no problem. But I really am curious to see if the tossed values would have actually affected the results had they been left in. In other words, I wonder if the equipment is so accurate that there might really only be one or two bad values in those samples, and the sheer number of samples diminishes their contribution.

@JackHoward, just a quick thing you could try. In the code, modify OLED_ADDRESS and see if that makes it work.

@tage, I am trying to understand your graphs. Referring to just the top graph for a sec, does each red dot (reading) represent 100 samples, winnowed down to 80 as you described, then averaged? And you took one such reading, then increased the load by 100mA, and then took another, and so on?

Why do you think the readings of the top two graphs are almost exclusively above the blue line?
Almost seems like there is some accumulated positive error which drives the readings upwards...

Also, why do you think the readings on the bottom graph are often repeated two, three, even four times in a row for successively higher loads? I mean, you are throwing away 20 points, yet the remaining point just happens to be the same for successive readings? My guess is that you are only getting a few distinct readings (maybe 3-4 or fewer?), ie, the readings are pretty tightly grouped. Oh, and those successive readings...are almost exclusively above the blue line!

Thanks!

Oh, btw, I would be interested in a side-by-side comparison graph where no data was thrown out for each of the 3 sample sizes :)

@Espruino_user_dk, I have no experience with these, but they are cheap enough to consider, and I am sure you can find others:
Link1,
Link2
My recent long range topic.

Let us know what you do :)

yeah, sorry, I just realized that and edited my comment, sorry :)

Doh, I get it now, wasn't reading carefully enough and missed the two I2CI.writeTo()'s before the decimal point check, sorry, my bad!

Datasheet says "fast read time < 1mSec", so I am guessing you could theoretically get over 1000 samples per second. Not sure how fast that sort would be though, plus you are doing way more work than needed inside the loop.

function AverageRead(n) {
  var sum = 0;
  for(i=0;i<n; i++){sum += analogRead(A0); }
  var avg = sum/n;
  var vZero = 0.4;
  var tCoeff = 19.5 / 1000;
  var tempinc = (E.getAnalogVRef()*avg - vZero)/tCoeff;
    var tempinf = tempinc * (9 / 5) + 32;
  return { 'C':tempinc, 'F':tempinf};
  }

I know this doesn't throw away the 2 highest/lowest outliers like you were doing, but if you printed them, I bet they wouldn't be far from the average, especially if you are taking so many samples anyhow. But it does allow you to get rid of the big array and the sorting and you could easily do as many samples as you wanted now without eating up so much memory and you could do it just as fast now. But try it both ways and see how far apart the readings are :)

Two thoughts:

if (char != ".") { value += char; }
else { dpLoc = i; }

'data' always has a decimal point?

I2C1.writeTo(a, dpc);
  if(typeof dpLoc !== 'undefined') {
    I2C1.writeTo(a, dplo[dpLoc - 1]);
  }

Finally found it! Try data.charAt(i) instead of data.charAt[i], or simply data[i] :)

Makes much more sense now, thanks! Don't know how I munged that analogRead(), I think I looked at the ref here real quick and saw the 1023 and assumed it was like Arduino LOL. Thanks for the calculator link, very cool.

Thanks! I never considered storing electronics in one of those bins! Very interesting idea and they come in many sizes too...

I see you are using the Steinhart-Hart equation, very nice!
I follow what your code does except could you explain this equation please?

var ohms=10000*val/(1-val);

It seems like there should be a factor of 1023 in there somewhere (see here) and maybe something for the voltage too (see here), but perhaps I just don't understand it all (haven't actually tried it myself yet).

Currently, val is some number between 0 and 1023. Lets see what happens to val/(1-val) for some example values:

val  :: val/(1-val)
5    :: 5/(-4)      == -1.25
100  :: 100/(-99)   == -1.01
300  :: 300/(-299)  =~ -1
500  :: 500/(-499)  =~ -1
1000 :: 1000/(-999) =~ -1

I think you see that something must be wrong here. I am thinking val needs to be normalized to a fraction of 1, ie, something like val/1023.

Also, I am curious how you went about calculating A, B, and C, ie, how did you stabilize and accurately measure the 3 temperature points as well as the 3 resistance values at those temperatures?

Thanks!

gotcha! Thanks :)

Thanks @DrAzzy! I hope to do something like this when I get some time :)

Oh wait! Just one more broken link...search for "LDO regulator".

Hi @DrAzzy, I just found this project, very nice!
Some of your links are gone though; I was wishing to see your updates :)

@tage hiya!
I think your compare function could be shortened to

function CompareForSort(a,b) { return a-b; }

Also, MedianRead() should return the result so that the temperature can then be calculated.

Hi DaveNI! I was curious about the BT Home Hub manager, but I failed on your link...

Bought this last summer, very happy with it -- Hakko

Two minutes ago my jaw dropped when you said tenth place digit; I assumed you meant better than +/- 0.1 degrees centigrade accuracy. Re-reading it, I was hoping you actually meant +/- 1.0 degrees centigrade. The reason my jaw dropped is because the research I had done into this prior to today showed that +/- 0.25 degrees centigrade accuracy was really stretching it. However...

However!

However! You caused me to look again. And here is what I found! And at a VERY reasonable price for the accuracy too. So, I thank you for your question, you helped me to find something I am interested in too.

BTW, did you try any changes to your code?
Is this for an aquarium? 18 is pretty cool for tropicals...

Edit: There are some with different characteristics here, but all +/- 0.1 degree Centigrade accuracy, and some of them are cheaper!

P.S. But for such an accurate sensor, you are going to want more accuracy in your analogRead(), you might want a 16-bit DAC, here are the through-holes I could find, some are reasonably priced.
And here are some 24-bit DACs, they aren't through-hole, but the price isn't too bad. BTW, I've never tried anything like this yet, so it's likely there are things I haven't considered...

Sorry, didn't mean to imply your sensor is bad at all, it just might not be accurate enough to worry about the roundoff error is all I meant. Perhaps 1 or 2 degrees Centigrade is perfect for your application, I have no idea. What is your application? What is your temperature range? What sort of accuracy can you live with?

At first glance, you are overwriting temp each time through the loop, instead of summing it as I think you mean to do. Well-chosen variable names could help you here.

I would recommend that you only sum together your readings in the for loop, then get the average after the loop finishes and then calculate the temp based on the average, as this could avoid some roundoff error, but it may not matter too much because the sensor isn't very accurate.

The analogRead() has 10 bits of accuracy, so it should return a number between 0 and 1023 which I don't see you compensating for.

So I think your calculations would go something like this:

Ravg = Rsum / numSamples // where Ravg is the average of your Readings. Note that Ravg will be a number between 0 and 1023

Vavg = (Ravg * E.getAnalogVRef()) / 1023 // This will be the average reading in Volts

MVavg = Vavg * 1000mV / 1V // convert to millivolts

Tavg = (MVavg - 400mV) * (1 degree Centigrade) / (19.5 mV) // shift the curve downward and convert to centigrade

This would make much more sense on a blackboard as it is just basically calculation by keeping track of units or whatever its called. The code obviously would be simpler since you won't be needing to multiply or divide by 1, etc.

Your Fahrenheit conversion looks fine. No promises that I haven't goofed up somewhere :)
Keep us posted on progress, thanks!

P.S. Google says that one guy factored the internal resistance into his calculations, I don't know if E.getAnalogVRef() does that. If not and you did want to factor that in, you would make a change like this:

Vavg = Ravg * (E.getAnalogVRef() - Vir) / 1023
where Vir is the voltage drop from internal resistance, in volts

P.P.S. I guess they call it the factor-label method of dimensional analysis - LOL!

Here are a few more links:

What is LoRa?
SX1272 Datasheet
Unfortunately that module is $70 USD on Digikey, unlike the $10 ones in the first post or this one from Alibaba.