USA Cal Club: Round 2

[CatalinaWOW]

I doubt if anyone here would mind such questions.  I know I don't.  But one of the values of the forum is that you encounter questions you didn't know you had, along with answers to same.  If you message your questions no one else benefits from the learning.  You should not be embarrassed by asking publicly, there are bound to be many others who also do not know the answers to your questions.  You will be in good company.

[bitseeker]

Yes, especially since it sounds like the questions are related to the Cal Club, ask away.

[SirAlucard]

Yes, especially since it sounds like the questions are related to the Cal Club, ask away.

Message Sent.

[bitseeker]

Just so folks aren't left hanging, SirAlucard's questions were regarding test equipment for specific active eBay listings. So, I just replied to his PM.

[SirAlucard]

Just so folks aren't left hanging, SirAlucard's questions were regarding test equipment for specific active eBay listings. So, I just replied to his PM.

Well there goes the mystery. 

Tho it did bring up a question for the club. Would it be possible to add on other references for other ranges? Being able to send around a package that allows people to calibrate their own equipment to each other's. Is that to difficult to do?

[rhb]

Sounds like a fun project and you know full well what's required. Stay away from Practical Machinst, as they'll trash any of the low cost imports, though some have gotten away with it recently. You might find The Home Machinist much friendlier, though the traffic is lower- https://www.chaski.org/homemachinist/index.php

What PM does have is Richard King, who probably knows more about scraping than anybody.

I just abandoned PM.  A request for a good reference on conical hydrodynamic bearings produced nothing but BS.  physicsforums.com provided contact with a Kiwi with a similar background and interests who provided the magic incantation to get google to cough up what I was looking for.  Now I just need to figure out how to get ASME papers and choose a couple of good graduate level textbooks on tribology.

As for Richard King, he condemned me for saying I intended to scrape the cross slide first for use as a template for scraping the saddle and bed. I reached this conclusion independently  of Connelly just from considering the task, though my analysis was confirmed by rereading Connelly this morning.  Richard dismisses Connelly as a "mere votech instructor".  Which is fairly weird given that he makes his living teaching courses in machine tool reconditioning.

While I still consider the title of "machinist" and "mechanic" on a par with PhD, as it takes a similar amount of time and effort to master either, I'm forced to conclude that most of the people claiming those titles are like my PhD  grad school classmate who did not know Snell's law.  But he did get the degree anyway.

"Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world,
The blood-dimmed tide is loosed, and everywhere
The ceremony of innocence is drowned;
The best lack all conviction, while the worst
Are full of passionate intensity."

W. B. Yeats.

The more I fool around on the Internet the more I am impressed by the EEVblog crowd.

Sigh...
Reg


FWIW My mini-lathe arrived broken courtesy of UPS and my spindle test bars were delayed because of stupid shipping.  So I have spent all my time studying the construction other than disassembly and cleaning.  The more I study the design; the more impressed I am.  As received they can do excellent work in skilled hands and with a rather modest amount of work I am confident they can match anything of comparable construction.

[tomato]

What PM does have is Richard King, who probably knows more about scraping than anybody.

I just abandoned PM... As for Richard King, he condemned me for saying I intended to scrape the cross slide first for use as a template for scraping the saddle and bed.

"You're on your own Reg as you seem bent on 'teaching the forum' how to, when you're guessing at it and have never scraped a machine yourself. I was willing to help until your last speech."

-- Richard King

https://www.practicalmachinist.com/vb/machine-reconditioning-scraping-and-inspection/scraping-lathe-limits-mensuration-364598/

[bitseeker]

OK, a little diversion to the topic on occasion is to be expected. I think it's time to get back on track with the Cal Club.

[rhb]

Does anyone have any information about the Tempduino other than cellularmitosis?  I'm next, so I'd like to prepare insofar as possible. Also, what's in the kit?  I got very busy buying test gear and have not followed the discussion closely.  I've got an HP 16500 LA arriving Tuesday.

Can someone link to the message describing the current kit?

Thanks,
Reg

[bitseeker]

Hi Reg. I'll link to the getting started thread as soon as I've finished writing it. One page back, post 339, I collected links to existing info about the main components of the kit, which you can peruse for some familiarity.

[rhb]

That was sufficient information.  I was following the thread closely early on, but then wandered off, even going to go as far as Colorado June 12-22.

Has anyone contacted Jason about the Tempduino source code?  If not, I will, but I don't want to bother Jason if someone has already contacted him about it.

I have several Uno and Mega 256 units, so if I get the source before the kit arrives I can start work on the problem.  The errors look as if it might be an overflow in an averaging routine buffer, but that's only a wild guess.  In any case, whether hardware or software, I'll find the cause and fix it.  That will assuage my sense of guilt for spending all my time buying more test gear rather than helping ;-)

[bitseeker]

I haven't attempted to contact Jason, so no worries about ganging up on him. Please proceed. I concur with your hypothesis of an overflow of some kind due to the regularity of the anomalies. However, I'm not sure what's causing the hysteresis-like behavior in the values unless it's just an error in the accumulation that subsequently leads to the overflow and reset to a new baseline.

No need to feel guilty. We're all doing what we can and I'm sure could all feel guilty about some aspect of our participation. Yet, we've been able to keep this going for a few years now. That's quite an accomplishment.

I'm thankful that you can help out with the Tempduino so that subsequent logging sessions for other members will provide better data than what I was able to collect. I'm happy I was able to improve my logging functionality this time in order to get everything synchronized in one file and record for 24+ hours vs. the single-hour logs I had done in the past. Next round, I look forward to being able to have good temp/humidity data incorporated.

[SirAlucard]

I've contacted him about something else entirely quite a while ago, and haven't heard back. So he may not be around?

[hwj-d]

That's the sensor-breakout. Pickup the datasheets from the sensors.

[rhb]

I just sent Jason a PM.  He's quite busy with work, so only very limited BW for other things.

A buffer overflow will in general  roll over to a different number.  If the temperature is being read in one interrupt routine and averaged and reported in another, a race condition can arise which would exhibit the observed behavior.

There are other possible causes, but that's an obvious possibility.  I suspect it's a very subtle bug and that if you have the right circumstances the bug is not apparent.

If I've not heard from Jason when the kit arrives I'll just write new FW for it.  A bug fix would be quicker than new code, but reading sensors and writing them to the output is not a large program.  Even at the absolutely abysmal state of my programming skills it's a couple of days work.

You know you have not been programming for a *long* time when you don't remember the syntax of your vi abbreviations and editing macros. A best guess is that it is over 4 years since I wrote a significant program.

So, as in all such cases, I'll be a lot slower than I would be if I were working regularly.

[vindoline]

Do we have an up to date list of participants?

Here is the current membership list:

Vgkid
kj7e
martinr33
nikonoid
Svgeesus
bitseeker
Vacuuminded
hwj-d
rhb
RandallMcRee
orin
ArthurDent
edavid
CalMachine
Conrad Hoffman
VintageNut
vindoline
technogeeky
TWMIV
Muxr
SirAlucard
MaxFrister
CatalinaWOW
JBeale
Grandchuck
t1d
VNUTDENYER
KK6IL
Mark03
maxwell3e10

dr.diesel
GEOelectronics
flittle
dr.diesel, flittle and Geoelectronics asked to be skipped this go-around. rhb is up next.

[vindoline]

For the curious, here's the Arduino sketch:

https://gist.github.com/cellularmitosis/4bc0de74b6c3dd03d57ef5ce09c51896

Drop the crc files into the same folder as your Arduino sketch and it should compile correctly in the Arduino IDE.

After I implemented this, I found out about Fletcher's checksum, which is much simpler, and will do just fine for an application like this.  I'll give that a shot for my next project.  https://en.wikipedia.org/wiki/Fletcher%27s_checksum

I believe that this is the Arduino sketch for CM's temperature/humidity data-logger.

[vindoline]

I just sent this message to nikonoid, but I thought I'd echo it here for the benefit of the next recipients.

I've included a little Arduino shield which uses an Si7021 temperature and humidity sensor.

Here's the Python script I use to read the data from the Arduino and log the data in CSV format:

https://gist.github.com/cellularmitosis/421781b4f89636b612378f33d705f8c3

(also attached to this post)

Usage:


The script takes one argument, which is the serial port it should read from.

For example, using this script on linux might look like:

Code: [Select]

./Si7021-logger.py /dev/ttyACM0

The script will print output like so:

Code: [Select]

timestamp,temp_c,humidity
1500422021.565,25.4043,68.5087
1500422022.565,25.4257,68.5239
1500422023.565,25.4150,68.5239
...

That's a timestamp (seconds since the 1970), temperature in celsius, and humidity in percent.

On Linux, your serial port will probably look like /dev/ttyACM0 or /dev/ttyUSB0.  On Mac, it might look like /dev/tty.usbserial-DN02TIYO. 

On Linux, after you plug in the Arduino, you can run the dmesg command to figure out which device name it got associated with.  I don't know of the equivalent of dmesg on Mac, so I just open the Arduino IDE to figure it out.  I'm guessing you can do the same on Windows, but I haven't tried it.

Since the output of the script is in CSV format, you can just redirect the output of the script to a file in order to log to a file, e.g.:

Code: [Select]

./Si7021-logger.py /dev/ttyACM0 > temp-log.csv

If you'd like to watch the output while also logging to a file, you can use the tee command:

Code: [Select]

./Si7021-logger.py /dev/ttyACM0 | tee temp-log.csv

Technical info:


The Arduino spits out 9 bytes of binary at a time: a 32-bit floating point temperature, a 32-bit floating point humidity, and an 8-bit CRC.

The Python script reads in 9 bytes and checks that the CRC is valid.  If it isn't valid, it tries reading another byte until the CRC works, so even if the script starts up in the middle of a 9-byte sequence, the script will recover after throwing away the first reading.

And here is some info on reading the data from the arduino.

[bitseeker]

Well, no wonder why I couldn't find the code. It's not checked in as a project, but as a Gist snippet. Thanks for the link, vindoline.

After looking at the code, this firmware is different than what's on the Tempduino. This firmware uses a fixed-length packed-byte output and the accompanying Python code converts the packed data into CSV (as confirmed by the "Technical info" section of the quoted documentation).

The Tempduino, when it first starts outputting, may send a little garbage followed by a few newline chars (i.e., blank lines) and then a line with the field names as a CSV header. Subsequent lines of output are the values, also in CSV format.

Aha! I think I found it. This one appears to send the expected output and also supports an LCD display, which the Tempduino has.

https://gist.github.com/cellularmitosis/7249b64a3b58010b7955e83dccb60e97

Thanks, vindoline, for pointing me toward Gist. I had previously only searched around the normal Github area.

[bitseeker]

OK, my C is rusty and I don't know the exact behavior of the compiler, but here's a snippet from thermometer.ino (line 27) that is averaging samples from the Si7021 before outputting a result record:

Code: [Select]

void loop() {

  double rh_accumulator = 0;
  double c_accumulator = 0;
  for(uint8_t i=0; i < oversample; i++) {
    rh_accumulator += si7021.getRH();
    c_accumulator += si7021.readTemp();
  }
  float ambient_rh = rh_accumulator / oversample;
  float ambient_c = c_accumulator / oversample;

The oversample variable is 7, so it's not accumulating a lot of samples for the averaging, especially for doubles. I'm not sure how much of an issue assigning the division from a double to a float would cause. You lose precision, but it's not repeated.

Note: If I understood correctly, I believe readTemp() is used here instead of getTemp() because the former uses the value that was acquired at the time that getRH() was called, whereas the latter gets a new sample from the temp sensor.

Then, we have this:

Code: [Select]

  char buf[32];
  char *ptr = buf;

  char t_buf[16];
  dtostrf(ambient_c, 1, 3, t_buf);
 
  char rh_buf[16];
  dtostrf(ambient_rh, 1, 3, rh_buf);

The dtostrf() function expects a double. I'm not sure if it cares that it's getting a float since it only needs to use three decimal places for creating the string.

And then it puts together the rest of the output for the serial port.

Code: [Select]

  ptr += sprintf(ptr, "%s", t_buf);
  ptr += sprintf(ptr, ",%s", rh_buf);
  uint16_t crc = crc16(buf, strlen(buf));
  ptr = csv_append_hex_crc16(crc, ptr);
  Serial.println(buf);

The remainder of the main loop just updates the onboard LCD.

[VNUTDENYER]

Hey CM, not a big deal but was I on list, for last, and that's why not showing??  Just current list last is ok. 

[vindoline]

Hey CM, not a big deal but was I on list, for last, and that's why not showing??  Just current list last is ok.

Sorry about that! List corrected.

-Vindoline

[rhb]

I got a reply from @cellularmitosis and he's going to look for the Tempduino source code tomorrow.

[bitseeker]

Reg, for the source, see my posts starting at https://www.eevblog.com/forum/metrology/usa-cal-club-round-2/msg2521782/#msg2521782

[Kosmic]

OK, my C is rusty and I don't know the exact behavior of the compiler, but here's a snippet from thermometer.ino (line 27) that is averaging samples from the Si7021 before outputting a result record:

Code: [Select]

void loop() {

  double rh_accumulator = 0;
  double c_accumulator = 0;
  for(uint8_t i=0; i < oversample; i++) {
    rh_accumulator += si7021.getRH();
    c_accumulator += si7021.readTemp();
  }
  float ambient_rh = rh_accumulator / oversample;
  float ambient_c = c_accumulator / oversample;

The oversample variable is 7, so it's not accumulating a lot of samples for the averaging, especially for doubles. I'm not sure how much of an issue assigning the division from a double to a float would cause. You lose precision, but it's not repeated.

Note: If I understood correctly, I believe readTemp() is used here instead of getTemp() because the former uses the value that was acquired at the time that getRH() was called, whereas the latter gets a new sample from the temp sensor.

Then, we have this:

Code: [Select]

  char buf[32];
  char *ptr = buf;

  char t_buf[16];
  dtostrf(ambient_c, 1, 3, t_buf);
 
  char rh_buf[16];
  dtostrf(ambient_rh, 1, 3, rh_buf);

The dtostrf() function expects a double. I'm not sure if it cares that it's getting a float since it only needs to use three decimal places for creating the string.

And then it puts together the rest of the output for the serial port.

Code: [Select]

  ptr += sprintf(ptr, "%s", t_buf);
  ptr += sprintf(ptr, ",%s", rh_buf);
  uint16_t crc = crc16(buf, strlen(buf));
  ptr = csv_append_hex_crc16(crc, ptr);
  Serial.println(buf);

The remainder of the main loop just updates the onboard LCD.

Personally I would:

1- validate what si7021.getRH() and si7021.readTemp() return just to not integrate invalid data. Technically you should filter out everything outside a normal reading.
2- char buf[32] is too short. you are printing (worst case) 2 x 16 bytes plus the CRC in the 32 bytes.
3- make sure the reader of the serial port validate the crc and reject the data if the CRC is invalid.